Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

第25回 Cloudn(クラウド・エヌ)勉強会 「Load Balancing Advanced アップデートのご紹介」

1,422 views

Published on

2015年8月6日に開催しました、第25回 Cloudn(クラウド・エヌ)勉強会の内容です。ロードバランサ(LBA)のアクセスログをLoggingサービスで閲覧できるようになりました!また、継続的に改善されているLBAの機能や使い勝手についてご紹介します。

Published in: Technology
  • Be the first to comment

第25回 Cloudn(クラウド・エヌ)勉強会 「Load Balancing Advanced アップデートのご紹介」

  1. 1. Load Balancing Advanced アップデートのご紹介 2015/8/6 NTTコミュニケーションズ
  2. 2. もくじ • おさらい “LBA とは?” • 新機能① 「ログ提供機能」 • 新機能② 「チューニング項目の追加」 • その他の改善点
  3. 3. もくじ • おさらい “LBA とは?” • 新機能① 「ログ提供機能」 • 新機能② 「チューニング項目の追加」 • その他の改善点
  4. 4. Q. Load Balancing Advanced (LBA) とは? A. Cloudn Compute (仮想マシン)に トラフィックを分散する 仮想ロードバランササービス
  5. 5. 仮想ロードバランサ より正確には…… 仮想マシン上で動作する ソフトウェアロードバランサ (の集合体)
  6. 6. ソフトウェアロードバランサが動作する 仮想マシン1台 “LBAインスタンス”
  7. 7. LBAインスタンス1台以上で構成される 仮想ロードバランササービス “LBA” 1台のロードバランサのように振る舞う
  8. 8. 通常はLBAインスタンスは1つ 負荷分散先 Compute LBA インスタンス エンドユーザ リクエスト 実体は仮想マシン → 箱モノLBのような スループットには 到底及ばない
  9. 9. 負荷分散先 Compute LBA インスタンス 負荷に応じて増加/減少する (自動スケールアウト/イン) LBAとしての 帯域・処理能力 UP!!!
  10. 10. Q. どうやって複数のLBAインスタンスに リクエストを分散させているの? A. “DNSラウンドロビン “で分散します!
  11. 11. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ test-lba.cloudn-service.com のIPアドレスは? (名前解決 1回目)
  12. 12. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ 1.1.1.1 2.2.2.2 3.3.3.3
  13. 13. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ おっしゃ!一番上の 1.1.1.1 にアクセスや!
  14. 14. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ test-lba.cloudn-service.com のIPアドレスは? (名前解決 2回目)
  15. 15. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ 2.2.2.2 3.3.3.3 1.1.1.1 (IPアドレスリスト の順番を変える)
  16. 16. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ おっしゃ!一番上の 2.2.2.2 にアクセスや!
  17. 17. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ test-lba.cloudn-service.com のIPアドレスは? (名前解決 3回目)
  18. 18. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ 3.3.3.3 1.1.1.1 2.2.2.2 (IPアドレスリスト の順番を変える)
  19. 19. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ おっしゃ!一番上の 3.3.3.3 にアクセスや!
  20. 20. DNSラウンドロビン DNS名: test-lba.cloudn-service.com LBA(3つのLBAインスタンスで構成) 1.1.1.1 LBA インスタンス 2.2.2.2 3.3.3.3IP: Cloudn DNSエンドユーザ 見事にリクエストが 分散!
  21. 21. 以上が、LBAの簡単な説明ですが…… 「ロードバランサなんて大げさなもの、 自分には必要ないかな」 なんて、思ってはいませんか?
  22. 22. 確かに、検証で少し仮想マシンを 利用する程度であればいらないかも…… 少しでもサービス断(可用性)が問題となる場合、 LBAのご利用をお勧めします! 逆に言うと
  23. 23. LBAを利用することで、格段に • 高い可用性を持つ • スケールしやすい アーキテクチャのシステムを 構築できます!
  24. 24. しかも驚くほどカンタンで安い!
  25. 25. 1つずつお話します
  26. 26. “ 高い可用性 ”
  27. 27. ここで残念なお知らせ クラウドでも 故障が発生することがあります。
  28. 28. あなたのサービスを最後に守るのは 他ならぬ、あなたです 泣かないためのアーキテクチャを LBAで作りましょう
  29. 29. 1台より2台 負荷分散先 Compute LBA 同じComputeを2台用意
  30. 30. 1台より2台 負荷分散先 Compute LBA 片方が壊れても・・・ DOWN
  31. 31. 1台より2台 負荷分散先 Compute LBA DOWN LBAが自動的に検知して 振り分けなくなるので大丈夫! 片方落ちとる やんけ (ヘルスチェック)
  32. 32. 1台より2台 負荷分散先 Compute LBA 復活 復活した場合は 自動で振り分け先に復帰 お、復活した やんけ
  33. 33. 1Zoneより2Zone LBA Zone A Zone B 負荷分散先 Compute DNSラウンドロビン Computeを各Zoneに用意
  34. 34. 1Zoneより2Zone LBA Zone A Zone B 負荷分散先 Compute DNSラウンドロビン 片Zoneが壊れても・・・
  35. 35. 1Zoneより2Zone LBA Zone A Zone B 負荷分散先 Compute DNSラウンドロビン 故障Zoneへの振り分けを 停止するので大丈夫! (故障LBAインスタンスのDNS登録を自動削除) 外形監視システム ①検知 ②登録削除 ③Zone AのIPアドレス しか返さない
  36. 36. “ スケールしやすい ”
  37. 37. サービス利用が増えた場合、 負荷分散先 Compute LBA • 利用者増 • 繁忙期 etc.
  38. 38. そのままComputeを追加登録 負荷分散先 Compute LBA サービス断なしでスケールアウト可能
  39. 39. 不要になれば登録解除 負荷分散先 Compute LBA スケールインもサービス断なし
  40. 40. メンテナンスにも活躍 負荷分散先 Compute LBA 片方ずつメンテ、アップデート
  41. 41. 運用開始後にアーキテクチャを 変更するのは大変です ぜひ設計段階でLBAの検討を!
  42. 42. “ カンタン ”
  43. 43. ポータルからLBAの画面を開き、 選択
  44. 44. LBAを新規作成し、 クリック 名前を付けて、
  45. 45. LBAにComputeを登録 “登録”を クリック リストから登録したい Computeを選択して、
  46. 46. これだけの操作で LBA Zone A Zone B 負荷分散先 Compute DNSラウンドロビン もう上の構成にできます
  47. 47. “ 安い”
  48. 48. 気になるお値段 Month ¥1,000 500 ・・・ ~ 安い!明瞭会計!
  49. 49. さらにLBAをオススメする理由 お客様の声(と担当者の愛)によって どんどん改善されています!
  50. 50. もくじ • おさらい “LBA とは?” • 新機能① 「ログ提供機能」 • 新機能② 「チューニング項目の追加」 • その他の改善点
  51. 51. LBAのアクセスログやヘルスチェックログが Cloudn Logging で閲覧可能になりました [info] 10.0.1.2:54873 [19/Jun/2015:16:28:33.983] 192.168.10.10:80 192.168.10.10:80_instances/192.168.10.101:80 1/0/1126/2/1129 200 443 - - ---- 300/300/299/74/0 0/0 "GET /index.html HTTP/1.0" Cloudn Logging ロギングサーバ ログ 転送
  52. 52. ログが閲覧できるメリット • アクセス(利用)状況を簡単に可視化 • トラブル時、すぐに自分で解析や対処可能 原因特定も楽に(クライアント? or LBA? or Compute?) • L4ロードバランスにおいても、LBAで NATされる前の接続元IPアドレスが分かる (L7では既に“X-Forwarded-For”ヘッダで把握可能) • リクエスト処理時間 → リソース設計、システムチューニング
  53. 53. 解析に必要なマニュアルも用意
  54. 54. 転送先のロギングサーバを LBAの画面から選択するだけで……
  55. 55. ※2015/8/6時点では、東西FLATのみ (VPCでは近日中に提供予定) Logging (Kibana)で グラフィカルに表示、分析!
  56. 56. もくじ • おさらい “LBA とは?” • 新機能① 「ログ提供機能」 • 新機能② 「チューニング項目の追加」 • その他の改善点
  57. 57. クライアントとLBA、LBAとComputeの 通信におけるタイムアウト値が 細かく設定可能になりました クライアント (エンドユーザ) LBA Compute NEW!!! NEW!!!
  58. 58. 今まで クライアント (エンドユーザ) LBA Compute Computeでリクエストの処理に 時間がかかってしまうと…… レスポンスを生成中…
  59. 59. 今まで クライアント (エンドユーザ) LBA Compute LBAがタイムアウトと判断して エラーを返してしまう ちょ、待てよ! ERROR 5秒待ったが、レスポンス 返ってこんかったわ タイムアウト 発動
  60. 60. 改善後 お客様のシステムに合わせて 適切なタイムアウト値が設定可能に クライアント (エンドユーザ) LBA Compute 60秒まで待つように設定! より多様なシステムに LBAを適用できるようになった!
  61. 61. 画面から簡単設定 クリック 値を入れて
  62. 62. もくじ • おさらい “LBA とは?” • 新機能① 「ログ提供機能」 • 新機能② 「チューニング項目の追加」 • その他の改善点
  63. 63. ①自動スケールアウト仕様改善 自動スケールアウトで増加した LBAインスタンスは、 負荷が完全に落ち着くまで消さないように
  64. 64. 今まで 負荷 時間 スケール アウト閾値 負荷が閾値を超えると……
  65. 65. 今まで 負荷 時間 スケール アウト閾値 スケールアウト
  66. 66. 今まで 負荷 時間 スケール アウト閾値 負荷が閾値を下回ると……
  67. 67. 今まで 負荷 時間 スケール アウト閾値 すぐにスケールイン
  68. 68. 今まで 負荷 時間 スケール アウト閾値 負荷がバタついて再び閾値を超えると……
  69. 69. 今まで 負荷 時間 スケール アウト閾値 また慌ててスケールアウト
  70. 70. 今まで 負荷 時間 スケール アウト閾値 また慌ててスケールアウト スケールアウトには時間がかかる → 負荷に対して処理能力が 不足する状態が続いてしまう *LBAの複製機能はあるので、急な変化が発生 することがあらかじめ予見できる場合は
  71. 71. 今まで 負荷 時間 スケール アウト閾値 また慌ててスケールアウト 長いスパンで見ると負荷は継続していた → そもそもスケールインすべきではなかった
  72. 72. 改善後 負荷 時間 スケール アウト閾値 負荷が閾値を超えると……
  73. 73. 改善後 負荷 時間 スケール アウト閾値 スケールアウト
  74. 74. 改善後 負荷 時間 スケール アウト閾値 負荷が閾値を下回ると……
  75. 75. 改善後 負荷 時間 スケール アウト閾値 スケールアウトしたまま ついさっきまで負荷が高かったから 念のためこのままでいよう
  76. 76. 改善後 負荷 時間 スケール アウト閾値 スケールイン 負荷が閾値をしばらく下回り続ける → 負荷が落ち着いたと判断
  77. 77. 改善後 負荷 時間 スケール アウト閾値 スケールイン 負荷が落ち着いたので 役目は終わったね
  78. 78. 改善後 負荷 時間 スケール アウト閾値 負荷が激しく増減するような状態であっても 常にスケールアウトした状態で乗り切れるように! しかも自動スケールアウトで作成される LBAインスタンスは無料
  79. 79. 改善後 負荷 時間 スケール アウト閾値 負荷が激しく増減するような状態であっても 常にスケールアウトした状態で乗り切れるように! しかも自動スケールアウトで作成される LBAインスタンスは無料
  80. 80. ②アクセス制限が可能に LBAに対するアクセス元を CIDRで制限可能になりました 【受信許可】 Protocol: TCP Port: 8080 CIDR: 192.168.10.0/24 192.168.10.xxx 192.168.11.xxx
  81. 81. 今まで 【受信許可】 Protocol: TCP Port: 8080 CIDR: 0.0.0.0/0 x.x.x.x y.y.y.y LBAのポートにはどこからでも アクセスできるように 設定しなければならなかった 必ず 0.0.0.0/0 を指定
  82. 82. なぜ? 【受信許可】 Protocol: TCP Port: 8080 CIDR: 0.0.0.0/0 弊社の監視(ヘルスチェック)で 各ポートを外形監視していたため、 CIDRでアクセスを制限すると監視に失敗 監視 z.z.z.z
  83. 83. 言い訳 そもそもLBAは 不特定多数からのアクセスを想定 どこからでもアクセス可能なように 設定されているという前提があった
  84. 84. 言い訳 しかし、実際にサービスしてみると アクセス元を制限して内部的にLBAを 利用したいというお客様も多かった 今回、一念発起の改善に至る
  85. 85. 改善後 弊社ヘルスチェック方式を改善し、 80, 443 番ポート以外では CIDRによるアクセス制限が可能 【受信許可】 Protocol: TCP Port: 8080 CIDR: 192.168.10.0/24 192.168.10.xxx 192.168.11.xxx ※2015/8/6時点では、まだ東日本FLATのみ
  86. 86. ③ソフトウェア最新化 LBAインスタンスを構成するソフトウェアは 継続的にアップデートされています! Linux Load Balance SSL Logging
  87. 87. ③ソフトウェア最新化 何より、新しいものを使うのは気持ちがいい! (もし自分でやろうとすると、結構大変です) なぜ必要? 脆弱性対応 Bug Fix パフォーマンス 向上
  88. 88. ④Cloudn CDN 連携 Cloudn CDN と連携した場合であっても 正しく負荷分散できるようになりました Compute (オリジンサーバ) LBA CDN (キャッシュサーバ) Zone A Zone B
  89. 89. CDN + LBA の動き Compute (CDNオリジンサーバ) CDN (キャッシュサーバ) キャッシュしていないコンテンツは オリジンサーバからダウンロード
  90. 90. 今まで Compute (CDNオリジンサーバ) CDN (キャッシュサーバ) 1つのLBAインスタンスに リクエストが偏ってしまう!
  91. 91. なぜ? CDN LBA アクセス元は不特定多数だから、 LBAインスタンスへの負荷分散は DNSラウンドロビンで問題無し! 最初だけ名前解決してコンテンツ 取得できたらOKでしょ。 DNSラウンドロビン?何それ? … お互いに組み合わせて利用されることを 想定していなかった
  92. 92. 改善後 Compute (CDNオリジンサーバ) CDN (キャッシュサーバ) キャッシュサーバが均等に リクエストを振り分け! これは… DNSラウンドロビン!
  93. 93. 最後に、本日の話をまとめます!
  94. 94. まとめ • LBAを利用することで…… スケールしやすく冗長性のあるシステム を簡単かつ安価に構築できます • LBAはお客様の声を取り入れた機能追加や 継続的な改善を大切にしています • ご利用をお待ちしております!

×