Amazon ECS のサービスイベントメッセージ
以下は、Amazon ECS コンソールで確認できる可能性があるサービスイベントメッセージの例です。
サービス (service-name
) が定常状態に達しました。
サービススケジューラは、サービスが正常で、必要な数のタスクが定常状態になったときに、service (
サービスイベントを送信します。service-name
) has
reached a steady state.
サービススケジューラは定期的にステータスを報告するため、このメッセージを複数回受信する場合があります。
サービス (service-name
) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。
サービススケジューラは、別のタスクを追加するために利用可能なリソースが見つからなかったときに、このイベントメッセージを送信します。以下に示しているのは、その考えられる原因です。
- クラスターにコンテナインスタンスが見つかなかった
-
タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「Amazon ECS Linux コンテナインスタンスの起動」を参照してください。
- ポートが足りない
-
タスクで固定ホストポートマッピングを使用している場合 (タスクでウェブサーバーのホスト上のポート 80 を使用している場合など)、1 つのコンテナが一度に使用できるホストポートは 1 つのみであるため、タスクごとに 1 つ以上のコンテナインスタンスが必要です。コンテナインスタンスをクラスターに追加するか、タスクの必要数を減らす必要があります。
- 登録されたポートが多すぎる
-
タスク配置に最も近いコンテナインスタンスは、コンテナインスタンスごとに許可される最大予約ホストポート数である 100 を超えることはできません。ホストポートの動的マッピングを使用すると、問題を解決できる場合があります。
- ポートは既に使用中です
-
このタスクのタスク定義は、選択されたコンテナインスタンスで既に実行されているタスクと同じポートをポートマッピングで使用します。サービスイベントメッセージは、以下のメッセージの一部としてコンテナインスタンス ID を本来選択していました。
The closest matching container-instance is already using a port required by your task.
- メモリが足りない
-
タスク定義で 1,000 MiB のメモリを指定しており、クラスター内の各コンテナインスタンスのメモリが 1,024 MiB の場合、コンテナインスタンスごとにこのタスクのコピーを 1 つのみ実行できます。タスク定義でメモリを減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。
注記
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「Amazon ECS Linux コンテナインスタンスのメモリを予約する」を参照してください。
- CPU が足りない
-
コンテナインスタンスには、CPU コアごとに 1,024 個の CPU ユニットがあります。タスク定義で 1,000 個の CPU ユニットを指定しており、クラスター内の各コンテナインスタンスの CPU ユニットが 1,024 個である場合、コンテナインスタンスごとにこのタスクのコピーを 1 つのみ実行できます。タスク定義で CPU ユニット数を減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。
- 十分な数の ENI アタッチメントポイントを利用できない
-
awsvpc
ネットワークモードを使用するタスクには、それぞれ独自の Elastic Network Interface (ENI) が提供されます。この ENI は、ENI をホストするコンテナインスタンスに添付されています。Amazon EC2 インスタンスは添付できる ENI の数には制限があり、クラスター内に利用可能なENI 容量があるコンテナインスタンスはありません。個別のコンテナインスタンスの ENI 制限は、以下の条件によって異なります。
-
awsvpcTrunking
アカウント設定をオプトインしていない場合、各コンテナインスタンスの ENI 制限は、インスタンスタイプによって異なります。詳細については、Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス」を参照してください。 -
awsvpcTrunking
アカウント設定をオプトインしているが、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動していない場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス」を参照してください。 -
awsvpcTrunking
アカウント設定をオプトインしていて、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動している場合、追加の ENI オプトインを利用できます。詳細については、「Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス」を参照してください。
awsvpcTrunking
アカウント設定のオプトインの詳細については、「Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす」を参照してください。クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。
-
- コンテナインスタンスに必須の属性がない
-
一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに
ECS_AVAILABLE_LOGGING_DRIVERS
エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とするパラメータが含まれており、この要件を満たすことができるコンテナインスタンスがない場合、そのタスクは配置できません。このエラーの一般的な原因は、サービスが
awsvpc
ネットワークおよび EC2 起動タイプを使用している場合です。指定したクラスターには、サービスの作成時にawsvpcConfiguration
で指定されたものと同じサブネットにコンテナインスタンスが登録されていません。特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「Amazon ECS タスク定義パラメータ」と「Amazon ECS コンテナエージェントの設定」を参照してください。
サービス (service-name
) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。container-instance-id に最も近い container-instance-id
には、使用可能な CPU ユニットがありません。
タスク配置に最も一致するコンテナインスタンスに、タスク定義の要件を満たす十分な CPU ユニットがありません。タスク定義のタスクサイズとコンテナ定義の両方のパラメータで、CPU の要件を確認します。
サービス (service-name
) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。container-instance-id に最も近い container-instance-id
で、エラー「AGENT」が発生しました。
タスク配置に最も一致するコンテナインスタンス上の Amazon ECS コンテナエージェントが切断されています。コンテナインスタンスに SSH で接続できる場合は、エージェントログを調べることができます。詳細については、「Amazon ECS コンテナエージェントのログ設定パラメータ」を参照してください。エージェントがインスタンスで実行されていることも確認する必要があります。Amazon ECS に最適化された AMI を使用している場合、次のコマンドでエージェントを停止して再開始する試みができます。
-
Amazon ECS に最適化された Amazon Linux 2 AMI および Amazon ECS に最適化された Amazon Linux 2023 AMI の場合
sudo systemctl restart ecs
-
Amazon ECS に最適化された Amazon Linux AMI の場合:
sudo stop ecs && sudo start ecs
サービス (service-name
) (instance instance-id
) は、 (理由 インスタンスが、少なくとも UnhealthyThreshold 回のヘルスチェックに連続して失敗した。) のため、(elb elb-name
) で正常ではありません
このサービスはロードバランサーに登録されており、ロードバランサーのヘルスチェックは失敗しています。詳細については、「Amazon ECS のサービスロードバランサーのトラブルシューティング」を参照してください。
サービス (service-name
) は、一貫してタスクを正常に開始できません。
このサービスには、連続して試行された後開始に失敗したタスクがあります。この時点で、サービススケジューラによって再試行間隔が段階的に増加し始めます。タスクの起動に失敗している理由をトラブルシューティングする必要があります。詳細については、「Amazon ECS サービスのスロットルロジック」を参照してください。
更新されたタスク定義などでサービスが更新された後、サービススケジューラは正常な動作を再開します。
サービス (service-name
) オペレーションは抑制されています。後で再試行します。
このサービスは、API スロットルの制限により、これ以上のタスクを起動できません。サービススケジューラが追加のタスクを起動できるようになると、再開します。
API レート制限クォータの引き上げをリクエストするには、[AWS Support Center (センター)
サービス (service-name
) は、サービスデプロイメント構成のため、デプロイメント中にタスクを停止または開始できませんでした。minimumHealthyPercent または maximumPercent の値を更新してから、もう一度試してください。
このサービスは、デプロイメント構成であるため、サービスのデプロイメント中にタスクを停止または開始できません。デプロイ設定は、サービスの作成時に定義される minimumHealthyPercent
値と maximumPercent
値で構成されます。これらの値は既存のサービスでも更新できます。
minimumHealthyPercent
は、デプロイ中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の下限を表します。これは、サービスに必要なタスク数に対するパーセンテージです。この値は切り上げられます。例えば、最小正常率が 50
で、必要なタスク数が 4 の場合、スケジューラは 2 つの新しいタスクを開始する前に既存のタスクを 2 つ停止できます。同様に、最小正常率が 75% で、必要なタスク数が 2 の場合、結果の値も 2 であるため、スケジューラはタスクを停止できません。
maximumPercent
は、デプロイ中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の上限を表します。これは、サービスに必要なタスク数に対するパーセンテージです。この値は切り捨てられます。例えば、最大パーセンテージが 200
で、目的のタスク数が 4 の場合、スケジューラは既存のタスクを 4 つ停止する前に 4 つの新しいタスクを開始できます。同様に、最大比率が 125
で、必要なタスク数が 3 の場合、結果の値も 3 であるため、スケジューラはタスクを開始できません。
最小正常率または最大正常率を設定するときは、デプロイメントがトリガーされたときにスケジューラが 1 つ以上のタスクを停止または開始できることを確認する必要があります。
サービス [service-name(サービス-名)
] がタスクを配置できませんでした。理由: 同時に実行できるタスク数の上限に達しました
エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「Amazon ECS の Service Quotas」を参照してください。クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「クォータ引き上げリクエスト」を参照してください。
サービス [service-name(サービス-名)
] がタスクを配置できませんでした。理由: 内部エラー。
このエラーが表示される理由として考えられるものは、次のとおりです。
あるサブネットがサポートされていないアベイラビリティーゾーンにあるため、サービスはタスクを開始できません。
サポートされた Fargate リージョンおよびアベイラビリティーゾーンの情報については、AWS Fargate で使用する Amazon ECS でサポートされているリージョン を参照してください。
サブネットのアベイラビリティーゾーンを確認する方法については、「Amazon VPC ユーザーガイド」の「サブネットの確認」を参照してください。
サービス [service-name(サービス-名)
] がタスクを配置できませんでした。理由:リクエストされた CPU 構成が制限を超えています。
エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「Amazon ECS の Service Quotas」を参照してください。クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「クォータ引き上げリクエスト」を参照してください。
サービス [service-name(サービス-名)
] がタスクを配置できませんでした。理由:リクエストされたメモリ構成が制限を超えています。
エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「Amazon ECS の Service Quotas」を参照してください。クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「クォータ引き上げリクエスト」を参照してください。
サービス [service-name(サービス-名)
] がタスクを配置できませんでした。理由: 同時に実行できる vCPU の上限数に達しました
AWS Fargate は、タスク数ベースのクォータから vCPU ベースのクォータに移行しています。
Fargate の vCPU ベースのクォータの引き上げをリクエストできます。詳細については、「Amazon ECS の Service Quotas」を参照してください。Fargate クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「Requesting a quota increase」(クォータ引き上げリクエスト) を参照してください。
タスクセット (taskSet-ID
) がスケールインできなかったため、サービス (service-name
) は定常状態に到達できませんでした。理由: 保護されているタスクの数が、必要なタスク数を超えています。
サービスに、必要なタスク数よりも多くの保護タスクがあります。次のいずれかを行うことができます。
-
現在のタスクの保護が期限切れになり、タスクを終了できるようになるまでお待ちください。
-
どのタスクを停止できるかを判断し、
UpdateTaskProtection
API でprotectionEnabled
オプションをfalse
に設定し、これらのタスクに対する保護を設定解除します。 -
サービスの必要なタスク数を増やして、保護されているタスクの数よりも多くします。
サービス (service-name
) が定常状態に到達できませんでした。理由:キャパシティープロバイダーにコンテナインスタンスが見つかりませんでした。
サービススケジューラは、別のタスクを追加するために利用可能なリソースが見つからなかったときに、このイベントメッセージを送信します。以下に示しているのは、その考えられる原因です。
- クラスターに関連付けられたキャパシティプロバイダーがありません
-
クラスターにキャパシティプロバイダーが関連付けられていることを確認するには、
describe-services
を使用します。サービスのキャパシティプロバイダー戦略を更新できます。キャパシティプロバイダーに利用可能なキャパシティがあることを確認します。EC2 起動タイプの場合は、コンテナインスタンスがタスク定義の要件を満たしていることを確認してください。
- クラスターにコンテナインスタンスが見つかなかった
-
タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「Amazon ECS Linux コンテナインスタンスの起動」を参照してください。
- ポートが足りない
-
タスクで固定ホストポートマッピングを使用している場合 (タスクでウェブサーバーのホスト上のポート 80 を使用している場合など)、タスクごとに 1 つ以上のコンテナインスタンスが必要です。一度に 1 つのホストポートを使用できるコンテナは 1 つだけです。コンテナインスタンスをクラスターに追加するか、タスクの必要数を減らす必要があります。
- 登録されたポートが多すぎる
-
タスク配置に最も近いコンテナインスタンスは、コンテナインスタンスごとに許可される最大予約ホストポート数である 100 を超えることはできません。ホストポートの動的マッピングを使用すると、問題を解決できる場合があります。
- ポートは既に使用中です
-
このタスクのタスク定義は、選択されたコンテナインスタンスで既に実行されているタスクと同じポートをポートマッピングで使用します。サービスイベントメッセージは、以下のメッセージの一部としてコンテナインスタンス ID を本来選択していました。
The closest matching container-instance is already using a port required by your task.
- メモリが足りない
-
タスク定義で 1,000 MiB のメモリを指定しており、クラスター内の各コンテナインスタンスのメモリが 1,024 MiB の場合、コンテナインスタンスごとにこのタスクのコピーを 1 つのみ実行できます。タスク定義でメモリを減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。
注記
特定のインスタンスタイプでタスクにできるだけ多くのメモリを提供してリソースの使用率を最大限に高めるには、「Amazon ECS Linux コンテナインスタンスのメモリを予約する」を参照してください。
- 十分な数の ENI アタッチメントポイントを利用できない
-
awsvpc
ネットワークモードを使用するタスクには、それぞれ独自の Elastic Network Interface (ENI) が提供されます。この ENI は、ENI をホストするコンテナインスタンスに添付されています。Amazon EC2 インスタンスにアタッチできる ENI の数には制限があり、クラスターには利用可能な ENI 容量があるコンテナインスタンスはありません。個別のコンテナインスタンスの ENI 制限は、以下の条件によって異なります。
-
awsvpcTrunking
アカウント設定をオプトインしていない場合、各コンテナインスタンスの ENI 制限は、インスタンスタイプによって異なります。詳細については、Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス」を参照してください。 -
awsvpcTrunking
アカウント設定をオプトインしているが、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動していない場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス」を参照してください。 -
awsvpcTrunking
アカウント設定をオプトインしていて、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動している場合、追加の ENI オプトインを利用できます。詳細については、「Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス」を参照してください。
awsvpcTrunking
アカウント設定のオプトインの詳細については、「Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす」を参照してください。クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。
-
- コンテナインスタンスに必須の属性がない
-
一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに
ECS_AVAILABLE_LOGGING_DRIVERS
エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とするパラメータが含まれており、この要件を満たすことができるコンテナインスタンスがない場合、そのタスクは配置できません。このエラーの一般的な原因は、サービスが
awsvpc
ネットワークモードを使用するタスクを使用していて、EC2 起動タイプと指定したクラスターに、サービスの作成時にawsvpcConfiguration
で指定された同じサブネットにコンテナインスタンスが登録されていない場合です。特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「Amazon ECS タスク定義パラメータ」と「Amazon ECS コンテナエージェントの設定」を参照してください。
サービス [service-name(サービス-名)
] がタスクを配置できませんでした。理由: 現在、容量は使用できません。後でもう一度試すか、別のアベイラビリティーゾーンで試してください。
現在、サービスを実行できる容量がありません。
次のいずれかを行うことができます。
-
Fargate 容量または EC2 コンテナインスタンスが使用可能になるまでお待ちください。
-
サービスを再起動し、追加のサブネットを指定します。
サービス (service-name
) のデプロイに失敗しました:タスクを開始できませんでした。
サービスのタスクが開始できませんでした。
停止タスクをデバッグする方法については、「Amazon ECS の停止したタスクのエラーメッセージ」を参照してください。
サービス (service-name
) が、Amazon ECS エージェントの開始を待ってタイムアウトになりました。/var/log/ecs/ecs-agent.log でログを確認してください。"
タスク配置に最も一致するコンテナインスタンス上の Amazon ECS コンテナエージェントが切断されています。コンテナインスタンスに SSH で接続できる場合は、エージェントログを調べることができます。詳細については、「Amazon ECS コンテナエージェントのログ設定パラメータ」を参照してください。エージェントがインスタンスで実行されていることも確認する必要があります。Amazon ECS に最適化された AMI を使用している場合、次のコマンドでエージェントを停止して再開始する試みができます。
-
Amazon ECS に最適化された Amazon Linux 2 AMI の場合
sudo systemctl restart ecs
-
Amazon ECS に最適化された Amazon Linux AMI の場合:
sudo stop ecs && sudo start ecs
TARGET GROUP IS NOT FOUND
が原因で、ターゲットグループ (target-group-ARN
) 内のサービス (service-name
) のタスクセット (TaskSet-ID
) に異常があります。
ターゲットグループが見つからなかったため、サービスのタスクセットはヘルスチェックに合格できません。サービスを削除して再作成してください。対応する Amazon ECS サービスが既に削除されていない限り、Elastic Load Balancing のターゲットグループを削除しないでください。
TARGET IS NOT FOUND
が原因で、ターゲットグループ (target-group-ARN
) 内のサービス (service-name
) のタスクセット (TaskSet-ID
) に異常があります。
ターゲットが見つからなかったため、サービスのタスクセットはヘルスチェックに合格できません。