84. デプロイは健康なタスクの入れ替え算である — 最小/最大ヘルス率、そしてBlue/Greenのポインタ切り替え
新しいリビジョンへの移行を「制約付きの入れ替えアルゴリズム」として、2つのつまみ・丸めの落とし穴・失敗検知・そして環境ごと差し替えるBlue/Greenまで、図で追っていきます。
① 「健康なタスクの在庫」を保った入れ替え
- 公式定義: minimumHealthyPercent はデプロイ中に RUNNING 状態を維持しなければならないタスク数の下限。desiredCount に対する%で、切り上げ(rounded up)。
- 公式定義: maximumPercent は RUNNING・STOPPING・PENDING 状態で許容されるタスク数の上限。desiredCount に対する%で、切り下げ(rounded down)。
デプロイは「健康な在庫の下限」と「総数の上限」に挟まれた隙間の中でしか進めない。min/maxはこの隙間の広さを決めるつまみで、隙間がバッチ幅そのものになる。
② 「先に止める」か「先に起こす」か
- 公式例: desired=4・min50%・max100% では「先に既存タスクを2つ止めてクラスタ容量を空けてから、新タスクを2つ起動」。
- 公式例: max200% では「先に新タスクを4つ起動してから旧4つを停止」(クラスタに必要なリソースがあることが前提)。
- デフォルト: REPLICA は min 100% / max 200%(=安全型)。DAEMON は max 100%、min は CLI/SDK/API で 0%・マネジメントコンソールで 50%。
minを下げれば追加容量ゼロで回せ、maxを上げれば一瞬2倍の容量と引き換えに素早く安全に切り替わる。同じ「入れ替え」でも、どちらのつまみを緩めたかで挙動が正反対になる。
③ 丸めの向きが生む「詰み」設定
- 公式警告: 「you should ensure that the scheduler can stop or start at least one task when a deployment is initiated」— デプロイ開始時に少なくとも1タスクを止める/起こせる設定にせよ。
- スタック時の service event message: 「Update the minimumHealthyPercent or maximumPercent value and try again.」
丸めの向き(min=切り上げ・max=切り下げ)を頭に入れないと、「少なくとも1つは動かせる」という前提が崩れてデプロイが停止する。設定後は必ず、下限<現状 または 上限>現状 のどちらかが成り立つか検算する。
④ 失敗検知 — サーキットブレーカーとCloudWatchアラーム
- 公式ガイドライン: サーキットブレーカーは「タスクが起動できないときにデプロイを止めたい」場合、CloudWatchアラームは「アプリケーションのメトリクスに基づいて止めたい」場合に使う。
- 併用時: 「the deployment is set to failed as soon as the failure criteria for either failure method is met」— どちらかの失敗条件が成立した時点で即失敗。
- 両方式とも、前のサービスリビジョンへのロールバックに対応。
サーキットブレーカーは「起動できたか」という配置レベルの事実で、CloudWatchアラームは「アプリが正常に振る舞えているか」というメトリクスで失敗を判定する。可観測性編で見たアラームのFSM(OK/ALARM/INSUFFICIENT_DATA)が、そのままデプロイを止める制御入力になる統合の実例。
⑤ デプロイ中もイメージは混ざらない(version consistency)
- 公式記述: デプロイ中に最初に起動したタスクがイメージダイジェストを確定し、ECS は以後の全タスクの起動と将来のサービス更新にそのダイジェストを使用 → 1サービスの全タスクが常に同一イメージ(version consistency)。デフォルトで有効。
- 挙動はコンテナ定義の versionConsistency パラメータで制御可能。
- 例外: ダイジェストの確定に3回以上失敗すると、デプロイはダイジェスト解決なしで続行される(サーキットブレーカー有効時は、さらにデプロイ失敗+ロールバック扱いになる)。
「タグは動くが指紋は動かない」を運用側で徹底するのがversion consistency。デプロイという一番危ない瞬間でも、1つのサービスの全タスクが物理的に同一のイメージを走らせることが保証される。
⑥ Blue/Green — 2部作って「参照だけ」差し替える
- 公式定義: bake time =「本番トラフィックのシフト後、blueとgreenの両サービスリビジョンが同時に走っている期間」。「the blue revision is kept running until the bake time expires」。
- Lifecycle hook = 特定のライフサイクル段階でのLambda関数または一時停止ポイント。Pauseフックは ContinueServiceDeployment を呼ぶまで停止。
- 代償: 「may double your resource usage during deployments」— デプロイ中は資源使用量が2倍になり得る。
- 2系統ある: ECSデプロイコントローラ自体が rolling / blue/green / linear / canary をサポート。別系統として CODE_DEPLOY コントローラ(CodeDeploy製のBlue/Greenモデル)もある。linear=等しい割合ずつ段階的にシフト、canary=まず少量、次に残り全部。
Blue/Greenは「環境を2つ用意し、トラフィックというポインタを1回で差し替える」アトミック更新。bake timeの間は旧環境という「元のデータ」を捨てずに持ち続けるので、ロールバックはポインタを戻すだけの定数時間操作になる。資源が一瞬2倍になるのが、この安全性の代償。
⑦ 全体を貫く軸(基礎概念との接続)
デプロイ編の各機構は、これまで学んだ基礎概念の実装例として読み直せる。個別の設定項目ではなく「制約・離散化・不変性・ポインタ」という軸で覚えると応用が利く。