はじめに
この記事は、FUJITSU Advent Calendar 2025 22日目の記事です。
AWS ECSの キャパシティプロバイダー(Capacity Provider) を活用すると、
ECSクラスタのスケーリングをタスクの起動要求ベースで自動化できます。
今回は、この仕組みを使い「ECS on EC2」で動作するバッチ処理のスケーリングを
完全自動化した事例を紹介します。
背景
AWS ECS on EC2上でコンテナを運用しているシステムがありました。
追加開発要件として、「月に数日間だけ大規模バッチ処理を動かす」ことが発生したため
スケーリング設計を見直すことにしました。
既存構成と課題
従来はEC2 Auto Scaling Group(ASG)の「CPU使用率」をスケーリングトリガーとしておりました。
はじめはこのスケーリング手法を踏襲しようと思っていたのですが
検討を進めていく中でいくつかの課題が見つかりました。
- バッチ開始時にEC2が自動起動しないため、事前に手動でEC2のスケールアウトが必要
- バッチ終了後もEC2が自動でスケールインせず、不要なインスタンスが残る
- CPU使用率を基準にしているため、スケールアウトまでに数分の遅延
タスクの起動リクエストが急増しても、CPU使用率が上がるまでEC2が増えないため、タスクの起動失敗が発生しておりました。
「タスク増加に応じてEC2も自動で増減してほしい」
そんな理想を叶えてくれそうなのが、キャパシティプロバイダーという仕組みでした。
キャパシティプロバイダーとは？
ECSのタスク起動要求をトリガーに自動でEC2の台数を調整してくれる仕組みです。
ポイントは以下の3点です。
・ECSは「タスク起動要求」を監視している
・タスク起動要求に対して、キャパシティが足りないと判断したら、自動でEC2をスケールアウト
・タスクが減って、必要キャパシティも少なくなったら、自動でEC2をスケールイン
これにより、「CPU使用率が上がるまで待つ」という遅延を解消し、ECSの需要とEC2の供給をリアルタイムに連動させられます。
詳しい仕組みはAWS公式ブログが参考になりそうです。
環境への設定
ECSコンソールの「インフラストラクチャー」タブから設定が可能です。
設定の中でポイントとなるのが「ターゲットキャパシティー(%)」です。
これはEC2のリソース使用率の目標値を指定するものです。
例えば90%に指定すると、「EC2リソースを90%利用した状態を保つ」ようにスケールが制御されます。
今回はバッチ処理でリソースを余すことなく使いたかったため、100% に設定しました。
ターゲットキャパシティを100%に設定するとEC2がフル稼働になります。
タスク配置戦略をbinpackにしたら、さらなるコスト削減に！
キャパシティプロバイダーによる自動スケーリングに加えて、タスク配置戦略をbinpackに変更しました。
binpack は、CPUまたはメモリの最小空きリソースに基づいてタスクを詰め込む戦略です。
binpack戦略を使うことで、少ないEC2台数でタスクを効率的に集約可能です。
結果として以下を実現できました。
- EC2リソースを最大限に活用
- バッチ終了後の自動スケールインが安定
- 従来方式からのコスト削減
個人的ベストプラクティスまとめ
| 設定項目 | 推奨値 |
|---|---|
| ターゲットキャパシティ | 100% |
| タスク配置戦略 | binpack |
| ASG最小台数 | 0に指定 |
まとめ
- キャパシティプロバイダーを導入することで、ECSタスク数とEC2スケーリングを連動できる
- CPUベースのASGスケーリングでは困難だった、バッチ処理の自動スケールが実現可能
- binpack戦略を組み合わせることで、さらなるコスト最適化も可能
ECS on EC2構成でも、キャパシティプロバイダーを導入すれば、Fargate並みの運用自動化を実現できます。
補足
- ECSタスクのCPU/メモリサイジングは適切に設定すること。
リソース不足や過剰割り当てを防ぐことで、スケーリング精度が向上します。 - Spotインスタンスや異なるインスタンスタイプの混在も可能。
これによりコスト最適化や冗長性の向上が期待できます