DevelopersIO 2025 TOKYO で「ECS ネイティブ Blue/Green デプロイについて調べてみた」というタイトルで登壇しました #devio2025

DevelopersIO 2025 TOKYO で「ECS ネイティブ Blue/Green デプロイについて調べてみた」というタイトルで登壇しました #devio2025

2025.10.19

2025 年 10 月 18 日に行われた DevelopersIO 2025 TOKYO の[自由研究発表] クラスメソッド社員による怒涛の LT 大会、11 連発にて、「ECS ネイティブ Blue/Green デプロイについて調べてみた」 というテーマで登壇しました。

補足

ECS ネイティブ Blue/Green 概要

スクリーンショット 2025-10-19 22.56.50.png

2025 年 7 月に ECS ネイティブで Blue/Green デプロイを利用できるようになりました。
このアップデート前でも CodeDeploy を利用することで Blue/Green デプロイメントを実現可能でしたが、CodeDeploy や関連するロール、taskdef.json の受け渡し周りなど、どうしても設定項目が多くなりがちでした。

スクリーンショット 2025-10-19 23.05.08.png

ECS ネイティブな Blue/Green デプロイメントを利用すると、IAM ロールの用意とターゲットグループ、ECS サービスの設定変更くらいで簡単に利用することができます。
CDK L2 コンスタントだとスライドのようなイメージになり、かなり設定が簡素化されていることがわかると思います。

※ CDK のコード全体は下記リポジトリに格納しているので、ご興味があればご確認下さい。

https://github.com/masutaro99/cdk-ecs-blue-green/blob/main/packages/iac/lib/iac-stack.ts

また、CodeDeploy を利用した Blue/Green デプロイでは ECS Service Connect との併用ができませんでしたが、今回の ECS ネイティブの Blue/Green デプロイでは併用可能になっています。

各種設定値

スクリーンショット 2025-10-19 23.20.31.png

ECS ネイティブの Blue/Green デプロイでは、ベイクタイムと呼ばれるトラフィック切り替え後にどれだけ古いバージョンのタスクを残すかを選ぶ設定があります。
こちらを長めに設定しておくことで、トラフィック切り替え後に古いバージョンに戻したくなっても新しくタスクを起動することなくロールバック可能です。
また、マネジメントコンソールを確認すると「トラフィック移行」を選択できそうですが、現時点では「すべて一度に」しか選択できないです。
これはテストトラフィックと本番トラフィックをそれぞれ一気に切り替える方式になります。
今後カナリアリリースなどのより高度なトラフィック制御ができるようになるのでは?などと想像が膨らんでしまいますが、ここは CodeDeploy と比較して現時点では柔軟性が下がっている部分なので、注意が必要です。

デプロイの流れと動作について

スクリーンショット 2025-10-19 23.14.01.png

ECS ネイティブ Blue/Green デプロイでは、「新しいバージョンのタスク起動」 → 「テスト用トラフィックの切り替え」 → 「本番用トラフィックの切り替え」 → 「一定時間待機(ベイクタイム)」 → 「古いバージョンのタスク削除」といった流れでデプロイが行われます。
各トラフィックの切り替えは ECS が Modify Rule を実行してターゲットグループの重み付けを変更することで行われます。
テスト用トラフィック切り替えと本番用トラフィックの切り替えの時間差は制御できないので、ここも注意が必要です。
この切り替え差は約 42 秒でしたので、テストリスナーを利用して人が E2E テストを行うような運用は現実的では無さそうです。

スクリーンショット 2025-10-19 23.14.23.png

テストリスナーを利用したテストを行うのであればきちんとスクリプト化してライフサイクルフックとして挟んであげる必要があります。
デプロイ時に切り戻しを判断するためのフローは予めきちんと定めておくべきなので、ちゃんと形式化して Lambda で自動化して下さいということですね。

スクリーンショット 2025-10-19 23.14.31.png

本番トラフィック切り替えた後でも、ベイクタイム (トラフィック切り替え後に古いバージョンのタスクを残す期間) の間であれば、古いタスクにロールバックすることが可能です。
こちらも ECS が Modify Rule を実行してターゲットグループの重み付けを変更してくれる形になります(単順にデプロイで行った作業を逆の順番で戻していくイメージ)。
ただし、ロールバックを指示した後、本番側ターゲットグループの Modify Rule が実行されるまでに 17 秒程度かかったので、若干ラグがあることを認識しておいた方が良さそうです。
ただ、本番リスナー切り替え前のロールバックであればこのラグも問題ないので、上手くライフサイクルフックを利用したテストで検知したいですね。

最後に

CodeDeploy と比較して考えてしまうと現状設定できる項目が少なく見えてしまいますが、設定内容の少なさはかなり魅力的です。
現状 CodeDeploy で既に組んでいるものを無理に切り替える必要はないとは思います (ECS Service Connect と併用したいパターンを除く)。
とはいえ、今後のアップデートにも期待しつつ、新規構築時には是非検討してみて下さい!

この記事をシェアする

FacebookHatena blogX

関連記事