AWS CodeDeploy から Amazon ECS 組み込みブルー/グリーンデプロイへの移行

この記事は Migrating from AWS CodeDeploy to Amazon ECS for blue/green deployments (記事公開日: 2025 年 9 月 16 日) を翻訳したものです。

ブルー/グリーンデプロイは、同一環境で実行している 2 つの異なるバージョンのアプリケーション間でトラフィックを切り替えることで、新しいソフトウェアをリリースできます。これにより、新しいバージョンのアプリケーションの安全なテストを促進し、ほぼゼロダウンタイムでのロールバック機能を提供することで、新しいソフトウェアリリースのデプロイに伴う一般的なリスクを軽減します。

最近まで、Amazon Elastic Container Service (Amazon ECS) は、ネイティブなデプロイ戦略としてローリングアップデートのみをサポートしていました。ブルー/グリーンデプロイを実装したい場合は AWS CodeDeploy を使用する必要がありましたが、最近リリースされた ECS ブルー/グリーンデプロイによりサポートされました。

ECS ブルー/グリーンデプロイは CodeDeploy と同様の機能を提供しますが、利用可能な機能とその実装にはいくつかの違いがあります。この記事は、現在 Amazon ECS でのブルー/グリーンデプロイに CodeDeploy を使用しており、新しい Amazon ECS ネイティブなデプロイ戦略への移行を検討しているお客様を対象としています。 (1) 移行を計画する際に考慮すべき要因 (2) CodeDeploy の概念を ECS ブルー/グリーンデプロイの同等機能にマッピングすること (3) 移行戦略についてのガイダンスを提供します。

移行の計画

CodeDeploy から ECS ブルー/グリーンデプロイに移行する際は、計画プロセスの一部として以下の点を考慮する必要があります。

• 新たな可能性： ECS ブルー/グリーンデプロイは、 CodeDeploy ではサポートされていない多数のユースケースを可能にします。これには以下が含まれます。
  • サービスディスカバリーオプション：CodeDeploy は Elastic Load Balancing (ELB) の背後に配置された ECS サービスのみをサポートしますが、ECS ブルー/グリーンデプロイは ELB と ECS Service Connect の両方をサポートします。
  • ヘッドレスサービスサポート：ECS ブルー/グリーンデプロイは、キュー処理サービスなど、サービス公開が不要な状況で使用できます。
  • Amazon EBS サポート：ECS ブルー/グリーンデプロイは、ECS サービスのデプロイ時に Amazon Elastic Block Store (Amazon EBS) ボリュームの設定をサポートします。
  • 複数のターゲットグループ：ECS デプロイコントローラーにより、サービスを複数のターゲットグループに関連付けることができます。これは、複数のロードバランサーを通じて同時にアクセス可能であることを意味します (例：内部および外部サービス公開の分離) 。
  • 柔軟な ALB リスナー設定：CodeDeploy は異なるサービス、本番およびテストエンドポイントに対して別々のリスナーが必要です。ECS ブルー/グリーンはリスナールールレベルで動作するため、ホスト名、HTTP ヘッダー、パス、メソッド、クエリ文字列、またはソース IP に基づく高度なリクエストルーティングを使用して単一のリスナーを活用できます。例えば、パスベースルーティングを使用して複数のサービスに共通のリスナーポートを使用し、クエリ文字列ベースルーティングを使用して A/B テストをサポートできます。同じリスナーポートでブルー/グリーンの本番およびテストトラフィックもサポートできます。
