# Amazon ECS カナリアデプロイ
<a name="canary-deployment"></a>

Canary デプロイでは、まず初期テストのためにトラフィックのごく一部を新しいリビジョンにルーティングし、Canary フェーズが正常に完了したら、残りのすべてのトラフィックを一度に移行します。Amazon ECS カナリアデプロイでは、リスクの露出を最小限に抑えながら、実際のユーザートラフィックで新しいサービスリビジョンを検証します。このアプローチでは、パフォーマンスをモニタリングし、問題が検出された場合には迅速にロールバックしながら変更をデプロイできます。

## カナリアデプロイに関連するリソース
<a name="canary-deployment-resources"></a>

Amazon ECS カナリアデプロイに関連するリソースは次のとおりです。
+ トラフィックの移行 – Amazon ECS が本番稼働トラフィックを移行するために使用するプロセス。Amazon ECS カナリアデプロイの場合、トラフィックは 2 つのフェーズで移行されます。最初に Canary の割合に応じて移行され、次にデプロイを完了するために移行されます。
+ Canary の割合 – 評価期間中に新しいバージョンにルーティングされたトラフィックの割合。
+ Canary ベイク時間 – フルデプロイに進む前に Canary バージョンをモニタリングする期間。
+ デプロイベイク時間 – すべての本番稼働トラフィックを新しいサービスリビジョンに移行した後、古いサービスリビジョンを終了するまでに Amazon ECS が待機する時間 (分単位)。これは本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間です。
+ ライフサイクルステージ – 「本番トラフィックの移行後」など、デプロイオペレーションの一連のイベント。
+ ライフサイクルフック – 特定のライフサイクルステージで実行される Lambda 関数。デプロイを検証する関数を作成できます。
+ ターゲットグループ – リクエストを 1 つ以上の登録済みターゲットにルーティングするために使用される Elastic Load Balancing リソース (EC2 インスタンスなど)。リスナーを作成するときは、デフォルトアクションのターゲットグループを指定します。トラフィックは、リスナー規則で指定されたターゲットグループに転送されます。
+ リスナー – 設定したプロトコルおよびポートを使用し、接続リクエストを確認する Elastic Load Balancing リソース。リスナーに対して定義したルールにより、Amazon ECS が登録済みターゲットにリクエストをルーティングする方法が決定します。
+ ルール – リスナーに関連付けられた Elastic Load Balancing リソース。ルールはリクエストのルーティング方法を定義し、アクション、条件、優先度で構成されます。

## 考慮事項
<a name="canary-deployment-considerations"></a>

デプロイタイプを選択する際、次の内容を考慮してください。
+ リソースの使用状況: カナリアデプロイでは、評価期間中に元のタスクセットと Canary タスクセットの両方が同時に実行され、リソースの使用量が増加します。
+ トラフィック量: Canary の割合が、新しいバージョンの有意な検証に十分なトラフィックを生成していることを確認します。
+ 複雑さのモニタリング: Canary デプロイでは、2 つの異なるバージョン間でメトリクスを同時にモニタリングおよび比較する必要があります。
+ ロールバック速度: カナリアデプロイでは、トラフィックを元のタスクセットに戻すことで、クイックロールバックが可能になります。
+ リスク軽減: カナリアデプロイでは、少数のユーザーへの露出を制限することで、優れたリスクを軽減できます。
+ デプロイ期間: カナリアデプロイには、全体的なデプロイ時間を延長するものの、検証の機会が設けられている評価期間が含まれます。

## カナリアデプロイの仕組み
<a name="canary-how-it-works"></a>

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

1. 準備フェーズ: 既存のブルー環境と一緒にグリーン環境を作成します。

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

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

1. Canary トラフィック移行フェーズ: Canary フェーズ中に設定されたトラフィックの割合を新しいグリーンサービスリビジョンに移行し、次にトラフィックの 100.0% をグリーンサービスリビジョンに移行します。

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

