翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon ECS サービス
Amazon ECS サービスを使用すると、Amazon ECS クラスター内で、タスク定義の指定した数のインスタンスを同時に実行して維持できます。タスクの 1 つが失敗または停止した場合、Amazon ECS サービススケジューラはタスク定義の別のインスタンスを起動してそれを置き換えます。これは、サービスで必要な数のタスクを維持するのに役立ちます。
オプションで、ロードバランサーの背後でサービスを実行することもできます。ロードバランサーは、サービスに関連付けられたタスク間でトラフィックを分散させます。
サービススケジューラの概念
長時間実行されるステートレスサービスおよびアプリケーションには、サービススケジューラを使用することをお勧めします。サービススケジューラにより、指定したスケジューリング戦略が順守され、タスクが失敗したときに タスクが再スケジュールされます。例えば、基盤となるインフラストラクチャに障害が発生した場合、サービススケジューラはタスクを再スケジュールします。タスク配置の戦略と制約を使用して、スケジューラがタスクを配置および終了する方法をカスタマイズできます。サービス内のタスクが停止すると、スケジューラはタスクを置き換えるために新しいタスクを起動します。このプロセスは、サービスが使用するスケジュール戦略に基づいて、サービスがタスクの必要数に達するまで続行されます。サービスのスケジューリング戦略は、サービスタイプとも呼ばれます。
また、コンテナのヘルスチェックまたはロードバランサーのターゲットグループのヘルスチェックが失敗すると、サービススケジューラーによって、異常であると判断されたタスクが置き換えられます。この置き換え動作は、maximumPercent
および desiredCount
のサービス定義パラメータによって異なります。タスクが異常とマークされた場合、サービススケジューラーによってまず置き換えタスクが開始されます。置き換えタスクのヘルスステータスが HEALTHY
になると、サービススケジューラーは異常のあるタスクを停止します。置き換えタスクのヘルスステータスが UNHEALTHY
の場合、スケジューラーは異常のある置き換えタスクまたは既存の異常タスクのいずれかを停止して、タスク総数が desiredCount
と等しくなるようにします。maximumPercent
パラメーターによって、置き換えタスクを先に開始できないようにスケジューラーが制限されている場合、スケジューラーは異常のあるタスクをランダムに 1 つずつ停止して容量を解放してから置き換えタスクを開始します。異常のあるタスクがすべて正常なタスクに置き換えられるまで、起動と停止のプロセスが続きます。異常なタスクがすべて置き換えられ、正常なタスクだけが実行中になると、合計タスク数が desiredCount
を超える場合、タスク数が desiredCount
になるまで、正常なタスクが無作為に停止されます。maximumPercent
および desiredCount
の詳細については、「サービス定義パラメータ」を参照してください。
注記
この動作は、ローリング更新デプロイタイプを使用するサービスによって実行および管理されるタスクには適用されません。ローリング更新中、サービススケジューラーはまず異常なタスクを停止してから置き換えタスクを開始します。
サービススケジューラには、タスクが繰り返し起動に失敗した場合にタスクを再起動する頻度を調整するロジックが含まれています。RUNNING
状態にならずにタスクが停止すると、サービススケジューラは起動の試行の速度を遅くし始め、サービスイベントメッセージを送信します。この動作により、問題を解決する前に、失敗したタスクに不要なリソースが使用されるのを防ぐことができます。サービスが更新されると、サービススケジューラは正常なスケジューリング動作を再開します。詳細については、サービスの調整ロジックおよびサービスイベントメッセージを参照してください。
利用できる 2 つのサービススケジューラ戦略があります。
-
REPLICA
- レプリカスケジュール戦略では、クラスター全体で必要数のタスクを配置して維持します。デフォルトでは、サービススケジューラによってタスクはアベイラビリティーゾーン間に分散されます。タスク配置の戦略と制約を使用すると、タスク配置の決定をカスタマイズできます。詳細については、「レプリカ」を参照してください。 -
DAEMON
- デーモンのスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。この戦略を使用する場合、タスクの必要数や配置戦略、サービスの自動スケーリングポリシーを指定する必要はありません。詳細については、「デーモン」を参照してください。注記
Fargate タスクは
DAEMON
スケジュール戦略をサポートしません。
デーモン
デーモンのスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。また、サービススケジューラは、実行中のタスクのタスク配置の制約事項を評価し、配置制約を満たさないタスクを停止します。この戦略を使用する場合、タスクの必要数や配置戦略、サービスの自動スケーリングポリシーを指定する必要はありません。
Amazon ECS は、CPU、メモリ、およびネットワークインターフェイスを含むコンテナインスタンスのコンピューティングリソースをデーモンタスク用に予約します。他のレプリカサービスを使用してクラスターでデーモンサービスを起動すると、Amazon ECS はデーモンタスクを優先します。これは、デーモンタスクがインスタンスで起動する最初のタスクであり、停止する最後のタスクであることを意味します。この戦略により、保留中のレプリカ・タスクでリソースが使用されず、デーモンタスクでリソースを使用できるようになります。
デーモンサービススケジューラは DRAINING
ステータスのインスタンスにはタスクを配置しません。コンテナインスタンスが DRAINING
ステータスに移行すると、そのインスタンス上のデーモンタスクは停止します。サービススケジューラは、すべてのレプリカタスクが停止した後に、デーモンタスクが最後に停止するようにします。サービススケジューラはまた、新しいコンテナインスタンスがいつクラスターに追加されるかをモニタリングし、追加されたらそれらのインスタンスにデーモンタスクを追加します。
デプロイ設定を指定する場合、最大パーセントパラメータは 100
である必要があります。のデーモンサービスのデフォルト値は 200% maximumPercent
です。デーモンサービスの minimumHealthyPercent
のデフォルト値は 100% です。
デーモンサービスの配置制約を変更するには、サービスを再起動する必要があります。Amazon ECS は、デーモンタスクの対象となるインスタンスに予約されているリソースを動的に更新します。既存のインスタンスの場合、スケジューラはインスタンスにタスクを配置しようとします。
タスク定義でタスクサイズまたはコンテナリソースの予約が変更されると、新しいデプロイが開始されます。Amazon ECS は、デーモンの更新された CPU およびメモリ予約をピックアップし、デーモンのタスクでその容量をブロックします。
上記のいずれかの場合に十分なリソースがない場合、次のことが起こります。
-
タスクの配置が失敗します。
-
CloudWatch イベントが生成されます。
-
Amazon ECS は、リソースが使用可能になるのを待って、インスタンスでタスクのスケジュールを試行します。
-
Amazon ECS は、配置制約基準を満たさなくなったリザーブドインスタンスを解放し、対応するデーモンタスクを停止します。
デーモンのスケジューリング戦略は、次の場合に使用できます。
-
アプリケーションコンテナの実行
-
ログ記録、モニタリング、トレースタスク用のサポートコンテナの実行
Fargate 起動タイプ、 CODE_DEPLOY
または EXTERNAL
デプロイメントコントローラータイプを使用するタスクは、スケジューリング戦略をサポートしません。
サービススケジューラがタスクの実行を停止する場合、アベイラビリティーゾーン間のクラスターの負荷バランスを維持します。スケジューラは、次のロジックを使用します。
-
配置戦略が定義されている場合、その戦略を使用して終了するタスクを選択します。例えば、サービスにアベイラビリティーゾーンの spread 戦略が定義されている場合、1 つのタスクが選択され、残りのタスクは最適に分散されたまま残ります。
-
配置戦略が定義されていない場合は、次のロジックを使用してクラスター内のアベイラビリティーゾーン全体への配分を維持します。
-
有効なコンテナインスタンスをソートします。それぞれのアベイラビリティーゾーンで、このサービスの実行中のタスクの数が最も多いインスタンスを優先します。例えば、実行中のサービスタスクがゾーン A には 1 つ、ゾーン B とゾーン C にはそれぞれ 2 つずつある場合、ゾーン B またはゾーン C のいずれかのコンテナインスタンスが終了に最適と見なされます。
-
前のステップに基づいて、最適なアベイラビリティーゾーン内のコンテナインスタンスで、タスクを停止します。このサービスで実行中のタスク数が最も多いコンテナインスタンスを優先します。
-
レプリカ
レプリカスケジュール戦略では、クラスターに必要数のタスクを配置して維持します。
Fargate でタスクを実行するサービスについては、サービススケジューラは、新しいタスクの起動時や実行中タスクの停止時に、アベイラビリティーゾーン間の負荷バランスを維持するよう最大限試みます。タスク置き換え戦略や制約を指定する必要はありません。
EC2 インスタンスでタスクを実行するサービスを作成する場合、オプションでタスク配置戦略と制約を指定して、タスク配置に関する決定をカスタマイズできます。タスク配置戦略または制約が指定されていない場合、デフォルトでは、サービススケジューラはタスクをアベイラビリティーゾーン全体に分散します。サービススケジューラは、次のロジックを使用します。
-
クラスター内のどのコンテナインスタンスがサービスのタスク定義をサポートできるか (必要な CPU、メモリ、ポート、コンテナインスタンス属性がなど) を判断します。
-
サービスに定義された配置の制約を満たすコンテナインスタンスを特定します。
-
デーモンサービスに依存するレプリカサービス (たとえば、タスクがログを使用する前に実行する必要があるデーモンログルータスクなど) がある場合は、デーモンサービスタスクがレプリカサービスタスクよりも前に EC2 インスタンスに配置されるようにするタスク置き換え制約を作成します。詳細については、「制約事項の例」を参照してください。
-
配置戦略が定義されている場合は、その戦略を使用して残りの候補からインスタンスを選択します。
-
定義された配置戦略がない場合は、次のロジックを使用してクラスター内のアベイラビリティーゾーン全体にタスクが配分されます。
-
有効なコンテナインスタンスをソートします。それぞれのアベイラビリティーゾーンで、このサービスの実行中のタスクの数が最も少ないインスタンスを優先します。例えば、ゾーン A に実行中のサービスタスクが 1 つあり、ゾーン B と C に実行中のサービスタスクがない場合、ゾーン B または C のいずれかの有効なコンテナインスタンスが配置に最適と見なされます。
-
前のステップに基づいて、新しいサービスタスクを最適なアベイラビリティーゾーン内の有効なコンテナインスタンスに配置します。このサービスで実行中のタスク数が最も少ないコンテナインスタンスを優先します。
-
その他のサービスの概念
-
オプションで、ロードバランサーの背後でサービスを実行できます。詳細については、「サービスの負荷分散」を参照してください。
-
オプションで、サービスのデプロイ設定を指定できます。デプロイは、サービスのタスク定義を更新することによって開始されます。デプロイ中、サービススケジューラは、最小ヘルス率と最大ヘルス率のパラメータを使用して、デプロイ戦略を判断します。詳細については、「サービス定義パラメータ」を参照してください。
-
サービスはオプションで Amazon ECS サービスディスカバリを使用するように設定できます。サービス検出では、 AWS Cloud Map 自動命名 APIs を使用して、サービスのタスクの DNS エントリを管理します。これにより、VPC 内からそれらを検出できるようになります。詳細については、「サービス検出」を参照してください。
-
サービスを削除するときに、クリーンアップが必要なタスクがまだ実行中の場合、サービスは
ACTIVE
からDRAINING
ステータスに移行し、そのサービスはコンソールまたはListServices
API オペレーションで表示されなくなります。すべてのタスクがSTOPPING
またはSTOPPED
ステータスに移行された後、サービスステータスはDRAINING
からINACTIVE
になります。DRAINING
API オペレーションを使用して、INACTIVE
またはDescribeServices
ステータスのサービスを表示できます。ただし、INACTIVE
のサービスは、後で Amazon ECS によって保存されたレコードからクリーンアップされて削除され、それらのサービスに対してDescribeServices
を呼び出すと、ServiceNotFoundException
エラーが返る可能性があります。 -
ベイク時間は、新しいサービスバージョンがスケールアウトされ、古いサービスバージョンがスケールインされた後の期間で、その間 Amazon ECS はデプロイに関連するアラームを監視し続けます。Amazon ECS は、デプロイに関連するアラーム設定に基づいてこの期間を計算します。
ベイク時間は、 CloudWatch アラームを使用してデプロイの失敗を検出する場合にのみ適用されます。詳細については、「障害検出方法」を参照してください。