• 運用上の改善： ECS ブルー/グリーンデプロイは、 (1) 既存の Amazon ECS 機能 (サーキットブレーカー、デプロイ履歴、ライフサイクルフックなど) との整合性の向上により、異なるAmazon ECS デプロイ戦略間の移行を支援し、 (2) ライフサイクルフックの実行時間の延長 (CodeDeploy のフックは 1 時間に制限) 、 (3) AWS CloudFormation サポートの改善 (サービスリビジョンとライフサイクルフック用の個別の AppSpec ファイルが不要) を提供します。
• API/CLI の違い： API (および関連する CLI コマンド) に違いがあります。ある API から別の API へのマッピングは通常簡単ですが、ECS ブルー/グリーンデプロイはデプロイステップを制御するためにライフサイクルフックをより広範囲に使用することに注意してください。例えば、CodeDeploy が新しいデプロイをテストするための待機時間オプション (本番トラフィックを再ルーティングする前) をサポートしているのに対し、ECS ブルー/グリーンデプロイではこれを実現するためにフックを使用する必要があります。
• コンソールの違い： 運用の一部として CodeDeploy コンソールを使用している場合、Amazon ECS コンソールがデプロイの進行の手動オーバーライドオプション (例：強制再ルーティングまたはベイク時間の早期終了) を提供していないことに注意してください。代わりに、Amazon ECS ライフサイクルフック (より安全なアプローチと言える) を通じて、より広範な運用プロセスと統合されたカスタム UI を作成できます。
• 移行パス： CodeDeploy から ECS ブルー/グリーンデプロイにサービスを移行するために利用可能な多数のオプションがあり、環境に最適なものを検討する必要があります。これらのオプションと関連する長所と短所については、この記事の後半でより詳細に説明します。
• パイプラインサポート： 既存のパイプラインツールでは、ECS ブルー/グリーンデプロイのサポートが最初は制限される可能性があります。より高度なパイプライン統合では、暫定期間中にカスタムアクションの使用が必要になる場合があります。この記事の執筆時点では、CodePipeline Amazon ECS「標準」アクションを使用して、ECS ブルー/グリーンデプロイを通じてコンテナイメージの変更をデプロイできます (ただし、他のサービス設定変更はできません) 。

CodeDeploy から ECS ブルー/グリーンデプロイへ

ECS ブルー/グリーンデプロイへの移行の実装コストを見積もる際は、APIの 違いと、CodeDeploy の機能を ECS ブルー/グリーンデプロイの同等機能にどのようにマッピングできるかを理解する必要があります。CodeDeploy の「一括」設定から開始することを前提として、このセクションでは主要な違いについて説明します。

ロードバランサー設定と ECS サービスの作成

CodeDeploy を使用して Amazon ECS サービスを作成する場合、まず本番リスナーと (オプションで) テストリスナーを持つロードバランサーを作成します。各リスナーは、図 1 (a)に示すように、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする単一の (デフォルト) ルールで設定されます。次に、リスナーとターゲットグループを使用するように設定された Amazon ECS サービスを作成し、デプロイコントローラーのタイプを CODE_DEPLOYに設定します。サービスの作成により、指定されたターゲットグループに登録された (ブルー) タスクセットが作成されます。

ECS サービスが作成されると、CodeDeploy デプロイグループを (CodeDeploy アプリケーションの一部として) 作成し、ECS クラスター、ECS サービス名、ロードバランサーのリスナー、2 つのターゲットグループ (本番リスナールールで使用されるプライマリターゲットグループと、置換タスクに使用されるセカンダリターゲットグループ) 、AWS Identity and Access Management (IAM) の CodeDeploy に Amazon ECS および ELB リソースを操作する権限を付与するサービスロール、およびデプロイ動作を制御する様々なパラメータの詳細を設定します。

ECS ブルー/グリーンデプロイは、Amazon ECS サービス自体にデプロイ設定を指定します。ロードバランサーの本番リスナーは、重み 1 と 0 に設定された 2 つのターゲットグループを含むルールで事前設定されている必要があります。ECS サービス作成の一部として、このリスナールールの Amazon Resource Name (ARN)、2 つのターゲットグループ、IAM ロール (Amazon ECS にリスナーとターゲットグループを操作する権限を付与するため)、 デプロイコントローラーのタイプを ECS に設定、および deploymentConfiguration.strategy を BLUE_GREEN に設定します。これにより、プライマリターゲットグループに登録されたタスクを持つ (ブルー) サービスリビジョンが作成されます。

