Amazon Web Services ブログ

Amazon ECS Service Connect を使用したブルー/グリーンデプロイプロセスにおけるサービス間通信の効率化

この記事は Streamline service-to-service communication during deployments with Amazon ECS Service Connect (記事公開日 : 2025 年 7 月 28 日) の翻訳です。

コンテナ化されたマイクロサービスをデプロイする際、更新中の信頼性の高いサービスディスカバリーと効率的なルーティングを維持することは大きな課題です。従来のブルー/グリーンデプロイアプローチは、トラフィック管理にロードバランサーを大きく依存しており、コンテナベースのサービス間通信を扱う場合に複雑になる可能性があります。この複雑さにより、サービス中断の可能性が高まり、本番トラフィックを新バージョンに向ける前に、新バージョンを分離環境でテストすることが困難になります。

Amazon Elastic Container Service (Amazon ECS) と Amazon ECS Service Connect を使用したブルー/グリーンデプロイの組み合わせは、これらの課題に対する直接的なソリューションを提供します。この統合により、共有名前空間内にテストトラフィックルーティング機能を導入することで、従来のブルー/グリーンデプロイモデルが強化されます。これにより、ほぼゼロのダウンタイムでマイクロサービスの新バージョンをデプロイし、分離環境で徹底的にテストし、必要に応じて迅速にロールバックする能力を維持できます。この記事では、コンテナ化されたアプリケーションのより効率的で回復力のあるデプロイプロセスを作成するために、この強力な組み合わせを実装する方法を説明します。

機能の概要

ブルー/グリーンデプロイは、2つの同一だが別個の環境を維持します：現在の本番バージョン用のブルー環境と新バージョン用のグリーン環境です。ローリングアップデートとは異なり、両方のバージョンが同時に実行され、それらの間でコントロールされたトラフィックシフトが行われ、迅速なロールバックとほぼゼロのダウンタイム移行が可能になります。

ECS Service Connect は、管理されたサービスディスカバリーと自動サイドカープロキシインジェクションを通じてコンテナ化されたアプリケーション通信を効率化します。これにより、サービスは共有名前空間内で直接的な論理名を使用して簡単に相互を発見し通信できるようになります。

ブルー/グリーンデプロイと ECS Service Connect の組み合わせは、組み込みのサービスディスカバリーと信頼性の高いルーティングを通じてトラフィック管理を強化します。これにより、チームは改善された信頼性と最小限のサービス中断でデプロイを行うことができます。

図1：ブルー/グリーンデプロイワークフローの Amazon ECS サービス状態
図1：ブルー/グリーンデプロイワークフローの Amazon ECS サービス状態

ブルー/グリーンデプロイプロセスは、上図に示すように、安全で制御された移行を支援するために設計された3つの明確な調整フェーズを通じて管理されます：

  1. 初期デプロイ状態：両方の環境は展開されていますが、トラフィックはまだグリーンタスクにルーティングされていません。
  2. 進行中のデプロイ状態：テストトラフィックはブルータスクからグリーンタスクにルーティングされます。検証が成功すると、ECS Service Connect Proxy の自動構成変更により、本番トラフィックもグリーンタスクにルーティングされます。
  3. 最終的なデプロイ状態：設定可能なベイク時間中は、必要に応じてすばやくロールバックできるように両方の環境がスケーリングされたままになります。

デプロイワークフローはライフサイクルステージによって管理されます。これはデプロイプロセスの正確なポイントであり、きめ細かい制御と検証を可能にします。各ステージは特定のデプロイイベント（例えば、POST_TEST_TRAFFIC_SHIFT、PRE_PRODUCTION_TRAFFIC_SHIFT）を表し、関連付けられたライフサイクルフックをトリガーすることができます。これらのフックは検証チェックやカスタムロジックを実行する AWS Lambda 関数です。

例えば、POST_TEST_TRAFFIC_SHIFT フックは、全ての本番トラフィックを切り替える前にテストトラフィックをシミュレートすることでグリーン環境を検証できます。この検証プロセスは、各フェーズでの品質基準の適合を強制することでデプロイの信頼性を高め、サービス中断のリスクを最小限に抑えます。Amazon ECS ブルー/グリーンライフサイクルステージの詳細については、AWS ドキュメントを参照してください。

