

# Amazon ECS リニアデプロイ
<a name="deployment-type-linear"></a>

リニアデプロイでは、時間の経過とともに古いサービスリビジョンから新しいサービスリビジョンにトラフィックが同じ割合ずつ徐々に移行されるため、次のステップに進む前に各ステップをモニタリングできます。Amazon ECS リニアデプロイでは、トラフィックの移行速度を制御し、本番稼働トラフィックの量が増加している新しいサービスリビジョンを検証します。このアプローチにより、各増分でパフォーマンスをモニタリングできる制御された方法で変更をデプロイできます。

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

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

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

デプロイタイプを選択する際、次の内容を考慮してください。
+ リソースの使用量: リニアデプロイではブルーおよびグリーンのサービスリビジョンの両方が一時的に実行されるため、デプロイ中にリソースの使用量が 2 倍になる場合があります。
+ デプロイモニタリング: リニアデプロイではデプロイステータスの詳細な情報が提示されるため、デプロイプロセスの各ステージとトラフィック移行の増分をモニタリングできます。
+ ロールバック: ブルーリビジョンがベイク時間が終了するまで実行が継続されるため、問題が検出された場合、リニアデプロイでは前のバージョンへのロールバックが容易になります。
+ 段階的な検証: リニアデプロイでは、本番稼働トラフィックの量を増やして新しいリビジョンを検証できるため、デプロイの信頼性が向上します。
+ デプロイ期間: ステップ間のトラフィック移行の増分と待機時間のため、リニアデプロイは一括デプロイよりも完了に時間を要します。

## リニアデプロイの仕組み
<a name="linear-deployment-how-works"></a>

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

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

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

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

1. リニアトラフィック移行のフェーズ: 設定されたデプロイ戦略に基づき、本番稼働トラフィックをブルーからグリーンに一定割合で移行します。

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

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

リニアトラフィック移行フェーズは、以下のステップに従います。
+ 初期 – デプロイは、トラフィックが 100% ブルー (現在の) サービスリビジョンにルーティングされた状態で開始されます。グリーン (新しい) サービスリビジョンはテストトラフィックを受信しますが、初期段階では本番トラフィックを受信しません。
+ 増分トラフィック移行 – トラフィックは、同じ割合の増分でブルーからグリーンに徐々に移行されます。例えば、ステップ設定が 10.0% の場合、トラフィックの移行は次のように行われます。
  + ステップ 1: 10.0% がグリーンに、90.0% がブルーに
  + ステップ 2: 20.0% がグリーンに、80.0% がブルーに
  + ステップ 3: 30.0% がグリーンに、70.0% がブルーに
  + 100% がグリーンになるまで続きます。
+ ステップベイク時間 – 各トラフィック移行の増分間で、デプロイは設定可能な期間 (ステップベイク時間) 待機し、トラフィック負荷の増加に伴う新しいリビジョンのパフォーマンスのモニタリングと検証を可能にします。トラフィックが 100.0% 移行されると、最後のステップのベイク時間はスキップされることに注意してください。
+ ライフサイクルフック – オプションの Lambda 関数は、デプロイ中のさまざまなライフサイクル段階で実行して、自動検証、モニタリング、またはカスタムロジックを実行できます。PRODUCTION\$1TRAFFIC\$1SHIFT 用に設定された Lambda 関数またはライフサイクルフックは、本番トラフィックの移行ステップごとに呼び出されます。

## デプロイのライフサイクルステージ
<a name="linear-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 | トラフィックは、グリーンがトラフィックの 100% を受信するまで、同じ割合でブルーからグリーンに徐々に移行されます。各トラフィック移行は、24 時間のタイムアウトでライフサイクルフックを呼び出します。 | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックの移行が完了しました。 | はい | 
| BAKE\$1TIME | ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。 | いいえ | 
| CLEAN\$1UP | ブルーサービスリビジョンにより、実行中のタスク 0 へと完全にスケールダウンされました。グリーンサービスリビジョンは、このステージの後に本番サービスリビジョンになります。 | いいえ | 