両方のアプローチともタスクの初期セットの作成という結果になりますが、基盤となる実装は、CodeDeploy がタスクセットを使用するのに対し、Amazon ECS はサービスリビジョンを使用するという点で異なります。後者は Amazon ECS サービスデプロイ API の一部として導入され、デプロイプロセスとサービスデプロイ履歴への可視性を向上させます。

サービスリビジョンのデプロイ

図 2 は、新しいサービスリビジョンがどのようにデプロイされるかを示しています。CodeDeploy は CreateDeployment() を使用してサービスの新しいバージョンをデプロイし、CodeDeploy アプリケーション名、デプロイグループ名、および  AppSpec ファイル内のリビジョン詳細を指定します。これには、新しいリビジョンのタスク定義と、使用するコンテナ名およびポートが含まれている必要があります。ECS ブルー/グリーンデプロイは、UpdateService() を呼び出して置換タスク定義の詳細を渡すことで、新しいサービスデプロイを作成します。

オプションで、CodeDeploy の AppSpecファイルは、ネットワーク設定やキャパシティプロバイダー戦略などのより多くのサービス設定変更を指定し、ライフサイクルフックを指定するためにも使用できます (次のセクションを参照) 。Amazon ECS を使用する場合は、UpdateService() を使用してこれらの変更を指定します。

図 3 は、トラフィック再ルーティングが実現される方法の違いを示しています。CodeDeploy では、デプロイが置換 (グリーン) タスクセットを作成し、そのタスクをセカンダリターゲットグループに登録します。これが正常になると、テスト (オプション) および本番で利用可能になります。どちらの場合も、再ルーティングは、グリーンタスクセットに関連付けられたセカンダリターゲットグループを指すように各リスナールールを変更することで実現されます。ロールバックは、本番リスナールールをプライマリターゲットグループに戻すことで実現されます。

対照的に、ECS ブルー/グリーンデプロイでは、サービスデプロイが (グリーン) タスクを持つ新しいサービスリビジョンを作成し、それらをセカンダリターゲットグループに登録します。その後、再ルーティングとロールバックは、リスナールールの重みを切り替えることで実現されます。

ライフサイクルフック

CodeDeploy と ECS ブルー/グリーンデプロイの両方とも (オプションの) ライフサイクルフックをサポートしており、特定のライフサイクルイベントによって AWS Lambda 関数をトリガーできます。フックは、カスタムロジックでデプロイワークフローを拡張するのに役立ちます。例えば、ライフサイクルフックを使用して、本番ポートにライブトラフィックを再ルーティングする前に、テストポートでのテストを自動化できます。

CodeDeploy と ECS ブルー/グリーンデプロイは大まかに類似したライフサイクルに従いますが、設定オプションとライフサイクルフックの指定方法に違いがあります。

• CodeDeploy は、 CreateDeployment() に提供される AppSpec ファイルの一部としてライフサイクルフックを指定します。これは、すべてのデプロイでフックを設定する必要があることを意味します。ECS ブルー/グリーンデプロイは、サービス設定の一部としてフック (Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可) を指定し、変更には UpdateService() 呼び出しが必要になります。
• CodeDeploy と Amazon ECS のライフサイクルイベントは同等ですが、以下の表に示すように異なる名前を持ちます。

• CodeDeploy と ECS ブルー/グリーンデプロイの両方ともフック実装に Lambda を使用しますが、期待される入力と出力は異なり、特に Lambda 関数がフックステータスのレスポンスを返す方法が異なります。CodeDeploy では、関数は PutLifecycleEventHookExecutionStatus() を呼び出してフック実行ステータスを返す必要があり、これは Succeeded または Failed のいずれかになります。Amazon ECS では、Lambda のレスポンス自体がフック実行ステータスを示すために使用されます。
• CodeDeploy は各フックを 1 回限りの呼び出しとして実行し、1 時間以内に最終実行ステータスが返されることを期待します。Amazon ECS フックはより柔軟で、IN_PROGRESS インジケーターを返すことができ、これは SUCCEEDED または FAILED になるまでフックが繰り返し再実行されるべきであることを示します。フックはデフォルトで 30 秒ごとに実行されますが、レスポンスのパラメータを渡すことで次の実行のタイミングを設定できます。

