サービスイベントメッセージ

サービスの問題をトラブルシューティングする際、最初に診断情報を確認する必要があるのは、サービスイベントログです。API、DescribeServices、 AWS CLIまたは を使用してサービスイベントを表示できます AWS Management Console。

Amazon ECS API を使用して、サービスイベントメッセージを表示する場合、サービススケジューラからのイベントのみが返されます。これには、最新のタスク配置とインスタンスの健全性イベントが含まれます。ただし、Amazon ECS コンソールには、次のソースからのサービスイベントが表示されます。

• Amazon ECS サービススケジューラからのタスク配置およびインスタンスのヘルスイベント。これらのイベントには、サービス (service-name) のプレフィックスが付いています。トラブルシューティングに役立つよう、このイベントビューには最新 100 件のイベントのみが表示され、重複したイベントメッセージは原因が解決されるか、6 時間が経過するまで省略されます。6 時間以内に原因が解決されない場合は、その原因に関する別のサービスイベントメッセージが表示されます。

• サービスの自動スケーリングイベント。これらのイベントには、メッセージ というプレフィックスが付いています。最新 10 件のスケーリングイベントが表示されます。これらのイベントは、サービスが Application Auto Scaling スケーリングポリシーで構成されている場合にのみ発生します。

現在のサービスイベントメッセージを表示するには、次の手順を実行します。

Console

