ECS Auto Scalingでスケジュールスケーリングとステップスケーリングを併用したときの注意点

Posted at 2025-09-15

はじめに

AWS案件に参画して遭遇したトラブルを備忘録としてまとめたいと思います。
ECS (Fargate) を利用しているプロジェクトで、
「スケジュールスケーリング」と「ステップスケーリング」を同時に設定した際に競合する問題に直面しました。

最初は「時間帯でタスク数を決めたいし、負荷に応じても増減したい」というシンプルな考えでしたが、実際に設定してみると「固定値の指示」と「負荷応答の指示」がぶつかってしまい、想定どおりに動作しませんでした。

これらを同時に設定した場合、例えばこんな競合が起きます：

結果、挙動が安定しないことが分かりました。

AWS公式ドキュメントにも以下の記載があります。

「スケジュールされたスケーリングを使用すると、スケーリング調整ポリシーとスケーリング調整アクションの両方のメリットを得ることができます。…スケジュールされたスケーリングアクションとスケーリングポリシーの両方を使用すると、アプリケーションの最小タスク数と最大タスク数の範囲内で調整が行われます。」

つまり「範囲をはみ出す設定はできない」という制約があるわけです。

AWSサポートや公式ガイドを確認した結果、次の方法が推奨されてると思いました。

EventBridgeScheduler を用いて、時間帯ごとに MinCapacity と desiredCount を切り替え
その範囲内でステップスケーリングを適用することで競合を回避
この考え方を適用すると、Scheduler が「土台（最低ライン）」を作り、その上でステップスケーリングが「負荷応答」を担う、という役割分担ができます。

公式ドキュメントにも以下の記載があります。

「各スケーラブルターゲットには、最小容量と最大容量もあります。スケーリングポリシーが、最小容量から最大容量までの範囲を超える、または下回ることはありません。」

これにより「ピーク時は必ず16台以上を維持し、それ以上はCPU負荷に応じて拡張」という挙動を実現できます。

Scheduler単体だと弱い
- 「詳細なログが残らない」「柔軟な条件分岐ができない」というデメリットがある
- 将来的に監査や高度な制御が必要になる場合は Lambda を併用すべきだと感じました
チーム内での認識合わせが重要
- 自分は最初「スケジュールとステップを両方設定すれば便利じゃん」と思っていましたが、
  実際には仕組みの仕様で競合が発生するので、ちゃんとエビデンスをもとに説明する必要がありました
実務を通じて理解が深まった
- 試験勉強では触れなかった「スケーリングの優先度」や「範囲設定の制約」を、実際の現場でトラブルシュートしたことで腹落ちしました

今回の事例を通じて、Auto Scaling 設計をより安定的に構築できるようになった気がするので、今後はマルチリージョン運用時のスケーリング戦略も検証してみたいです。

本記事が同様の課題に直面している方の参考になれば幸いです。