ELBとAuto Scalingを理解する

この単元で学ぶこと

• 負荷分散と台数調整の責任を説明する
• ALBとNLBを通信要件から選ぶ
• 正常性・状態・容量を含む構成を設計する

本文解説

1. 入口と処理能力 WebサイトにEC2が3台あっても、利用者が1台だけに接続すれば残りの能力を使えません。ロードバランサーは共通の入口として通信を複数の転送先へ分散します。一方、需要が3台の能力を超えたときに台数を増やすのはAuto Scalingです。分散だけで総処理能力が無限に増えるわけではありません。

2. ALBを使う条件 ALBはHTTP/HTTPSのリクエストを扱い、ホスト名やパス等のルールで転送先を選べます。例えば /images は画像サービス、/orders は注文サービスへ分けます。リスナーは受信するポートとプロトコル、ターゲットグループは転送先の集合です。HTTPS終端では証明書やバックエンドへの通信方式も設計します。

3. NLBとの比較 NLBはTCP/UDP等の通信に向き、HTTPのパス分岐を目的とするALBとは判断軸が異なります。独自TCPプロトコルのアプリや固定IPが必要な接続要件ではNLBを検討します。単にアクセスが多いという理由だけで種類を決めず、通信方式、ルーティング条件、IP要件を先に抽出します。

4. グループと起動設定 Auto Scalingグループでは最小容量、希望容量、最大容量と配置先サブネットを定めます。起動テンプレートはAMIやインスタンスタイプ等を提供します。グループをターゲットグループへ関連付けると、追加EC2の登録と終了EC2の登録解除を連動できます。希望容量が2なら、通常その容量を維持するよう管理されます。

5. 増減の指標 ターゲット追跡はCPU使用率やALBのターゲット当たりリクエスト数等を目標に近付けます。台数が増えると1台の負荷が下がる関係が重要です。毎朝9時の既知のピークには事前のスケジュールも役立ちます。新規起動から準備完了まで時間があるため、ウォームアップと最低限の余力を考慮します。

6. 異常の検出と置換 ロードバランサーのヘルスチェックは正常な転送先の判断に使います。アプリが応答不能でもEC2のステータスチェックは通ることがあるため、Auto ScalingでELBヘルスチェックを有効にするとアプリ側の異常判定も置換へ利用できます。準備中を異常扱いし続けないよう、チェック先や起動時の猶予も調整します。

7. 入替えに耐える状態管理 カートの内容をEC2のメモリーだけに保存すると、次の通信が別EC2へ行った場合や置換時に失われます。必要な状態は外部の適切なストアへ保存し、処理ノードを入れ替えやすくします。スケールイン時には登録解除の遅延とアプリの終了処理を合わせ、実行中の処理を突然切り捨てないようにします。

8. 可用性の確認 複数AZへ分散しても、残ったAZの台数がピークを処理できなければ遅延が増えます。最大容量、EC2クォータ、IPアドレス、起動時間、DBの処理能力まで確認します。2AZの各2台から片方を失ったケースを負荷試験し、正常な入口、残存容量、状態保持の三つがそろうか検証します。

図解

重要ポイント

• ALB/NLBは通信を分散し、Auto Scalingは容量を調整する
• EC2とELBのヘルスチェックは検出対象が異なる
• 複数AZ・外部状態・残存容量を組み合わせる

間違えやすい点

• ALBを追加するだけでEC2が自動増加すると思わない
• ELB異常判定が設定なしに必ずAuto Scalingへ使われるとは限らない
• スティッキーセッションだけではEC2故障時の状態消失を防げない

用語解説

希望容量

Auto Scalingグループが維持しようとする容量。最小・最大容量の範囲内で調整する。

ヘルスチェック

定期的に転送先の正常性を確かめる仕組み。アプリの準備状態に合った検査が必要。

ステートレス

個々の処理サーバー内に、次のリクエストが必須とする状態を抱えない構成。

関連教材

• ELBとAuto Scalingのシナリオ判断