ECS Service Connectによるブルー/グリーンデプロイの理解

ECS Service Connect は、Amazon ECS タスク内に組み込まれたルーティング機能を通じてバージョン移行を管理することで、ブルー/グリーンデプロイを効率化します。DNS 更新とロードバランサーの再構成が必要な従来のアプローチとは異なり、ECS Service Connect はサイドカープロキシを通じてルーティングを処理し、明確な移行を作成します。

ブルー/グリーンデプロイ中、ECS Service Connect はバージョン間の正確なトラフィック制御を可能にするヘッダーベースのルーティングメカニズムを採用します。アプリケーションコードは変更されないままで、インフラストラクチャがバージョンターゲティングを処理します。以下は、特定のヘッダー名（$HEADER）とヘッダー値（$VALUE）を持つ testTrafficRules を設定する方法の例です。

"serviceConnectConfiguration": {
	/* ... */
	"testTrafficRules": {         // グリーンデプロイへのテストトラフィックをルーティング
		"header": {               // テストトラフィック用のヘッダーベースルーティング
			"name": "$HEADER",    // カスタムヘッダー名
			"value": {
				"exact": "$VALUE" // ヘッダー値の完全一致
			}
		}
	}
}

以下は POST_TEST_TRAFFIC_SHIFT ライフサイクルフックの設定例です。利用可能なライフサイクルステージの完全なリストは AWS ドキュメントで確認できます。

"deploymentConfiguration": {
   "strategy": "BLUE_GREEN",
   "bakeTimeInMinutes": 2,       // ブルー環境の設定可能なベイク時間
   "lifecycleHooks": [           // ライフサイクルフック設定
       {
           "hookTargetArn": "$AWS_LAMBDA_FUNCTION",   // AWS Lambda関数ARN
           "roleArn": "$ECS_LAMBDA_INVOKE_ROLE",      // Lambda呼び出し用のロール
           "lifecycleStages": [
               "POST_TEST_TRAFFIC_SHIFT"              // ライフサイクルステージ
           ]
       }
   ]
}

ECS Service Connect は、アプリケーションコードをデプロイから分離するのに役立つ組み込みプロキシレイヤーを導入することで、デプロイの仕組みを変更します。開発者はデプロイの懸念事項なしに機能の構築に集中でき、運用チームはアプリケーションコードに触れることなく改善されたリリース戦略を実装できます。この分離により、チーム間で通常必要とされる調整が不要になり、コンテナ化されたアプリケーションのリリースプロセス全体が効率化されます。

ブルー/グリーンテスト戦略

ブルー/グリーンデプロイの重要なフェーズは、本番トラフィックを切り替える前にグリーン環境を検証することです。ECS Service Connect 内では、テストトラフィックは名前空間内でのみルーティングされるため、テストパターンを実装する際に慎重な検討が必要です。このセクションでは、2つの一般的なパターンを調査します：

Application Load Balancer を通じたヘッダーベースのテスト：このアプローチでは、Application Load Balancer (ALB) のヘッダーパススルー機能を使用します。フロントエンドサービスは特定のヘッダーをバックエンドサービスに転送し、本番トラフィックを分離しながらロードバランサーを通じてグリーン環境を対象としたテストを可能にします。この方法は、トラフィックフローを制御し、サービスの動作を検証するための直接的なメカニズムを提供します。エンドユーザーにテストパスを公開しないようにするために、インターネットに公開されていない専用のロードバランサーを使用し、アプリケーション VPC 内に Lambda 関数をデプロイすることでこのソリューションを強化することをお勧めします。ウォークスルーセクションでは、基本的なヘッダーベースのルーティングアプローチを実装します。

図2：ALBワークフローを通じたヘッダーベースのテスト
図2：ALBワークフローを通じたヘッダーベースのテスト

専用テストサービスの実装：この方法では、名前空間内に専用のテストサービスをデプロイします。以下の図では、POST_TEST_TRAFFIC_HOOK が名前空間内でテストヘッダーを使用してグリーンデプロイを検証するために Amazon ECS サービスをスケールアップします。テストの結果は Amazon S3 バケットに渡されます。関数内のロジックがこの結果を評価します。このアプローチは包括的な検証機能を提供しながら、アーキテクチャの整合性を維持します。ただし、より多くのAWSリソースが必要です。

