サービスイベントメッセージ - Amazon Elastic Container Service

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

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

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

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

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

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

New 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 例では、default クラスター内の service-name サービスが記述されます。ここには、最新のサービスイベントメッセージが表示されます。

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

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

以下は、Amazon ECS コンソールで確認できる可能性があるサービスイベントメッセージの例です。

サービススケジューラは、サービスが正常で、必要な数のタスクが定常状態になったときに、service (service-name) has reached a steady state. サービスイベントを送信します。

サービススケジューラは定期的にステータスを報告するため、このメッセージを複数回受信する場合があります。

サービススケジューラは、別のタスクを追加するために利用可能なリソースが見つからないときに、このイベントメッセージを送信します。以下に示しているのは、その考えられる原因です。

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

タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「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 アカウント設定のオプトインの詳細については、「Elastic Network Interface のトランキング」を参照してください。

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

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

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

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

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

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

タスク配置に最も一致するコンテナインスタンス上の 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

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

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

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

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

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

このサービスは、デプロイメント構成であるため、サービスのデプロイメント中にタスクを停止または開始できません。デプロイメント設定は、サービスの作成時に定義される minimumHealthyPercent 値と maximumPercent 値で構成されますが、既存のサービスから更新することもできます。

minimumHealthyPercent は、デプロイメント中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の下限を、サービスに必要なタスク数の割合 (%) として表します。この値は切り上げられます。たとえば、最小正常率が 50 で、必要なタスク数が 4 の場合、スケジューラは 2 つの新しいタスクを開始する前に既存のタスクを 2 つ停止できます。同様に、最小正常率が 75% で、必要なタスク数が 2 の場合、結果の値も 2 であるため、スケジューラはタスクを停止できません。

maximumPercent は、デプロイメント中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の上限を、サービスに必要なタスク数の割合 (%) として表します。この値は切り捨てられます。例えば、最大パーセンテージが 200 で、目的のタスク数が 4 の場合、スケジューラは既存のタスクを 4 つ停止する前に 4 つの新しいタスクを開始できます。同様に、最大比率が 125 で、必要なタスク数が 3 の場合、結果の値も 3 であるため、スケジューラはタスクを開始できません。

最小正常率または最大正常率を設定するときは、デプロイメントがトリガーされたときにスケジューラが 1 つ以上のタスクを停止または開始できることを確認する必要があります。

エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「Amazon ECS の Service Quotas」を参照してください。クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「Requesting a quota increase」(クォータ引き上げリクエスト) を参照してください。

あるサブネットがサポートされていないアベイラビリティーゾーンにあるため、サービスはタスクを開始できません。

サポートされた Fargate リージョンおよびアベイラビリティーゾーンの情報については、AWS Fargate で使用する Amazon ECS でサポートされているリージョン を参照してください。

サブネットのアベイラビリティーゾーンを確認する方法については、「Amazon VPC ユーザーガイド」の「サブネットの確認」を参照してください。

エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「Amazon ECS の Service Quotas」を参照してください。クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「Requesting a quota increase」(クォータ引き上げリクエスト) を参照してください。

エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「Amazon ECS の Service Quotas」を参照してください。クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「Requesting a quota increase」(クォータ引き上げリクエスト) を参照してください。

AWS Fargate は、タスク数ベースのクォータから vCPU ベースのクォータに移行しています。

Fargate の vCPU ベースのクォータの引き上げをリクエストできます。詳細については、「Amazon ECS の Service Quotas」を参照してください。Fargate クォータの引き上げをリクエストするには、「Service Quotas ユーザーガイド」の「Requesting a quota increase」(クォータ引き上げリクエスト) を参照してください。

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

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

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

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