その他の実装上の考慮事項

CodeDeploy はデプロイグループの詳細オプションの設定を提供しており、これらを Amazon ECS の同等機能にマッピングする必要がある場合があります。これには以下が含まれます。

• Amazon Simple Notification Service (Amazon SNS) トリガー：Amazon ECS からの Amazon EventBridge イベントを使用して、状態変更を SNS トピックに発行します。
• Amazon CloudWatch アラーム検出と自動ロールバック：Amazon ECS デプロイの失敗検出機能を使用します。

移行パス

CodeDeploy と ECS ブルー/グリーンデプロイ間の実装の違いを考慮した後、適切な移行アプローチを特定する必要があります。いくつかのオプションが利用可能であり、アーキテクチャと要件に最も適合するものを評価する必要があります。関与する要因には以下が含まれます。

• ダウンタイム：ダウンタイムは発生するか、発生する場合はどの程度の時間か？
• CodeDeploy へのロールバック：ECS ブルー/グリーンデプロイへの切り替えがうまくいかない場合に、移行をロールバックする能力を保持する必要があるか？これは「ブルー/グリーンソリューションのためのブルー/グリーン戦略！」と考えることができます。
• サービスディスカバリー：サービスアドレスの変更 (新しい ALB の URI) に対応できるか、それとも同じアドレスを保持する必要があるか？
• パフォーマンスおよび/またはデプロイの速度
• コスト

ロードバランサーの背後に配置された ECS サービスを継続して使用する場合、以下の移行オプションは、Amazon ECS サービス自体とロードバランサーのリソースの両方を考慮して、既存のリソースをどの程度再利用するかについての様々なバリエーションを示しています。すべての場合において、Amazon ECS デプロイコントローラーに渡すための IAM ロールを作成する必要があり、これにより必要なロードバランサーリソースを操作できるようになります。

オプション 1：インプレース更新

このアプローチでは、既存の Amazon ECS サービスを更新して、CodeDeploy デプロイコントローラーではなく、ブルー/グリーンデプロイ戦略を持つ Amazon ECS デプロイコントローラーを使用します。CodeDeploy で使用されているのと同じロードバランサーリスナーとターゲットグループを再利用します。前述のように、CodeDeploy は、サービスに接続されたロードバランサーのリスナーを、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする単一の (デフォルト) ルールで設定します。ECS ブルー/グリーンデプロイの場合、ロードバランサーリスナーは、重み 1 と 0 に設定された 2 つのターゲットグループを含むルールで事前設定されている必要があります。したがって、以下のステップが必要です。

1. 本番/テストリスナーのデフォルトルールを変更して、代替ターゲットグループを含め、ターゲットグループと代替ターゲットグループの重みをそれぞれ 1 と 0 に設定します。
2. UpdateService() を呼び出して既存の Amazon ECS サービスを更新し、パラメータdeploymentController を ECS に、パラメータ deploymentStrategy を BLUE_GREEN に設定します。IAM ロール、ターゲットグループ、代替ターゲットグループ、本番リスナールール、およびテストリスナールール (オプション) の ARN を渡します。
3. Amazon ECS デプロイコントローラーが代替ターゲットグループの下で新しいタスクを持つ新しいサービスリビジョンを作成し、すぐにこのターゲットグループにトラフィックを再ルーティングします。これが完了するまで待機し、その後サービスが期待どおりに動作していることを確認します。
4. ECS ブルー/グリーンデプロイを使用するようになったら、この Amazon ECS サービス用の CodeDeploy リソースを削除します。

