Amazon Elastic Container Service
開発者ガイド (API バージョン 2014-11-13)

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

サービスの問題をトラブルシューティングする場合、最初に診断情報を確認する必要があるのは、サービスイベントログです。

Amazon ECS コンソールでサービスイベントメッセージを表示する際、重複したサービスイベントメッセージは、原因が解決するか、6 時間が経過するまで除外されます。問題が解決しない場合は、6 時間後に別のサービスイベントメッセージが送信されます。

Amazon ECS コンソールでサービスイベントログを検査するには

  1. https://console.aws.amazon.com/ecs/ にある Amazon ECS コンソールを開きます。

  2. [Clusters (クラスター)] ページで、サービスが存在するクラスターを選択します。

  3. [Cluster : clustername (クラスター: clustername)] ページで、検査するサービスを選択します。

  4. [Service : servicename (サービス : servicename)] ページで、[Events (イベント)] を選択します。

    
                    サービスイベントメッセージ
  5. [Message (メッセージ)] 列で、エラーやその他の役立つ情報を調べます。

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

以下は、コンソールに表示されることがあるサービスイベントメッセージの例です。

(service service-name) was unable to place a task because no container instance met all of its requirements.

上記のイメージで、このサービスは別のタスクの追加に使用できるリソースを見つけることができませんでした。以下に示しているのは、その考えられる原因です。

クラスターにコンテナインスタンスが見つかなかった

タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「Amazon ECS コンテナインスタンスの起動」を参照してください。

ポートが足りない

タスクで固定ホストポートマッピングを使用している場合 (タスクでウェブサーバーのホスト上のポート 80 を使用している場合など)、1 つのコンテナが一度に使用できるホストポートは 1 つのみであるため、タスクごとに 1 つ以上のコンテナインスタンスが必要です。コンテナインスタンスをクラスターに追加するか、タスクの必要数を減らす必要があります。

メモリが足りない

タスク定義で 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 エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とするパラメータが含まれており、この要件を満たすことができるコンテナインスタンスがない場合、そのタスクは配置できません。特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「タスク定義パラメータ」と「Amazon ECS コンテナエージェントの設定」を参照してください。

注記

1.17.0 以前の Amazon ECS コンテナエージェントバージョンの Windows コンテナインスタンスは、デフォルトでは awslogs ログドライバーはサポートされていません。Windows コンテナインスタンス搭載の awslogs ログドライバーを使用できない場合は、最新の Amazon ECS-optimized Windows AMI を使用していることを確認してください。

(service service-name) was unable to place a task because no container instance met all of its requirements.The closest matching container-instance container-instance-id has insufficient CPU units available.

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

(service service-name) was unable to place a task because no container instance met all of its requirements.The closest matching container-instance container-instance-id encountered error "AGENT".

タスク配置に最も近い一致するコンテナインスタンス上の Amazon ECS コンテナエージェントが切断されています。コンテナインスタンスに SSH で接続できる場合は、エージェントログを調べることができます。詳細については、「Amazon ECS コンテナエージェントログ」を参照してください。エージェントがインスタンスで実行されていることも確認する必要があります。Amazon ECS-optimized AMI を使用している場合は、以下のコマンドを使用して、エージェントを停止して再び開始できます。

  • Amazon ECS-optimized Amazon Linux 2 AMI の場合:

    sudo systemctl restart ecs
  • Amazon ECS-optimized Amazon Linux AMI の場合:

    sudo stop ecs && sudo start ecs

(service service-name) (instance instance-id) is unhealthy in (elb elb-name) due to (reason Instance has failed at least the UnhealthyThreshold number of health checks consecutively.)

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

(service service-name) is unable to consistently start tasks successfully.

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

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

このページの内容: