Amazon ECS（Fargate）上のWebサービスを、利用者に影響を与えずに更新し、問題があれば旧バージョンへ戻したい。 Blue/Greenデプロイはそのための代表的な方式である。
ECSのBlue/Greenには現在、CodeDeployに切替を任せる方式と、ECS自身が切替を行うネイティブ方式の2つがある。 どちらもALBのターゲットグループを2つ持ち、新バージョンを確認してから本番を切り替えるという骨格は同じだが、承認でデプロイを止める仕組みと、必要な構成要素が大きく異なる。
本稿では2つの方式を並べ、インフラ管理とデプロイの責務をどう分けるかという観点から、選び方の判断軸を整理する。
1. Blue/Greenデプロイの共通の骨格
現行バージョンが稼働する環境（Blue）とは別に、新バージョン用の環境（Green）を用意し、ALBの振り分けを切り替えることで無停止の更新を実現する。
- 新バージョンの配置: Green側のターゲットグループへ新しいタスクを起動する
- テストトラフィックでの確認: 本番トラフィックはBlueに残したまま、確認用の経路でGreenへ到達して動作を確かめる
- 本番トラフィックの切替: 本番の振り分けをBlueからGreenへ移す
- 旧バージョンの扱い: 一定時間Blueを残し、問題があれば戻せるようにしてから停止する
ここまでは2つの方式で共通である。違いは、この流れを誰が制御するかにある。
2. 2つの方式
ECSのデプロイ戦略には、ローリング更新、Blue/Green、線形、カナリアの4つがある。 本稿で比較するのはBlue/Green戦略である。
3. 承認でデプロイを止める仕組みの違い
リリースには、通常の更新として自動で本番へ進めたいものと、重要なリリースとして担当者の確認を挟みたいものがある。 デプロイのたびに「自動で進めるか、確認で止めるか」を選べるかが、2つの方式でいちばん違う点である。
CodeDeploy方式: 止め方はデプロイグループに固定される
CodeDeployのBlue/Greenでは、新バージョンが確認可能な状態（READY）になったときの挙動を指定する。
この挙動はデプロイグループの設定である。デプロイを作成するAPIには、この挙動を上書きする項目がない。 つまり、デプロイごとに自動と手動を切り替えたい場合は、CodeDeployの外側に判断の仕組みを置く必要がある。
当社の構成では、デプロイグループを常に「停止」に固定し、Step FunctionsでCodeDeployを包んでいる。
インフラ側の設定（デプロイグループ）は変えずに、運用担当が実行時の入力で承認方式を選べる。 その代わり、Step Functionsのステートマシンという構成要素が1つ増える。
ECSネイティブ方式: 一時停止フックで止める
ECSのネイティブ方式では、デプロイの進行をライフサイクルの段階として扱い、段階ごとにフックを置ける。
一時停止フックの主な仕様は次のとおりである。
- テストトラフィックの切替後（
POST_TEST_TRAFFIC_SHIFT）などの段階に置ける。テストトラフィックの切替中（TEST_TRAFFIC_SHIFT）と本番トラフィックの切替中（PRODUCTION_TRAFFIC_SHIFT）の段階には置けない - 止まった時点で、EventBridgeへ待機中を示すイベント（
HOOK_AWAITING_ACTION）が送られる。通知の起点に使える - タイムアウトは既定で24時間、最大14日。タイムアウト時の既定動作はロールバックで、続行にも変更できる
- 線形・カナリア戦略で本番トラフィック切替の直前（
PRE_PRODUCTION_TRAFFIC_SHIFT）に置くと、切替の段階ごとに毎回止まる
確認のために止める仕組みそのものがECSに備わっているため、承認のためだけのオーケストレーションを別途持つ必要がない。
当社の構成では、CD処理がデプロイのたびにデプロイ設定（戦略、bake time、一時停止フック）を指定する。 重要なリリースでは一時停止フックを付け、通常の更新では付けない、という選択をデプロイ単位で行える。
4. 責務分離の比較
どちらの方式でも、インフラ管理とデプロイを分ける考え方は共通である。 インフラ管理は初期構成を作り、その後の更新はCI/CDが担う。違いは、デプロイの判断をどこに置くかに現れる。
ネイティブ方式で「作成後のデプロイ設定をTerraformが追わない」のは、デプロイ設定がデプロイのたびに変わる運用上の値になるためである。 Terraformは既定で、実際の設定と構成の差を検出して構成に合わせようとする。追い続けると、CDが指定した値を次のapplyで元に戻そうとし、インフラ管理とデプロイの責務がぶつかる。
環境変数とシークレットの値をインフラ管理から切り離す考え方は、ECSの設定値を3系統に分けるで独立して解説している。
5. どちらを選ぶか
新しく構築する場合、承認で止める仕組みがECSに備わっていることは大きい。 承認のためだけにStep Functionsを置く理由がなくなり、デプロイの経路が短くなる。
一方、CodeDeploy方式で安定して運用している環境を、方式が新しくなったことだけを理由に移行する必要はない。 移行には、デプロイ経路とCI/CDの作り直しを伴うためである。
当社の構成は両方の方式を用意しており、既存の運用と承認の要件から選べるようにしている。
6. まとめ
Blue/Greenデプロイの設計で問われるのは、切替の技術そのものよりも、「誰が、どの時点で、本番へ進めてよいと判断するか」をどこに置くかである。 2つの方式は、その判断をデプロイグループの設定と外側の仕組みに置くか、デプロイ設定とECSのフックに置くかという違いとして整理できる。