1. 完了フェーズ: ブルー環境を終了してデプロイを確定します。

Canary トラフィックの移行フェーズは、次のステップに従います。
+ 初期 – デプロイは、トラフィックが 100% ブルー (現在の) サービスリビジョンにルーティングされた状態で開始されます。グリーン (新しい) サービスリビジョンはテストトラフィックを受信しますが、初期段階では本番トラフィックを受信しません。
+ Canary トラフィックの移行 – これは 2 ステップのトラフィック移行戦略です。
  + ステップ 1: 10.0% がグリーンに、90.0% がブルーに
  + ステップ 2: 100.0% がグリーンに、0.0% がブルーに
+ Canary ベイク時間 – Canary トラフィックの移行後に設定可能な時間 (Canary ベイク時間) 待機し、トラフィック負荷の増加に伴う新しいリビジョンのパフォーマンスのモニタリングと検証を可能にします。
+ ライフサイクルフック – オプションの Lambda 関数は、デプロイ中のさまざまなライフサイクル段階で実行して、自動検証、モニタリング、またはカスタムロジックを実行できます。PRODUCTION\$1TRAFFIC\$1SHIFT 用に設定された Lambda 関数またはライフサイクルフックは、本番トラフィックの移行ステップごとに呼び出されます。

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

カナリアデプロイプロセスは、個別のライフサイクルステージを経て進行し、それぞれのステージに特定の責任と検証チェックポイントがあります。これらのステージを理解すると、デプロイの進行状況をモニタリングして問題を効果的にトラブルシューティングできます。

各ライフサイクルステージは最大 24 時間、さらに PRODUCTION\$1TRAFFIC\$1SHIFT の各トラフィック移行ステップは最大 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 | Canary 本番稼働トラフィックはグリーンリビジョンにルーティングされ、ライフサイクルフックは 24 時間のタイムアウトで呼び出されます。2 番目のステップでは、残りの本番稼働トラフィックをグリーンリビジョンに移行します。 | はい | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックの移行が完了しました。 | はい | 
| BAKE\$1TIME | ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。 | いいえ | 
| CLEAN\$1UP | ブルーサービスリビジョンにより、実行中のタスク 0 へと完全にスケールダウンされました。グリーンサービスリビジョンは、このステージの後に本番サービスリビジョンになります。 | いいえ | 

### 設定パラメータ
<a name="canary-configuration-parameters"></a>

カナリアデプロイデプロイには、次の設定パラメータが必要です。
+ Canary の割合 – Canary フェーズ中に新しいサービスリビジョンにルーティングするトラフィックの割合。これにより、本番稼働トラフィックの制御されたサブセットによるテストが可能になります。
+ Canary ベイク時間 – Canary フェーズ中に残りのトラフィックを新しいサービスリビジョンに移行するまで待機する時間。これにより、新しいバージョンをモニタリングして検証する時間を確保できます。

### トラフィック管理
<a name="canary-traffic-management"></a>

カナリアデプロイでは、ロードバランサーのターゲットグループを使用してトラフィックの分散を管理します。
+ 元のターゲットグループ – 現在の安定バージョンのタスクが含まれ、トラフィックの大部分を受信します。
+ Canary ターゲットグループ – 新しいバージョンのタスクが含まれ、テスト用のトラフィックのごく一部を受信します。
+ 加重ルーティング – ロードバランサーは加重ルーティングルールを使用して、設定された Canary の割合に基づいてターゲットグループ間でトラフィックを分散します。

### モニタリングと評価
<a name="canary-monitoring-validation"></a>

効果的なカナリアデプロイは、包括的なモニタリングに基づきます。
+ ヘルスチェック – 両方のタスクセットは、トラフィックを受信する前にヘルスチェックに合格する必要があります。
+ メトリクスの比較 – 応答時間、エラー率、スループットなど、元のバージョンと Canary バージョン間で主要なパフォーマンス指標を比較します。
+ 自動ロールバック – Canary バージョンのパフォーマンスが低下した場合に自動的にロールバックをトリガーするように CloudWatch アラームを設定します。
+ 手動検証 – 評価期間を使用して、続行する前にログ、メトリクス、ユーザーフィードバックを手動で確認します。

