お昼休みの開始直後や、始業直後。決まった時刻に決まってアプリケーションが重くなる…⋯。そんな経験はありませんか？
負荷がかかってから慌てて増やす（ステップスケーリング）のも手ですが、それでは間に合わずにユーザーを待たせてしまうこともあります。
私は模擬試験で「毎日12:00 〜 13:30のピークをどうさばくか？」と問われ、「ターゲットグループをいじればいいのかな？」と迷って不正解。正解は、「あらかじめ増えることがわかっているなら、時間を指定して増やしておく」という攻めの戦略、スケジュールドスケーリングでした。
「予測できる敵」には先手を打つ
今回の解決策の核となるのが、Auto Scalingグループの「スケジュールされたアクション」です。
ECSでECインスタンスを使っている場合、以下の3つの要素を連携させて「12時前に自動でサーバーを増強し、13時半に自動で戻す」仕組みを作ります。
１．Auto Acalingグループ：EC2インスタンスの「数」を管理。
２．スケジュールドスケーリングポリシー：「何時に何台にするか」のスケジュールを定義。
３．キャパシティープロバイダー：ECSが「このAuto Scalingグループを使っていいよ」と許可するための橋渡し役。
構築のポイント：ALBとヘルスチェック
試験で特に引っかかりやすいのが、「どこに何をアタッチするか」という順序です。
- ALBターゲットグループは「Auto Scalingグループ」に構成する
ECSクラスターではなく、Auto Scalingグループに構成するのが正解です。 - ELBヘルスチェックを有効にする
これを有効にすることで、もしインスタンスが不調になっても自動で入れ替えてくれるようになり、可用性が高まります。
スケジュール設定のメリット
「負荷を見てから増やす（ステップスケーリング）」ではなく、スケジュール設定（cron式など）を使うメリットは絶大です。
- ウォームアップ不要
ピークが始まる「前」に増やしておけるので、12:00ジャストに100%のパワーを発揮できます。 - コストの最適化
13:30のピーク終了に合わせて確実に台数を減らせるので、無駄な料金が発生しません。
試験で役立つ！キーワード判別法
ECSやAuto Scalingの問題で、以下のフレーズがあればこの構成が正解です！
- 「特定の時間帯（12:00 〜 13:00など）に動作が遅くなる」
- 「ピークの時間帯が予測可能である」
- 「キャパシティープロバイダー」
- 「スケジュールされたスケーリングポリシー」
今回の学び：攻略の格言
「決まった時間に待ち伏せろ！Auto Scalingにスケジュールを仕込み、キャパシティープロバイダーでECSに繋げ！」
あとがき：一歩ずつ、合格へ
最後まで読んでいただき、ありがとうございました！
今回の構成は、設定項目が多くて一見複雑に見えますが、「サーバーを増やす時間割を作る」と考えれば非常にシンプルです。
私は最初、ECS単体でなんとかしようとしていましたが、土台となる「EC2（Auto Scaling）」をしっかり制御することが、結局は安定したコンテナ運用に繋がるのだと痛感しました。
それでは、次回の記事でお会いしましょう！
