# Amazon ECS サービスデプロイコントローラーと戦略
<a name="ecs_service-options"></a>

サービスをデプロイする前に、デプロイするためのオプションとサービスが使用する機能を確認してください。

## スケジュール戦略
<a name="service-strategy"></a>

利用できる 2 つのサービススケジューラ戦略があります。
+ `REPLICA` - レプリカスケジュール戦略では、クラスター全体で必要数のタスクを配置して維持します。デフォルトでは、サービススケジューラによってタスクはアベイラビリティーゾーン間に分散されます。タスク配置の戦略と制約を使用すると、タスク配置の決定をカスタマイズできます。詳細については、「[レプリカスケジューリング戦略](#service_scheduler_replica)」を参照してください。
+ `DAEMON` - デーモンのスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。この戦略を使用する場合、タスクの必要数や配置戦略、サービスの自動スケーリングポリシーを指定する必要はありません。詳細については、「[デーモンスケジューリング戦略](#service_scheduler_daemon)」を参照してください。
**注記**  
Fargate タスクは `DAEMON` スケジュール戦略をサポートしていません。

### レプリカスケジューリング戦略
<a name="service_scheduler_replica"></a>

*レプリカ*スケジュール戦略では、クラスターに必要数のタスクを配置して維持します。

Fargate でタスクを実行するサービスについては、サービススケジューラは、新しいタスクの起動時や実行中タスクの停止時に、アベイラビリティーゾーン間の負荷バランスを維持するよう最大限試みます。タスク置き換え戦略や制約を指定する必要はありません。

EC2 インスタンスでタスクを実行するサービスを作成する場合、オプションでタスク配置戦略と制約を指定して、タスク配置に関する決定をカスタマイズできます。タスク配置戦略または制約が指定されていない場合、デフォルトでは、サービススケジューラはタスクをアベイラビリティーゾーン全体に分散します。サービススケジューラは、次のロジックを使用します。
+ クラスター内のどのコンテナインスタンスがサービスのタスク定義をサポートできるか (必要な CPU、メモリ、ポート、コンテナインスタンス属性がなど) を判断します。
+ サービスに定義された配置の制約を満たすコンテナインスタンスを特定します。
+ デーモンサービスに依存するレプリカサービス (たとえば、タスクがログを使用する前に実行する必要があるデーモンログルータスクなど) がある場合は、デーモンサービスタスクがレプリカサービスタスクよりも前に EC2 インスタンスに配置されるようにするタスク置き換え制約を作成します。詳細については、「[Amazon ECS タスク配置の制約事項の例](constraint-examples.md)」を参照してください。
+ 配置戦略が定義されている場合は、その戦略を使用して残りの候補からインスタンスを選択します。
+ 定義された配置戦略がない場合は、次のロジックを使用してクラスター内のアベイラビリティーゾーン全体にタスクが配分されます。
  + 有効なコンテナインスタンスをソートします。それぞれのアベイラビリティーゾーンで、このサービスの実行中のタスクの数が最も少ないインスタンスを優先します。例えば、ゾーン A に実行中のサービスタスクが 1 つあり、ゾーン B と C に実行中のサービスタスクがない場合、ゾーン B または C のいずれかの有効なコンテナインスタンスが配置に最適と見なされます。
  + 前のステップに基づいて、新しいサービスタスクを最適なアベイラビリティーゾーン内の有効なコンテナインスタンスに配置します。このサービスで実行中のタスク数が最も少ないコンテナインスタンスを優先します。

サービスで高い利用可能性を確保できるようになるため、サービス再調整機能は `REPLICA` 戦略を使用する際に使用することをお勧めします。

### デーモンスケジューリング戦略
<a name="service_scheduler_daemon"></a>

*デーモン*のスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。サービススケジューラは、実行中のタスクのタスク配置の制約事項を評価し、配置制約を満たさないタスクを停止します。この戦略を使用する場合、タスクの必要数や配置戦略を指定したり、サービス自動スケーリングポリシーを使用したりする必要はありません。

Amazon ECS は、CPU、メモリ、およびネットワークインターフェイスを含むコンテナインスタンスのコンピューティングリソースをデーモンタスク用に予約します。他のレプリカサービスを使用してクラスターでデーモンサービスを起動すると、Amazon ECS はデーモンタスクを優先します。これは、デーモンタスクがインスタンス上で起動する最初のタスクであり、すべてのレプリカタスクが停止した後に停止する最後のタスクであることを意味します。この戦略により、保留中のレプリカ・タスクでリソースが使用されず、デーモンタスクでリソースを使用できるようになります。

デーモンサービススケジューラは `DRAINING` ステータスのインスタンスにはタスクを配置しません。コンテナインスタンスが `DRAINING` ステータスに移行すると、そのインスタンス上のデーモンタスクは停止します。サービススケジューラはまた、新しいコンテナインスタンスがいつクラスターに追加されるかをモニタリングし、追加されたらそれらのインスタンスにデーモンタスクを追加します。

デプロイメント設定を指定する場合、`maximumPercent` パラメータの値は `100` (パーセンテージとして指定) である必要があります。これは、設定されていない場合に使用されるデフォルト値です。`minimumHealthyPercent` パラメータのデフォルト値は `0` (パーセンテージで指定) です。

デーモンサービスの配置制約を変更するには、サービスを再起動する必要があります。Amazon ECS は、デーモンタスクの対象となるインスタンスに予約されているリソースを動的に更新します。既存のインスタンスの場合、スケジューラはインスタンスにタスクを配置しようとします。

タスク定義でタスクサイズまたはコンテナリソースの予約が変更されると、新しいデプロイが開始されます。新しいデプロイは、サービスを更新したり、タスク定義の異なるリビジョンを設定したりするときにも開始されます。Amazon ECS は、デーモンの更新された CPU およびメモリ予約をピックアップし、デーモンのタスクでその容量をブロックします。

上記のいずれかの場合に十分なリソースがない場合、次のことが起こります。
+ タスクの配置が失敗します。
+ CloudWatch イベントが生成されます。
+ Amazon ECS は、リソースが使用可能になるのを待って、インスタンスでタスクのスケジュールを試行します。
+ Amazon ECS は、配置制約基準を満たさなくなったリザーブドインスタンスを解放し、対応するデーモンタスクを停止します。

デーモンのスケジューリング戦略は、次の場合に使用できます。
+ アプリケーションコンテナの実行
+ ログ記録、モニタリング、トレースタスク用のサポートコンテナの実行

Fargate 起動タイプ、`CODE_DEPLOY` または `EXTERNAL` のデプロイメントコントローラータイプを使用するタスクは、デーモンスケジューリング戦略をサポートしません。

サービススケジューラがタスクの実行を停止する場合、アベイラビリティーゾーン間のクラスターの負荷バランスを維持します。スケジューラは、次のロジックを使用します。
+ 配置戦略が定義されている場合、その戦略を使用して終了するタスクを選択します。例えば、サービスにアベイラビリティーゾーンの spread 戦略が定義されている場合、1 つのタスクが選択され、残りのタスクは最適に分散されたまま残ります。
+ 配置戦略が定義されていない場合は、次のロジックを使用してクラスター内のアベイラビリティーゾーン全体への配分を維持します。
  + 有効なコンテナインスタンスをソートします。それぞれのアベイラビリティーゾーンで、このサービスの実行中のタスクの数が最も多いインスタンスを優先します。例えば、実行中のサービスタスクがゾーン A には 1 つ、ゾーン B とゾーン C にはそれぞれ 2 つずつある場合、ゾーン B またはゾーン C のいずれかのコンテナインスタンスが終了に最適と見なされます。
  + 前のステップに基づいて、最適なアベイラビリティーゾーン内のコンテナインスタンスで、タスクを停止します。このサービスで実行中のタスク数が最も多いコンテナインスタンスを優先します。

## デプロイコントローラー
<a name="service_deployment-controllers"></a>

デプロイコントローラーは、サービスにタスクがデプロイされる方法を決定するメカニズムです。有効なオプションは次のとおりです。
+ ECS

  `ECS` デプロイコントローラーを使用するサービスを作成する際、次のデプロイ戦略から選択できます。
  + `ROLLING`: *ローリング更新* (`ROLLING`) デプロイ戦略を使用するサービスを作成すると、Amazon ECS サービススケジューラによって現在実行中のタスクが新しいタスクに置き換えられます。ローリング更新中にサービスに対して Amazon ECS が追加または削除するタスク数は、サービスデプロイ設定により制御されます。

    ローリング更新のデプロイは、次のシナリオに最適です。
    + サービスの段階的な更新: サービス全体を一度にオフラインにせず、サービスを段階的に更新する必要がある場合。
    + 制限のあるリソース要件: 2 つの完全な環境を同時に実行することで生じる追加のリソースコストを回避したい場合 (ブルー/グリーンデプロイで必要)。
    + 許容されるデプロイ時間: ローリング更新はタスクを 1 つずつ置き換えるため、アプリケーションがより長いデプロイプロセスを許容できる場合。
    + インスタントロールバックが不要: サービスで数秒ではなく数分かかるロールバックプロセスを許容できる場合。
    + シンプルなデプロイプロセス: 複数の環境、ターゲットグループ、リスナーを管理する複雑さのないシンプルなデプロイアプローチを求める場合。
    + ロードバランサーの要件なし: サービスにロードバランサー、Application Load Balancer、Network Load Balancer、Service Connect (ブルー/グリーンデプロイに必要) を使用しない場合または必要としない場合。
    + ステートフルアプリケーション: アプリケーションで、2 つの並列環境の実行を困難にする状態が維持される場合。
    + コストに敏感: デプロイ中に重複する環境を実行しないことで、デプロイコストを最小限に抑えたい場合。

    ローリング更新はサービスのデフォルトのデプロイ戦略であり、多くの一般的なアプリケーションシナリオでデプロイの安全性とリソース効率のバランスを実現します。
  + `BLUE_GREEN`: *ブルー/グリーン*デプロイ戦略 (`BLUE_GREEN`) はブルーおよびグリーンという 2 つの同一の本番環境を実行することで、ダウンタイムおよびリスクを軽減するリリース方法です。Amazon ECS ブルー/グリーンデプロイを使用すると、本番トラフィックをルーティングする前に、新しいサービスリビジョンを検証できます。このアプローチによって変更をデプロイするより安全な方法が実現され、必要に応じてすばやくロールバックできます。

    Amazon ECS ブルー/グリーンデプロイは次のシナリオに最適です。
    + サービス検証: 本番トラフィックをルーティングする前に、新しいサービスリビジョンを検証する必要がある場合
    + ダウンタイムなし: サービスにダウンタイムのないデプロイが必要な場合
    + インスタントロールバック: 問題が検出された場合、すばやくロールバックする機能が必要な場合
    + ロードバランサーの要件: サービスが Application Load Balancer、Network Load Balancer、Service Connect を使用する場合
  + `LINEAR`: *リニア*デプロイ戦略 (`LINEAR`) は、トラフィックを現在の本番稼働環境から新しい環境に、指定した期間にわたって同じ割合で徐々に移行します。Amazon ECS リニアデプロイでは、トラフィックの移行のペースを制御し、本番稼働トラフィックの量が増えるにつれて新しいサービスリビジョンを検証できます。

    Amazon ECS リニアデプロイは次のシナリオに最適です。
    + 段階的な検証: トラフィックの増加に伴って新しいサービスバージョンを段階的に検証する必要がある場合
    + パフォーマンスモニタリング: デプロイ中にメトリクスとパフォーマンスをモニタリングするための時間が必要な場合
    + リスクの最小化: 新しいバージョンを本番稼働トラフィックに段階的に公開してリスクを最小限に抑える必要がある場合
    + ロードバランサーの要件: サービスが Application Load Balancer、Network Load Balancer、Service Connect を使用する場合
  + `CANARY`: *カナリア*デプロイ戦略 (`CANARY`) では、まずトラフィックのごく一部を新しいサービスリビジョンに移行し、指定した期間が経過した後に残りのトラフィックをすべて一度に移行します。これにより、完全なデプロイを実施する前にユーザーのサブセットで新しいバージョンをテストできます。

    Amazon ECS カナリアデプロイは次のシナリオに最適です。
    + 機能テスト: 完全なロールアウト前に少数のユーザーサブセットで新機能をテストする必要がある場合
    + 本番稼働用検証: 実際の本番稼働トラフィックでパフォーマンスと機能を検証する必要がある場合
    + ブラスト半径制御: 新しいバージョンで問題が見つかった場合にブラスト半径を最小限に抑える必要がある場合
    + ロードバランサーの要件: サービスが Application Load Balancer、Network Load Balancer、Service Connect を使用する場合
+ 外部

  サードパーティーのデプロイコントローラーを使用します。
+ ブルー/グリーンデプロイ (AWS CodeDeploy を搭載)

  CodeDeploy によってアプリケーションの更新されたバージョンが新しい置き換えタスクセットとしてインストールされ、本番トラフィックが元のアプリケーションタスクセットから置き換えタスクセットに再ルーティングされます。デプロイが正常に完了すると、元のタスクセットは終了します。本番トラフィックをルーティングする前に、サービスの新しいデプロイを検証するためにこのデプロイコントローラーを使用します。

## デプロイに関する用語
<a name="deployment-terminology"></a>

Amazon ECS デプロイドキュメント全般で、以下の用語が使用されています。

ブルー/グリーンデプロイ  
既存の環境 (ブルー) とともに新しい環境 (グリーン) を作成し、検証後にトラフィックをブルーからグリーンに切り替えるデプロイ戦略。

Canary デプロイ  
トラフィックのごく一部を新しいバージョンにルーティングしながら、大部分のトラフィックを検証するために安定したバージョンに保持するデプロイ戦略。

リニアデプロイ  
時間の経過とともにトラフィックを古いバージョンから新しいバージョンに同じ割合ずつ段階的に移行するデプロイ戦略。

ローリングデプロイ  
古いバージョンのインスタンスを新しいバージョンのインスタンスに一度に 1 つずつ置き換えるデプロイ戦略。

タスクセット  
デプロイ中にサービス内で同じタスク定義を実行するタスクのコレクション。

ターゲットグループ  
デプロイ中にロードバランサーからトラフィックを受信するターゲットの論理グループ。

デプロイコントローラー  
Amazon ECS、CodeDeploy、外部コントローラーなど、サービスの新しいバージョンをデプロイするために使用される方法。

ロールバック  
デプロイ中に問題が検出されたときに、アプリケーションの以前のバージョンに戻すプロセス。