Amazon EC2 Auto Scaling

は、アプリケーション負荷と可用性要件に合わせてインスタンス数を維持・増減するサービスです。

SAA では、複数にインスタンスを分散し、障害インスタンスを交換し、需要増減へする構成で選びます。

概要

起動テンプレートとグループ（ASG）を作成し、最小・希望・最大容量を設定します。ASGは希望容量を維持し、スケーリングポリシーに従って台数を変更します。

主要技術

①ヘルスチェックと置き換え ⚠️ 頻出

またはので異常を検出し、インスタンスを終了して新しいものへ置き換えます。アプリケーション状態を外部へ保存し、交換可能にします。

稼働中のインスタンスへ直接パッチや設定変更を当てると、台ごとに構成がずれ (構成ドリフト)、同じ起動テンプレートから作り直しても同じ状態に戻らなくなります。イミュータブルインフラストラクチャでは稼働中のサーバーを変更せず、EC2 Image Builder などで変更済みのを作り、起動テンプレートの新しいバージョンを指定してインスタンスの更新 (instance refresh) を実行し、最小限の正常な割合を保ちながら古いインスタンスを順に新しいものへ置き換えます。

②マルチAZ

1つのASGを複数のへ関連付け、容量を分散します。単一AZ障害時には、利用可能なAZへ容量を補います。

ただし、障害後の補充は新しいインスタンスの起動を待つため、その間は容量が減ります。1 つの AZ を失っても必要な台数を下回らないよう、残りの AZ だけで必要量をまかなえる台数を最初から配置しておく設計を静的安定性と呼びます。たとえば必要な台数が 6 台なら、3 つの AZ に 3 台ずつ置けば、1 つの AZ を失っても 6 台が残ります。

③スケーリングポリシー

方式	用途
ターゲット追跡	やリクエスト数を目標値へ維持します。
ステップスケーリング	の超過幅に応じて増減します。
スケジュール	予測可能な時間帯に容量を変更します。
予測スケーリング	過去パターンから必要容量を準備します。

ターゲット追跡は、指定したを目標値に保つよう必要な台数をが計算し、アラームも自動で作ります。増減幅を自分で設計する必要がないため、AWSも平均CPU使用率やターゲットあたりのリクエスト数での伸縮にはターゲット追跡を推奨しています。ステップスケーリングは、アラームの超過幅ごとに増減量を段階として定義し、スケーリングの途中でも追加の超過に応じて増やし続けます。シンプルスケーリングは1つのアラームに増減量を1つだけ持ち、調整のたびにクールダウンを待つ古い方式です。

販売開始の時刻のように集中する時刻が事前に分かる負荷はスケジュールで最小容量を先に引き上げ、それ以外の予測できない増減はターゲット追跡に任せるというように、方式は同じグループで併用できます。予測スケーリングは日次や週次の周期を学習する方式で、不定期の催しの集中は過去の傾向から予測できません。

起動に時間がかかるアプリケーションでは、ウォームプールで初期化を済ませたインスタンスを停止状態 (または休止状態) で待機させると、時にすぐ組み込めます。停止中はボリュームなどの料金だけで済みます。ミドルウェアを導入済みのから起動して、ユーザーデータでの導入を減らすことも起動時間の短縮に効きます。

指定したの空き容量がに足りないと、起動は InsufficientInstanceCapacity で失敗します。混合インスタンスポリシーで同等の性能の複数タイプを指定すると空きのあるタイプで起動でき、台数と日時が事前に分かっているならキャパシティー予約で容量を先に確保できます。を超えたときの InstanceLimitExceeded とは原因が異なります。

④ELBとライフサイクル

と連携し、正常なインスタンスへトラフィックを分散します。ライフサイクルフックで起動時の初期化や終了前のデータ退避を実行できます。

試験対策

「障害を自動交換」「負荷に応じて台数増減」「複数」はASG + です。ASGはデータを複製しないため、セッションやファイルをインスタンスローカルだけに置きません。