図3：専用テストサービス実装ワークフロー
図3：専用テストサービス実装ワークフロー

これらの検証戦略により、ECS Service Connect のセキュリティと分離の利点を維持しながら、新しいバージョンの徹底的なテストが可能になり、信頼性の高いデプロイプロセスを確保します。

前提条件

このウォークスルーをデプロイするには、リソースを作成するための必要な権限を持つ AWS アカウントへのアクセス、AWS Command Line Interface (AWS CLI)、および AWS Cloud Development Kit (AWS CDK) が必要です。
また、AWS CLI のバージョン 2.27.51 以降が必要になります。AWS CLI の最新リリースについては、GitHub の AWS CLI version 2 Changelog を参照してください。

このウォークスルー全体を通じて、ECSクラスターと Amazon Virtual Private Cloud (Amazon VPC) にリソースをデプロイします。これらのステップバイステップのコード例は、サンプル GitHub リポジトリ内のAWS CDK アプリで見つけることができます。

ウォークスルー

ECS Service Connect とそのブルー/グリーンデプロイ戦略の核となるコンセプトを調査しました。実際の実装を通じてこれらの原則を実証できます。

このガイドでは、ECS Service Connect と AWS CLI を使用してブルー/グリーンデプロイでサンプルアプリケーションをデプロイする方法を示します。この設定は AWS CloudFormation、AWS Management Console、または他の Infrastructure as Code（IaC）ツールを通じても実装できます。

1. 環境のセットアップ

環境セットアッププロセスには、必要な AWS インフラストラクチャのデプロイと初期サービスの設定が含まれます。必要なリソースを設定するために、これらの手順に従ってください：

  1. GitHub リポジトリをクローンします。 
    $ git clone https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns.git
  2. ライフサイクルフックとして設定される Lambda 関数をビルドします。 
    $ cd sample-amazon-ecs-blue-green-deployment-patterns/ecs-bluegreen-service-connect
$ sh build-lambda-zip.sh
  3. AWS CDK を利用してコアインフラストラクチャをデプロイします。Amazon VPC、ALB、ECS クラスター、Lambda 関数、関連付けられる AWS Identity and Access Management (IAM) ロールを含むCloud Formation スタックを作成します。 
    $ npm install
$ cdk bootstrap
$ cdk deploy
  4. インフラストラクチャをデプロイした後、Cloud Formation スタックの出力から環境変数を設定します。 
    $ source load-env-variables.sh
  5. ECS サービスの初期バージョンのデプロイと必要なタスク定義を作成します。 
    $ sh demo-setup.sh

demo-setup.sh スクリプトは、タスク定義とサービス設定のJSONファイルを含む出力ディレクトリを生成します。これらのファイルは、後続のデプロイ手順で使用されます。これらのファイルは、以下のセクションで使用されるブルー/グリーンデプロイ設定のテンプレートとして機能します。

2. 環境の確認

このデプロイは、以下のコンポーネントを持つ ECS Service Connect を使用したブルー/グリーンデプロイをサポートするアーキテクチャを作成します：

  • ALB を主要なエントリポイントとして、外部トラフィックを管理し、bluegreen-fronend サービスに分散します。
  • 相互接続された2つの Amazon ECS サービスを備えた ECS クラスター：
    • bluegreen-frontend には、ALB からの受信リクエストを処理し、ヘッダーをそのまま転送する nginx ベースのリバースプロキシが含まれています。本番環境では、このフロントエンドサービスにはアプリケーションロジックが含まれますが、このウォークスルーでは簡単のためにただトラフィックを転送するのみです。
    • bluegreen-backend はリクエストを処理し、静的な HTML コンテンツを提供します。
  • ECS Service Connect は、サービスディスカバリーとコンポーネント間のルーティングを行います。
  • Lambda 関数はライフサイクルフックを通じてデプロイ検証を実装します。この機能は POST_TEST_TRAFFIC_SHIFT の段階で起動し、テストトラフィックがグリーン環境にルーティングされるときに重要な検証を行い、デプロイの信頼性を高めます。