1. コンソール (https://console.aws.amazon.com/ecs/v2) を開きます。

2. ナビゲーションペインで [Clusters] (クラスター) を選択します。

3. [Clusters] (クラスター) ページで、クラスターを選択します。

4. 検査するサービスを選択します。

5. [Events] (イベント) で [Deployments and events] (デプロイとイベント) を選択し、メッセージを表示します。

AWS CLI

指定したサービスのサービスイベントメッセージを表示するには、describe-service コマンドを使用します。

次の AWS CLI 例では、最新のサービスイベントメッセージを提供するデフォルトクラスター内の service-name サービスについて説明します。

aws ecs describe-services \
    --cluster default \
    --services service-name \
    --region us-west-2

サービスイベントメッセージ

以下は、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 つのみ実行できます。タスク定義でメモリを減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。

注記

リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「コンテナインスタンスのメモリ管理」を参照してください。

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 制限は、インスタンスタイプによって異なります。詳細については、Linux インスタンス用の Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数」を参照してください。

• awsvpcTrunking アカウント設定をオプトインしても、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動していない場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、Linux インスタンス用の Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数」を参照してください。

• awsvpcTrunking アカウント設定をオプトインしていて、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動している場合、追加の ENI オプトインを利用できます。詳細については、「サポートされている Amazon EC2 インスタンスタイプ」を参照してください。

awsvpcTrunking アカウント設定のオプトインの詳細については、「Elastic Network Interface のトランキング」を参照してください。

クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。

コンテナインスタンスに必須の属性がない

一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに ECS_AVAILABLE_LOGGING_DRIVERS エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とする パラメータが含まれており、この要件を満たす使用可能なコンテナインスタンスがない場合、タスクを配置できません。

このエラーの一般的な原因は、サービスが awsvpcネットワークモードと EC2 起動タイプを使用するタスクを使用している場合です。指定したクラスターには、サービスの作成awsvpcConfiguration時に で指定されたのと同じサブネットにコンテナインスタンスが登録されていません。

特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「タスク定義パラメータ」と「Amazon ECS コンテナエージェントの設定」を参照してください。

サービス (service-name) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。最も近い一致する container-instance で使用可能な CPU ユニットcontainer-instance-idが不足しています。

タスク配置に最も近い一致するコンテナインスタンスに、タスク定義の要件を満たすのに十分な CPU ユニットが含まれていません。タスク定義のタスクサイズとコンテナ定義の両方のパラメータで、CPU の要件を確認します。

サービス (service-name) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。最も近い一致する container-instance でエラー「エージェントcontainer-instance-id」が発生しました。

タスク配置に最も一致するコンテナインスタンス上の 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 回数連続して失敗したため）。

このサービスはロードバランサーに登録されており、ロードバランサーのヘルスチェックは失敗しています。詳細については、「サービスロードバランサーのトラブルシューティング」を参照してください。

サービス (service-name) は、一貫してタスクを正常に開始できません。

このサービスには、連続して試行された後開始に失敗したタスクがあります。この時点で、サービススケジューラによって再試行間隔が段階的に増加し始めます。タスクの起動に失敗している理由をトラブルシューティングする必要があります。詳細については、「Amazon ECS サービスの調整ロジック」を参照してください。

更新されたタスク定義などでサービスが更新された後、サービススケジューラは正常な動作を再開します。

サービス (service-name) オペレーションは抑制されています。後で再試行します。

このサービスは、API スロットルの制限により、これ以上のタスクを起動できません。サービススケジューラが追加のタスクを起動できるようになると、再開します。

API レート制限クォータの引き上げをリクエストするには、[AWS Support Center (センター)]の ページを開き、必要に応じてサインインし、[Create case (ケースを作成する)] を選択します。[Service Limit increase] (サービス制限の緩和) を選択します。フォームに入力して送信します。

サービス (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 ユーザーガイド」の「サブネットの確認」を参照してください。

• Fargate Spot で ARM アーキテクチャを使用するタスク定義を実行しようとしています。

サービス [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) は定常状態に到達できませんでした。理由: 保護されているタスクの数が、必要なタスク数を超えています。

サービスに、必要なタスク数よりも多くの保護タスクがあります。次のいずれかを行うことができます。

• 現在のタスクの保護が期限切れになり、タスクを終了できるようになるまでお待ちください。

• 停止できるタスクを特定し、 protectionEnabledオプションを に設定して UpdateTaskProtection API を使用しfalse、これらのタスクの保護を解除します。

• サービスの必要なタスク数を増やして、保護されているタスクの数よりも多くします。

サービス (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 つのみ実行できます。タスク定義でメモリを減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。

注記

特定のインスタンスタイプでタスクにできるだけ多くのメモリを提供してリソースの使用率を最大限に高めるには、「コンテナインスタンスのメモリ管理」を参照してください。

十分な数の ENI アタッチメントポイントを利用できない

awsvpc ネットワークモードを使用するタスクには、それぞれ独自の Elastic Network Interface (ENI) が提供されます。この ENI は、ENI をホストするコンテナインスタンスに添付されています。Amazon EC2 インスタンスにはアタッチできる ENIs の数に制限があり、クラスターには使用可能な ENI 容量を持つコンテナインスタンスはありません。

個別のコンテナインスタンスの ENI 制限は、以下の条件によって異なります。

• awsvpcTrunking アカウント設定をオプトインしていない場合、各コンテナインスタンスの ENI 制限は、インスタンスタイプによって異なります。詳細については、Linux インスタンス用の Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数」を参照してください。

• awsvpcTrunking アカウント設定をオプトインしても、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動していない場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、Linux インスタンス用の Amazon EC2 ユーザーガイドの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数」を参照してください。

• awsvpcTrunking アカウント設定をオプトインしていて、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを起動している場合、追加の ENI オプトインを利用できます。詳細については、「サポートされている Amazon EC2 インスタンスタイプ」を参照してください。

awsvpcTrunking アカウント設定のオプトインの詳細については、「Elastic Network Interface のトランキング」を参照してください。

クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。

コンテナインスタンスに必須の属性がない

一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに ECS_AVAILABLE_LOGGING_DRIVERS エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とする パラメータが含まれており、この要件を満たす使用可能なコンテナインスタンスがない場合、タスクを配置できません。

このエラーの一般的な原因は、サービスが awsvpcネットワークモードを使用するタスクを使用していて、EC2 起動タイプと指定したクラスターに、サービスの作成awsvpcConfiguration時に で指定されたのと同じサブネットにコンテナインスタンスが登録されていない場合です。

特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「タスク定義パラメータ」と「Amazon ECS コンテナエージェントの設定」を参照してください。

サービス [service-name(サービス-名)] がタスクを配置できませんでした。理由: 現在、容量は使用できません。後でもう一度試すか、別のアベイラビリティーゾーンで試してください。

現在、サービスを実行できる容量がありません。

次のいずれかを行うことができます。

• Fargate 容量または EC2 コンテナインスタンスが使用可能になるまでお待ちください。

• サービスを再起動し、追加のサブネットを指定します。

サービス (service-name ) のデプロイに失敗しました: タスクの開始に失敗しました。

サービスのタスクが開始されませんでした。

停止したタスクをデバッグする方法については、「」を参照してください停止したタスクのエラーコード。

サービス (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

サービス (service-name ) タスクセット (taskSet -ID ) が、 が原因でターゲットグループ (targetGroup -ARN)) で正常ではありませんTARGET GROUP IS NOT FOUND。

ターゲットグループが見つからないため、サービスのタスクセットがヘルスチェックに失敗しています。サービスを削除して再作成する必要があります。対応する Amazon ECS サービスがすでに削除されていない限り、Elastic Load Balancing ターゲットグループは削除しないでください。

サービス (service-name ) タスクセット (taskSet -ID ) が、 が原因でターゲットグループ (targetGroup -ARN)) で正常ではありませんTARGET IS NOT FOUND。

ターゲットが見つからないため、サービスのタスクセットがヘルスチェックに失敗しています。