スケジュールスケーリングと予測スケーリング

動的スケーリングポリシー（ターゲット追跡とステップスケーリング）はリアクティブであり、メトリクスがすでにしきい値を超えた後に対応します。営業時間のピーク、月末のバッチ処理、ブラックフライデーのセールなど、既知で予測可能なトラフィックパターンでは、インスタンスの起動とウォームアップに数分かかるため、リアクティブスケーリングでは遅すぎます。スケジュールスケーリングと予測スケーリングは、負荷が発生する前に容量を先回りして調整することで、この問題に対応します。

スケジュールスケーリングアクションは、指定した日時、または繰り返し実行するcronスケジュールに従って、ASGの最小容量、最大容量、希望容量を変更します。負荷が増加する正確な時刻が分かっている場合に適しています。たとえば、予定されたマーケティングイベントの前に事前ウォームアップを行ったり、トラフィックが最小になる夜間にコスト削減のためスケールダウンしたりできます。スケジュールアクションは、指定時刻に現在の希望容量を上書きします。

スケジュールされたアクションでは、Unix cron形式を使用します: minute hour day-of-month month day-of-week。時刻はすべてUTCです。一般的なパターンとして、スケールアップには0 8 * * 1-5（平日の朝08:00 UTC）、スケールダウンには0 20 * * *（毎晩20:00 UTC）などがあります。同じASGに複数のスケジュールアクションを作成することもできます。たとえば、毎日スケールアップするアクションと、スケールダウンするアクションをそれぞれ1つずつ設定できます。

スケジュールアクションには、一回限り（特定の開始時刻に1回だけ実行）と繰り返し（cronスケジュールに従って実行）があります。一回限りのアクションは、製品リリースなど、将来の予定が決まっているイベントに最適です。繰り返しのアクションは、毎日または毎週のトラフィックサイクルのような定期的なパターンに対応します。また、繰り返しのアクションに開始時刻と終了時刻を設定して、指定した期間内だけスケジュールを自動的に有効化・無効化することもできます。

スケジュールアクションと動的スケーリングポリシーは併用できます。スケジュールアクションは、設定した時刻に新しい基準キャパシティを設定します。その後、動的ポリシー（ターゲット追跡またはステップスケーリング）が、更新された最小値・最大値の範囲内でキャパシティを調整し続けます。たとえば、朝のスケジュールアクションでmin=4、desired=8に設定し、日中は負荷に応じてターゲット追跡が15までスケールアップし、夕方のスケジュールアクションでmin=2、desired=2に戻す、といった動作です。

Predictive Scalingは、CloudWatchメトリクスから過去の負荷パターンを機械学習で分析し、将来必要となるキャパシティを予測します。予測された負荷が到達する前に、通常は5～60分前からスケールアウトアクションを先行してスケジュールします。Predictive Scalingは、毎日または毎週繰り返すトラフィックサイクルのあるワークロードに適しています。より多くのデータを収集するにつれて、予測を継続的に更新します。

ASGにPredictiveScalingポリシーをアタッチすると、Predictive Scalingを有効にできます。指定するのはメトリクスの組み合わせです。つまり、スケーリングの要因となる負荷メトリクス（CPUやALBのリクエスト数など）と、各インスタンスで追跡するスケーリングメトリクスです。AWSは負荷メトリクスを予測し、スケーリングメトリクスを目標値に維持するために必要なインスタンス数を算出します。

Predictive Scalingには2つのモードがあります。ForecastOnlyは、キャパシティを実際には変更せずに予測を生成するため、自動スケーリングを適用する前に予測を確認するのに役立ちます。ForecastAndScaleは、予測を生成するとともに、キャパシティの変更を自動的に適用します。まず数週間ForecastOnlyを使用して精度を検証し、その後ForecastAndScaleに切り替えてください。AWSでは、最初の予測を生成する前に、少なくとも24時間分のメトリクスデータが必要です。

Predictive Scalingはスケールアウトアクションを先行して実行しますが、SchedulingBufferTimeを設定すると、インスタンスをさらに早くウォームアップできます。SchedulingBufferTimeを5分に設定すると、予測によって必要とされる時刻の5分前にキャパシティが追加されます。また、MaxCapacityBufferを設定して、予測された必要量を超えてASGが一定の割合までスケールできるようにすることもできます。これにより、予測誤差に対する余裕を確保できます。

変動するものの予測可能なワークロードには、両方を組み合わせる方法が推奨されます。Predictive Scalingは、予想される周期的な負荷に対応するため、あらかじめキャパシティを配置します。一方、Target Tracking Scalingは、予測を超える予期しない急増に対応します。両者を組み合わせることで、先行対応と事後対応の両方を実現できます。ASGは、両ポリシーによるスケールアウト推奨値のうち、より保守的なものを安全に適用します。

トラフィックの急増が完全に予測可能で、正確な時刻（イベント起因または営業時間に基づくパターン）が分かっている場合は、Scheduled Scalingを使用します。パターンは繰り返すものの正確な時刻が変動する可能性がある場合は、MLがパターンを自動的に学習するPredictive Scalingを使用します。予期しない負荷に備える常時稼働の動的な安全策として、Target Trackingを使用します。負荷が完全にランダムな場合は、ターゲット追跡またはステップスケーリングだけに任せます。SAA-C03試験では、運用効率が最も高い方法を選ばせる問題がよく出題されます。繰り返し発生する周期的なワークロードでは、Predictive Scalingが適しています。

このレッスンで学んだAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

このレッスンでは、Scheduled Scalingがcron式を使用して既知の時刻にASGのキャパシティを変更し、予測可能なイベントや繰り返し発生する営業時間のパターンに適していること、Predictive Scalingが過去のCloudWatchデータを機械学習し、負荷が到達する前に先行してスケールすること、そしてPredictive + Target Trackingを組み合わせることで先行対応と事後対応の両方を実現し、最も回復力の高いスケーリング戦略を構築できることを学びました。次は、制御されたデプロイのためのInstance RefreshとLifecycle Hooksについて説明します。