- はじめに
- なぜECS native Blue/Greenデプロイを導入したのか
- ECS Blue/Greenデプロイの基本概念
- ALBの挙動
- 課題とその解決過程
- 副次的なメリット
- 全体を通しての学び
- まとめ
- 参考リンク
はじめに
はじめまして、DMM.comのオンラインサロン開発部で新卒2年目エンジニアをしている國分です。本記事では、実際にAmazon ECS Blue/Greenデプロイを導入・運用するなかで直面した課題や、その解決方法についてご紹介します。
自身の学びを書き残す目的もありますが、同じような悩みを持つ方の一助になれば幸いです。
今回ご紹介するのは、Amazon ECSの組み込みBlue/Greenデプロイ機能とService Connectを併用した事例です。2025年7月にリリースされたばかりということもあり、情報が少なく、手探りで実装を進める場面が多々ありました。
私自身、インフラの知識にまだ不安があるなかで挑戦した取り組みだったため、特に悩んだポイントやどのように乗り越えたかを、6つのトピックに分けてまとめています。
なぜECS native Blue/Greenデプロイを導入したのか
従来、我々のチームではECSのローリングデプロイを使用していました。ローリングデプロイは、タスクを段階的に置き換えていく方式で、デプロイ中に新旧のバージョンそれぞれ混在する期間が発生します。この期間中、問題に直面すると影響を受けるユーザーも出てくる可能性があり、ロールバックにも時間がかかります。
より安全なデプロイを実現するため、Blue/Greenデプロイの導入を検討しました。AWSにはCodeDeployを使ったBlue/Greenデプロイの仕組みもありますが、今回は2025年7月にリリースされたECS nativeのBlue/Greenデプロイ機能を選択しました。CodeDeployと異なり、追加のサービスを導入する必要がなく、ECSの設定だけで実現できる点が魅力的でした。
特に、我々のシステムではService Connectを使ってサービス間通信していたため、この選択はより重要でした。CodeDeployのBlue/Greenは主にALBレイヤーでのトラフィック切り替えに特化しており、ALBのターゲットグループ間でのみ切り替えが行われます。 一方、Service Connectはサービスディスカバリーとトラフィック管理をService Connect側で行うため、CodeDeployのトラフィック切り替え仕組みとの統合が複雑になります。 ECS nativeのBlue/GreenデプロイではService DiscoveryとService Connectが統合された形で動作するため Blue環境からGreen環境へのシームレスな切り替えが実現できます。
これにより安全かつシンプルな実装が可能になりました。
ECS Blue/Greenデプロイの基本概念
Blue/Greenデプロイは、既存の本番環境（Blue環境）をそのまま維持しながら、新しいバージョンの環境（Green環境）を並行して構築する方式です。Green環境が準備でき、検証が完了したら、トラフィックをBlue環境からGreen環境に切り替えます。問題が発生した場合は、すぐにBlue環境に戻すことができます。
ECS Blue/Greenデプロイでは、デプロイ時に自動的にGreen環境用のタスク定義、サービス、ターゲットグループが作成されます。デプロイが完了すると、トラフィックがGreen環境にシフトし、一定時間（ベイクタイム）が経過するとBlue環境のリソースが削除されます。
デプロイライフサイクルフックは、デプロイの各段階で自動的にLambda関数を実行する機能です。 具体的には以下のような段階が存在します。
RECONCILE_SERVICEPRE_SCALE_UPPOST_SCALE_UPTEST_TRAFFIC_SHIFTPOST_TEST_TRAFFIC_SHIFTPRODUCTION_TRAFFIC_SHIFTPOST_PRODUCTION_TRAFFIC_SHIFT
といった段階があります。 それぞれのタイミングで開発者がカスタム検証、承認待機、通知などのロジックを挿入できます。これにより、デプロイプロセスの柔軟性が向上します。
Service Connectは、ECSタスク間の通信を管理する機能です。サービスディスカバリーやヘルスチェック、トラフィック分散などを提供します。Blue/Greenデプロイと組み合わせることで、サービス間通信も含めて安全にデプロイを実行できます。
ALBの挙動
Blue/GreenデプロイにおけるALB（Application Load Balancer）の動作を理解することは、実装を進めるうえで重要でした。
デプロイ開始時、ALBは既存のBlue環境のターゲットグループにトラフィックをルーティングしています。デプロイが開始されると、ECSは自動的にGreen環境用の新しいターゲットグループを作成します。この時点では、ALBのリスナールールにBlue用とGreen用の2つのルールが存在しますが、実際にトラフィックが流れるのはBlue環境のみです。
Green環境のタスクが起動し、ヘルスチェックが成功すると、デプロイライフサイクルフックのPOST_TEST_TRAFFIC_SHIFTが実行されます。このフックで開発者の承認を待ちます。承認すると、ALBのリスナールールが更新され、Green環境のものがBlue環境として置き換わります。この切り替えは、ALBの内部で行われるため、ダウンタイムなく実行されます。
一定時間（ベイクタイム）が経過すると、Blue環境のターゲットグループのタスクが削除され、旧Blue環境のリソースが削除されます。この時点で、ALBのリスナールールはBlue環境用の1つだけになります。
問題が発生してロールバックが必要な場合、ALBは自動的にBlue環境のターゲットグループにトラフィックを戻します。この切り替えも、ALBの内部で行われるため、即座に実行されます。
課題とその解決過程
1. 新しい機能なのでドキュメントが少ない
ECS native Blue/Greenデプロイは2025年7月にリリースされたばかりの機能でした。実装を開始した時点では、第三者視点の日本語の技術記事はほとんどなく、AWS公式のドキュメントと公式ブログ記事が主な情報源でした。AWS公式ブログの記事を何度も読み返し、ドキュメントの各セクションを丁寧に確認しました。
特に、デプロイライフサイクルフックの動作やService Connectとの組み合わせ方については、複数のドキュメントを横断的に参照する必要がありました。
GitHubのissueやコミュニティフォーラムも確認しましたが、まだ事例が少なく、具体的な実装例を見つけるのは困難でした。AWSのサポートにもお世話になり、現状のアーキテクチャを踏まえたベストプラクティスの模索についても相談させていただきました。
2. ライフサイクルフックの制約
デプロイライフサイクルフックは、デプロイの各段階でLambda関数を実行できる機能です。当初は、このフックを使ってGreen環境のヘルスチェックや統合テストを実行し、問題がなければトラフィックを切り替えるという流れを想定していました。
しかし、実際に実装を進めると、各フックでできることとできないことに制約があることを発見しました。
POST_TEST_TRAFFIC_SHIFTフックではGreen環境の基本的なヘルスチェックを行えますが、本来やりたかったことはより詳細な検証でした。
当初の理想:
多少のトラフィックをGreen環境に流した後、New Relicなどの監視ツールでメトリクス（エラーレート、P95 Latency、データポイント数など）を確認し、問題がないことを確認してから本番環境への移行を承認するという流れです。
現実と解決方法:
しかし、実装を進める中で、フックから監視ツールのAPIを呼び出してメトリクスを取得し、その結果に基づいて承認/却下の判定を自動化することは、複数の技術的な制約により実現が難しいとわかりました。
具体的には以下の課題がありました。まず、New Relic APIからメトリクスを取得するまでに一定の遅延が発生します。デプロイ直後のデータポイントはまだ十分に集約されていないということもあり、正確な判定には数分の待機が必要となる場合があります。一方、デプロイライフサイクルフックのタイムアウトは有限であり、待機時間を確保しつつ判定ロジックを実行することのバランスが難しくなります。
また、メトリクス評価自体の複雑性も課題でした。エラーレート、レイテンシ、データポイント数など複数のメトリクスを評価する際、単純な閾値比較では不十分で、統計的な異常検知や相関分析を必要とするケースが多いです。こうした判定ロジックをフック内に実装するのは、可視性と保守性が低下します。さらに、フック実行中に外部API呼び出しが失敗した場合の再試行戦略やエラーハンドリングも複雑になります。
結果として、New Relicによる自動監視は見送り、デプロイ後の検証は運用チームが手動でダッシュボードを確認する形でカバーすることになりました。この判断により、複雑で脆い自動化よりも、確実で保守性の高いプロセスを優先できました。
3. Temporalワークフローエンジンの同期制御
我々のアプリケーションは、Temporalというワークフローエンジンを使用しています。Temporalは、長時間実行されるワークフローやタスクの実行を管理する分散システムです。ECSタスク内でTemporalワーカーを実行し、タスクキューからタスクを取得して処理しています。
Blue/Greenデプロイでは、一時的にBlue環境とGreen環境の両方が共存します。この期間中、両方の環境でTemporalワーカーが起動している状態だと、同じタスクキューからタスクを取得してしまい、二重処理の恐れもあります。
また、実行中のワークフローが存在する場合、Blue環境からGreen環境へ切り替える際にワークフローの実行も中断されるリスクもありました。
解決方法:
この問題を解決するため、Redisを使った状態管理とベイクタイム(トラフィック切り替え後、旧環境を削除するまでの猶予期間)を組み合わせました。
まず、Redisに現在のバージョン(Blue環境/Green環境)を保持し、Workflow使用時にこのバージョンを参照するようにしました。これにより、Blue環境とGreen環境で異なるタスクキューに接続させ、二重処理を防ぐことができました。
さらに、ベイクタイムを活用しました。我々が開発しているサービスではまだ10分を超えるような重い処理は行われていないため、ベイクタイムを10分に設定し、トラフィック切り替え後もBlue環境のワーカーで実行中のワークフローが確実に完了することを担保しました。
なお、将来的に10分を超える長時間ワークフローが必要になった場合は、以下のような対策を検討しています: - ベイクタイムの延長(ただし、デプロイ完了までの時間とコストとのトレードオフを考慮)
4. HTTPヘッダーのgRPC内伝播
前提: マイクロサービス+モジュラモノリス構成
我々のシステムは、複数のマイクロサービス（accountサービスなど）と、複数のドメインをまとめたmodularというモジュラモノリス型サービスで構成されています。これらのサービス間通信はgRPCで行われており、Service Connectを利用してサービスディスカバリーと負荷分散を実現しています。
Service Connectを使用したサービス間通信では、HTTPリクエストがgRPCメタデータに変換されて転送されます。我々のアプリケーションでは、ダークカナリアリリースのテスト用トラフィックを識別するために、HTTPヘッダーに特定の値を設定していました。このヘッダーをGreen環境に送る必要がありました。
解決方法:
Service Connectの設定では、HTTPヘッダーをgRPCメタデータとして転送する設定が必要でした。デフォルトでは、すべてのHTTPヘッダーが自動的にgRPCメタデータに変換されるわけではないため、明示的な設定が必要でした。実装時には、ヘッダーが意図通りに伝播されているかを確認するために、Green環境のログを詳細に確認しました。
また、ヘッダーの名前がgRPCメタデータのキーとしてどのように変換されるかも確認する必要がありました。gRPCメタデータのキーは小文字に変換されるため、アプリケーション側でヘッダーを参照する際にも注意が必要でした。
さらに、ヘッダーの値に特殊文字が含まれている場合の扱いにも注意が必要でした。Service Connectの設定とアプリケーション側の実装を調整することで、最終的にヘッダーを正確に引き回せるようになりました。
5. IP制限をWAFへ移行
既存のシステムでは、WAFとALBのリスナールールの両方を組み合わせてIP制限を実装していました。WAFで基本的なアクセス制御を行いつつ、ALBのリスナールールで特定のIPアドレスからのアクセスのみを許可するルールを追加で設定していました。
ですが、Blue/Greenデプロイでは、Blue環境用とGreen環境用の2つのターゲットグループが必要です。ALBのリスナールールは複数のルールを設定できます。Blue/Greenデプロイの仕様上、Blue用とGreen用の2つのターゲットグループに対するルールが自動的に作成されます。しかしこれら以外のルールを追加しようとすると、デプロイ時にECSが自動的にリスナールールを作成・更新する仕組みと衝突し、手動で追加したルールとBlue/Green用のルールの優先度が不確定になるリスクを孕んでいます。その結果、トラフィックが意図しないターゲットグループにルーティングされたり、デプロイ中にルールが予期せず削除・変更される現象に直面しました。
この制約に対応するため、IP制限の実装をすべてWAFへ移行しました。WAFでは、IPセットを定義し、それに基づいてアクセス制御を行うことができます。ALBのリスナールールとは独立して動作するため、Blue/Greenデプロイの動作に影響を与えません。
WAFへの移行は、既存のIP制限ルールをWAFのIPセットに統合することから始めました。移行期間中は、リスナールールとWAFの両方でIP制限を維持し、段階的にWAFに集約しました。並行運用期間では、両方の設定が正常に動作していることを確認しながら進めました。
WAFへの完全移行により、IP制限の管理が一元化され、Blue/Greenデプロイの制約からも解放されました。また、WAFではより柔軟なアクセス制御が可能になったため、将来的な拡張性も向上しました。
6. そもそもそんなにインフラの知識がなかったのでキャッチアップに時間を要した
実装を開始した時点では、ECSやALB、VPCなどの基本的な概念は理解していましたが、Blue/GreenデプロイやService Connectの詳細な動作については、十分な知識がありませんでした。
理解する必要があった主な概念は以下の通りです。
- ECSのタスク定義、サービス、ターゲットグループの関係
- ALBのリスナールールとターゲットグループの紐付け
- VPCとセキュリティグループによるネットワーク制御
- Service Connectの内部動作とDNS解決の仕組み
AWS公式ドキュメントを読み込むことから始めました。特に、ECSのデプロイ戦略に関するドキュメントと、Service Connectのアーキテクチャドキュメントを重点的に読みました。
また、社内のインフラに詳しいメンバーに質問し、既存のインフラ構成を理解することも重要でした。実際の環境でどのように設定されているかを確認することで、ドキュメントだけでは理解しにくい部分を補完できました。
ハンズオン形式で、小さなサンプルアプリケーションを使ってBlue/Greenデプロイを試してみることも有効でした。実際に手を動かすことで、デプロイの流れや各リソースの関係性を理解できました。
理解が深まったポイントとしては、デプロイ時に自動的に作成されるリソースのライフサイクルを把握できたことです。どのタイミングでどのリソースが作成され、どのタイミングで削除されるかを理解することで、デプロイプロセス全体を把握できるようになりました。
副次的なメリット
Blue/Greenデプロイの導入により、当初の目的である安全なデプロイの実現に加えて、予想外のメリットも得られました。我々の開発組織は、同じ基盤を2チームで開発していることもあり、ステージング環境が逼迫していました。ステージング環境を使用する際は、他のチームとの調整が必要で、開発効率が落ちていました。
Blue/Greenデプロイの導入により、ステージング環境を占有することなく、Green環境を用いて検証が可能になりました。Green環境は本番環境と同じ構成で動作するため、ステージング環境での検証と同等の信頼性を持ちながら、他のチームの作業を妨げることなく検証を進められます。この結果、プロセスを早く回せるようになり、開発サイクルの改善につながりました。
全体を通しての学び
今回の実装を通じて、いくつかの重要な学びがありました。デプロイ戦略の選択は、アプリケーションの特性やチームの状況を考慮して決定する必要があります。Blue/Greenデプロイは強力な機能ですが、実装には相応の理解と準備が必要です。特に、Service ConnectやTemporalのような外部システムと組み合わせる場合は、それぞれの動作を深く理解する必要があります。
新機能を導入する際は、ドキュメントが少ない可能性を前提に、公式ドキュメントを徹底的に読み込むことが重要です。また、実際に小さな環境で試してみることで、ドキュメントだけでは理解しにくい部分を補完できます。チーム内での知識共有も重要でした。実装中に得た知見をドキュメント化し、他のメンバーと共有することで、チーム全体の理解が深まりました。
インフラ知識は、一度にすべてを理解するのではなく、段階的に習得していくことが現実的です。今回の実装では、必要に応じて都度学習を進めることで、必要な知識を身につけることができました。
まとめ
ECS native Blue/Greenデプロイは、安全なデプロイを実現する強力な機能です。しかし、Service Connectやライフサイクルフックなど、理解すべき要素が多く、実装には相応の時間と学習が必要でした。特に、Temporalのような外部システムと組み合わせる場合は、それぞれの動作を深く理解し、適切に同期を取る必要があります。また、既存のインフラ構成（IP制限など）との整合性も考慮する必要がありました。
今後、同様の実装を検討している方へのアドバイスとしては、まずは小さな環境で試してみること、公式ドキュメントを徹底的に読み込むこと、そして必要に応じて社内の知見者に相談することが重要です。
本記事が、ECS native Blue/Greenデプロイの実装を検討している方の参考になれば幸いです。
