Amazon ECS カナリアデプロイ

トラフィックの移行 – Amazon ECS が本番稼働トラフィックを移行するために使用するプロセス。Amazon ECS カナリアデプロイの場合、トラフィックは 2 つのフェーズで移行されます。最初に Canary の割合に応じて移行され、次にデプロイを完了するために移行されます。

Canary の割合 – 評価期間中に新しいバージョンにルーティングされたトラフィックの割合。

Canary ベイク時間 – フルデプロイに進む前に Canary バージョンをモニタリングする期間。

デプロイベイク時間 – すべての本番稼働トラフィックを新しいサービスリビジョンに移行した後、古いサービスリビジョンを終了するまでに Amazon ECS が待機する時間 (分単位)。これは本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間です。

ライフサイクルステージ – 「本番トラフィックの移行後」など、デプロイオペレーションの一連のイベント。

ライフサイクルフック – 特定のライフサイクルステージで実行される Lambda 関数。デプロイを検証する関数を作成できます。

ターゲットグループ – リクエストを 1 つ以上の登録済みターゲットにルーティングするために使用される ELB リソース (EC2 インスタンスなど)。リスナーを作成するときは、デフォルトアクションのターゲットグループを指定します。トラフィックは、リスナー規則で指定されたターゲットグループに転送されます。

リスナー – 設定したプロトコルおよびポートを使用し、接続リクエストを確認する ELB リソース。リスナーに対して定義したルールにより、Amazon ECS が登録済みターゲットにリクエストをルーティングする方法が決定します。

ルール – リスナーに関連付けられた ELB リソース。ルールはリクエストのルーティング方法を定義し、アクション、条件、優先度で構成されます。

リソースの使用状況: カナリアデプロイでは、評価期間中に元のタスクセットと Canary タスクセットの両方が同時に実行され、リソースの使用量が増加します。

トラフィック量: Canary の割合が、新しいバージョンの有意な検証に十分なトラフィックを生成していることを確認します。

複雑さのモニタリング: Canary デプロイでは、2 つの異なるバージョン間でメトリクスを同時にモニタリングおよび比較する必要があります。

ロールバック速度: カナリアデプロイでは、トラフィックを元のタスクセットに戻すことで、クイックロールバックが可能になります。

リスク軽減: カナリアデプロイでは、少数のユーザーへの露出を制限することで、優れたリスクを軽減できます。

デプロイ期間: カナリアデプロイには、全体的なデプロイ時間を延長するものの、検証の機会が設けられている評価期間が含まれます。

初期 – デプロイは、トラフィックが 100% ブルー (現在の) サービスリビジョンにルーティングされた状態で開始されます。グリーン (新しい) サービスリビジョンはテストトラフィックを受信しますが、初期段階では本番トラフィックを受信しません。

Canary トラフィックの移行 – これは 2 ステップのトラフィック移行戦略です。

Canary ベイク時間 – Canary トラフィックの移行後に設定可能な時間 (Canary ベイク時間) 待機し、トラフィック負荷の増加に伴う新しいリビジョンのパフォーマンスのモニタリングと検証を可能にします。

ライフサイクルフック – オプションの Lambda 関数は、デプロイ中のさまざまなライフサイクル段階で実行して、自動検証、モニタリング、またはカスタムロジックを実行できます。PRODUCTION_TRAFFIC_SHIFT 用に設定された Lambda 関数またはライフサイクルフックは、本番トラフィックの移行ステップごとに呼び出されます。

Canary の割合 – Canary フェーズ中に新しいサービスリビジョンにルーティングするトラフィックの割合。これにより、本番稼働トラフィックの制御されたサブセットによるテストが可能になります。

Canary ベイク時間 – Canary フェーズ中に残りのトラフィックを新しいサービスリビジョンに移行するまで待機する時間。これにより、新しいバージョンをモニタリングして検証する時間を確保できます。

元のターゲットグループ – 現在の安定バージョンのタスクが含まれ、トラフィックの大部分を受信します。

Canary ターゲットグループ – 新しいバージョンのタスクが含まれ、テスト用のトラフィックのごく一部を受信します。

加重ルーティング – ロードバランサーは加重ルーティングルールを使用して、設定された Canary の割合に基づいてターゲットグループ間でトラフィックを分散します。

ヘルスチェック – 両方のタスクセットは、トラフィックを受信する前にヘルスチェックに合格する必要があります。

メトリクスの比較 – 応答時間、エラー率、スループットなど、元のバージョンと Canary バージョン間で主要なパフォーマンス指標を比較します。

自動ロールバック – Canary バージョンのパフォーマンスが低下した場合に自動的にロールバックをトリガーするように CloudWatch アラームを設定します。

手動検証 – 評価期間を使用して、続行する前にログ、メトリクス、ユーザーフィードバックを手動で確認します。

小規模から開始する – 問題が発生した場合の影響を最小限に抑えるために、トラフィックの 5～10% から開始します。

アプリケーションの重要度を検討する – ミッションクリティカルなアプリケーションにはより小さな割合を使用し、重要度の低いサービスにはより大きな割合を使用します。

トラフィック量を考慮する – Canary の割合が有意な検証のために十分なトラフィックを生成していることを確認します。

十分な時間 – 有意なパフォーマンスデータをキャプチャするのに十分な評価期間を設定します。通常は 10～30 分です。

トラフィックパターンを検討する – アプリケーションのトラフィックパターンとピーク使用時間を考慮します。

速度と安全性のバランス – 評価期間が長いほどデータが増加しますが、デプロイ速度は低下します。

主要メトリクス – 両方のタスクセットの応答時間、エラー率、スループット、リソース使用率をモニタリングします。

アラームベースのロールバック – メトリクスがしきい値を超えたときにロールバックを自動的にトリガーするように CloudWatch アラームを設定します。

比較分析 – ダッシュボードを設定して、元のバージョンと Canary バージョン間のメトリクスを並べて比較します。

ビジネスメトリクス – 変換率やユーザーエンゲージメントなどのビジネス固有のメトリクスを技術メトリクスとともに設定します。

自動ロールバック – ヘルスチェックとパフォーマンスメトリクスに基づいて自動ロールバックトリガーを設定します。

手動ロールバック手順 – 自動トリガーがすべての問題をキャプチャしない場合の手動ロールバックの明確な手順を文書化します。

ロールバックのテスト実施 – ロールバック手順を定期的にテストして、必要に応じて正しく動作することを確認します。

デプロイ前のテスト実施 – カナリアデプロイ前にステージング環境の変更を徹底的にテストします。

ヘルスチェック設定 – ヘルスチェックがアプリケーションの準備状況と機能を正確に反映していることを確認します。

依存関係の検証 – 新しいバージョンにダウンストリームおよびアップストリームサービスとの互換性があることを確認します。

データ整合性 – データベーススキーマの変更とデータ移行に下位互換性があることを確認します。

デプロイウィンドウ – チームがモニタリングして対応できる営業時間内にカナリアデプロイをスケジュールします。

コミュニケーションチャネル – デプロイステータスと問題のエスカレーションに関する明確なコミュニケーションチャネルを確立します。

ロールの割り当て – モニタリング、意思決定、ロールバック実行の役割と責任を定義します。