Amazon ECS ブルー/グリーンデプロイ用 Service Connect リソース
ブルー/グリーンデプロイで Service Connect を使用すると、ブルーおよびグリーンのサービスリビジョン間に適切なトラフィックルーティングを有効にするため、特定のコンポーネントを設定する必要があります。このセクションでは、必要なコンポーネントとその設定について説明します。
アーキテクチャの概要
Service Connect により、Amazon ECS タスクに自動的に挿入されたマネージドサイドカープロキシを介して、サービス検出およびサービスメッシュ機能の両方が構築されます。これらのプロキシはルーティングの決定、再試行、メトリクス収集を処理し、AWS Cloud Map はサービスレジストリのバックエンドを提供します。Service Connect を有効にしてサービスをデプロイするとサービス自体が AWS Cloud Map で登録され、クライアントサービスは名前空間を介してサービスを検出します。
標準の Service Connect 実装では、クライアントサービスは論理サービス名に接続し、サイドカープロキシは実際のサービスインスタンスへのルーティングを処理します。ブルー/グリーンデプロイを使用すると、このモデルが拡張されて testTrafficRules 設定を介したテストトラフィックのルーティングが含まれます。
ブルー/グリーンデプロイ中は、次の主要コンポーネントが連携します。
-
Service Connect Proxy: サービス間のすべてのトラフィックは Service Connect プロキシを通過し、設定に基づいてルーティングを決定します。
-
AWS Cloud Map 登録: ブルーデプロイおよびグリーンデプロイの両方が AWS Cloud Map に登録されますが、グリーンデプロイは最初は「テスト」エンドポイントとして登録されます。
-
テストトラフィックのルーティング: Service Connect 設定の
testTrafficRulesは、テストトラフィックを識別してグリーンデプロイにルーティングする方法を決定します。リクエストの特定の HTTP ヘッダーがトラフィックをテストリビジョンに転送するヘッダーベースのルーティングによって実現されます。デフォルトでは、カスタムルールが指定されていない場合、Service Connect は HTTP ベースプロトコルのx-amzn-ecs-blue-green-testヘッダーを認識します。 -
クライアント設定: 名前空間内のすべてのクライアントは、本番ルートおよびテストルートの両方を自動的に受けますが、テストルールに一致するリクエストのみがグリーンデプロイに移行されます。
このアプローチが強力なのは、移行中のサービス検出の複雑さを処理するからです。トラフィックがブルーデプロイからグリーンデプロイに移行すると、すべての接続および検出メカニズムが自動的に更新されます。サービスメッシュがすべてを処理するため、DNS レコードを更新したり、ロードバランサーを再設定したり、個別にサービス検出の変更をデプロイしたりする必要はありません。
トラフィックのルーティングとテスト
Service Connect はブルー/グリーンデプロイ用の高度なトラフィックルーティング機能を提供します (テストシナリオ用のヘッダーベースのルーティングやクライアントエイリアス設定など)。
テストトラフィックヘッダーのルール
ブルー/グリーンデプロイ中に、テスト目的のために特定のリクエストをグリーン (新規) サービスリビジョンにルーティングするため、テストトラフィックヘッダーのルールを設定できます。デプロイを完了する前に、トラフィックが制御された新しいバージョンを検証できます。
Service Connect はヘッダーベースのルーティングを使用し、テストトラフィックを識別します。デフォルトでは、カスタムルールが指定されていない場合、Service Connect は HTTP ベースプロトコルの x-amzn-ecs-blue-green-test ヘッダーを認識します。このヘッダーがリクエストに存在すると、Service Connect プロキシによってテストのためにリクエストがグリーンデプロイへと自動的にルーティングされます。
テストトラフィックヘッダーのルールを使用すると、以下を実行できます。
-
特定のヘッダーを持つリクエストをグリーンサービスリビジョンにルーティングする
-
トラフィックのサブセットで新機能をテストする
-
フルトラフィックのカットオーバー前に、サービス動作を検証する
-
Canary テスト戦略を実装する
-
本番のような環境で統合テストを実行する
ヘッダーベースのルーティングメカニズムは、既存のアプリケーションアーキテクチャとシームレスに連携します。クライアントサービスがブルー/グリーンデプロイプロセスを認識する必要はありません。テストリクエストを送信するときに適切なヘッダーを含めるだけで、Service Connect プロキシはルーティングロジックを自動的に処理します。
テストトラフィックヘッダーのルール設定の詳細については、「Amazon Elastic Container Service API リファレンス」の「ServiceConnectTestTrafficHeaderRules」を参照してください。
ヘッダーマッチングルール
ヘッダーマッチングルールは、ブルー/グリーンデプロイ中にテストトラフィックをルーティングする際の基準を定義します。グリーンサービスリビジョンにルーティングされるリクエストを正確に制御するために、複数の一致条件を設定できます。
ヘッダーマッチングは以下の内容をサポートします。
-
ヘッダー値の完全一致
-
ヘッダープレゼンスチェック
-
パターンベースのマッチング
-
複数ヘッダーの組み合わせ
ユースケース例では、特定のユーザーエージェント文字列、API バージョン、機能フラグのあるリクエストをテストするためにグリーンサービスにルーティングします。
ヘッダーマッチング設定の詳細については、「Amazon Elastic Container Service API リファレンス」の「ServiceConnectTestTrafficHeaderMatchRules」を参照してください。
ブルー/グリーンデプロイのクライアントエイリアス
クライアントエイリアスは、ブルー/グリーンデプロイ中にサービスに安定した DNS エンドポイントを提供します。クライアントアプリケーションが接続エンドポイントを変更する必要がなく、ブルーおよびグリーンのサービスリビジョン間にシームレスなトラフィックルーティングを実現します。
ブルー/グリーンデプロイ中、クライアントエイリアスは以下を実行します。
-
クライアント接続に一貫した DNS 名を維持する
-
サービスリビジョン間で自動トラフィック切り替えを有効にする
-
段階的なトラフィック移行戦略をサポートする
-
トラフィックをブルーリビジョンにリダイレクトし、ロールバック機能を提供する
異なるポートまたはプロトコルに複数のクライアントエイリアスを設定でき、複雑なサービスアーキテクチャがデプロイ中に接続を維持できるようにします。
クライアントエイリアスグ設定の詳細については、「Amazon Elastic Container Service API リファレンス」の「ServiceConnectClientAlias」を参照してください。
トラフィックルーティングのベストプラクティス
Service Connect を使用したブルー/グリーンデプロイ用にトラフィックルーティングを実装する際は、次のベストプラクティスを考慮してください。
-
ヘッダーベースのテストから開始: テストトラフィックヘッダーのルールを使用して、すべてのトラフィックを切り替える前に、制御されたトラフィックでグリーンサービスを検証します。
-
ヘルスチェックの設定: 異常なインスタンスにトラフィックをルーティングしないように、ブルーサービスおよびグリーンサービスの両方に適切なヘルスチェックが設定されていることを確認します。
-
サービスメトリクスのモニタリング: デプロイ中に両方のサービスリビジョンの主要なパフォーマンス指標を追跡し、問題を早期に特定します。
-
ロールバック戦略の計画: クライアントエイリアスおよびルーティングルールを設定すると、問題が検出されたときにブルーサービスへと迅速にロールバックできます。
-
ヘッダー一致ロジックのテスト: 本番以外の環境でヘッダー一致ルールを検証してから、本番デプロイに適用します。
Service Connect ブルー/グリーンデプロイのワークフロー
Service Connect がブルー/グリーンデプロイプロセスを管理するしくみを理解すると、デプロイを効果的に実装してトラブルシューティングできます。次のワークフローは、デプロイの各フェーズ中にでさまざまなコンポーネントが相互作用する様子を示しています。
デプロイフェーズ
Service Connect のブルー/グリーンデプロイはいくつかの異なるフェーズを通ります。
-
初期状態: ブルーサービスが本番トラフィックの 100% を処理します。名前空間内のすべてのクライアントサービスは、Service Connect で設定された論理サービス名を介してブルーサービスに接続されます。
-
グリーンサービス登録: グリーンデプロイが開始されると、「テスト」エンドポイントとして AWS Cloud Map に登録されます。クライアントサービスの Service Connect プロキシは、本番およびテスト用のルート設定の両方を自動的に提供します。
-
テストトラフィックのルーティング: テストトラフィックヘッダー (
x-amzn-ecs-blue-green-testなど) を含むリクエストは、Service Connect プロキシによってグリーンサービスに自動的にルーティングされます。本番トラフィックは引き続きブルーサービスに流れます。 -
トラフィック移行の準備: テストが正常に処理されると、デプロイプロセスは本番トラフィック移行に備えます。ブルーサービスおよびグリーンサービスの両方ともで、登録状態および正常性が維持されます。
-
本番トラフィック移行: Service Connect 設定は、本番トラフィックをグリーンサービスにルーティングするために更新されます。クライアントサービスの更新や DNS の変更を必要とせず、自動的に行われます。
-
ベイク期間: 本番トラフィックが移行した後、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。
-
ブルーサービスの登録解除: トラフィック移行および検証が正常に処理されたら、ブルーサービスは AWS Cloud Map から登録解除されて終了し、デプロイを完了します。
Service Connect プロキシの動作
Service Connect プロキシは、ブルー/グリーンデプロイ中のトラフィックを管理するうえで重要な役割を果たします。動作を理解することで、効果的なテストおよびデプロイ戦略を設計できます。
ブルー/グリーンデプロイ中の主要なプロキシ動作
-
自動ルート検出: アプリケーションの再起動や設定の変更を必要とせず、プロキシは AWS Cloud Map から本番およびテストのルートの両方を自動的に検出します。
-
ヘッダーベースのルーティング: プロキシは受信リクエストヘッダーを検査し、設定されたテストトラフィックのルールに基づいてトラフィックを適切なサービスリビジョンにルーティングします。
-
ヘルスチェックの統合: プロキシはトラフィックを正常なサービスインスタンスにのみルーティングし、ルーティングプールから異常なタスクを自動的に除外します。
-
再試行とサーキットブレーク: プロキシはビルトインの再試行ロジックおよびサーキットブレーク機能を提供し、デプロイ中の耐障害性を向上させます。
-
メトリクス収集: プロキシはブルーサービスおよびグリーンサービスの両方向けに詳細なメトリクスを収集し、デプロイ中の包括的なモニタリングを可能にします。
サービス検出の更新
ブルー/グリーンデプロイに Service Connect を使用する主な利点の 1 つは、サービス検出の更新を自動的に処理することです。従来のブルー/グリーンデプロイには、多くの場合は複雑な DNS 更新またはロードバランサーの再設定が必要ですが、Service Connect によってこれらの変更が明確に管理されます。
デプロイ中、Service Connect は以下のものを処理します。
-
名前空間の更新: Service Connect 名前空間には、適切なルーティングルールが適用されて、ブルーおよびグリーンのサービスエンドポイントの両方が自動的に含まれます。
-
クライアント設定: 名前空間内のすべてのクライアントサービスは再起動や再デプロイを必要とせず、更新されたルーティング情報を自動的に受けとります。
-
段階的な移行: サービス検出の更新は段階的かつ安全に行われ、進行中のリクエストが中断されることはありません。
-
ロールバックサポート: ロールバックが必要な場合、Service Connect はサービス検出の設定を迅速に戻して、トラフィックをブルーサービスに戻すことができます。
