はじめに
2026 年 9 月 4 日、AWS は Amazon ECS のローリングデプロイメントに対して、デプロイの成功判定をユーザー自身の判断で柔軟に定義できるようにする「Early Success Criteria」という新機能を発表しました。これまで一律だったデプロイ完了の基準に、ワークロードの特性に応じた選択肢が加わったアップデートです。
ECS でデプロイを運用していると、「タスクの大半はもう動いているのに、残りわずかなタスクの起動をひたすら待たされている」「デプロイ自体はほぼ終わっているはずなのに、後続の CI/CD パイプラインがなかなか次に進まない」といった事象に遭遇したことがある方もいるのではないでしょうか。多くの場合、これは特定のタスクの起動やドレインに時間がかかっているだけで、サービス自体には何の問題もないケースです。今回のアップデートは、まさにこの「あと少しが待ちきれない」という状況に対する解決策です。
以下では、何が変わったのか、内部でどのような仕組みでデプロイが完了扱いになるのか、そして healthy percent という値をどう決めればよいのかを順に見ていきます。ECS を運用しているインフラ・プラットフォームエンジニアの方はもちろん、CI/CD の高速化やデプロイ戦略の見直しに関心のあるマネージャー層の方にも読んでいただけるよう、基礎的な部分から丁寧に説明します。
何が変わったのか
今回のアップデートで何が変わったのかを、まず Before / After で整理します。
| Before | After | |
|---|---|---|
| デプロイ完了の判定 | 希望タスク数の 100% が running かつ healthy になるまで、デプロイは完了とみなされなかった | 設定した healthy percent に達した時点で、デプロイを完了とみなせるようになった |
| 残りタスクの起動 | デプロイのライフサイクル内で、全タスクの起動を待ち続けていた | デプロイの外側で、通常のサービススケーリングを通じて起動が継続される |
| ソースリビジョンのクリーンアップ | クリーンアップが完了してから、初めて成功が宣言されていた | BLOCKING(従来どおり完了後に宣言)と DEFERRED(先に宣言し、非同期でクリーンアップ)を選べるようになった |
| ロールバック監視の適用範囲 | 全タスクの起動とクリーンアップが終わるまで有効だった | 設定した healthy percent に達するまで有効で、以降は通常のスケーリングに委ねられる |
healthy percent は、希望タスク数に対して何 % のタスクが healthy であればデプロイを成功とみなすかを表す設定値です。たとえば希望タスク数が 100 で healthy percent を 90 に設定した場合、90 タスクが healthy になった時点でデプロイは成功として扱われ、残り 10 タスクは通常のサービススケーリングとして後追いで起動します。
この機能はローリングデプロイメント戦略を使うサービスが対象で、全 AWS コマーシャルリージョンおよび AWS GovCloud (US) リージョンで利用できます。新規サービスだけでなく、既存サービスへの後付けの設定も可能です。
アーキテクチャ解説
デプロイフェーズとスケーリングフェーズ
Early Success Criteria が入ったことで、ECS のローリングデプロイは「デプロイフェーズ」と、その後の「スケーリングフェーズ」に分かれるとイメージすると理解しやすくなります。設定した healthy percent に到達するまでが従来どおりのデプロイフェーズで、ロールバック監視もこの区間だけ有効です。healthy percent に到達したあとは、残りのタスクの起動がデプロイのライフサイクルから切り離され、通常のサービススケーリングに委ねられます。
healthy percent の丸め方
healthy percent は、希望タスク数に対する割合を切り上げて必要タスク数を算出します。たとえば希望タスク数が 3 で healthy percent が 50 の場合、単純計算では 1.5 タスクですが、切り上げにより 2 タスクが必要になります。いくつかのパターンを表にすると、次のようになります。
| 希望タスク数 | healthy percent | 必要な healthy タスク数(切り上げ) |
|---|---|---|
| 2 | 50 | 1 |
| 3 | 50 | 2 |
| 10 | 80 | 8 |
| 100 | 90 | 90 |
| 10 | 100 | 10 |
また、healthy percent の評価はターゲットリビジョン上で少なくとも 1 タスクが起動し healthy になってから始まります。デプロイ開始直後、まだ 1 タスクも healthy になっていない段階でいきなり早期成功と判定されることはありません。
ソースリビジョンのクリーンアップ方式
ソースリビジョンのクリーンアップ方式の違いも、この完了判定の流れに直結しています。BLOCKING を選んだ場合は、healthy percent への到達(アラームベースロールバックを使っていれば bake time の経過も含む)のあとにソースリビジョンのクリーンアップが完了して、初めてデプロイが完了扱いになります。一方 DEFERRED を選んだ場合は、healthy percent への到達と bake time の経過の時点でデプロイを完了とし、ソースリビジョンのクリーンアップはデプロイの外側で非同期に、最大 2 週間かけて実行されます。
ロールバック監視の適用範囲
デプロイメントサーキットブレーカーや CloudWatch アラームによるロールバックは、デプロイが完了するまでの間だけ機能する障害検知の仕組みです。デプロイが完了したあとは、残りのタスクが通常のサービススケーリングで起動される間も含めて、これらの仕組みによるロールバックは行われなくなります。つまり、healthy percent を低く設定するほど、ロールバックによる保護がかかる区間は短くなるということです。
設定方法
コンソールで設定する
サービスの作成・更新フローの「Deployment configuration」で、Early Success Criteria を有効にするトグルがあります。有効にすると Healthy percent の入力欄が表示され、Source service revision cleanup として Blocking か Deferred のどちらかを選択できます。既存サービスの更新フローからも同様に設定できるため、いま稼働中のサービスに後付けで適用することも可能です。
AWS CLI で設定する
AWS CLI からは、update-service(または create-service)の --deployment-configuration パラメータに earlySuccessCriteria を指定します。
aws ecs update-service \
--cluster <cluster-name> \
--service <service-name> \
--deployment-configuration '{
"strategy": "ROLLING",
"earlySuccessCriteria": {
"enable": true,
"healthyPercent": 90,
"sourceServiceRevisionCleanup": "BLOCKING"
}
}'
strategy は ROLLING を指定する必要があります。この機能はローリングデプロイメント戦略でのみ利用できます。
設定を確認する
デプロイの状況は DescribeServiceDeployments で確認できます。設定した Early Success Criteria の内容とあわせて、デプロイのステータスが返ってきます。デプロイが進行中の間はタスク数がリアルタイムに反映されますが、デプロイが完了したあとのタスク数は完了時点のスナップショットになる点に注意してください。これは BLOCKING / DEFERRED のどちらを選んでも同じです。サービス全体の最新のタスク数を見たい場合は、DescribeServices を使います。
早期完了したデプロイも、ListServiceDeployments を SUCCESSFUL ステータスでフィルタした結果に含まれます。デプロイのステータス変化イベントや AWS CloudTrail の記録も、従来どおり IN_PROGRESS から SUCCESSFUL へ遷移する形で記録され、Early Success Criteria によって新しいデプロイステータスが追加されるわけではありません。
healthy percent の決め方
設定できる範囲
healthy percent は、0 から 100 までの任意の値を自由に設定できるわけではありません。サービスの minimumHealthyPercent(ローリングデプロイ中に維持しておくべき稼働タスク数の下限を表す、Early Success Criteria とは別に以前から存在するデプロイ設定値)から 100 までの範囲でしか設定できないという制約があります。つまり、Early Success Criteria によって、そのサービスがもともと許容している最低限の稼働水準よりもさらに緩い基準を追加できるわけではありません。
早さと安全性のトレードオフ
healthy percent を低く設定するほど、デプロイは早く完了扱いになります。しかし、デプロイが完了した時点でデプロイメントサーキットブレーカーや CloudWatch アラームによるロールバック監視は解除され、残りのタスクが通常のサービススケーリングで起動される間に何か問題が起きても、自動的にはロールバックされなくなります。逆に healthy percent を高く設定するほど、より多くのタスクがロールバック監視の対象になったまま起動を待つことになるぶん安全性は高まりますが、デプロイ完了までの時間は従来の 100% 判定に近づいていきます。
公式ドキュメントの Considerations でも、ターゲットサービスリビジョンが健全であると確信できる水準に healthy percent を設定すること、そしてデプロイが完了したあとはそのデプロイを止められないことが、明確に注意点として挙げられています。healthy percent は「ここから先は個々のタスクの起動待ちに過ぎず、サービス全体としてはすでに健全だと判断できる」水準として設定するのが基本方針です。
見極めのポイント
具体的な値を決めるうえでの軸になるのは、一部のタスクだけ起動やドレインに時間がかかっている理由が、サービス自体の健全性とは無関係な要因だと言い切れるかどうかです。この前提が崩れているサービスでは、healthy percent を下げる意味自体がありません。この前提に立てるのであれば、あとは運用上の許容度の問題です。残りのタスクの処理が終わるまでの時間を、後続の CI/CD パイプラインがどれだけ待てるか、そして本番トラフィックへの影響度が大きいサービスほどロールバック監視を長く効かせておきたいという事情を踏まえて、healthy percent の高低を決めていくことになります。影響範囲が限定的なサービスや、事前検証が十分にできているサービスほど、低めの値でも運用しやすくなるはずです。
活用シーン
GPU 推論ワークロードでのデプロイ高速化
GPU アクセラレーテッド推論のように、特定のハードウェアの空き待ちによって一部タスクの起動が長引くワークロードは、公式ドキュメントでも明示的に挙げられているユースケースです。たとえば desired count が 50 のサービスで、45 タスク(90%)まで healthy になっていれば、残り 5 タスクの起動はハードウェアの空き次第です。healthy percent を 90、sourceServiceRevisionCleanup を BLOCKING に設定すれば、デプロイ全体を長時間ブロックすることなく、CI/CD パイプラインの後続ステップに進めます。
長期接続を持つサービスの無停止デプロイ
WebSocket のような長時間接続を保持するサービスでは、旧リビジョンのタスクがなかなかドレインし終わらず、デプロイがいつまでも完了しないという課題があります。こうしたケースでは、sourceServiceRevisionCleanup を DEFERRED に設定することで、healthy percent に到達した時点でデプロイを完了扱いにしつつ、旧リビジョンのタスクは接続が自然に終了するまでバックグラウンドでドレインを続けられます。ただし DEFERRED でのクリーンアップは最大 2 週間までしか試行されないため、それより長く接続が残り続ける可能性があるサービスでは、DescribeServices で旧リビジョンのタスクの残存状況を別途監視しておく必要があります。
大規模マイクロサービスの CI/CD 高速化
数百タスク規模のサービスでは、全タスクの起動を待つだけでもデプロイ全体のリードタイムが大きく伸びてしまいます。すでに十分な実績があるサービスであれば、healthy percent を高めの値、たとえば 95 程度に設定するだけでも、後続のデプロイやパイプラインをブロックする時間を短縮できます。複数のサービスを連鎖的にデプロイするような構成では、この短縮効果がサービスの数だけ積み重なるため、全体のリードタイム改善につながります。
導入前に確認しておきたいこと
対象はローリングデプロイ限定
Early Success Criteria はローリングデプロイメント戦略を使うサービスにのみ設定できます。Blue/Green デプロイなど、他のデプロイ戦略を使っているサービスには適用できない点は、導入を検討する際に最初に確認しておく必要があります。
healthy の判定はヘルスチェックの設計に依存する
見落としやすいポイントとして、タスクが healthy と判定されるかどうかは、そのサービスに設定されているヘルスチェックの内容に完全に依存します。ヘルスチェックの設計が浅く、アプリケーションの実質的な異常を検知できないものになっている場合、healthy percent をどれだけ精緻に設定しても、Early Success Criteria が期待する安全性は得られません。この機能を導入する前提として、ヘルスチェック自体がサービスの健全性を適切に表せているかどうかを見直しておくことをおすすめします。
healthyPercent と minimumHealthyPercent の整合性
healthyPercent はサービスの minimumHealthyPercent から 100 の範囲でしか設定できません。minimumHealthyPercent を据え置いたまま healthyPercent だけを大きく下げようとすると、InvalidParameterException として設定自体が拒否されます。healthyPercent を低めに設定したい場合は、minimumHealthyPercent 側もあわせて見直す必要がある、という点は実装時につまずきやすいポイントです。
実際の効果とリスクのバランス
healthyPercent を 100% から段階的に下げていくと、デプロイの所要時間はおおむね比例して短くなり、値によってはデプロイ時間がおよそ半分近くまで短縮されるケースもあります。あわせて、デプロイ完了イベントの statusReason は、通常完了時の "Service deployment completed successfully." から、早期成功条件による完了時には "Service deployment met early success criteria." に変わります。DescribeServiceDeployments や CloudTrail の記録から、どちらの経路で完了したデプロイなのかを見分けられることの裏づけにもなります。
一方で、healthyPercent と minimumHealthyPercent を下げすぎると、稼働中のタスク数が不足し、サービスに影響するおそれがあります。本番環境に導入する際は、デプロイ時間の短縮と可用性のバランスを見ながら、まずは影響範囲の小さいサービスやステージング環境で値を検証してから、段階的に適用範囲を広げていくのが安全です。
まとめ
Early Success Criteria は、Amazon ECS のローリングデプロイにおける「デプロイ完了」の定義を、これまでの一律の基準から、ワークロードごとの事情に合わせて選べる基準へと変えるアップデートです。デプロイ全体のリードタイムを縮めたい場面や、一部のタスクの起動・ドレインだけが長引いてしまう場面など、これまでは待つしかなかった「あと少し」を解消する選択肢が加わったと捉えると分かりやすいでしょう。
導入にあたっては、healthy percent をどこまで下げるかが、そのまま安全性とのトレードオフに直結するという点を意識しておく必要があります。まずは影響範囲の小さいサービスやステージング環境で値を検証してから、段階的に適用範囲を広げていくのが安全です。
デプロイのたびに「あと少し」で待たされていたチームにとっては、試す価値のあるアップデートです。