

# Amazon ECS ブルー/グリーンサービスのデプロイワークフロー
<a name="blue-green-deployment-how-it-works"></a>

Amazon ECS ブルー/グリーンデプロイプロセスは構造化されたアプローチに従っており、安全かつ信頼性の高いアプリケーション更新を実現する 6 つの異なるフェーズで構成されます。各フェーズは、アプリケーションを現在のバージョン (ブルー) から新しいバージョン (グリーン) に検証および移行するためにそれ特有の目的を果たします。

1. **準備フェーズ**: 既存のブルー環境と一緒にグリーン環境を作成します。新しいサービスリビジョンのプロビジョニングやターゲットグループの準備が含まれます。

1. **デプロイフェーズ**: 新しいサービスリビジョンをグリーン環境にデプロイします。Amazon ECS は更新されたサービスリビジョンを使用して新しいタスクを起動し、ブルー環境は引き続き本番トラフィックを処理します。

1. **テストフェーズ**: テストトラフィックルーティングを使用してグリーン環境を検証します。Application Load Balancer によってテストリクエストがグリーン環境に送信され、本番トラフィックはブルー環境の状態にとどまります。

1. **トラフィック移行のフェーズ**: 設定されたデプロイ戦略に基づき、本番トラフィックをブルーからグリーンに移行します。このフェーズには、モニタリングおよび検証チェックポイントが含まれます。

1. **モニタリングフェーズ**: ベイク期間中のアプリケーションの正常性、パフォーマンスメトリクス、アラーム状態がモニタリングされます。ロールバックオペレーションは問題が検出されると開始されます。

1. **完了フェーズ**: 設定に応じて、ブルー環境を終了するか、潜在的なロールバックシナリオに合わせて維持することで、デプロイを確定します。

## ワークフロー
<a name="blue-green-deployment-workflow"></a>

次の図は、包括的なブルー/グリーンデプロイのワークフローであり、Amazon ECS および Application Load Balancer 間の相互作用を示しています。

![\[詳細なコンポーネント相互作用、トラフィック移行フェーズ、モニタリングチェックポイントなど、Amazon ECS のブルー/グリーンデプロイプロセスを示す包括的な図\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/blue-green.png)


拡張デプロイワークフローには、次の詳細なステップが含まれます。

1. **初期状態**: ブルーサービス (現在の本番用) は本番トラフィックの 100% を処理します。Application Load Balancer には、正常なブルータスクを含むブルーターゲットグループにすべてのリクエストをルーティングするルールを含む 1 つのリスナーがあります。

1. **グリーン環境プロビジョニング**: Amazon ECS により、更新されたタスク定義を使用して新しいタスクが作成されます。これらのタスクは新しいグリーンターゲットグループに登録されますが、最初はトラフィックを受信しません。

1. **ヘルスチェックの検証**: Application Load Balancer がグリーンタスクにヘルスチェックを実行します。グリーンタスクがヘルスチェックに合格した場合にのみ、デプロイは次のフェーズに進行します。

1. **テストトラフィックのルーティング**: 設定された場合、Application Load Balancer のリスナールールは特定のトラフィックパターン (テストヘッダーを持つリクエストなど) が検証のためにグリーン環境にルーティングされ、本番トラフィックはブルー環境の状態にとどまります。これは本番トラフィックを処理するリスナーによって制御され、リクエスト属性に基づく異なるルールを使用します。

1. **本番トラフィック移行**: デプロイ設定に基づき、トラフィックはブルーからグリーンに移行します。ECS ブルー/グリーンデプロイは、トラフィックの 100% がブルー環境からグリーン環境に移動する即時 (すべてを一度に) 移行です。Application Load Balancer により、重みに基づいてブルーおよびグリーンのターゲットグループ間のトラフィック分散を制御するリスナールールを持つ 1 つのリスナーが使用されます。

1. **モニタリングと検証**: トラフィック移行中の全過程において、Amazon ECS は CloudWatch メトリクス、アラーム状態、デプロイの正常性をモニタリングします。問題が検出された場合、自動ロールバックトリガーが発動します。

1. **ベイク期間**: 本番トラフィックが移行した後、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。

1. **ブルー環境の終了**: トラフィックの移行および検証が正常に処理されたら、ブルー環境が終了してクラスターリソースが解放されるか、迅速にロールバックできるように維持されます。

1. **最終状態**: グリーン環境が新しい本番環境になり、トラフィックの 100% を処理します。デプロイは正常処理としてマークされます。

## デプロイのライフサイクルステージ
<a name="blue-green-deployment-stages"></a>

ブルー/グリーンデプロイプロセスは、個別のライフサイクルステージ (「本番トラフィックの移行後」など、デプロイオペレーションの一連のイベント) を経て進行していき、それぞれのステージに特定の役割および検証チェックポイントがあります。これらのステージを理解すると、デプロイの進行状況をモニタリングして問題を効果的にトラブルシューティングできます。

 各ライフサイクルステージは最大 24 時間継続できます。値を 24 時間未満にとどめることをお勧めします。非同期プロセスがフックをトリガーするために時間が必要になるからです。システムがタイムアウトしてデプロイに失敗し、ステージが 24 時間に達した後にロールバックが開始されます。CloudFormation デプロイには追加のタイムアウト制限があります。24 時間のステージ制限は有効性が維持されますが、CloudFormation によってデプロイ全体に 36 時間の制限が実施されます。CloudFormation によってデプロイが失敗し、36 時間以内にプロセスが完了しない場合はロールバックが開始されます。


| ライフサイクルのステージ | 説明 | ライフサイクルフックにこのステージを使用しますか? | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | このステージは、複数のサービスリビジョンが ACTIVE 状態で新しいサービスのデプロイを開始した場合にのみ発生します。 | はい | 
| PRE\$1SCALE\$1UP | グリーンサービスリビジョンは開始されていません。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| SCALE\$1UP | グリーンサービスリビジョンが 100% までにスケールアップし、新しいタスクを起動する時間。現時点では、グリーンサービスリビジョンはトラフィックを処理していません。 | いいえ | 
| POST\$1SCALE\$1UP | グリーンサービスリビジョンが開始されました。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| TEST\$1TRAFFIC\$1SHIFT | ブルーおよびグリーンのサービスリビジョンが実行されています。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されます。グリーンサービスリビジョンは、テストトラフィックの 0% から 100% に移行しています。 | はい | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | テストトラフィックの移行が完了しました。グリーンサービスリビジョンにより、テストトラフィックの 100% が処理されます。 | はい | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックがグリーンサービスリビジョンに移行しています。グリーンサービスリビジョンは、本番トラフィックの 0% から 100% に移行しています。 | はい | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックの移行が完了しました。 | はい | 
| BAKE\$1TIME | ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。 | いいえ | 
| CLEAN\$1UP | ブルーサービスリビジョンにより、実行中のタスク 0 へと完全にスケールダウンされました。グリーンサービスリビジョンは、このステージの後に本番サービスリビジョンになります。 | いいえ | 

各ライフサイクルステージには、次のステージに進む前に合格する必要があるビルトインの検証チェックポイントが含まれています。検証が失敗した場合、サービスの可用性および信頼性を維持するため、デプロイを自動的にロールバックできます。

Lambda 関数を使用する場合、関数は作業を完了するか、15 分以内に IN\$1PROGRESS を返す必要があります。`callBackDelaySeconds` を使用して、Lambda への呼び出しを遅らせることができます。詳細については、GitHub の sample-amazon-ecs-blue-green-deployment-patterns の [app.py 関数](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25)を参照してください。