Auto Scaling は、ワークロードの変化に応じて Elastic Compute Service (ECS) インスタンスおよびエラスティックコンテナインスタンスの数を自動的に調整し、手動での介入を最小限に抑えます。このページでは、4 つの一般的なシナリオを紹介し、お客様の状況に最適なスケーリング手法を特定するお手伝いをします。
予測不可能なトラフィックスパイクへの対応
課題： ニュースサイトでは、速報ニュースが発生するとページビューが急増し、ニュースの注目度が薄れると同時にトラフィックも減少します。このようなトラフィックスパイクは事前に予測できないため、インスタンス数を手動で調整するのは非現実的かつミスが発生しやすくなります。
ソリューション： CPU 使用率などのメトリックをモニターする監視タスクを作成します。Auto Scaling はモニタリング結果に基づき、自動的に応答します。
代表的な構成は次のとおりです。
簡易スケーリングルール（2 つのタスク）： CPU 使用率が 70% 以上になった場合、スケーリンググループにインスタンスを 3 台追加します。使用率が 30% を下回った場合は、インスタンスを 3 台削除します。
ターゲットトラッキングスケーリングルール（1 つのタスク）： CPU 使用率の目標値を 50% に設定します。Auto Scaling はその目標値を維持するようにインスタンス数を自動調整します。
予測可能なトラフィックパターンへの対応
課題： ゲーム会社では、毎日 18:00 から 22:00 の間に需要が一貫して急増します。ピーク時間前に手動でスケールアップし、その後スケールダウンするのは繰り返し作業であり、忘れてしまう可能性があります。
ソリューション： 毎日決まった時刻にインスタンスを追加またはリリースする定期タスクを作成します。
構成例：
17:55 に定期タスクがトリガーされ、簡易スケーリングルールによりインスタンスを 3 台追加します。これにより、18:00 からのピーク時間に備えてウォームアップ時間を確保できます。
22:05 に別の定期タスクがトリガーされ、ピーク時間終了後に上記 3 台のインスタンスを削除する簡易スケーリングルールを実行します。
これにより、トラフィックが到着するタイミングで必要なキャパシティを確保し、不要になった時点で即座にリリースできるため、夜間のアイドルインスタンスを回避できます。
安定したワークロードにおける高可用性の維持
課題： 通信会社では、明確なトラフィック変動のない安定したワークロードを運用していますが、インスタンスが予期せず障害を起こした場合、チームがそれをタイムリーにキャッチできず、サービス中断が発生する可能性があります。
ソリューション： スケーリンググループでヘルスチェックを有効化します。Auto Scaling はインスタンスの健全性を継続的にモニターし、異常なインスタンスを検出した際に自動的に置き換え用のインスタンスを作成し、サービスの継続稼働を保証します。
スケーリンググループにインスタンスの最小数を設定してください。Auto Scaling はグループ内のインスタンス数がその最小値を下回らないように制御し、可用性のベースラインを保証します。
複合的かつ複雑なトラフィックパターンへの対応
課題： ある企業では日々安定したトラフィックを処理していますが、時折需要の急増が発生します。すでにサブスクリプションインスタンスを保有しており、既存のインスタンス群を置き換えるのではなく、負荷が増加した場合にのみ追加キャパシティが必要です。
ソリューション： サブスクリプションインスタンスをスケーリンググループに手動で追加し、CPU 使用率をモニターしてそれに応じてスケーリングする監視タスクを設定します。Auto Scaling はサブスクリプションインスタンスを常に実行状態に保ち、必要に応じて追加インスタンスのみを追加または削除します。
より複雑な要件に対応するには、複数の機能を同時に組み合わせて使用します。
予測可能なピーク期間向けの定期タスク
予測外のスパイク向けの監視タスク
継続的な可用性を確保するヘルスチェック
これらの機能を組み合わせることで、幅広いトラフィック条件に対応しながら、コストと手動作業を最小限に抑えることができます。