Amazon ECS タスクが停止した理由を知りたいです。

解決策

DescribeTasks API を使用すると、停止したタスクの詳細を確認できます。タスクをトラブルシューティングするには、停止理由と終了コードを確認してください。停止したタスクの詳細は、API の結果に 1 時間だけ表示されます。停止したタスクの詳細を確認する時間を延長するには、GitHub のウェブサイトにある amazon-ecs-stopped-tasks-cwlogs テンプレートを使用します。

タスクが停止した理由

タスク内の必須コンテナが終了した

必須コンテナが終了した場合は、次の終了コードのいずれかを参考に問題をトラブルシューティングします。

• 終了コード 0 は、エントリポイント、成功、CMD のいずれかが完了し、コンテナが停止したときに発生します。
• 終了コード 1 は、アプリケーションエラーが発生したときに発生します。この終了コードをトラブルシューティングするには、アプリケーションログを確認します。
• 終了コード 137 は、デフォルトの 30 秒以内に SIGTERM に応答せず、Amazon ECS がコンテナでタスクを強制終了 (SIGKILL) させた場合に発生します。デフォルトの 30 秒から変更するには、ECS コンテナエージェントで ECS_CONTAINER_STOP_TIMEOUT パラメータを使用して更新します。
  注: この終了コードは、メモリ不足 (OOM) エラーが原因で発生することもあります。リソースの使用状況については、Amazon ECS に関する Amazon CloudWatch メトリクスを確認します。
• 終了コード 139 は、アプリケーションが使用できない AWS リージョンのメモリにアクセスしようとしたときに発生します。この終了コードは、設定されていないプレースホルダーや無効な環境プレースホルダーが原因で、セグメンテーション違反が発生した場合にも発生します。この問題をトラブルシューティングするには、Lambda 関数の Amazon ECS CloudWatch ログを確認します。
• 終了コード 143 は、コンテナが正常なシャットダウンに関する警告を受信し、Amazon ECS がそのコンテナをシャットダウンしたときに発生します。
• 終了コード 255 は、エラーが原因でコンテナで ENTRYPOINT CMD コマンドを実行できなかった場合に発生します。エラーが原因でコンテナで障害が発生したかどうかを確認するには、CloudWatch ログをレビューします。

他のトラブルシューティング手順については、「コンテナの終了時に、Amazon ECS タスクが停止したり開始できなかったりする場合のトラブルシューティング方法を教えてください」を参照してください。

CannotPullContainerError

このエラーは、Amazon ECS が指定されたコンテナイメージを取得できなかったことが原因で、タスクを開始できなかった場合に発生します。

Amazon Elastic Compute Cloud (Amazon EC2) 起動タイプのタスクに関するこの問題を解決するには、「Amazon ECS で EC2 タスクを起動する際の CannotPullContainerError エラーを解決する方法を教えてください」を参照してください。

Fargate 起動タイプを使用する Amazon ECS タスクでこの問題を解決するには、「Fargate 上の Amazon ECS タスクで発生する cannotpullcontainererror を解決する方法を教えてください」を参照してください。

タスクが Elastic Load Balancer のヘルスチェックに合格できなかった

EC2 起動タイプを使用するタスクにおいて、この問題を解決する方法については、「Amazon EC2 起動タイプを使用する Amazon ECS タスクで、Application Load Balancer のヘルスチェックに合格する方法を教えてください」を参照してください。

Fargate 起動タイプを使用するタスクでこの問題を解決するには、「Fargate で Amazon ECS タスクがヘルスチェックに合格できない場合のトラブルシューティング方法を教えてください」を参照してください。

コンテナのヘルスチェックが不合格となった

ヘルスチェックは、HealthCheck API または Dockerfile で定義します。詳細については、Docker のウェブサイトで「HEALTHCHECK」を参照してください。

コンテナのヘルスチェックに関するエラーのトラブルシューティング方法については、「Amazon ECS タスクがコンテナヘルスチェックに合格できない場合のトラブルシューティング方法を教えてください」を参照してください。