以下のアーキテクチャ図は、グリーンバージョンの bluegreen-backend サービスをデプロイする前の初期状態を示しています。

図4：グリーンバージョンのアプリケーションをデプロイする前の初期状態
図4：グリーンバージョンのアプリケーションをデプロイする前の初期状態

デプロイプロセスでは、POST_TEST_TRAFFIC_SHIFT ライフサイクルステージにおいて、Lambda 関数を使用してグリーン環境の検証を実装します。この関数は、指定されたテストヘッダー（x-amzn-ecs-bluegreen-test:test）を ALB エンドポイント（$ALB_URL）に送信することで検証を実行します。

検証結果に基づいて、Lambda 関数は以下の3つの可能な hookStatus 値のいずれかを返し、それぞれが特定のデプロイ動作をトリガーします：

  • SUCCEEDED：デプロイ開始を許可します
  • FAILED：ロールバックをトリガーします
  • IN_PROGRESS：追加の検証リクエストを試みます、試行間隔（デフォルトでは 30 秒）を空けてリトライします

以下の実装コードは、Lambda 関数の検証ロジックを示しています：

import requests
def lambda_handler(event, context):
    """
    Tests blue/green deployment.
    """
    try:
        response = requests.get(
            $ALB_URL,
            headers={"x-amzn-ecs-bluegreen-test": "test"},
            timeout=5
        )
        if response.status_code == 200 and "Green Version" in response.text:
            return {"hookStatus": "SUCCEEDED"}
        else:
            return {"hookStatus": "FAILED"}
    except Exception as e:
        print(f"Error: {str(e)}")
        return {"hookStatus": "FAILED"}

ベースラインアーキテクチャと検証メカニズムを確認しました。グリーンバージョンの実装のために bluegreen-backend サービスの更新を進めます。

3. バックエンドタスクをグリーンバージョンに更新する

環境が設定されたので、グリーンデプロイとして機能する bluegreen-backend サービスの更新バージョンを作成できます。この変更には、背景色をブルーからグリーンに変更する新しいタスク定義の登録が含まれます。新しい背景色によって、デプロイプロセス中のトラフィックルーティングの成功を視覚的に確認できます。

以前に環境セットアップフェーズで生成した JSON ファイルを使用して、新しいタスク定義を登録するために以下のコマンドを実行します：

$ aws ecs register-task-definition \
    --cli-input-json file://outputs/taskdef_backend_update.json

4. ブルー/グリーン戦略を使用してアプリケーションの新バージョンをデプロイする

新しいタスク定義が登録されたので、ECS Service Connect を使用してブルー/グリーンデプロイを実装できます。このセクションでは、制御されたテストと検証を可能にするテストトラフィックルールとライフサイクルフックのような必要なデプロイ設定パラメータを説明します。

デプロイには、新しいタスク定義と必要なトラフィックルーティングルール（serviceConnectConfiguration と deploymentConfiguration）の両方を組み込むためにbluegreen-backend サービス設定を更新する必要があります。

serviceConnectConfiguration セクション：デプロイプロセス中に正確なトラフィックルーティングを定義する testTrafficRules が必要です。これらのルールは、HTTP ヘッダーに基づいてどのリクエストをグリーン環境に向けるべきかを指定し、新バージョンの分離されたテストを可能にします。

"serviceConnectConfiguration": {
    ...
   "services": [{
        ...
        "clientAliases": [{
            ...
            "testTrafficRules": {
               "header": {
                   "name": "x-amzn-ecs-bluegreen-test",
                   "value": {
                       "exact": "test"
                   }
               }
           }
       }]
   }]
},

deploymentConfiguration セクション：適切な検証制御を持つブルー/グリーンデプロイ戦略を実装するために特定のパラメータが必要です。この設定は、Amazon ECS がデプロイプロセスを管理し、Lambda 関数統合によって各ステージで検証を実施する方法を定義します。hookTargetArn は検証のための Lambda 関数を指定し、roleArn は必要なIAM権限を提供し、POST_TEST_TRAFFIC_SHIFT はデプロイ検証チェックが実行されるタイミングを定義します。