インプレース更新は安全な操作ですが、 (1) 手動エラーの可能性を最小限に抑えるためにプロセスを自動化し (特にリスナー設定を変更する場合) 、 (2) 開発者および/または UAT 環境でこのプロセスを徹底的にテストすることに注意する必要があります。また、Amazon ECS コントローラーがサービスリビジョンの初期作成を完了するとすぐにトラフィックが再ルーティングされることも認識しておく必要があります。さらに、再ルーティング前にこのリビジョンをテストするオプションはありません (ただし、タスクは CodeDeploy で実行されていたタスクセットと同一である必要があります) 。

オプション 2：新しい ECS サービスと既存のロードバランサー

このアプローチは移行にブルー/グリーン戦略を使用します (言い換えれば、ブルー/グリーンソリューションのためのブルー/グリーン移行です) 。ECS ブルー/グリーンデプロイを使用して新しい並列ブルー/グリーンセットアップを作成し、それを検証し、CodeDeploy セットアップから新しい ECS ブルー/グリーンデプロイセットアップに切り替え、その後 CodeDeploy リソースを削除します。

1. 必要に応じてこのセットアップにロールバックできるように、CodeDeploy セットアップ用のリスナー、ターゲットグループ、および Amazon ECS サービスをそのまま残しておきます。
2. 既存のロードバランサーの下に新しいターゲットグループと新しいリスナー (元のリスナーとは異なるポート) を作成します。その後、既存の Amazon ECS サービスと一致する新しい Amazon ECS サービスを作成しますが、デプロイコントローラーとして ECS を使用し、デプロイ戦略として BLUE_GREEN を使用し、IAM ロール、新しいターゲットグループ、および新しいリスナールールの ARN を渡します。
3. 新しいセットアップを検証します (新しいリスナーのポートを使用) 。すべてがうまくいけば、元のリスナーのポートを異なるポート番号に変更し (元のポートを解放するため) 、新しいリスナーのポートを元のポートに切り替えて、新しいセットアップにトラフィックをルーティングします。
4. 新しいセットアップを観察し、すべてが期待どおりに動作し続けたら、CodeDeploy セットアップを削除できます。

図 4 はこのアプローチを示しています。

前述のアプローチと同様に、このアプローチは移行にブルー/グリーン戦略を使用します。主な違いは、CodeDeploy セットアップから ECS ブルー/グリーンデプロイセットアップへの切り替えが、ロードバランサーの上の別のルーティング層で行われることです (図 5 に示すとおり) 。この層の実装例には、Amazon Route 53、Amazon API Gateway、および Amazon CloudFront が含まれます。

このアプローチは、すでにこのルーティング層を持っているユーザーに適しており、Amazon ECS サービスとのすべての通信がその層を通じて行われている場合 (つまり、ロードバランサーレベルでの直接通信がない場合) に適用できます。オプション 2 と比較すると、このオプションはゼロダウンタイムという利点がありますが、少しコストが高くなります。

以下の表は、これら 3 つの移行アプローチを、あなたにとって重要度が異なる可能性のある多数の要因で比較しています。この表を使用して、あなた自身の特定の状況と優先事項に最も適したオプションを評価できます。

まとめ

この記事では、AWS CodeDeploy から Amazon ECS の組み込みブルー/グリーンデプロイへの移行について説明しました。この議論には以下が含まれていました。

• 移行を決定する前に考慮すべき要因
• 主要なアーキテクチャの違いと関連する実装上の考慮事項
• 移行にアプローチする 3 つの異なる方法

現在 CodeDeploy を使用しており、ECS ブルー/グリーンデプロイへの移行を検討している場合は、この記事を実現可能性を評価し、移行を計画するためのガイドとして使用できます。ECS ブルー/グリーンデプロイの詳細については、Amazon ECS の開発者ガイドをご確認ください。

翻訳はソリューションアーキテクトの加治が担当しました。原文はこちらです。