(instance i-##) (port #) is unhealthy in (ヘルスチェック不合格の理由)

このエラーは、正常ではない状態の Amazon EC2 インスタンスが、指定されたポートでヘルスチェックに応答しない場合に発生します。

この問題をトラブルシューティングするには、次の手順を実行します。

• コンテナインスタンスにアタッチされているセキュリティグループが必要なトラフィックを許可していることを確認します。
• 次のコマンドを実行し、バックエンドが遅延なしで応答することを確認します。

  curl -iv localhost:container-port/path

  注: 実際のものでそれぞれ、container-port をコンテナポートに、path をヘルスチェックのパスに置き換えます。
• 応答タイムアウト値をデフォルトの 30 秒から増やします。ECS_CONTAINER_STOP_TIMEOUT パラメータを使用して ECS コンテナエージェントを更新します。

このエラーメッセージの詳細については、「Network Load Balancer のアクセスログ」を参照してください。

Service ABCService: ECS is performing maintenance on the underlying infrastructure hosting the task (ECS は、タスクをホストしている基盤インフラストラクチャのメンテナンスを実行しています)

このエラーは、アプリケーションコンテナを実行する AWS Fargate サーバーのメンテナンスを Amazon ECS が実行する際に発生します。その結果、Amazon ECS のサービスは一時的に利用できなくなります。

詳細については、「Amazon ECS 上の AWS Fargate のタスク廃止とメンテナンス」を参照してください。

スタンドアロンタスクについては、「Fargate で実行されているタスクに対する、Amazon ECS タスク廃止通知への対応方法を教えてください」を参照してください。

Amazon ECS サービスでスケーリングイベントが有効になっている

Amazon ECS サービスのスケーリングイベント中、スケーリングポリシーによりサービスで実行されるタスクの数が減少することが原因で、タスクは停止します。その後、Amazon ECS は新しく指定した数に達するまでタスクを停止します。このアクションは通常、需要が減少し、Amazon ECS がワークロードを処理するために必要なタスクが少なくなったときに発生します。

この問題を解決するには、次の手順を実行します。

• サービスまたはタスクの変更に対して CloudWatch アラームを作成します。
• スケジュールされたデプロイのうち、タスクに影響する可能性があるものをレビューします。

サービスの自動スケーリングやデプロイによるスケールインイベントの終了からタスクを保護するには、Amazon ECS タスクスケールイン保護を使用します。

詳細については、「Amazon ECS サービスにスケジュールされたスケーリングアクションを確認、管理する方法を教えてください」を参照してください。

Task stopped by user (タスクがユーザーにより停止されました)

タスクが StopTask API を受信しました。呼び出しを開始したユーザーを得意呈するには、CloudTrail の StopTask で userIdentity 情報を確認します。

ResourceInitializationError: errors

複数の ResourceInitialization というエラーメッセージと、その解決手順については、「Amazon ECS で発生する ResourceInitializatioError エラーのトラブルシューティング」を参照してください。

ResourceInitializationError: unable to pull secrets or registry auth というエラーのトラブルシューティング方法については、「ECS タスクで、シークレットまたは Amazon ECR 認証の取得を試みる際に発生する ResourceInitializationError の解決方法を教えてください」を参照してください。

ResourceInitializationError: failed to validate logger args というエラーのトラブルシューティング方法については、「Amazon ECS で発生する、ResourceInitializationError: failed to validate logger args というエラーの解決方法を教えてください」を参照してください。

SpotInterruptionError

SpotInterruptionError の詳細については、「Amazon ECS で発生する SpotInterruption エラーのトラブルシューティング」を参照してください。

このエラーをトラブルシューティングするには、「AWS Fargate Spot タスクのスポット終了通知への対応方法を教えてください」を参照してください。

OutOfMemoryError

このエラーは、コンテナ内のプロセスがタスク定義で割り当てたメモリよりも多くのメモリを使用したことが原因で、コンテナが終了したときに発生します。

このエラーをトラブルシューティングするには、「Amazon ECS で発生する OutOfMemory エラーのトラブルシューティング方法を教えてください」を参照してください。

エラーメッセージ

タスクの停止時にエラーメッセージが表示された場合は、そのエラーに応じて、次のトラブルシューティング手順を実行します。

No Container Instances were found in your cluster (クラスタでコンテナインスタンスが見つかりませんでした)

この問題を解決するには、コンテナインスタンスを起動します。

クラスターのコンテナインスタンスを確認するには、次の手順を実行します。

1. Amazon ECS コンソールを開きます。
2. ナビゲーションペインで [クラスター] を選択します。
3. クラスターを選択します。
4. [インフラストラクチャ] タブを選択します。
5. [コンテナインスタンス] セクションをレビューします。

コンテナインスタンスがない場合は、「Amazon EC2 インスタンスが Amazon ECS クラスターに参加できない理由を知りたいです」を参照してください。

InvalidParameterException

このエラーメッセージを解決するには、TaskDefinition にパラメータがあり、正しい ARN が設定されていることを確認してください。タスクのロールとタスク実行ロールに必要なアクセス許可があることを確認します。

You've reached the limit of the number of tasks that you can run concurrently (同時に実行できるタスク数の上限に達しました)

このエラーは、Amazon ECS のサービスクォータを超えた場合に発生します。この問題のトラブルシューティングを行うには、「Amazon ECS のサービスクォータに関する問題の解決方法を教えてください」を参照してください。

関連情報

Amazon ECS でのタスク停止エラーを解決する

Amazon ECS でのタスク停止エラーを確認する