"deploymentConfiguration": {
   "strategy": "BLUE_GREEN",
   "bakeTimeInMinutes": 2,
   "lifecycleHooks": [{
       "hookTargetArn": "arn:aws:lambda:us-west-2:1111111111:function:LifeCycleHook",
       "roleArn": "arn:aws:iam::1111111111:role/EcsLambdaInvokeRole",
       "lifecycleStages": [
           "POST_TEST_TRAFFIC_SHIFT"
       ]}
   ]
}

グリーンバージョンの bluegreen-backend サービスをデプロイするために以下のコマンドを実行します。

$ aws ecs update-service \
	--service bluegreen-backend \
	--cli-input-json file://outputs/service_backend_update.json

5. デプロイプロセスの理解

ECS Service Connect を使用したブルー/グリーンデプロイ中、Amazon ECSは新しいグリーン環境タスクを作成することでプロセスを開始し、準備ができると POST_TEST_TRAFFIC_SHIFT ライフサイクルフックのタイミングでテストトラフィックが新しい環境に向けられます。検証プロセスでは、Lambda 関数によってテストヘッダーを持つリクエストが ALB に送信され、ALB はそれらのリクエストをフロントエンドサービスに転送し、ECS Service Connect はグリーンバックエンドへのルーティングを行います。デプロイの成功は Lambda 関数の検証結果に依存し、デプロイを進める（SUCCEEDED）かロールバックをトリガーする（FAILED）かが決まります。

図5：ECS Service Connect ブルー/グリーンデプロイステップ
図5：ECS Service Connect ブルー/グリーンデプロイステップ

この検証メカニズムによって、本番トラフィックの移行が発生する前にグリーン環境が正しく動作していることを確認できます。デプロイプロセスの詳細な仕様と追加の設定オプションについては、AWS ドキュメントを参照してください。

6. アプリケーションの新バージョンの検証

ブルー/グリーンデプロイが完了した後、以下のコマンドを実行して新しいグリーンバージョンが本番トラフィックを正常に処理していることを確認します：

$ curl -s $ALB_DNS | grep "Green Version"

このコマンドは（テストヘッダーなしで）ALBエンドポイントにリクエストを送信し、レスポンス内の「Green Version」テキストを検索します。成功したレスポンスは、本番トラフィックがグリーン環境によって提供されていることを示し、デプロイが正常に完了してトラフィック移行が期待通りに発生したことを確認します。

クリーンアップ

このウォークスルーを完了した後、継続的な課金を防ぎ、整理されたAWS環境を維持するために、デプロイされたすべてのリソースをクリーンアップする必要があります。未使用のリソースを排除することで、予期しない料金が発生するのを防ぎ、AWS環境が整理された状態に保たれます。

  1. 実証セットアップで作成した全てのリソースを削除します。 
    $ sh demo-teardown.sh
  2. AWS CDK でデプロイされたインフラストラクチャコンポーネントを削除します。（削除に失敗した場合は、該当のリソースをコンソール等で削除してください。 
    $ cdk destroy
  3. タスク定義の Amazon Resource Names (ARNs) を取得します。 
    $ aws ecs list-task-definitions --family-prefix bluegreen-backend \
    --query 'taskDefinitionArns[*]'
	
$ aws ecs list-task-definitions --family-prefix bluegreen-frontend \
    --query 'taskDefinitionArns[*]'
  4. $TASK_DEFINITION_ARN の値をステップ3のコマンドで抽出したARNで置き換え、Amazon ECS タスク定義を削除します。 
    $ aws ecs deregister-task-definition \
    --task-definition $TASK_DEFINITION_ARN
	
$ aws ecs delete-task-definitions \
    --task-definitions $TASK_DEFINITION_ARN

結論

Amazon ECS Service Connect とブルー/グリーンデプロイの組み合わせは、サービスディスカバリーの効率化・分離テストの実現・ロールバック機能を備えた信頼性の高いトラフィック移行の提供、によってコンテナ化されたマイクロサービスのデプロイをモダナイズします。この機能がデプロイプロセスをどのように改善し、運用リスクを軽減できるかを楽しみにしています。この機能を Amazon ECS サービスで実装し、この機能をアプリケーションに統合する際のフィードバックを共有してください。詳細については、AWS ドキュメントをご覧ください。

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