Auto ScalingとElastic Load Balancingのシナリオ判断

負荷増加、異常な処理先、容量の上限、セッション消失といった事例から、台数調整と負荷分散の問題を切り分けます。仮の数値で希望台数と障害時の能力も確認します。

この単元で学ぶこと

1. 振分けだけでは能力が増えない ELBを追加しても、処理するEC2が一台で限界ならその能力がボトルネックです。ASG等で必要な台数を用意し、ロードバランサーへの登録とアプリの状態を確認します。通信の入口が受けられる量と、業務を処理できる量を分けます。

2. 設定値を読む各EC2一台として最小2、希望4、最大8なら目指すのは4台です。通常の希望容量を6へ変えると現在の4から2台分の増加を目指します。ここでは重み付き容量、置換やリバランスの一時的な増減を除く単純な希望台数として計算します。

3. 上限と需要一台の能力が毎秒50件、需要が毎秒300件なら単純合計では6台分です。しかし希望台数の最大が4なら、その範囲だけで需要を満たせません。設定の上限、資源の割当て、アプリやDBの制約を確認します。計算値は仮の独立処理能力で実測値ではありません。

4. 増強の準備時間キャンペーン開始直後に負荷が上がる場合、新EC2の起動とアプリの初期化まで待つ必要があります。事前に時刻が分かるなら予定に合わせた容量変更を検討できます。反応する設定だけで初期化時間がなくなるわけではありません。

5. 正常性を切り分ける EC2が動いていてもアプリが失敗する場合、ロードバランサーのヘルスチェックとASGが使う正常性判定を確認します。アプリのURLや成功条件が適切か、置換に使うチェックが設定されているかを見ます。振分け停止とEC2置換も同じ処理ではありません。

6. 振分け条件を選ぶ同じドメインの /shop と /admin を別のアプリへ送りたいならALBのパス条件が候補です。任意のUDP通信の分散ならNLBを比較します。単に通信が多いから種類を決めるのではなく、プロトコルと必要な判断条件で選びます。

7. 障害後の余力二AZに各二台、一台50件/秒で通常200件/秒の能力があるとします。一AZ停止後は100件/秒で、需要150件/秒に50件/秒不足します。正常時に足りたことを障害時の達成と取り違えず、残存能力と増強を検討します。

8. 台数変更で失う状態セッションを一台のメモリだけに持つと、その台数を減らしたり置換したりした際に利用者が状態を失う場合があります。外部の適した保存先や接続終了の扱いを設計します。台数変更を費用だけで判断せず、処理途中の仕事やデータの継続を確認します。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。