ALBが均等に負荷を分散するEC2 Auto Scalingグループで、需要に応じて台数を増減したい。CPUが負荷を反映し、1分の詳細モニタリングと起動後のウォームアップ時間は設定済みである。
最小・最大容量の範囲内で平均CPUを50%付近へ近づける。目標値からのずれを評価するアラームもAWSに管理させたい。常時50%を厳密に保証する要件ではない。
最も適切なポリシーはどれか。
ASGAverageCPUUtilizationを50にしたtarget trackingで平均CPUを目標へ近づけ、容量範囲内で増減する。
詳細解説
スケールアウトだけでは台数の増減の要件を満たさず、目標追跡のアラーム管理とも異なる。
グループ平均CPUを目標に容量を調整し、関連アラームをAuto Scalingが作成・管理する。
容量範囲が固定ならポリシーは台数を増減できない。目標値だけで制限を超えて調整することはない。
時刻による調整だけでは、予測できない実測CPUの変化を目標へ追跡しない。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料で事前定義CPU指標、AWS管理アラーム、ウォームアップ、欠損データと容量の丸めを確認する。
参考にした公式資料
確認できる内容
目標追跡をstep/scheduled scalingと区別し、常時50%が保証されない理由を説明できる。
理解のポイント
- target tracking
- ASGAverageCPUUtilization
- ウォームアップ
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
実測負荷を目標に追跡する
ASGAverageCPUUtilizationはグループの平均CPU使用率である。負荷を均等に分散する構成で、目標を超えたら増やし、余裕があれば段階的に減らす。関連するCloudWatchアラームはAuto Scalingが管理するため手動変更しない。時刻で台数を指定するscheduled scalingとは判断軸が異なる。
調整の限界を運用で確認する
最小・最大容量、インスタンスの整数単位での増減、起動時間により、利用率は目標からずれる。ウォームアップ中の扱いと欠損データによるINSUFFICIENT_DATAを確認する。最大容量に到達してもCPUが高い場合は、ポリシーが必ず50%へ戻すと考えず、容量やアプリ側を調査する。