はじめに
2026 年 7 月 1 日、AWS は Amazon ECS の「デプロイメントサーキットブレーカー」に対して、設定をカスタマイズ可能にするアップデートを発表しました。これまで固定値で決まっていた「ロールバックを発動させる失敗の閾値」を、サービスの特性に合わせて自由に調整できるようになったことが大きな特徴です。
ECS でローリングデプロイを運用している方の中には、デプロイ中にタスクの起動が一時的に不安定になり、意図せず自動ロールバックが発動してしまった経験や、逆に本番環境で異常の検知が遅れて被害が広がってしまった経験がある方もいるのではないでしょうか。今回のアップデートは、その課題に直接応えるものです。
本記事では、何が変わったのか、どのような判定ロジックで動作するのか、そしてどのような基準で設定値を決めればよいのかを中心に解説します。ECS でサービスを運用しているエンジニアの方や、デプロイの安定性・信頼性の向上に関心がある方を想定読者としています。
サーキットブレーカーとは
Amazon ECS のデプロイメントサーキットブレーカーは、ローリングデプロイの実行中にタスクの起動状況を監視し、一定数以上の失敗を検知した場合にデプロイを自動で停止し、直前の安定した状態にロールバックする仕組みです。有効化するだけで、異常なデプロイが本番環境に居座り続けることを防いでくれます。
この仕組みは大きく 2 段階で失敗を監視します。1 段階目は、タスクが RUNNING 状態に遷移できるかどうかの監視です。コンテナイメージの取得に失敗したり、アプリケーションの起動時エラーでタスクが繰り返し停止したりすると、ここで失敗としてカウントされます。2 段階目は、タスクが RUNNING になった後のヘルスチェックの監視です。ロードバランサーのヘルスチェックやコンテナヘルスチェックが失敗し続ける場合も、同様に失敗としてカウントされます。
この 2 段階の流れを図にすると、以下のようになります。
これまでは、この失敗をいくつ検知したらロールバックするかという閾値が AWS 側であらかじめ決められた計算式で固定されており、ユーザー側で変更することはできませんでした。具体的には、希望タスク数の 50 %、かつ下限 3・上限 200 という式で自動的に算出される値が、そのまま閾値として使われる仕様になっていました。
何が変わったのか
前章で見た通り、従来のデプロイメントサーキットブレーカーは、失敗の閾値も、失敗のカウント方式も、どちらもユーザー側で変更することができませんでした。閾値は希望タスク数から機械的に算出される固定式のみ、カウント方式もヘルシーなタスクが起動すると失敗数がリセットされる挙動に固定されていました。
この固定仕様は、多くのサービスにとっては妥当な値である一方、アプリケーションの特性によっては合わないケースがありました。たとえば、起動直後に一時的なエラーが出やすいアプリケーションでは、閾値に達する前に正常化するはずが、たまたま連続して失敗が重なりロールバックされてしまうことがあります。逆に、少数の失敗でも即座に異常として扱いたい本番環境では、固定の閾値では検知が緩すぎることもありました。
今回のアップデートでは、この閾値とカウント方式の両方を、サービスごとに設定できるようになりました。具体的には resetOnHealthyTask と thresholdConfiguration という 2 つの設定項目が追加され、それぞれ以下のように動作します。
resetOnHealthyTask は、失敗のカウント方式を制御する設定です。true(デフォルト)にすると、これまでと同じく、タスクがヘルシーな状態になるたびに失敗カウントが 0 にリセットされ、連続した失敗のみが閾値にカウントされます。false にすると、デプロイ全体を通して失敗が累積し、途中でヘルシーなタスクが起動してもカウントはリセットされなくなります。
thresholdConfiguration は、閾値そのものの算出方法を制御する設定です。デフォルトの BOUNDED_PERCENT は従来と同じく、希望タスク数に対する割合(デフォルト 50 %)から閾値を算出しつつ、下限 3・上限 200 の範囲に収めます。新しく追加された UNBOUNDED_PERCENT は、同じ割合ベースの計算をしながらも上限・下限を設けず、タスク数の多い大規模サービスでも比例した閾値を使いたい場合に向いています。同じく新しく追加された COUNT は、割合ではなく固定の失敗数をそのまま閾値として使う方式で、環境の規模によらず一定数の失敗を許容したい場合に向いています。
これらを整理すると、以下のようになります。
| 設定項目 | 従来 | 今回のアップデート後 |
|---|---|---|
| 失敗のカウント方式 | 常にリセットあり(連続失敗のみカウント) |
resetOnHealthyTask で リセットあり / なし を選択可能 |
| 閾値の算出方法 | 希望タスク数の 50 %(下限 3・上限 200)固定 |
thresholdConfiguration で BOUNDED_PERCENT(従来と同じ) / UNBOUNDED_PERCENT(上限なし) / COUNT(固定数) から選択可能 |
| 設定できるタイミング | なし(固定仕様) | サービス作成時・更新時のどちらでも設定可能 |
今回のアップデートは、「1 つの計算式がすべてのサービスに最適とは限らない」という従来の課題に対し、カウント方式と閾値算出方法を組み合わせて調整できるようにすることで対応したものです。
判定ロジックの解説
前章で紹介した resetOnHealthyTask は、文章だけで説明するとイメージがつかみにくいため、具体的なタスクの起動結果の並びを例に、実際のカウントの動き方を見ていきます。
ここでは話を単純にするため、thresholdConfiguration に COUNT を指定し、閾値を 3 に固定した場合を例にします。デプロイ中に、タスクの起動が「失敗・失敗・成功・失敗・失敗・失敗」という順番で発生したとします。
まず resetOnHealthyTask が true(デフォルト)の場合、つまり従来と同じ「連続した失敗のみをカウントする」方式では、以下のように失敗カウントが推移します。
Task 3 で一度成功しているため、それまでの失敗カウントはいったん 0 にリセットされます。その結果、閾値の 3 に到達するのは Task 6 の時点になります。途中で正常なタスクが起動している以上、デプロイ全体としては持ち直しつつあると判断され、ロールバックの発動は後ろ倒しになります。
一方、同じ起動結果の並びに対して resetOnHealthyTask を false にした場合、つまり失敗を累積でカウントする方式では、以下のようになります。
こちらは Task 3 で成功していても失敗カウントがリセットされないため、Task 4 の時点で早くも閾値の 3 に到達し、ロールバックが発動します。
同じ起動結果の並びでも、resetOnHealthyTask の設定によって、ロールバックが発動するタイミングは大きく変わります。
閾値・カウント方式の決め方
ここまでで、resetOnHealthyTask によるカウント方式の違いと、thresholdConfiguration による閾値算出方法の違いを見てきました。実際に設定を検討する際は、この 2 つの軸をそれぞれ自分たちのサービス特性に照らして決めていく必要があります。
まず resetOnHealthyTask は、アプリケーションの起動特性に基づいて選びます。依存先のミドルウェアへの接続確立やキャッシュのウォームアップなど、起動直後に一時的な失敗が発生しやすい構成のアプリケーションであれば、true(デフォルト)のまま連続失敗のみをカウントする方式が適しています。一方で、起動特性上は本来安定しているはずのアプリケーションであれば、false にして失敗を累積でカウントする方式にすることで、デプロイ全体を通して問題が繰り返されているパターンをより早く検知できます。
次に thresholdConfiguration は、主にサービスの希望タスク数の規模に基づいて選びます。数十タスク程度までの一般的な規模であれば、従来と同じ BOUNDED_PERCENT のままで十分に機能します。一方、数百タスク規模の大規模サービスでは、BOUNDED_PERCENT の上限 200 という制約が働き、実際の規模に対して閾値が相対的に小さくなりすぎることがあります。このような場合は UNBOUNDED_PERCENT を使い、上限を設けずに規模に比例した閾値にする方が実態に合います。逆に、開発・テスト環境のように希望タスク数が少なく、割合ではなく決まった失敗数で早期にロールバックさせたい場合は、COUNT を使って固定値を直接指定する方が意図が明確になります。
これらの組み合わせの例を整理すると、以下のようになります。
| サービスの特性 | resetOnHealthyTask |
thresholdConfiguration |
|---|---|---|
| 起動時に一時的な失敗が出やすいアプリケーション |
true(デフォルト) |
BOUNDED_PERCENT(デフォルト) |
| 大規模な本番サービス(希望タスク数が数百規模) | false |
UNBOUNDED_PERCENT |
| 開発・テスト環境で素早くロールバックしたい | false |
COUNT(小さめの固定値) |
| 起動は安定しているが、規模は一般的な本番サービス | false |
BOUNDED_PERCENT(デフォルト) |
ただし、これらはあくまで組み合わせの一例であり、唯一の正解ではありません。実際には、まずデフォルト設定のまま運用しつつ、意図しないタイミングでロールバックが発動していないか、あるいは検知が遅れて被害が広がっていないかを観察し、必要に応じて値を調整していくアプローチが現実的です。
ユースケース
具体的にどのような場面で今回のアップデートが役に立つのかを、いくつかの用途に分けて見ていきます。
開発・テスト環境での高速なフィードバックループ
開発・テスト環境でのデプロイでは、閾値の計算を待たずに素早く失敗を検知したいというニーズがあります。thresholdConfiguration を COUNT にして小さめの固定値を指定しておけば、CI/CD パイプラインの中でコードや設定ミスによる起動失敗を、後続の検証プロセスに進む前に検知できます。
起動が不安定な既存アプリケーションの移行期
ECS への移行期や、レガシーなアプリケーションを段階的にモダナイズしている過程では、アプリケーション側の改善が完了するまでの間、起動直後の一時的な失敗によって不必要にロールバックされることを避けたい場合があります。resetOnHealthyTask をデフォルトの true のままにしておけば、この期間中もサーキットブレーカーが過敏に反応しすぎることを防げます。
大規模な本番サービスでの適切な閾値スケーリング
希望タスク数が数百規模に及ぶサービスでは、BOUNDED_PERCENT の上限 200 という制約により、規模に対して閾値が相対的に小さくなることがあります。UNBOUNDED_PERCENT と resetOnHealthyTask=false を組み合わせることで、規模に比例した閾値を維持しながら、デプロイ全体で失敗が積み重なっている状況を早期に検知できます。
監視・アラート体制の強化
今回のアップデート自体はサーキットブレーカーの判定ロジックに関するものですが、あわせて活用したいのが Amazon EventBridge との連携です。ECS はサービスデプロイの状態変化を EventBridge にイベントとして送信しており、SERVICE_DEPLOYMENT_FAILED イベントを監視するルールを組んでおくことで、ロールバックが発動したことを即座に検知し、必要であれば手動での対応につなげられます。閾値やカウント方式を用途に合わせて調整した上で、この監視体制もあわせて整えることで、サーキットブレーカーを運用の一部として組み込むことができます。
設定方法
ここからは、実際に resetOnHealthyTask と thresholdConfiguration を設定する手順を、AWS CLI を例に見ていきます。
新規にサービスを作成する場合は、create-service の --deployment-configuration オプションの中で、deploymentCircuitBreaker の一部として指定します。以下は、公式ドキュメントに掲載されている例をもとにした、固定の失敗数 5 を閾値とし、失敗を累積でカウントする設定でサービスを作成するコマンドです。
aws ecs create-service \
--service-name <service-name> \
--deployment-controller type=ECS \
--desired-count <desired-count> \
--deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true,resetOnHealthyTask=false,thresholdConfiguration={type=COUNT,value=5}}" \
--task-definition <task-definition-family>:<revision> \
--launch-type FARGATE \
--platform-family LINUX \
--platform-version 1.4.0 \
--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}"
別のクラスターを対象にする場合は、--cluster <cluster-name> を追加してください(省略した場合は default クラスターが対象になります)。
resetOnHealthyTask=false を指定している点と、thresholdConfiguration で type=COUNT、value=5 を指定している点が、今回のアップデートで新しく追加された部分です。何も指定しなければ、resetOnHealthyTask=true、thresholdConfiguration={type=BOUNDED_PERCENT,value=50} が適用され、従来と同じ挙動になります。
既に稼働しているサービスの設定を変更したい場合は、update-service を使います。以下は、大規模サービスを想定して UNBOUNDED_PERCENT を指定する例です。こちらのコマンドは、公式ドキュメントに掲載されている構文をもとに、新しいパラメータを組み込んで作成したものです。本番環境に適用する前に、開発環境などで一度動作を確認してください。
aws ecs update-service \
--cluster <cluster-name> \
--service <service-name> \
--deployment-configuration '{
"deploymentCircuitBreaker": {
"enable": true,
"rollback": true,
"resetOnHealthyTask": false,
"thresholdConfiguration": {
"type": "UNBOUNDED_PERCENT",
"value": 50
}
}
}'
サーキットブレーカー自体をこれから有効にする場合は、enable と rollback をあわせて指定する必要がある点は従来と変わりません。既にサーキットブレーカーを有効にしているサービスに対して、カウント方式や閾値のみを変更したい場合も、同様に deploymentCircuitBreaker オブジェクト全体を指定し直す形になります。
Amazon ECS コンソールからサービスを作成・更新する場合も、デプロイ設定の画面で同様の項目を GUI 上から設定できます。CLI でのパラメータ名を把握しておくと、コンソール上のどの項目に対応するかも判断しやすくなります。
なお、今回の発表によると、resetOnHealthyTask と thresholdConfiguration は AWS Management Console、AWS CLI、AWS SDK に加えて、AWS CloudFormation、AWS CDK、Terraform からも設定可能とされています。具体的なプロパティ名や記法は本記事執筆時点では確認できていないため、実際に IaC で設定する際は、利用しているツールの最新ドキュメントを参照してください。
導入前に確認すべきこと
まず、既存サービスへの影響についてです。resetOnHealthyTask と thresholdConfiguration は、明示的に指定しない限り、それぞれ true と BOUNDED_PERCENT(デフォルト値 50)が適用されます。これは従来から変わらない挙動そのものであるため、既にサーキットブレーカーを有効にしている既存のサービスであれば、今回のアップデートによって意図せず挙動が変わってしまうことはありません。設定を変更したいサービスに対してのみ、必要な箇所を明示的に指定していく形になります。
次に、適用対象の確認です。デプロイメントサーキットブレーカー自体が、ローリングアップデート(ECS)デプロイコントローラーを使うサービスにのみ対応している点は、今回のアップデートでも変わっていません。Blue/Green デプロイや外部デプロイコントローラーを使っているサービスには適用されないため、対象のサービスがどのデプロイコントローラーを使っているか、あらかじめ確認しておく必要があります。
リージョンについても触れておきます。今回の設定は、Amazon ECS が利用可能なすべての AWS リージョンで利用できるとされています。複数リージョンにまたがってサービスを運用している場合でも、リージョンごとに対応可否を気にする必要はありません。
最後に、監視体制についてです。前章でも触れた通り、ECS はサービスデプロイの状態変化を Amazon EventBridge にイベントとして送信しています。SERVICE_DEPLOYMENT_FAILED イベントを監視するルールをあらかじめ用意しておくことで、閾値やカウント方式を変更した後にロールバックが実際にどのタイミングで発動しているかを継続的に把握できます。設定値は一度決めて終わりではなく、運用しながら実際の発動状況を見て調整していくものです。
まとめ
今回のアップデートにより、Amazon ECS のデプロイメントサーキットブレーカーは、resetOnHealthyTask による失敗のカウント方式(連続 / 累積)と、thresholdConfiguration による閾値の算出方法(BOUNDED_PERCENT / UNBOUNDED_PERCENT / COUNT)の両方を、サービスごとに調整できるようになりました。「1 つの計算式がすべてのサービスに最適とは限らない」という課題に対して、AWS 側の固定仕様に頼らざるを得なかった部分を、利用者自身の判断でチューニングできるようになったことが、今回のアップデートの本質です。
設定を変更しなければ従来と同じ挙動が維持されるため、既存のサービスに対して無理に設定変更を急ぐ必要はありません。まずはデフォルトのまま運用を続けながら、意図しないタイミングでロールバックが発動していないか、あるいは検知が遅れていないかを観察し、必要に応じて resetOnHealthyTask や thresholdConfiguration を調整していくという進め方が現実的です。あわせて Amazon EventBridge での監視体制を整えておけば、設定変更の効果を継続的に確認しながら運用できます。
デプロイの自動ロールバックという仕組み自体はこれまでもありましたが、今回のアップデートによって、その挙動を自分たちのアプリケーション特性や運用方針に合わせて設計できるようになりました。ECS でサービスを運用している方は、一度自分たちのサービスに当てはめて設定を見直してみることをおすすめします。
参考リンク
- Amazon ECS now supports configurable deployment circuit breaker settings(今回のアップデートの公式発表)
- How the Amazon ECS deployment circuit breaker detects failures(デプロイメントサーキットブレーカーの仕様に関する公式ドキュメント)
- Announcing Amazon ECS deployment circuit breaker(サーキットブレーカー自体が発表された際の AWS ブログ)
- Amazon ECS service deployment state change events(EventBridge と連携するための公式ドキュメント)