# Amazon ECS サービスのパラメータの更新
サービスを作成した後、タスクの数など、サービスパラメータを更新する必要がある場合があります。
サービススケジューラが新しいタスクを起動するとき、次のロジックを使用してクラスター内のタスク配置を決定します。
+ クラスター内のどのコンテナインスタンスがサービスのタスク定義をサポートできるか判断します。例えば、必要な CPU、メモリ、ポート、コンテナインスタンス属性があります。
+ デフォルトで、サービススケジューラは、別の配置戦略を選択できる場合でも、この方法でアベイラビリティーゾーン間でタスクのバランスをとるように試みます。
+ 有効なコンテナインスタンスを、インスタンスと同じアベイラビリティーゾーンでサービスの実行中タスクが少ない順にソートします。例えば、ゾーン A に実行中のサービスタスクが 1 つあり、ゾーン B と C に実行中のサービスタスクがない場合、ゾーン B または C のいずれかの有効なコンテナインスタンスが配置に最適と見なされます。
+ 新しいサービスタスクを最適なアベイラビリティーゾーン内の有効なコンテナインスタンスに配置し (前の手順に基づいて)、実行中のサービスタスクの数が最小のコンテナインスタンスを優先させます。
サービススケジューラがタスクの実行を停止する場合、次のロジックを使用してアベイラビリティーゾーン間のクラスターの負荷バランスを維持します。
+ コンテナインスタンスを、インスタンスと同じアベイラビリティーゾーンでサービスの実行中タスクが多い順にソートします。たとえば、実行中のサービスタスクがゾーン A には 1 つ、ゾーン B とゾーン C にはそれぞれ 2 つずつある場合、ゾーン B またはゾーン C のいずれかのコンテナインスタンスが終了に最適と見なされます。
+ 実行中のサービスタスクの数が多いコンテナインスタンスの順に従って、最適なアベイラビリティーゾーン内のコンテナインスタンスで (前述の手順に基づいて) タスクを停止します。
リストを使用して、サービスパラメータを変更できるかどうかを判断してください。
**アベイラビリティーゾーンの再調整**
サービスにアベイラビリティーゾーンの再調整を使用するかどうか示します。
このパラメータはローリングデプロイで変更できます。
**キャパシティプロバイダー戦略**
キャパシティプロバイダー戦略の詳細。クラスターの作成、タスクの実行、またはサービスの更新時に、キャパシティプロバイダーを設定できます。
Fargate を使用する場合、キャパシティプロバイダーは `FARGATE` または `FARGATE_SPOT` です。
Amazon EC2 を使用する場合、キャパシティプロバイダーは Auto Scaling グループです。
ローリングデプロイとブルー/グリーンデプロイのキャパシティプロバイダーは変更できます。
次のリストは、有効な移行を表示しています。
+ Fargate を Auto Scaling グループキャパシティプロバイダーに更新します。
+ EC2 を Fargate キャパシティプロバイダーに更新します。
+ Fargate キャパシティプロバイダーを Auto Scaling グループキャパシティプロバイダーに更新します。
+ Amazon EC2 キャパシティプロバイダーを Fargate キャパシティプロバイダーに更新します。
+ Auto Scaling グループまたは Fargate キャパシティプロバイダーを更新して起動タイプに戻します。CLI または API を使用する場合は、`capacityProviderStrategy` パラメータに空のリストを渡します。
**クラスター**
クラスターの名前を変更することはできません。
**Deployment configuration**
デプロイ設定には、CloudWatch アラーム、障害の検出に使用されるサーキットブレーカー、必要な設定が含まれます。
デプロイサーキットブレーカーは、サービスが定常状態に到達できなかった場合にサービスのデプロイを失敗させるかどうかを決定します。デプロイサーキットブレーカーを使用すると、サービスデプロイは失敗状態に移行し、新しいタスクの起動を停止します。ロールバックオプションを使用すると、サービスのデプロイに失敗すると、サービスは、前回正常に完了したデプロイへとロールバックされます。
Amazon ECS サーキットブレーカーを使用するサービスを更新すると、Amazon ECS はサービスデプロイとサービスリビジョンを作成します。これらのリソースを使用すると、サービス履歴に関する詳細情報を表示できます。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。
サービススケジューラは、最小ヘルス率と最大ヘルス率のパラメータ (サービスのデプロイ設定) を使用して、デプロイ戦略を判断します。
サービスでローリング更新 (`ECS`) のデプロイタイプが使用されている場合、**最小ヘルス率**は、デプロイ時に `RUNNING` 状態に保つ必要のあるサービスのタスクの下限数をサービスのタスクの必要数のパーセント値 (最も近い整数に切り上げ) で表します。サービスに EC2 を使用するタスクが含まれている場合、`DRAINING` 状態のコンテナインスタンスがある間は、パラメータも適用されます。追加のクラスターキャパシティーを使用しないデプロイのために、このパラメータを使用します。例えば、サービスで必要数が 4 タスク、最小ヘルス率が 50% とすると、スケジューラは 2 つの新しいタスクを開始する前に、2 つの既存のタスクを停止してクラスターのキャパシティーを解放できます。ロードバランサーを使用しないサービスのタスクは、`RUNNING` 状態にある場合正常な状態とサービスからみなされます。ロードバランサーを使用するサービスのタスクは、`RUNNING` 状態にあり、ロードバランサーによって正常と報告された場合に、サービスから正常であるとみなされます。最小ヘルス率のデフォルト値は 100% です。
サービスでローリング更新 (`ECS`) のデプロイタイプが使用されている場合、**maximum percent** パラメータは、デプロイ時に `PENDING`、`RUNNING`、または `STOPPING` 状態で使用できるサービスのタスクの上限数をそれらのタスク数の適切なパーセント値 (最も近い整数に切り下げ) として表します。サービスに EC2 を使用するタスクが含まれている場合、`DRAINING` 状態のコンテナインスタンスがある間は、パラメータも適用されます。このパラメータは、デプロイのバッチサイズを定義するために使用します。例えば、サービスで必要数が 4 タスク、最大ヘルス率の値が 200% とすると、スケジューラは 4 つの古いタスクを停止する前に、4 つの新しいタスクを開始できます。そのために必要なクラスターリソースを使用できることが前提です。最大ヘルス率のデフォルト値は 200% です。
更新中にサービススケジューラがタスクを置き換えるとき、サービスはまずロードバランサーからタスクを削除し (使用されている場合)、接続のドレインが完了するのを待ちます。その後、タスクで実行されているコンテナに **docker stop** と同等のコマンドが発行されます。この結果、`SIGTERM` 信号と 30 秒のタイムアウトが発生し、その後に `SIGKILL` が送信され、コンテナが強制的に停止されます。コンテナが `SIGTERM` 信号を正常に処理し、その受信時から 30 秒以内に終了する場合、`SIGKILL` 信号は送信されません。サービススケジューラは、最小ヘルス率と最大ヘルス率の設定で定義されているとおりに、タスクを開始および停止します。
また、コンテナのヘルスチェックまたはロードバランサーのターゲットグループのヘルスチェックが失敗すると、サービススケジューラーによって、異常であると判断されたタスクが置き換えられます。この置き換え動作は、`maximumPercent` および `desiredCount` のサービス定義パラメータによって異なります。タスクが異常とマークされた場合、サービススケジューラーによってまず置き換えタスクが開始されます。次に以下が発生します。
+ 置き換えタスクのヘルスステータスが `HEALTHY` になると、サービススケジューラーが異常のあるタスクを停止します。
+ 置き換えタスクのヘルスステータスが `UNHEALTHY` の場合、スケジューラーは異常のある置き換えタスクまたは既存の異常タスクのいずれかを停止して、タスク総数が `desiredCount` と等しくなるようにします。
`maximumPercent` パラメーターによって、置き換えタスクを先に開始できないようにスケジューラーが制限されている場合、スケジューラーは異常のあるタスクをランダムに 1 つずつ停止して容量を解放してから置き換えタスクを開始します。異常のあるタスクがすべて正常なタスクに置き換えられるまで、起動と停止のプロセスが続きます。異常なタスクがすべて置き換えられ、正常なタスクだけが実行中になると、合計タスク数が `desiredCount` を超える場合、タスク数が `desiredCount` になるまで、正常なタスクが無作為に停止されます。`maximumPercent` および `desiredCount` の詳細については、「[サービス定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html)」を参照してください。
**デプロイコントローラー**
サービスで使用するデプロイコントローラータイプ。次の 3 つのデプロイコントローラータイプを使用できます。
+ `ECS`
+ `EXTERNAL`
+ `CODE_DEPLOY`
サービスを更新すると、使用されるデプロイコントローラーを更新できます。次のリストは、有効な移行を表示しています。
+ CodeDeploy ブルー/グリーンデプロイ (`CODE_DEPLOY`) から ECS ローリングデプロイまたはブルー/グリーンデプロイ (`ECS`) に更新します。
+ CodeDeploy ブルー/グリーンデプロイ (`CODE_DEPLOY`) から外部デプロイ (`EXTERNAL`) に更新します。
+ ECS ローリングまたはブルー/グリーンデプロイ (`ECS`) から外部デプロイ (`EXTERNAL`) に更新します。
+ 外部デプロイ (`EXTERNAL`) から ECS ローリングデプロイまたはブルー/グリーンデプロイ (`ECS`) に更新します。
サービスのデプロイコントローラーを更新する際には、次の点を考慮してください。
+ VPC Lattice または Amazon ECS Service Connect を使用している場合、サービスのデプロイコントローラーを `ECS` デプロイコントローラーから他のコントローラーに更新することはできません。
+ サービスのデプロイ中に、サービスのデプロイコントローラーを更新することはできません。
+ サービスにロードバランサーがない場合、サービスのデプロイコントローラーを `CODE_DEPLOY` に更新することはできません。
+ `deploymentConfiguration` にアラーム、デプロイサーキットブレーカー、`BLUE_GREEN` デプロイ戦略が含まれている場合、サービスのデプロイコントローラーを `ECS` から他のコントローラーに更新することはできません。詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。
+ サービスのデプロイコントローラーを `ECS` から他のコントローラーに更新した場合、コンテナ定義で `versionConsistency` に指定した値は Amazon ECS で使用されません。
+ サービスのデプロイコントローラーを `ECS` から他のコントローラーに更新しても、`UpdateService` および `DescribeService` API レスポンスは依然として `taskSets` ではなく、`deployments` を返します。`UpdateService` および `CreateService` の詳細については、「*Amazon ECS API Reference*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)」および「[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)」を参照してください。
+ サービスがローリング更新のデプロイ戦略を使用している場合、デプロイコントローラーを `ECS` から他のコントローラーに更新すると、`deploymentConfiguration` の `maximumPercent` 値の使用方法が変更されます。ローリング更新デプロイで合計タスクの上限として使用されるだけではなく、`maximumPercent` は異常なタスクを置き換えるために使用されます。スケジューラが異常なタスクを置き換える方法の詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。
+ サービスのデプロイコントローラーを `ECS` から他のデプロイコントローラーに更新した場合、ロードバランサー設定で指定した `advancedConfiguration` は無視されます。詳細については、「*Amazon ECS API リファレンス*」の「[LoadBalancer](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LoadBalancer.html)」および「[AdvancedConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AdvancedConfiguration.html)」を参照してください。
CloudFormation を使用してサービスのデプロイコントローラーを更新する際には、実行する移行のタイプに応じて次の点を考慮してください。
+ `EXTERNAL` デプロイコントローラー情報に加え、`TaskSet` および `PrimaryTaskSet`リソースを含む CloudFormation テンプレートがあって、`EXTERNAL` から `ECS` に更新するときにテンプレートからタスクセットのリソースを削除する場合、デプロイコントローラーが `ECS` に更新されると、`DescribeTaskSet` および `DeleteTaskSet` API コールは 400 エラーを返します。CloudFormation スタックを `UPDATE_COMPLETE` ステータスに移行しても、タスクセットのリソースで CloudFormation の削除が失敗します。詳細については、「AWS CloudFormation ユーザーガイド」の「[リソースはスタックから削除されましたが、削除されない](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted)」を参照してください。この問題を解決するには、Amazon ECS `DeleteTaskSet` API を使用してタスクセットを直接削除します。タスクセットを削除する方法の詳細については、「*Amazon Elastic Container Service* *API リファレンス*」の「[DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)」を参照してください。
+ 新しいタスク定義で `CODE_DEPLOY` から `ECS` に移行して、CloudFormation でロールバックオペレーションを実行すると、Amazon ECS `UpdateService` リクエストは次のエラーで失敗します。
```
Resource handler returned message: "Invalid request provided: Unable to update
task definition on services with a CODE_DEPLOY deployment controller. Use AWS
CodeDeploy to trigger a new deployment. (Service: Ecs, Status Code: 400,
Request ID: 0abda1e2-f7b3-4e96-b6e9-c8bc585181ac) (SDK Attempt Count: 1)"
(RequestToken: ba8767eb-c99e-efed-6ec8-25011d9473f0, HandlerErrorCode: InvalidRequest)
```
+ `ECS` から `EXTERNAL` デプロイコントローラーへの移行が正常に完了した後には、Amazon ECS がデプロイを管理しなくなるため、`ACTIVE` タスクセットを手動で削除する必要があります。タスクセットを削除する方法の詳細については、「Amazon Elastic Container Service *API リファレンス*」の「[DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)」を参照してください。
**希望タスク数**
タスクのインスタンスをサービス内に配置し、実行し続ける数です。
サービスを一時的に停止したい場合は、この値を 0 に設定します。次に、サービスを開始する準備ができたら、サービスを元の値で更新します。
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。
**マネージドタグの有効化**
サービス内のタスクに Amazon ECS マネージドタグをオンにするか否かを決定します。
更新後に起動されたタスクのみに更新が反映されます。すべてのタスクのタグを更新する場合、強制デプロイオプションを使用します。
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。
**ECS Exec の有効化**
Amazon ECS Exec を使用するかどうかを決定します。
サービスの作成時に設定された値を上書きしたくない場合は、このアクションを実行するときにこれを null に設定できます。
このパラメータはローリングデプロイで変更できます。
**ヘルスチェックの猶予期間**
Amazon ECS サービススケジューラが、タスクが最初に開始された後で異常な Elastic Load Balancing、VPC Lattice、コンテナのヘルスチェックを無視する期間 (秒単位)。ヘルスチェックの猶予期間値を指定しない場合、デフォルト値 `0` が使用されます。ヘルスチェックを使用しない場合、`healthCheckGracePeriodSeconds` は使用されません。
サービスのタスクが開始してヘルスチェックに応答するまでに時間がかかる場合は、ヘルスチェックの猶予期間として最大 2,147,483,647 秒 (約 69 年) まで指定できます。この間は、Amazon ECS サービススケジューラはヘルスチェックのステータスを無視します。この猶予期間により、サービススケジューラがタスクを異常とマークして時間より前に停止することがなくなります。
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。
**ロードバランサー**
ロードバランサーを更新するとき、サービスにリンクされたロールを使用する必要があります。
Elastic Load Balancing ロードバランサーオブジェクトのリストです。これには、ロードバランサー名、コンテナ名、ロードバランサーからアクセスするコンテナポートが含まれます。コンテナ名は、コンテナの定義に表示されるものです。
Amazon ECS は、Elastic Load Balancing ロードバランサーまたは Amazon ECS コンテナインスタンスに関連付けられたセキュリティグループを自動的には更新しません。
ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいタスクを開始し、その後新しいタスクを実行中に古いタスクを停止します。
ローリング更新を使用するサービスの場合、Elastic Load Balancing ターゲットグループを追加、更新、削除できます。1 つのターゲットグループから複数のターゲットグループに、および複数のターゲットグループから 1 つのターゲットグループに更新できます。
ブルー/グリーンデプロイを使用するサービスの場合、CodeDeploy を介して `[CreateDeployment](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html)` を使用し、Elastic Load Balancing ターゲットグループを更新できます。ブルー/グリーンデプロイでは、複数のターゲットグループがサポートされていないことに注意してください。詳細については、「[Amazon ECS サービスに複数のターゲットグループを登録する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)」を参照してください。
外部デプロイコントローラーを使用するサービスの場合、[CreateTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateTaskSet.html) を使用してロードバランサーを追加、更新、削除できます。外部デプロイでは、複数のターゲットグループがサポートされていないことに注意してください。詳細については、「[Amazon ECS サービスに複数のターゲットグループを登録する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)」を参照してください。
空のリストを渡してロードバランサーを削除します。
このパラメータはローリングデプロイで変更できます。
**ネットワーク構成**
サービスのネットワーク構成です。
このパラメータはローリングデプロイで変更できます。
**配置の制約事項**
使用するサービスを更新するための、タスク配置制約オブジェクトの配列です。値を指定しないと、サービスの既存の配置制約は変更されません。この値を指定すると、サービスに定義されているすべての既存の配置制約が上書きされます。既存の配置制約をすべて削除するには、空の配列を指定します。
タスクごとに最大 10 個の制約を指定できます。この制限数には、タスク定義内の制約と、実行時に指定される制約が含まれます。
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。
**配置戦略**
使用するサービスを更新するためのタスク配置戦略オブジェクトです。値を指定しないと、サービスの既存の配置戦略は変更されません。この値を指定すると、サービスに定義されているすべての既存の配置戦略が上書きされます。既存の配置戦略を削除するには、空のオブジェクトを指定します。
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。
**プラットフォームバージョン**
サービスが実行される Fargate プラットフォームバージョンです。
Linux プラットフォームのバージョンを使用するサービスは、Windows プラットフォームのバージョンを更新できません。その逆も同様です。
このパラメータはローリングデプロイで変更できます。
**タグの伝播**
タグをタスク定義またはサービスからタスクへ伝播するかどうかを決定します。値を指定しない場合、タグは伝播されません。
更新後に起動されたタスクのみに更新が反映されます。すべてのタスクのタグを更新するには、`forceNewDeployment` を `true` に設定して、Amazon ECS が更新されたタグで新しいタスクを開始するようにします。
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。
**Service Connect の設定**
Amazon ECS Service Connect の設定です。このパラメータは、サービスがどのようにアプリケーション内の他のサービスに接続するかを決定します。
このパラメータはローリングデプロイで変更できます。
**サービスレジストリ**
サービスレジストリを更新するとき、サービスにリンクされたロールを使用する必要があります。
このサービスに割り当てるサービス検出レジストリの詳細。詳細については、「[サービス検出](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html)」を参照してください。
サービスレジストリ設定を追加、更新、削除すると、Amazon ECS は更新されたサービスレジストリ設定で新しいタスクを開始し、その後新しいタスクの実行時に古いタスクを停止します。
空のリストを渡して、サービスレジストリを削除します。
このパラメータはローリングデプロイで変更できます。
**タスク定義**
サービス内のタスクに使用するタスクの定義とリビジョンです。
タスク定義でコンテナが使用するポートを変更する場合は、更新後のポートを使用するようにコンテナインスタンスのセキュリティグループを更新する必要がある場合があります。
サービスのタスク定義を更新する場合は、ロードバランサー設定で指定されたコンテナ名とコンテナポートはタスク定義のままにしておく必要があります。
コンテナイメージのプル動作は、コンピューティングオプションによって異なります。詳細については、以下のいずれかを参照してください。
+ [Amazon ECS の AWS Fargate 用のアーキテクト](AWS_Fargate.md)
+ [Amazon ECS 用の EC2 キャパシティのアーキテクト](launch-type-ec2.md)
+ [Amazon ECS の外部インスタンス (Amazon ECS Anywhere)](launch-type-external.md)
このパラメータはローリングデプロイで変更できます。
**ボリューム設定**
`configuredAtLaunch` だったボリュームの詳細です。タスク定義で `configuredAtLaunch`が `true` に設定されていると、デプロイ中に作成およびアタッチされるサービス内のタスクごとに、このサービスパラメータによって 1 つの Amazon EBS ボリュームが設定されます。[ServiceManagedEBSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceManagedEBSVolumeConfiguration.html) では、サイズ、volumeType、IOPS、スループット、スナップショット、暗号化を設定できます。ボリュームの `name` は、タスク定義の `name` と一致する必要があります。null に設定すると、新しいデプロイがトリガーされません。それ以外では、この設定が既存の設定と異なると、新しいデプロイがトリガーされます。
このパラメータはローリングデプロイで変更できます。
**VPC Lattice の設定**
サービスの VPC Lattice 設定です。サービス間の通信のためにサービスと VPC Lattice を統合する方法を定義します。
このパラメータはローリングデプロイで変更できます。
## AWS CDK に関する考慮事項
AWS CDK はリソースの状態を追跡しません。サービスを作成しているのか、更新しているかはわかりません。お客様は、エスケープハッチを使用して ecs `Service` L1 コンストラクトに直接アクセスする必要があります。
エスケープハッチの詳細については、「*AWS Cloud Development Kit (AWS CDK) v2 デベロッパーガイド*」の「[AWS コンストラクトライブラリからコンストラクトをカスタマイズする](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html#develop-customize-escape)」を参照してください。
既存のサービスを `ecs.Service` コンストラクトに移行するには、次を実行します。
1. エスケープハッチを使用して、`Service` L1 コンストラクトにアクセスします。
1. `Service` L1 コンストラクトで次のプロパティを手動で設定します。
サービスが Amazon EC2 容量を使用している場合:
+ `daemon?`
+ `placementConstraints?`
+ `placementStrategies?`
+ `awsvpc` ネットワークモードを使用する場合は、`vpcSubnets?` および `securityGroups?` コンストラクトを設定する必要があります。
サービスが Fargate を使用している場合:
+ `FargatePlatformVersion`
+ `vpcSubnets?` と `securityGroups?` コンストラクト。
1. `launchType` を次のように設定します。
```
const cfnEcsService = service.node.findChild('Service') as ecs.CfnService;
cfnEcsService.launchType = "FARGATE";
```
起動タイプからキャパシティプロバイダーに移行するには、次を実行します。
1. エスケープハッチを使用して、`Service` L1 コンストラクトにアクセスします。
1. `capacityProviderStrategies?` コンストラクトを追加します。
1. サービスをデプロイします。