ELBとAuto Scalingのシナリオ判断

この単元で学ぶこと

• 通信条件から入口を選ぶ
• 障害箇所と容量不足を切り分ける
• 増減と状態保持の運用を設計する

本文解説

1. 要件を三つに分ける 通販サイトには「/apiと画像を別の処理へ」「セールで増える利用者へ追従」「1AZ障害でも購入を継続」という要求があります。順にルーティング、伸縮性、可用性の要求です。一つの製品名でまとめず、入口、EC2群、データ保存先のどこが担当するかを書き分けると不足を発見できます。

2. Webと独自プロトコル ホスト名やHTTPパスが判断材料ならALBのルールを使います。店内端末が独自TCPで接続し、相手先が固定IPを許可リストへ登録するならNLBを検討します。「高性能だからNLB」のような抽象的判断ではなく、アプリ層の分岐が必要か、通信の種類と接続制約は何かを確認します。

3. セール開始前の容量 9時に一斉アクセスがあるのに、9時を過ぎてCPUが上がってから増設すると起動待ちが発生します。時刻が分かる分はスケジュールで先に増やし、想定との差はターゲット追跡で補います。最低容量を極端に小さくすると突発増加へ間に合わないため、起動・アプリ初期化の実測時間も計画へ入れます。

4. アプリだけの異常 OSは生きているのにWebプロセスが停止したケースではEC2の正常性だけでは足りません。ALBのアプリ用エンドポイントで検査し、その判定をAuto Scalingの置換にも利用します。ただし全台が共通DB障害を理由に失敗するチェックは置換を繰り返す恐れがあります。何を正常と判定するか、共通依存への影響も設計します。

5. 台数が増えない原因 目標CPUを下げても最大容量が4台なら5台目は作れません。上限、クォータ、起動失敗、サブネットの空きIP、容量調達を確認します。またEC2を増やしてもDBが遅いままならボトルネックは別です。アプリ応答時間、リクエスト数、EC2とDBの負荷を組み合わせて調べます。

6. ログインが消える原因 EC2を追加した直後にログイン状態が消える場合、セッションが1台のローカルメモリーにしかない可能性があります。スティッキー設定で症状が減っても、そのEC2が故障すれば保存内容は失われます。セッションストアの可用性や有効期限を含めて外部化し、EC2の台数と利用者状態を切り離します。

7. 縮小と片AZ障害 注文処理中にEC2を終了すると応答が途切れます。正常な縮小では登録解除後の猶予と終了処理を整え、突然の障害には注文ID等で再送を安全に扱います。片AZを失う訓練では残存EC2数だけでなく、再増設が完了するまでの性能を測定します。常時余力と自動追加のどちらに依存するかが費用との判断点です。

8. 検証結果の読み方 「Auto Scalingを設定済み」では合格判定できません。混雑時に何分で何台増え、エラー率がどう変化したか、アプリ停止時に転送と置換がどう動いたかを記録します。単なる台数の増加と購入完了の回復は別です。最終的には利用者が必要な処理を継続できたかを確認します。

図解

重要ポイント

• パス分岐・伸縮・AZ耐性は別要件として読む
• 既知のピークは事前増設、未知の増加は負荷追跡を組み合わせる
• 設定値だけでなく購入成功率と復旧時間を実測する

間違えやすい点

• 共通DBの障害を全EC2置換だけで直そうとしない
• スティッキー設定を永続的な状態保護と同一視しない
• 最大容量を引き上げるだけで下流の能力も増えるわけではない

用語解説

ボトルネック

全体の性能を制約している箇所。EC2以外にDBや外部APIもなり得る。

登録解除の遅延

ターゲットを外す際に既存の処理へ猶予を与える設定。

残存容量

一部のAZ等を失った後も利用可能な処理能力。

関連教材

• ELBとAuto Scalingを理解する
• RDS Multi-AZとRead Replicaを理解する