### カナリアデプロイのベストプラクティス
<a name="canary-best-practices"></a>

サービスを使用したカナリアデプロイを成功させるには、以下のベストプラクティスに従ってください。

#### 適切なトラフィックの割合を選択する
<a name="canary-traffic-percentage"></a>

Canary トラフィックの割合を選択するときは、次の要因を考慮してください。
+ 小規模から開始する – 問題が発生した場合の影響を最小限に抑えるために、トラフィックの 5～10% から開始します。
+ アプリケーションの重要度を検討する – ミッションクリティカルなアプリケーションにはより小さな割合を使用し、重要度の低いサービスにはより大きな割合を使用します。
+ トラフィック量を考慮する – Canary の割合が有意な検証のために十分なトラフィックを生成していることを確認します。

#### 適切な評価期間を設定する
<a name="canary-evaluation-time"></a>

以下の考慮事項に基づいて評価期間を設定します。
+ 十分な時間 – 有意なパフォーマンスデータをキャプチャするのに十分な評価期間を設定します。通常は 10～30 分です。
+ トラフィックパターンを検討する – アプリケーションのトラフィックパターンとピーク使用時間を考慮します。
+ 速度と安全性のバランス – 評価期間が長いほどデータが増加しますが、デプロイ速度は低下します。

#### 包括的なモニタリングを実装する
<a name="canary-monitoring-setup"></a>

カナリアデプロイのパフォーマンスを追跡するようにモニタリングを設定します。
+ 主要メトリクス – 両方のタスクセットの応答時間、エラー率、スループット、リソース使用率をモニタリングします。
+ アラームベースのロールバック – メトリクスがしきい値を超えたときにロールバックを自動的にトリガーするように CloudWatch アラームを設定します。
+ 比較分析 – ダッシュボードを設定して、元のバージョンと Canary バージョン間のメトリクスを並べて比較します。
+ ビジネスメトリクス – 変換率やユーザーエンゲージメントなどのビジネス固有のメトリクスを技術メトリクスとともに設定します。

#### ロールバック戦略を計画する
<a name="canary-rollback-strategy"></a>

以下の戦略を使用して、潜在的なロールバックシナリオに備えます。
+ 自動ロールバック – ヘルスチェックとパフォーマンスメトリクスに基づいて自動ロールバックトリガーを設定します。
+ 手動ロールバック手順 – 自動トリガーがすべての問題をキャプチャしない場合の手動ロールバックの明確な手順を文書化します。
+ ロールバックのテスト実施 – ロールバック手順を定期的にテストして、必要に応じて正しく動作することを確認します。

#### デプロイ前に徹底的に検証する
<a name="canary-testing-validation"></a>

カナリアデプロイを続行する前に、徹底的な検証を実施するようにしてください。
+ デプロイ前のテスト実施 – カナリアデプロイ前にステージング環境の変更を徹底的にテストします。
+ ヘルスチェック設定 – ヘルスチェックがアプリケーションの準備状況と機能を正確に反映していることを確認します。
+ 依存関係の検証 – 新しいバージョンにダウンストリームおよびアップストリームサービスとの互換性があることを確認します。
+ データ整合性 – データベーススキーマの変更とデータ移行に下位互換性があることを確認します。

#### チームの関与を調整する
<a name="canary-team-coordination"></a>

カナリアデプロイ中に効率的なチームの調整を実施します。
+ デプロイウィンドウ – チームがモニタリングして対応できる営業時間内にカナリアデプロイをスケジュールします。
+ コミュニケーションチャネル – デプロイステータスと問題のエスカレーションに関する明確なコミュニケーションチャネルを確立します。
+ ロールの割り当て – モニタリング、意思決定、ロールバック実行の役割と責任を定義します。