# タスクを置き換えて Amazon ECS サービスをデプロイする
*ローリング更新* (`ECS`) デプロイタイプを使用するサービスを作成すると、Amazon ECS サービススケジューラは現在実行中のタスクを新しいタスクに置き換えます。ローリング更新中にサービスに対して Amazon ECS が追加または削除するタスク数は、サービスデプロイ設定により制御されます。
Amazon ECS は、次のパラメータを使用してタスク数を決定します。
+ `minimumHealthyPercent` は、ローリングデプロイメント中またはコンテナインスタンスがドレインしているときに、サービスに対して実行され正常な状態であることが必要なタスク数の下限を、サービスに必要なタスク数の割合 (%) として表します。この値は切り上げられます。例えば、最小正常率が `50` で、必要なタスク数が 4 の場合、スケジューラは 2 つの新しいタスクを開始する前に既存のタスクを 2 つ停止できます。同様に、最小正常率が 75% で、必要なタスク数が 2 の場合、結果の値も 2 であるため、スケジューラはタスクを停止できません。
+ `maximumPercent` は、ローリングデプロイメント中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の上限を、サービスに必要なタスク数の割合 (%) として表します。この値は切り捨てられます。例えば、最大パーセンテージが `200` で、目的のタスク数が 4 の場合、スケジューラは既存のタスクを 4 つ停止する前に 4 つの新しいタスクを開始できます。同様に、最大比率が `125` で、必要なタスク数が 3 の場合、結果の値も 3 であるため、スケジューラはタスクを開始できません。
ローリングデプロイ中にタスクが異常な状態になると、Amazon ECS はそれらを置き換えてサービスの `minimumHealthyPercent` を維持し、可用性を保護します。異常な状態のタスクは、それらが属するのと同じサービスリビジョンを使用して置き換えられます。これにより、ソースリビジョンの異常な状態のタスクの置換は、ターゲットリビジョンのタスクの失敗とは無関係になります。`maximumPercent` 設定で許可されている場合、スケジューラは異常な状態のタスクを停止する前に代替タスクを起動します。`maximumPercent` パラメータによって、代替タスクを先に開始できないようにスケジューラが制限されている場合、スケジューラは異常なタスクを 1 つずつ停止して容量を解放してから代替タスクを開始します。
**重要**
最小正常率または最大正常率を設定するときは、デプロイが開始されたときにスケジューラが 1 つ以上のタスクを停止または開始できることを確認する必要があります。無効なデプロイメント構成が原因でサービスのデプロイメントが停止している場合、サービスイベントメッセージが送信されます。詳細については、「[サービス (*service-name*) は、サービスデプロイメント構成のため、デプロイメント中にタスクを停止または開始できませんでした。minimumHealthyPercent または maximumPercent の値を更新してから、もう一度試してください。](service-event-messages-list.md#service-event-messages-7)」を参照してください。
ローリングデプロイには 2 つの方法があり、サービスデプロイが失敗したタイミングをすばやく特定できます。
+ [Amazon ECS デプロイサーキットブレーカーが障害を検出する方法](deployment-circuit-breaker.md)
+ [CloudWatch アラームが Amazon ECS のデプロイ障害を検出する方法](deployment-alarm-failure.md)
これらの方法は個別に使用することも、一緒に使用することもできます。両方の方法を使用する場合、失敗に対するいずれかの方法の失敗の基準が満たされ次第、デプロイは失敗に設定されます。
使用するメソッドを決定する際は、以下のガイドラインを参考にします。
+ サーキットブレーカー - タスクが開始できないときにデプロイを停止する場合は、このメソッドを使用します。
+ CloudWatch アラーム - アプリケーションメトリクスに基づきデプロイを停止する場合は、このメソッドを使用します。
どちらの方法も、以前のサービスリビジョンへのロールバックをサポートしています。
## コンテナイメージの解決
デフォルトでは、Amazon ECS はタスク定義で指定されたコンテナイメージタグをコンテナイメージダイジェストに解決します。単一のタスクを実行および維持するサービスを作成すると、そのタスクはタスク内のコンテナイメージダイジェストを確立するために使用されます。複数のタスクを実行および維持するサービスを作成すると、デプロイ中にサービススケジューラによって開始された最初のタスクを使用して、タスク内のコンテナイメージダイジェストを確立します。
コンテナイメージダイジェストの確立を 3 回以上試行しても失敗した場合、デプロイはイメージダイジェストの解決なしで続行されます。デプロイサーキットブレーカーが有効になっている場合、デプロイも失敗し、ロールバックされます。
コンテナイメージダイジェストが確立されると、Amazon ECS はこのダイジェストを、他の対象タスクの開始や、その後のサービスの更新に使用します。この結果、サービス内のすべてのタスクで常に同じコンテナイメージが実行され、ソフトウェアのバージョン整合性が得られます。
この動作は、コンテナ定義の `versionConsistency` パラメータを使用して、タスク内のコンテナごとに設定できます。詳細については、「[versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency)」を参照してください。
**注記**
`1.31.0` より前のバージョンの Amazon ECS エージェントは、イメージダイジェストの解決をサポートしていません。エージェントバージョン `1.31.0`～`1.69.0` では、Amazon ECR リポジトリにプッシュされたイメージに対してのみイメージダイジェストの解決がサポートされています。エージェントバージョン `1.70.0` 以降では、すべてのイメージに対してイメージダイジェストの解決がサポートされています。
イメージダイジェスト解決に対応した Fargate Linux プラットフォームの最低バージョンは `1.3.0` です。イメージダイジェスト解決に対応した Fargate Windows プラットフォームの最低バージョンは `1.0.0` です。
Amazon ECS は、Amazon GuardDuty セキュリティエージェントや Service Connect プロキシなど、Amazon ECS によって管理されるサイドカーコンテナのダイジェストをキャプチャしません。
複数のタスクがあるサービスでコンテナイメージの解決に関連する潜在的なレイテンシーを減らすには、EC2 コンテナインスタンスで Amazon ECS エージェントバージョン `1.83.0` 以降を実行してください。潜在的なレイテンシーを回避するには、タスク定義でコンテナイメージダイジェストを指定します。
タスク数が 0 のサービスを作成した場合、タスク数が 0 よりも大きいサービスの別のデプロイをトリガーするまで Amazon ECS はコンテナダイジェストを確立できません。
更新されたイメージダイジェストを確立するために、新しいデプロイを強制できます。更新されたダイジェストは新しいタスクの開始に使用され、既に実行中のタスクには影響しません。新しいデプロイの強制の詳細については、「*Amazon ECS API リファレンス*」の「[forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)」を参照してください。
EC2 キャパシティプロバイダーを使用すると、最初のデプロイ中にタスクを開始するキャパシティーが不十分な場合、ソフトウェアバージョンの整合性が失敗する可能性があります。容量が制限されていてもバージョンの整合性を維持するには、デフォルトの動作に依存するのではなく、タスク定義のコンテナ設定で `versionConsistency: "enabled"` を明示的に設定してください。これは、デプロイに進む前に、キャパシティが利用可能になるまで Amazon ECS が待機する原因になります。