# Amazon ECS トラブルシューティング
ロードバランサー、タスク、サービス、またはコンテナインスタンスの問題のトラブルシューティングが必要な場合があります。この章は、Amazon ECS コンソールで Amazon ECS コンテナエージェント、コンテナインスタンス上の Docker デーモン、サービスイベントログから診断情報を見つけるのに役立ちます。
停止したタスクの詳細については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| 停止したタスクのエラーを解決します。 | [Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md) |
| 停止したタスクのエラーを表示します。 | [Amazon ECS の停止したタスクのエラーを解決する](resolve-stopped-errors.md) |
| 停止したタスクのエラーコードを確認します。 | [Amazon ECS の停止したタスクのエラーメッセージ](stopped-task-error-codes.md) |
| CannotPullContainer タスクのエラーを確認します。 | [Amazon ECS での CannotPullContainer タスクエラー](task_cannot_pull_image.md) |
| タスクの IAM ロールリクエストを表示します。 | [Amazon ECS タスクの IAM ロールリクエストの表示](task_iam_roles-logs.md) |
| タスクイベントを使用してトラブルシューティングを実行します。 | [コンソールの Amazon ECS イベントキャプチャ](task-lifecycle-events.md) |
サービスエラーの詳細については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| サービスイベントメッセージを表示します。 | [Amazon ECS のサービスイベントメッセージを表示する](service-event-messages.md) |
| サービスイベントメッセージを確認します。 | [Amazon ECS のサービスイベントメッセージ](service-event-messages-list.md) |
| ロードバランサーの問題を確認します。 | [Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md) |
| サービスの自動スケーリングの問題を確認します。 | [Amazon ECS のサービス自動スケーリングのトラブルシューティング](troubleshoot-service-auto-scaling.md) |
タスク定義のエラーの詳細については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| タスク定義のメモリエラーを解決します。 | [Amazon ECS タスク定義の無効な CPU またはメモリエラーをトラブルシューティングする](task-cpu-memory-error.md) |
Amazon ECS エージェントのエラーの詳細については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| Amazon ECS コンテナエージェントログを表示します。 | [Amazon ECS コンテナエージェントログの表示](logs.md) |
| Amazon ECS ログを収集する方法について説明します。 | [Amazon ECS ログコレクターを使用したコンテナログの収集](ecs-logs-collector.md) |
| Amazon ECS エージェントを使用して診断の詳細を取得します。 | [エージェントのイントロスペクションを使用して Amazon ECS 診断の詳細を取得する](introspection-diag.md) |
Docker エラーの一般的な情報については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| Docker 診断を使用します。 | [Amazon ECS の Docker 診断](docker-diags.md) |
| Docker デバッグモードを有効にします。 | [Amazon ECS の Docker デーモンからの詳細な出力の設定](docker-debug-mode.md) |
| Docker API エラー 500 のトラブルシューティングを実行します。 | [Amazon ECS の Docker `API error (500): devmapper` のトラブルシューティング](CannotCreateContainerError.md) |
ECS Exec および Amazon ECS Anywhere のエラーの詳細については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| ECS Exec のトラブルシューティングを実行します。 | [Amazon ECS Exec に関する問題のトラブルシューティング](ecs-exec-troubleshooting.md) |
| Amazon ECS Anywhere のトラブルシューティングを実行します。 | [Amazon ECS Anywhere に関する問題のトラブルシューティング](ecs-anywhere-troubleshooting.md) |
Amazon EBS ボリュームの Amazon ECS タスクへのアタッチに関する問題については、以下を参照してください。
| Action | 詳細情報 |
| --- | --- |
| Amazon ECS タスクへの Amazon EBS ボリュームのアタッチに関するトラブルシューティング。 | [Amazon ECS タスクへの Amazon EBS ボリュームのアタッチに関するトラブルシューティング](troubleshoot-ebs-volumes.md) |
| Amazon ECS タスクへの Amazon EBS ボリュームのアタッチに関するステータスの理由。 | [Amazon ECS タスクへの Amazon EBS ボリュームアタッチメントのステータス理由](troubleshoot-ebs-volumes-scenarios.md) |
Amazon ECS Service Connect で共有 AWS Cloud Map 名前空間を使用する際の問題については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| 共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect のトラブルシューティング。 | [共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect のトラブルシューティング](service-connect-shared-namespaces-troubleshooting.md) |
スロットリングの問題を解決するための情報については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| Fargate のスロットリングクォータについて説明します。 | [AWS Fargate スロットリングのクォータ](throttling.md) |
| Amazon ECS スロットリングのベストプラクティスについて説明します。 | [Amazon ECS のスロットリングに関する問題を処理する](operating-at-scale-dealing-with-throttles.md) |
API エラーの詳細については、次のいずれかを参照してください。
| Action | 詳細情報 |
| --- | --- |
| API エラーを解決します。 | [Amazon ECS での API エラーの原因](api_failures_messages.md) |
AI を活用したトラブルシューティングについては、以下を参照してください。
| Action | 詳細情報 |
| --- | --- |
| Amazon Q Developer に関するコンソールのトラブルシューティング。 | [Amazon Q Developer のトラブルシューティング](troubleshooting-with-Q.md) |
| Amazon ECS MCP サーバーを使用して、AI アシスタントを用いたトラブルシューティングを行います。 | [Amazon ECS MCP サーバー](ecs-mcp-introduction.md) |
# Amazon ECS の停止したタスクのエラーを解決する
タスクの開始に失敗すると、コンソールと `describe-tasks` 出力パラメータ (`stoppedReason` および `stopCode`) にエラーメッセージが表示されます。
停止したタスクは、コンソールで 1 時間表示できます。停止したタスクを表示するには、フィルターオプションを変更する必要があります。詳細については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
次のページには、エラーコードに関する情報が記載されています。
+ 停止したタスクのエラーメッセージの変更について説明します。
[Amazon ECS の停止したタスクのエラーメッセージの更新](stopped-tasks-error-messages-updates.md)
+ 停止したタスクを表示して、原因に関する情報を取得します。
[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)
+ 停止したタスクのエラーメッセージと、考えられるエラーの原因について説明します。
[Amazon ECS の停止したタスクのエラーメッセージ](stopped-task-error-codes.md)
+ 停止したタスク接続を検証し、エラーを修正する方法について説明します。
[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)
# Amazon ECS の停止したタスクのエラーメッセージの更新
2024 年 6 月 14 日より、Amazon ECS チームは、以下の表に示すように停止したタスクのエラーメッセージを変更します。`stopCode` の変更はありません。アプリケーションが正確なエラーメッセージ文字列に依存している場合は、新しい文字列でアプリケーションを更新する必要があります。ご質問や問題については、AWS サポート にお問い合わせください。
**注記**
このエラーメッセージは変更される可能性があるため、オートメーションではエラーメッセージに依存しないことをお勧めします。
## CannotPullContainerError
| 以前のエラーメッセージ | 新しいエラーメッセージ |
| --- | --- |
| CannotPullContainerError: Error response from daemon: pull access denied for repository, repository does not exist or may require 'docker login': denied: User: roleARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/stopped-tasks-error-messages-updates.html) |
| CannotPullContainerError: Error response from daemon: Get imageURI: net/http: request canceled while waiting for connection | CannotPullContainerError: The task can’t pull the image. ネットワーク設定を確認します。Error response from daemon: Get image: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) |
| CannotPullContainerError: ref pull has been retried 5 time(s): failed to copy: httpReadSeeker: failed open: failed to do request: Get registry-uri: dial tcp : i/o timeout | CannotPullContainerError: The task cannot pull image-uri from the registry registry-uri. There is a connection issue between the task and the registry. Check your task network configuration. : failed to copy: httpReadSeeker: failed open: failed to do request: Get registry-uri: dial tcp : i/o timeout |
## ResourceNotFoundException
| 以前のエラーメッセージ | 新しいエラーメッセージ |
| --- | --- |
| Fetching secret data from AWS Secrets Manager in region region: secret sercretARN: ResourceNotFoundException: Secrets Manager can't find the specified secret. | ResourceNotFoundException: The task can't retrieve the secret with ARN 'sercretARN' from AWS Secrets Manager. Check whether the secret exists in the specified Region. ResourceNotFoundException: Fetching secret data from AWS Secrets Manager in region region: secret sercretARN: ResourceNotFoundException: Secrets Manager can't find the specified secret. |
## ResourceInitializationError
| 以前のエラーメッセージ | 新しいエラーメッセージ |
| --- | --- |
| ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post "https://api.ecr.us-east-1.amazonaws.com/": dial tcp :: i/o timeout. Please check your task network configuration. | ResourceInitializationError: unable to pull secrets or registry auth: The task cannot pull registry auth from Amazon ECR: There is a connection issue between the task and Amazon ECR. Check your task network configuration. RequestError: send request failed caused by: Post "https://api.ecr.us-east-1.amazonaws.com": dial tcp :: i/o timeout |
| ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secrets from ssm: service call has been retried 5 time(s): RequestCanceled: request context canceled caused by: context deadline exceeded | ResourceInitializationError: unable to pull secrets or registry auth: unable to retrieve secrets from ssm: The task cannot pull secrets from AWS Systems Manager. There is a connection issue between the task and AWS Systems Manager Parameter Store. Check your task network configuration. RequestCanceled: request context canceled caused by: context deadline exceeded |
| ResourceInitializationError: failed to download env files: file download command: non empty error stream: RequestCanceled: request context canceled caused by: context deadline exceeded | ResourceInitializationError: failed to download env files: The task can't download the environment variable files from Amazon S3. There is a connection issue between the task and Amazon S3. Check your task network configuration. service call has been retried 5 time(s): RequestCanceled: request context canceled caused by: context deadline exceeded |
| ResourceInitializationError: failed to validate logger args::signal:killed | ResourceInitializationError: failed to validate logger args: The task cannot find the Amazon CloudWatch log group defined in the task definition. There is a connection issue between the task and Amazon CloudWatch. Check your network configuration. : signal: killed |
| ResourceInitializationError: unable to pull secrets or registry auth: pull command failed: : signal: killed | ResourceInitializationError: unable to pull secrets or registry auth: Check your task network configuration. : signal: killed |
# Amazon ECS の停止したタスクのエラーを表示する
タスクの開始に問題がある場合、アプリケーションエラーまたは設定エラーのためにタスクが停止している可能性があります。例えば、タスクを実行するとタスクが `PENDING` ステータスを表示して消えるとします。
タスクが Amazon ECS サービスによって作成された場合、Amazon ECS がサービスを維持するために行うアクションはサービスイベントで公開されます。イベントは、AWS マネジメントコンソール、AWS CLI、AWS SDK、Amazon ECS API または SDK と API を使用するツールで表示できます。これらのイベントには、タスク内のコンテナの実行が停止したり、Elastic Load Balancing によるヘルスチェックに何度も失敗したりしたことが原因で、Amazon ECS が停止してタスクが置き換えられることが含まれます。
また、タスクが Amazon EC2 にあるコンテナインスタンスまたは外部コンピュータで実行された場合、コンテナランタイムと Amazon ECS エージェントのログを確認することもできます。これらのログは、ホスト Amazon EC2 インスタンスまたは外部コンピュータにあります。詳細については、「[Amazon ECS コンテナエージェントログの表示](logs.md)」を参照してください。
## 手順
------
#### [ Console ]
**AWS マネジメントコンソール**
次の手順に従って、コンソールを使用して停止されたタスクにエラーがないかどうかを確認することができます。停止したタスクを表示するには、フィルターオプションを変更する必要があります。
停止したタスクは 1 時間だけコンソールに表示されます。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、クラスターを選択します。
1. **[Cluster: *name*]** (クラスター: 名前) ページで、**[Tasks]** (タスク) タブを選択します。
1. 停止済みのタスクを表示するようにフィルターを設定します。**希望ステータスのフィルター** では、**停止** を選択します。
[**停止済み**] オプションには停止されたタスクが表示され、[**任意の必要なステータス**] にはすべてのタスクが表示されます。
1. 停止したタスクを選択して検査します。
1. 停止済みのタスクの行の [**前回のステータス**] 列で、[**停止済み**] を選択します。
ポップアップウィンドウに停止した理由が表示されます。
------
#### [ AWS CLI ]
1. クラスターで停止したタスクを一覧表示します。出力には、タスクの Amazon リソースネーム (ARN) が含まれますが、この名前は、タスクを説明するものである必要があります。
```
aws ecs list-tasks \
--cluster cluster_name \
--desired-status STOPPED \
--region region
```
1. 停止したタスクを記述して情報を取得します。詳細については、「*AWS Command Line Interfaceリファレンス*」の「[describe-tasks](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-tasks.html)」を参照してください。
```
aws ecs describe-tasks \
--cluster cluster_name \
--tasks arn:aws:ecs:region:account_id:task/cluster_name/task_ID \
--region region
```
次の出力パラメータを使用します。
+ `stopCode` - ResourceInitializationError などの停止コードは、タスクが停止された理由を示します。
+ `StoppedReason` - タスクが停止した理由を示します。
+ `reason` (`containers` 構造の場合) - 理由には、停止したコンテナに関するその他の詳細が含まれます。
------
## 次のステップ
停止したタスクを表示して、原因に関する情報を取得します。詳細については、「[Amazon ECS の停止したタスクのエラーメッセージ](stopped-task-error-codes.md)」を参照してください。
# Amazon ECS の停止したタスクのエラーメッセージ
タスクが予期せず停止した場合に表示される可能性のあるエラーメッセージは、以下のとおりです。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
**ヒント**
[Amazon ECS MCP サーバー](ecs-mcp-introduction.md) と AI アシスタントを使用することで、タスクの失敗とコンテナログの分析を自然言語で実行できます。
停止したタスクのエラーコードには、「ResourceInitializationError」などのカテゴリが関連付けられています。各カテゴリの詳細については、以下を参照してください。
| Category | 詳細情報 |
| --- | --- |
| TaskFailedToStart | [Amazon ECS TaskFailedToStart エラーのトラブルシューティング](failed-to-start-error.md) |
| ResourceInitializationError | [Amazon ECS での ResourceInitializationError エラーのトラブルシューティング](resource-initialization-error.md) |
| ResourceNotFoundException | [Amazon ECS ResourceNotFoundException エラーのトラブルシューティング](resource-not-found-error.md) |
| SpotInterruptionError | [Amazon ECS での SpotInterruption エラーのトラブルシューティング](spot-interruption-errors.md) |
| InternalError | [Amazon ECS での InternalError エラーのトラブルシューティング](internal-error.md) |
| OutOfMemoryError | [Amazon ECS での OutOfMemoryError エラーのトラブルシューティング](out-of-memory.md) |
| ContainerRuntimeError | [Amazon ECS での ContainerRuntimeError エラーのトラブルシューティング](container-runtime-error.md) |
| ContainerRuntimeTimeoutError | [Amazon ECS での ContainerRuntimeTimeoutError エラーのトラブルシューティング](container-runtime-timeout-error.md) |
| CannotStartContainerError | [Amazon ECS での CannotStartContainerError エラーのトラブルシューティング](cannot-start-container.md) |
| CannotStopContainerError | [Amazon ECS での CannotStopContainerError エラーのトラブルシューティング](cannot-stop-container.md) |
| CannotInspectContainerError | [Amazon ECS での CannotInspectContainerError エラーのトラブルシューティング](cannot-inspect-container.md) |
| CannotCreateVolumeError | [Amazon ECS での CannotCreateVolumeError エラーのトラブルシューティング](cannot-create-volume.md) |
| CannotPullContainer | [Amazon ECS での CannotPullContainer タスクエラー](task_cannot_pull_image.md) |
# Amazon ECS TaskFailedToStart エラーのトラブルシューティング
以下に、`TaskFailedToStart` エラーメッセージおよび、そのエラーを修正するために取れる措置を示します。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## Unexpected EC2 error while attempting to Create Network Interface with public IP assignment enabled in subnet '*subnet-id*
これは、`awsvpc` ネットワークモードを使用し、パブリック IP アドレスを持つサブネットで実行される Fargate タスクにおいて、サブネットに十分な IP アドレスがない場合に発生します。
利用可能な IP アドレスの数は、Amazon EC2 コンソールのサブネットの詳細ページ、または `[describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html)` を使用して確認できます。詳細については、「*Amazon VPC ユーザーガイド*」の「[サブネットを表示する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#view-subnet)」を参照してください。
この問題を修正するには、タスクを実行するための新しいサブネットを作成します。
## InternalError: **
このエラーは、ENI アタッチメントが要求されたときに発生します。Amazon EC2 は ENI のプロビジョニングを非同期で処理します。プロビジョニングプロセスには時間がかかります。Amazon ECS では、待ち時間が長かったり、エラーが報告されない場合に備えてタイムアウトを設けています。ENI がプロビジョニングされても、レポートは障害タイムアウト後に Amazon ECS に送られる場合があります。この場合、Amazon ECS は使用中の ENI で報告されたタスク障害を確認します。
## The selected task definition is not compatible with the selected compute strategy
このエラーは、起動タイプがクラスターのキャパシティタイプと一致しないタスク定義を選択した場合に発生します。クラスターに割り当てられたキャパシティープロバイダーと一致するタスク定義を選択する必要があります。
## Unable to attach network interface to unused device index
このエラーは、`awsvpc` ネットワーキングタイプを使用しているときに、タスク用に十分な CPU/メモリがない場合に発生します。まず、インスタンスの CPU を確認します。詳細については、「*Amazon EC2 インスタンスタイプ*」の「[Amazon EC2 インスタンスタイプの仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html)」を参照してください。インスタンスの CPU 値をインスタンスの ENI の数で乗算します。その値をタスク定義で使用します。
## AGENT
タスクを起動しようとしたコンテナインスタンスに、現在接続されていないエージェントがあります。タスク配置の待ち時間が長くならないように、リクエストは拒否されました。
切断されたエージェントをトラブルシューティングする方法については、「[切断された Amazon ECS エージェントをトラブルシューティングするにはどうすればよいですか?](https://repost.aws/knowledge-center/ecs-agent-disconnected-linux2-ami)」を参照してください。
# Amazon ECS での ResourceInitializationError エラーのトラブルシューティング
以下に、`ResourceInitialization` エラーメッセージおよび、そのエラーを修正するために取れる措置を示します。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
**Topics**
+ [The task cannot pull registry authentication from Amazon ECR. There is a connection issue between the task and Amazon ECR. Check your task network configuration.](#unable-to-pull-secrets-ecr)
+ [The task can't download the environment variable files from Amazon S3. There is a connection issue between the task and Amazon S3. Check your task network configuration.](#failed-to-download-env-files)
+ [The task cannot pull secrets from AWS Systems Manager Parameter Store. Check your network connection between the task and AWS Systems Manager.](#unable-to-pull-secrets-sys-manager)
+ [The task can’t pull secrets from AWS Secrets Manager. There is a connection issue between the task and Secrets Manager. Check your task network configuration.](#unable-to-pull-secrets-asm-no-arn)
+ [The task can’t pull the secret from Secrets Manager. The task can't retrieve the secret with ARN ‘*secretARN*' from Secrets Manager. Check whether the secret exists in the specified Region.](#unable-to-pull-secrets-asm)
+ [pull command failed: unable to pull secrets or registry auth Check your task network configuration.](#pull-command-failed)
+ [The task cannot find the Amazon CloudWatch log group defined in the task definition. There is a connection issue between the task and Amazon CloudWatch. ネットワーク設定を確認します。](#failed-to-initialize-logging-network)
+ [failed to initialize logging driver](#failed-to-initialize-logging)
+ [failed to invoke EFS utils commands to set up EFS volumes](#efs-utils-failed)
## The task cannot pull registry authentication from Amazon ECR. There is a connection issue between the task and Amazon ECR. Check your task network configuration.
このエラーは、タスクが Amazon ECR に接続できないことを示します。
タスクと Amazon ECR との間の接続を確認してください。詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## The task can't download the environment variable files from Amazon S3. There is a connection issue between the task and Amazon S3. Check your task network configuration.
このエラーは、タスクが Amazon S3 から環境設定ファイルをダウンロードできない場合に発生します。
タスクと Amazon S3 VPC エンドポイントとの間の接続を確認してください。詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## The task cannot pull secrets from AWS Systems Manager Parameter Store. Check your network connection between the task and AWS Systems Manager.
このエラーは、タスクが Systems Manager の認証情報を使用して、タスク定義で定義されたイメージをプルできない場合に発生します。
タスクと Systems Manager VPC エンドポイントとの間の接続を確認してください。詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## The task can’t pull secrets from AWS Secrets Manager. There is a connection issue between the task and Secrets Manager. Check your task network configuration.
このエラーは、タスクが Secrets Manager の認証情報を使用して、タスク定義で定義されたイメージをプルできない場合に発生します。
エラーは、Systems Manager VPC エンドポイントとタスク間のネットワーク接続に問題があることを示します。
タスクとエンドポイント間の接続を確認する方法については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## The task can’t pull the secret from Secrets Manager. The task can't retrieve the secret with ARN ‘*secretARN*' from Secrets Manager. Check whether the secret exists in the specified Region.
このエラーは、タスクが Secrets Manager の認証情報を使用して、タスク定義で定義されたイメージをプルできない場合に発生します。
この問題は、次のいずれかの理由によって発生します。
| エラーの原因 | 手順 |
| --- | --- |
| Secrets Manager VPC エンドポイントとタスク間のネットワーク接続の問題 エラーメッセージに次のいずれかの文字列が表示されている場合、問題の原因はネットワークです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/resource-initialization-error.html) | タスクと Secrets Manager エンドポイント間の接続を確認します。詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。 |
| タスク定義で定義されたタスク実行ロールに、Secrets Manager のアクセス許可がありません。 | タスク実行ロールに、Secrets Manager に必要なアクセス許可を追加します。詳細については、「[Secrets Manager または Systems Manager のアクセス許可](task_execution_IAM_role.md#task-execution-secrets)」を参照してください。 |
| シークレット ARN が存在しません | Secrets Manager に ARN が 存在することを確認します。イメージの表示については、「Secrets Manager デベロッパーガイド」の「[Secrets Manager でシークレットを検索する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_search-secret.html)」を参照してください。 |
## pull command failed: unable to pull secrets or registry auth Check your task network configuration.
このエラーは、タスクが Amazon ECR、Systems Manager、または Secrets Manager に接続できない場合に発生します。これはネットワークの設定ミスが原因です。
この問題を解決するには、タスクと Amazon ECR との間の接続を確認します。また、タスクとシークレットを保存するサービス (Systems Manager または Secrets Manager) との間の接続も確認する必要があります。詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## The task cannot find the Amazon CloudWatch log group defined in the task definition. There is a connection issue between the task and Amazon CloudWatch. ネットワーク設定を確認します。
このエラーは、タスクがタスク定義で定義した CloudWatch ロググループを見つけられない場合に発生します。
このエラーは、CloudWatch VPC エンドポイントとタスクとの間のネットワーク接続に問題があることを示します。
タスクとエンドポイント間の接続を確認する方法については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## failed to initialize logging driver
このエラーは、タスクがタスク定義で定義した CloudWatch ロググループを見つけられない場合に発生します。
このエラーは、タスク定義内に CloudWatch グループが存在しないことを示します。
対象の CloudWatch を検索するには、次の手順を実行します。
1. 次のコマンドを実行して、タスク定義情報を取得します。
```
aws ecs describe-task-definition \
--task-definition task-def-name
```
各コンテナの出力を見て、`awslogs-group` 値を書き留めます。
```
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/example-group",
"awslogs-create-group": "true",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
},
```
1. このグループが CloudWatch に存在することを確認します。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「[ロググループとログストリームの操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」を参照してください。**
この問題は、タスク定義で指定されたグループが正しくないことか、ロググループが存在しないことのいずれかです。
1. 問題を修正します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/resource-initialization-error.html)
## failed to invoke EFS utils commands to set up EFS volumes
以下の問題により、タスクに Amazon EFS ボリュームをマウントできない可能性があります。
+ Amazon EFS ファイルシステムが正しく設定されていません。
+ タスクに必要なアクセス許可がありません。
+ ネットワークおよび VPC 構成に関連する問題があります。
この問題をデバッグして修正する方法については、AWS re:Post の 「[AWS Fargate タスクに Amazon EFS ボリュームをマウントできない理由](https://repost.aws/knowledge-center/fargate-unable-to-mount-efs)」を参照してください。
# Amazon ECS ResourceNotFoundException エラーのトラブルシューティング
以下に、` ResourceNotFoundException` エラーメッセージおよび、そのエラーを修正するために取れる措置を示します。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## The task can't retrieve the secret with ARN '*sercretARN*' from AWS Secrets Manager. Check whether the secret exists in the specified Region.
このエラーは、タスクが Secrets Manager からシークレットを取得できない場合に発生します。つまり、タスク定義で指定されたシークレット (およびエラーメッセージに含まれるシークレット) は Secrets Manager に存在しないということです。
リージョンはエラーメッセージに含まれています。
Fetching secret data from AWS Secrets Manager in region *region*: secret *sercretARN*: ResourceNotFoundException: Secrets Manager can't find the specified secret.
シークレットの検索方法については、「*AWS Secrets Manager ユーザーガイド*」の「[AWS Secrets Manager でシークレットを検索する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_search-secret.html)」を参照してください。
次の表を使用して、エラーを特定して対処します。
| 問題 | アクション |
| --- | --- |
| シークレットは、タスク定義とは異なるリージョンにあります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/resource-not-found-error.html) |
| タスク定義に誤ったシークレット ARN が存在します。正しいシークレットは Secrets Manager に存在します。 | 正しいシークレットでタスク定義を更新します。詳細については、「Amazon Elastic Container Service API リファレンス」の「[コンソールを使用した Amazon ECS タスク定義の更新](update-task-definition-console-v2.md)」または「[RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)」参照してください。 |
| シークレットが存在しません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/resource-not-found-error.html) |
# Amazon ECS での SpotInterruption エラーのトラブルシューティング
`SpotInterruption` エラーの原因は、Fargate と EC2 によって異なります。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## Fargate
`SpotInterruption` エラーは、Fargate Spot に容量がない場合や、Fargate がスポット容量を元に戻した場合に発生します。
タスクを複数のアベイラビリティーゾーンで実行することで、容量を増やすことができます。
## EC2
このエラーは、使用可能なスポットインスタンスがない場合や、EC2 がスポットインスタンスの容量を元に戻した場合に発生します。
インスタンスを複数のアベイラビリティーゾーンで実行することで、容量を増やすことができます。
# Amazon ECS での InternalError エラーのトラブルシューティング
**適用先**: Fargate
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
`InternalError` エラーは、ランタイムに関連しない予期せぬ内部エラーがエージェントに発生した場合に発生します。
このエラーは、プラットフォームバージョン `1.4` 以降を使用の場合にのみ発生します。
この問題のデバッグおよび修正方法については、[Amazon ECS の停止したタスクのエラーメッセージ](stopped-task-error-codes.md) を参照してください。
# Amazon ECS での OutOfMemoryError エラーのトラブルシューティング
以下は、OutOfMemoryError のエラーメッセージと、エラーを修正するために実行できるアクションの一部です。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## container killed due to memory usage
このエラーは、コンテナ内のプロセスでタスク定義で割り当てられたメモリよりも多くのメモリを消費しているか、またはホストやオペレーティングシステムに制約があることが原因でコンテナが終了したときに発生します。
# Amazon ECS での ContainerRuntimeError エラーのトラブルシューティング
以下は、ContainerRuntimeError のエラーメッセージと、エラーを修正するために実行できるアクションの一部です。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## ContainerRuntimeError
このエラーは、エージェントが `containerd` がランタイム固有のオペレーションに関する予期しないエラーを受け取った場合に発生します。このエラーは通常、エージェントや `containerd` ランタイムの内部障害によって発生します。
このエラーは、プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` 以降 (Windows) を使用している場合のみに発生します。
この問題をデバッグして修正する方法については、AWS re:Post の「[Amazon ECS タスクが停止する理由](https://repost.aws/knowledge-center/ecs-task-stopped)」を参照してください。
# Amazon ECS での ContainerRuntimeTimeoutError エラーのトラブルシューティング
以下は、ContainerRuntimeTimeoutError のエラーメッセージと、エラーを修正するために実行できるアクションの一部です。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## Could not transition to running; timed out after waiting 1m or Docker timeout error
このエラーは、タイムアウト期間内にコンテナが `RUNNING`または`STOPPED`のどちらかの状態に移行できなかった場合に発生します。理由とタイムアウト値は、エラーメッセージに表示されます。
# Amazon ECS での CannotStartContainerError エラーのトラブルシューティング
以下は、CannotStartContainerError のエラーメッセージと、エラーを修正するために実行できるアクションの一部です。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## failed to get container status: **
このエラーは、コンテナをスタートできない場合に発生します。
コンテナは、ここで指定したメモリを超えようとすると、停止されます。コンテナに提供するメモリを増やしてください。これは、タスク定義の `memory` パラメータです。詳細については、「[メモリ](task_definition_parameters.md#container_definition_memory)」を参照してください。
# Amazon ECS での CannotStopContainerError エラーのトラブルシューティング
以下は、CannotStopContainerError のエラーメッセージと、エラーを修正するために実行できるアクションの一部です。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## CannotStopContainerError
このエラーは、コンテナを停止できない場合に発生します。
この問題をデバッグして修正する方法については、AWS re:Post の「[Amazon ECS タスクが停止する理由](https://repost.aws/knowledge-center/ecs-task-stopped)」を参照してください。
# Amazon ECS での CannotInspectContainerError エラーのトラブルシューティング
以下は、CannotInspectContainerError のエラーメッセージと、エラーを修正するために実行できるアクションの一部です。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## CannotInspectContainerError
このエラーは、コンテナエージェントがコンテナランタイムを通してコンテナを説明できない場合に発生します。
プラットフォームバージョン `1.3` 以前を使用している場合、Amazon ECS エージェントは Docker から理由を返します。
プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` 以降 (Windows) を使用している場合、Fargate エージェントは `containerd` から理由を返します。
この問題をデバッグして修正する方法については、AWS re:Post の「[Amazon ECS タスクが停止する理由](https://repost.aws/knowledge-center/ecs-task-stopped)」を参照してください。
# Amazon ECS での CannotCreateVolumeError エラーのトラブルシューティング
以下は、CannotCreateVolumeError のエラーメッセージと、エラーを修正するために実行できるアクションの一部です。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
## CannotCreateVolumeError
このエラーは、エージェントがタスク定義に指定されているボリュームマウントを作成できない場合に発生します。
このエラーは、プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` 以降 (Windows) を使用している場合のみに発生します。
この問題をデバッグして修正する方法については、AWS re:Post の「[Amazon ECS タスクが停止する理由](https://repost.aws/knowledge-center/ecs-task-stopped)」を参照してください。
# Amazon ECS での CannotPullContainer タスクエラー
次のエラーは、Amazon ECS が指定されたコンテナイメージを取得できないためにタスクを開始できなかったことを示しています。
**注記**
1.4 Fargate プラットフォームバージョンでは、長いエラーメッセージが切り捨てられます。
停止したタスクのエラーメッセージを AWS マネジメントコンソール で確認する方法については、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。
**ヒント**
[Amazon ECS MCP サーバー](ecs-mcp-introduction.md) と AI アシスタントを使用することで、イメージプルエラーの調査を自然言語で実行できます。
**Topics**
+ [The task can’t pull the image. ロールにレジストリからイメージをプルするためのアクセス許可があることを確認します。](#pull-request-image-not-found)
+ [The task cannot pull ‘*image-name*’ from the Amazon ECR repository ‘*repository URI*’. There is a connection issue between the task and Amazon ECR. Check your task network configuration.](#pull-image-io-timeout)
+ [The task can’t pull the image. Check your network configuration](#pull-request-image-not-found-network)
+ [CannotPullContainerError: プルイメージマニフェストが 5 回再試行されました: ref の解決に失敗しました](#pull-request-image-tag)
+ [API error (500): Get https://111122223333.dkr.ecr.us-east-1.amazonaws.com/v2/: net/http: request canceled while waiting for connection](#request-canceled)
+ [API エラー](#pull-request-api-error)
+ [write /var/lib/docker/tmp/*GetImageBlob111111111*: no space left on device](#pull-request-write-error)
+ [ERROR: toomanyrequests: Too Many Requests or You have reached your pull rate limit.](#container-pull-too-many-requests)
+ [Error response from daemon: Get *url*: net/http: request canceled while waiting for connection](#container-pull-request-canceled-connection)
+ [ref pull has been retried 1 time(s): failed to copy: httpReaderSeeker: failed open: unexpected status code](#container-pull-failed-open)
+ [pull access denied](#container-pull-access-denied.title)
+ [pull command failed: panic: runtime error: invalid memory address or nil pointer dereference](#container-pull-runtime-error.title)
+ [error pulling image conf/error pulling image configuration](#container-pull-pulling-image.title)
+ [コンテキストがキャンセルされました](#container-pull-context-canceled)
## The task can’t pull the image. ロールにレジストリからイメージをプルするためのアクセス許可があることを確認します。
このエラーは、アクセス許可の問題により、タスク定義で指定されたイメージをタスクがプルできないことを示します。
この問題を解決するには。
1. イメージが*リポジトリ*に存在することを確認してください。イメージの表示の詳細については、「*Amazon Elastic Container Registry ユーザーガイド*」の「[Amazon ECR でのイメージの詳細の表示](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-info.html)」を参照してください。
1. *role-arn* にイメージをプルするための正しいアクセス許可があることを確認します。
ロールを更新する方法については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。
タスクには次のいずれかのロールを使用します。
+ Fargate のタスクの場合、これはタスク実行ロールになります。Amazon ECR の追加のアクセス許可については、「[インターフェイスエンドポイントのアクセス許可によって Amazon ECR イメージをプルする Fargate タスクです。](task_execution_IAM_role.md#task-execution-ecr-conditionkeys)」を参照してください。
+ EC2 のタスクの場合、これはコンテナインスタンスロールになります。Amazon ECR の追加のアクセス許可については、「[Amazon ECR のアクセス許可](instance_IAM_role.md#container-instance-role-ecr)」を参照してください。
## The task cannot pull ‘*image-name*’ from the Amazon ECR repository ‘*repository URI*’. There is a connection issue between the task and Amazon ECR. Check your task network configuration.
このエラーは、タスクが Amazon ECR に接続できないことを示します。*リポジトリ URI* リポジトリへの接続を確認してください。
これらの問題を検証および解決する方法の詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## The task can’t pull the image. Check your network configuration
このエラーは、タスクが Amazon ECR に接続できないことを示します。
これらの問題を検証および解決する方法の詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## CannotPullContainerError: プルイメージマニフェストが 5 回再試行されました: ref の解決に失敗しました
このエラーは、タスクがイメージをプルできないことを示します。
この問題を解決する方法は以下のとおりです。
+ タスク定義で指定されたイメージがリポジトリ内のイメージと一致することを確認してください。
+ Amazon ECS はイメージバージョンの安定性を強制します。元のイメージが使用できなくなった場合、このエラーが発生します。イメージタグは、この挙動の執行プロセスの一部です。タグとして :latest を使用するタスク定義のイメージを、特定のバージョンに変更してください。詳細については、「[コンテナイメージの解決](deployment-type-ecs.md#deployment-container-image-stability)」を参照してください。
これらの問題を検証および解決する方法の詳細については、「[Amazon ECS の停止したタスクの接続を検証する](verify-connectivity.md)」を参照してください。
## API error (500): Get https://111122223333.dkr.ecr.us-east-1.amazonaws.com/v2/: net/http: request canceled while waiting for connection
このエラーは、インターネットへのルートがないため、接続がタイムアウトしたことを示します。
この問題を解決するには、以下ができます。
+ パブリックサブネットのタスクでは、タスクの起動時に **[Auto-assign public IP]** (自動割り当てパブリック IP)を **[ENABLED]** (有効)に指定する必要があります。詳細については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。
+ プライベートサブネットのタスクでは、タスク起動時に **[Auto-assign public IP]** (自動割り当てパブリック IP) を **[DISABLED]** (無効) に指定し、VPC の NAT ゲートウェイを設定してリクエストをインターネットにルートします。詳細については、*Amazon VPC ユーザーガイド* の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) を参照してください。
## API エラー
このエラーは、Amazon ECR エンドポイントとの接続に問題があることを示します。
この問題を解決する方法については、サポート ウェブサイトの「[Amazon ECS の Amazon ECR エラー "CannotPullContainerError: API error" を解決するには](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-api-error-ecr/)」を参照してください。
## write /var/lib/docker/tmp/*GetImageBlob111111111*: no space left on device
このエラーは、ディスク容量が不足していることを示しています。
この問題を解決するには、ディスク容量を解放します。
Amazon ECS 最適化 AMI を使用している場合は、次のコマンドを使用してファイルシステムで 20 個の最大ファイルを取得できます。
```
du -Sh / | sort -rh | head -20
```
出力例:
```
5.7G /var/lib/docker/containers/50501b5f4cbf90b406e0ca60bf4e6d4ec8f773a6c1d2b451ed8e0195418ad0d2
1.2G /var/log/ecs
594M /var/lib/docker/devicemapper/mnt/c8e3010e36ce4c089bf286a623699f5233097ca126ebd5a700af023a5127633d/rootfs/data/logs
...
```
場合によっては、実行中のコンテナによってルートボリュームがいっぱいになる可能性があります。コンテナが `max-size` 制限のないデフォルトの `json-file` ログドライバーを使用している場合、ログファイルが使用されているスペースの大半を占めている可能性があります。`docker ps` コマンドを使用して、上記の出力からコンテナ ID にディレクトリ名をマッピングすることによって、どのコンテナが容量を使用しているかを確認します。例えば、次のようになります。
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
50501b5f4cbf amazon/amazon-ecs-agent:latest "/agent" 4 days ago Up 4 days ecs-agent
```
デフォルトでは、`json-file` ログドライバーを使用する場合、Docker はすべてのコンテナの標準出力 (および標準エラー) をキャプチャし、JSON 形式を使用してファイルに書き込みます。ログドライバーオプションとして `max-size` を設定できます。これにより、ログファイルの容量が大きくなりすぎるのを防ぐことができます。詳細については、Docker ドキュメントの「[JSON ファイルロギングドライバー](https://docs.docker.com/engine/logging/drivers/json-file/)」を参照してください。
このオプションの使用方法を示すコンテナ定義のスニペットを次に示します。
```
{
"log-driver": "json-file",
"log-opts": {
"max-size": "256m"
}
}
```
コンテナログのディスク容量使用量が大きすぎる場合、`awslogs` ログドライバーを使用することもできます。`awslogs` ログドライバーがログを CloudWatch に送信します。これによりコンテナインスタンスのコンテナログに使用されるディスク容量が解放されます。詳細については、「[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)」を参照してください。
Docker がアクセスできるディスクサイズに更新する必要がある場合があります。
詳細については、「[CannotPullContainerError: no space left on device](https://repost.aws/questions/QUx6Ix1R1SSNisYSs1Sw8EBA/cannotpullcontainererror-no-space-left-on-device)」を参照してください。
## ERROR: toomanyrequests: Too Many Requests or You have reached your pull rate limit.
このエラーは、Docker Hub のレート制限があることを示します。
次のエラーのいずれかが表示された場合は、Docker Hub のレート制限に達している可能性があります。
Docker Hub のレート制限の詳細については、[[Understanding Docker Hub rate limiting]](https://www.docker.com/increase-rate-limits) (Docker ハブのレート制限を理解する) を参照してください。
Docker Hub のレート制限を上げ、コンテナインスタンスの Docker プルを認証する必要がある場合は、「[Private registry authentication for container instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth-container-instances.html)」を参照してください。
## Error response from daemon: Get *url*: net/http: request canceled while waiting for connection
このエラーは、インターネットへのルートがないため、接続がタイムアウトしたことを示します。
この問題を解決するには、以下ができます。
+ パブリックサブネットのタスクでは、タスクの起動時に **[Auto-assign public IP]** (自動割り当てパブリック IP)を **[ENABLED]** (有効)に指定する必要があります。詳細については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。
+ プライベートサブネットのタスクでは、タスク起動時に **[Auto-assign public IP]** (自動割り当てパブリック IP) を **[DISABLED]** (無効) に指定し、VPC の NAT ゲートウェイを設定してリクエストをインターネットにルートします。詳細については、*Amazon VPC ユーザーガイド* の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) を参照してください。
## ref pull has been retried 1 time(s): failed to copy: httpReaderSeeker: failed open: unexpected status code
このエラーは、イメージのコピー時に問題があったことを示します。
この問題を解決するには、次のいずれかの記事を確認してください。
+ Fargate タスクについては、[Fargate Amazon ECSタスクの「cannotpullcontainererror」エラーの解決方法](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-fargate-pull-container-error/)を参照してください。
+ その他のタスクについては、[Amazon ECS タスクの「cannotpullcontainererror」エラーの解決方法](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-error/)を参照してください。
## pull access denied
このエラーは、イメージにアクセスできないことを示します。
この問題を解決するには、Amazon ECR で Docker クライアントを認証する必要がある場合があります。詳細については、「*Amazon ECR ユーザーガイド*」の「[プライベートレジストリ認証](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html)」を参照してください。
## pull command failed: panic: runtime error: invalid memory address or nil pointer dereference
このエラーは、メモリアドレスが無効であるか、ポインターデリファレンスが nil であるため、イメージにアクセスできないことを示しています。
この問題を解決するには。
+ Amazon S3 に到達するためのセキュリティグループのルールがあることを確認してください。
+ ゲートウェイエンドポイントを使用するときは、エンドポイントにアクセスするためのルートをルートテーブルに追加する必要があります。
## error pulling image conf/error pulling image configuration
このエラーは、レート制限に達したか、ネットワークエラーが発生したことを示します。
この問題を解決するには、「[Amazon ECS EC2 起動タイプタスクで CannotPullContainerError エラーを解決する方法](https://repost.aws/knowledge-center/ecs-pull-container-error)」を参照してください。
## コンテキストがキャンセルされました
このエラーは、コンテキストがキャンセルされたことを示しています。
このエラーの一般的な原因は、タスクが使用している VPC にコンテナイメージを Amazon ECR から取得するルートがないためです。
# Amazon ECS の停止したタスクの接続を検証する
ネットワーク接続の問題により、タスクが停止することがあります。断続的な問題である可能性がありますが、タスクがエンドポイントに接続できないことが原因である可能性が最も高いです。
## タスクの接続をテストする
`AWSSupport-TroubleshootECSTaskFailedToStart` ランブックを使用して、タスクの接続をテストできます。ランブックを使用する場合は、次のリソースに関する情報が必要です。
+ タスク ID
最後に失敗したタスク のID を使用します。
+ タスクが属していたクラスター
ランブックの使用方法については、「AWS Systems Manager Automation ランブックリファレンス」の「[https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshootecstaskfailedtostart.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshootecstaskfailedtostart.html)」を参照してください。**
ランブックはタスクを分析します。タスクの開始を妨げる可能性のある次の問題については、「**出力**」セクションで結果を確認できます。
+ 設定済みのコンテナレジストリーへのネットワーク接続
+ VPC エンドポイント接続
+ セキュリティグループのルール設定
## VPC エンドポイントの問題を修正する
`AWSSupport-TroubleshootECSTaskFailedToStart` ランブックの結果に VPC エンドポイントの問題が表示された場合は、次の設定を確認します。
+ エンドポイントと VPC エンドポイントを作成する VPC では、プライベート DNS を使用する必要があります。
+ タスクが接続できないサービスの AWS PrivateLink エンドポイントが、タスクと同じ VPC 内にあることを確認してください。詳細については、以下のいずれかを参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/verify-connectivity.html)
+ ポート 443 DNS (TCP) トラフィックで HTTPS を許可するタスクサブネットのアウトバウンドルールを設定します。詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[セキュリティグループのルールを設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules)」を参照してください。
+ カスタムネームドメインサーバーを使用する場合は、DNS クエリの設定を確認します。クエリは、53 番ポートで外部への通信を行うことができ、UDP および TCP プロトコルを使用する必要があります。また、443 番ポートでの HTTPS 通信も必要です。詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[セキュリティグループのルールを設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules)」を参照してください。
+ サブネットにネットワーク ACL がある場合は、次の ACL ルールが必要です。
+ ポート 1024-65535 でトラフィックを許可するアウトバウンドルール
+ ポート 443 の TCP トラフィックを許可するインバウンドルール
ルールの設定方法については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ネットワーク ACL を使用してサブネットへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)」を参照してください。
## ネットワークの問題を修正する
`AWSSupport-TroubleshootECSTaskFailedToStart` ランブックの結果にネットワークの問題が表示されたら、次の設定を確認します。
### パブリックサブネットで awsvpc ネットワークモードを使用するタスク
ランブックに基づいて次の設定を実行します。
+ パブリックサブネットのタスクでは、タスクの起動時に **[Auto-assign public IP]** (自動割り当てパブリック IP)を **[ENABLED]** (有効)に指定する必要があります。詳細については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。
+ インターネットトラフィックを処理するにはゲートウェイが必要です。タスクサブネットのルートテーブルには、ゲートウェイへのトラフィック用のルートが必要です。
詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ルートテーブルのルートの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)」を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/verify-connectivity.html)
+ タスクサブネットにネットワーク ACL がある場合は、次の ACL ルールが必要です。
+ ポート 1024-65535 でトラフィックを許可するアウトバウンドルール
+ ポート 443 の TCP トラフィックを許可するインバウンドルール
ルールの設定方法については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ネットワーク ACL を使用してサブネットへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)」を参照してください。
### プライベートサブネットで awsvpc ネットワークモードを使用するタスク
ランブックに基づいて次の設定を実行します。
+ タスクの起動時に、**[自動割り当てパブリック IP]** で **[無効]** を選択します。
+ リクエストがインターネットにルーティンされるように VPC の NAT ゲートウェイを設定します。詳細については、「Amazon Virtual Private Cloud ユーザーガイド」の「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」を参照してください。**
+ タスクサブネットのルートテーブルには、NAT ゲートウェイへのトラフィック用のルートが必要です。
詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ルートテーブルのルートの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)」を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/verify-connectivity.html)
+ タスクサブネットにネットワーク ACL がある場合は、次の ACL ルールが必要です。
+ ポート 1024-65535 でトラフィックを許可するアウトバウンドルール
+ ポート 443 の TCP トラフィックを許可するインバウンドルール
ルールの設定方法については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ネットワーク ACL を使用してサブネットへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)」を参照してください。
### パブリックサブネットで awsvpc ネットワークモードを使用しないタスク
ランブックに基づいて次の設定を実行します。
+ クラスターの作成時に、**[Amazon EC2 インスタンスのネットワーク]** の **[IP の自動割り当て]** で、**[オンにする]** を選択します。
このオプションにより、インスタンスのプライマリネットワークインターフェイスにパブリック IP アドレスを割り当てます。
+ インターネットトラフィックを処理するにはゲートウェイが必要です。インスタンスサブネットのルートテーブルには、ゲートウェイへのトラフィック用のルートが必要です。
詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ルートテーブルのルートの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)」を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/verify-connectivity.html)
+ インスタンスサブネットにネットワーク ACL がある場合は、次の ACL ルールが必要です。
+ ポート 1024-65535 でトラフィックを許可するアウトバウンドルール
+ ポート 443 の TCP トラフィックを許可するインバウンドルール
ルールの設定方法については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ネットワーク ACL を使用してサブネットへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)」を参照してください。
### プライベートサブネットで awsvpc ネットワークモードを使用しないタスク
ランブックに基づいて次の設定を実行します。
+ クラスターの作成時に、**[Amazon EC2 インスタンスのネットワーク]** の **[IP の自動割り当て]** で、**[オフにする]** を選択します。
+ リクエストがインターネットにルーティンされるように VPC の NAT ゲートウェイを設定します。詳細については、*Amazon VPC ユーザーガイド* の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) を参照してください。
+ インスタンスサブネットのルートテーブルには、NAT ゲートウェイへのトラフィック用のルートが必要です。
詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ルートテーブルのルートの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)」を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/verify-connectivity.html)
+ タスクサブネットにネットワーク ACL がある場合は、次の ACL ルールが必要です。
+ ポート 1024-65535 でトラフィックを許可するアウトバウンドルール
+ ポート 443 の TCP トラフィックを許可するインバウンドルール
ルールの設定方法については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[ネットワーク ACL を使用してサブネットへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)」を参照してください。
# Amazon ECS タスクの IAM ロールリクエストの表示
IAM ロールでタスク認証情報にプロバイダーを使用すると、プロバイダーは監査ログに保存されたものをリクエストします。監査ログは、コンテナエージェントログと同じログローテーション設定を継承します。コンテナエージェントの設定変数 `ECS_LOG_ROLLOVER_TYPE`、`ECS_LOG_MAX_FILE_SIZE_MB`、および `ECS_LOG_MAX_ROLL_COUNT` を設定して、監査ログの動作に影響を与えることもできます。詳細については、「[Amazon ECS コンテナエージェントのログ設定パラメータ](ecs-agent-versions.md#agent-logs)」を参照してください。
コンテナエージェントバージョン 1.36.0 以降の場合、監査ログは `/var/log/ecs/audit.log` にあります。ログがローテーションされると、`YYYY-MM-DD-HH` 形式のタイムスタンプがログファイル名の最後に追加されます。
コンテナエージェントバージョン 1.35.0 以前の場合、監査ログは `/var/log/ecs/audit.log.YYYY-MM-DD-HH` にあります。
ログエントリの形式は以下のとおりです。
+ タイムスタンプ
+ HTTP レスポンスコード
+ リクエスト元の IP アドレスとポート番号
+ 認証情報プロバイダーの相対 URI
+ リクエストを行ったユーザーエージェント
+ リクエスト元のコンテナが属するタスクの ARN
+ `GetCredentials` API 名とバージョン番号
+ コンテナインスタンスが登録されている Amazon ECS クラスターの名前
+ コンテナインスタンス ARN
ログファイルを表示するには、次のコマンドが使用できます。
```
cat /var/log/ecs/audit.log.2016-07-13-16
```
出力:
```
2016-07-13T16:11:53Z 200 172.17.0.5:52444 "/v1/credentials" "python-requests/2.7.0 CPython/2.7.6 Linux/4.4.14-24.50.amzn1.x86_64" TASK_ARN GetCredentials 1 CLUSTER_NAME CONTAINER_INSTANCE_ARN
```
# Amazon ECS のサービスイベントメッセージを表示する
サービスに関する問題をトラブルシューティングする際は、まず最初にサービスイベントログの診断情報を確認します。サービスイベントは、`DescribeServices` API、AWS CLI、または AWS マネジメントコンソール を使って表示できます。
Amazon ECS API を使用して、サービスイベントメッセージを表示する場合、サービススケジューラからのイベントのみが返されます。これには、最新のタスク配置とインスタンスの健全性イベントが含まれます。ただし、Amazon ECS コンソールには、次のソースからのサービスイベントが表示されます。
+ Amazon ECS サービススケジューラからのタスク配置およびインスタンスのヘルスイベント。これらのイベントには、**service *(service-name)*** のプレフィックスがついています。このイベントビューが役立つ情報を提供するために、最新の `100` 件のイベントのみを表示します。重複したサービスイベントメッセージは、原因が解決するか、6 時間が経過するまで表示されません。6 時間以内に原因が解決されない場合、その原因に関する別のサービスイベントメッセージが表示されます。
+ サービスの自動スケーリングイベント。これらのイベントには**Message**というプレフィックスが付き、サービスが Application Auto Scaling スケーリングポリシーで構成されている場合にのみ発生します。
**ヒント**
[Amazon ECS MCP サーバー](ecs-mcp-introduction.md) と AI アシスタントを使用することで、サービスイベントの分析を自然言語で実行できます。
現在のサービスイベントメッセージを表示するには、次の手順を実行します。
------
#### [ Console ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、クラスターを選択します。
1. 検査するサービスを選択します。
1. **[イベント]** タブでメッセージを表示します。
------
#### [ AWS CLI ]
指定したサービスのサービスイベントメッセージを表示するには、[describe-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-services.html) コマンドを使用します。
次の AWS CLI 例では、*default* クラスター内の *service-name* サービスが記述されます。ここには、最新のサービスイベントメッセージが表示されます。
```
aws ecs describe-services \
--cluster default \
--services service-name \
--region us-west-2
```
------
# Amazon ECS のサービスイベントメッセージ
以下は、Amazon ECS コンソールで確認できる可能性があるサービスイベントメッセージの例です。
## サービス (*service-name*) が定常状態に達しました。
サービススケジューラは、サービスが正常で、必要な数のタスクが定常状態になったときに、`service (service-name) has reached a steady state.` サービスイベントを送信します。
サービススケジューラは定期的にステータスを報告するため、このメッセージを複数回受信する場合があります。
## サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。
サービススケジューラは、別のタスクを追加するために利用可能なリソースが見つからなかったときに、このイベントメッセージを送信します。以下に示しているのは、その考えられる原因です。
キャパシティープロバイダーを使用して、EC2 インスタンスを自動的にスケーリングします。詳細については、「[EC2 ワークロード用の Amazon ECS キャパシティプロバイダー](asg-capacity-providers.md)」を参照してください。
キャパシティープロバイダーを使用する場合は、キャパシティープロバイダー戦略を渡すか、クラスターに関連付けられたデフォルトのキャパシティープロバイダー戦略があり、起動タイプとキャパシティープロバイダー戦略を入力として渡していないことを確認してください
クラスターにコンテナインスタンスが見つかなかった
タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。
ポートが足りない
タスクで固定ホストポートマッピングを使用している場合 (タスクでウェブサーバーのホスト上のポート 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 コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
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 アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしている**が、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動していない**場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、*Amazon EC2 ユーザーガイド*の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしていて**、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動している**場合、追加の ENI オプトインを利用できます。詳細については、「[Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス](eni-trunking-supported-instance-types.md)」を参照してください。
`awsvpcTrunking` アカウント設定のオプトインの詳細については、「[Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす](container-instance-eni.md)」を参照してください。
クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。
コンテナインスタンスに必須の属性がない
一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに `ECS_AVAILABLE_LOGGING_DRIVERS` エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とするパラメータが含まれており、この要件を満たすことができるコンテナインスタンスがない場合、そのタスクは配置できません。
このエラーの一般的な原因は、サービスが `awsvpc` ネットワークおよび EC2 を使用している場合です。指定したクラスターには、サービスの作成時に `awsvpcConfiguration` で指定されたものと同じサブネットにコンテナインスタンスが登録されていません。
トラブルシューティングには、AWSSupport-TroubleshootECSContainerInstance ランブックを使用できます。ランブックでは、インスタンスのユーザーデータに正しいクラスター情報が含まれているかどうか、インスタンスプロファイルに必要なアクセス権限が含まれているかどうか、およびネットワーク設定の問題が確認されます。詳細については、*「AWS Systems Manager オートメーションランブックリファレンスユーザーガイド」*の「[AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html)」を参照してください。
特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「[Fargate での Amazon ECS タスク定義パラメータ](task_definition_parameters.md)」と「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
## サービス (*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 コンテナエージェントのログ設定パラメータ](ecs-agent-versions.md#agent-logs)」を参照してください。エージェントがインスタンスで実行されていることも確認する必要があります。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*) (タスク *task–id*) (インスタンス *instance–id*) は、(reason インスタンスが、少なくとも UnhealthyThreshold 回のヘルスチェックに連続して失敗した) ため、(elb *elb elb–name*) で正常な状態になっていません
このサービスはロードバランサーに登録されており、ロードバランサーのヘルスチェックは失敗しています。メッセージには、どの特定のタスクがヘルスチェックに失敗しているかを識別するのに役立つタスク ID が含まれています。詳細については、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。
## サービス (*service-name*) は、一貫してタスクを正常に開始できません。
このサービスには、連続して試行された後開始に失敗したタスクがあります。この時点で、サービススケジューラによって再試行間隔が段階的に増加し始めます。タスクの起動に失敗している理由をトラブルシューティングする必要があります。詳細については、「[Amazon ECS サービスのスロットルロジック](service-throttle-logic.md)」を参照してください。
更新されたタスク定義などでサービスが更新された後、サービススケジューラは正常な動作を再開します。
## サービス (*service-name*) オペレーションは抑制されています。後で再試行します。
このサービスは、API スロットルの制限により、これ以上のタスクを起動できません。サービススケジューラが追加のタスクを起動できるようになると、再開します。
API レート制限クォータの引き上げをリクエストするには、[[AWS サポート Center (センター)](https://console.aws.amazon.com/support/home#/)]の ページを開き、必要に応じてサインインし、[**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.md)」を参照してください。クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) を参照してください。
## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由: 内部エラー。
このエラーが表示される理由として考えられるものは、次のとおりです。
あるサブネットがサポートされていないアベイラビリティーゾーンにあるため、サービスはタスクを開始できません。
サポートされた Fargate リージョンおよびアベイラビリティーゾーンの情報については、[AWS Fargate で使用する Amazon ECS でサポートされているリージョン](AWS_Fargate-Regions.md) を参照してください。
サブネットのアベイラビリティーゾーンを確認する方法については、「*Amazon VPC ユーザーガイド*」の「[サブネットの確認](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#view-subnet)」を参照してください。
## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由:リクエストされた CPU 構成が制限を超えています。
エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) を参照してください。
## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由:リクエストされたメモリ構成が制限を超えています。
エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) を参照してください。
## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由: 同時に実行できる vCPU の上限数に達しました
AWS Fargate は、タスク数ベースのクォータから vCPU ベースのクォータに移行しています。
Fargate の vCPU ベースのクォータの引き上げをリクエストできます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。Fargate クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げをリクエストする](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。
## タスクセット (*taskSet-ID*) がスケールインできなかったため、サービス (*service-name*) は定常状態に到達できませんでした。理由: 保護されているタスクの数が、必要なタスク数を超えています
サービスに、必要なタスク数よりも多くの保護タスクがあります。次のいずれかを行うことができます。
+ 現在のタスクの保護が期限切れになり、タスクを終了できるようになるまでお待ちください。
+ どのタスクを停止できるかを判断し、`UpdateTaskProtection` API で `protectionEnabled` オプションを `false` に設定し、これらのタスクに対する保護を設定解除します。
+ サービスの必要なタスク数を増やして、保護されているタスクの数よりも多くします。
## サービス (*service-name*) が定常状態に到達できませんでした。理由:キャパシティープロバイダーにコンテナインスタンスが見つかりませんでした。
サービススケジューラは、別のタスクを追加するために利用可能なリソースが見つからなかったときに、このイベントメッセージを送信します。以下に示しているのは、その考えられる原因です。
クラスターに関連付けられたキャパシティプロバイダーがありません
クラスターにキャパシティプロバイダーが関連付けられていることを確認するには、`describe-services` を使用します。サービスのキャパシティプロバイダー戦略を更新できます。
キャパシティプロバイダーに利用可能なキャパシティがあることを確認します。EC2 の場合は、コンテナインスタンスがタスク定義の要件を満たしていることを確認してください。
クラスターにコンテナインスタンスが見つかなかった
タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。
ポートが足りない
タスクで固定ホストポートマッピングを使用している場合 (タスクでウェブサーバーのホスト上のポート 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 コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
十分な数の ENI アタッチメントポイントを利用できない
`awsvpc` ネットワークモードを使用するタスクには、それぞれ独自の Elastic Network Interface (ENI) が提供されます。この ENI は、ENI をホストするコンテナインスタンスに添付されています。Amazon EC2 インスタンスにアタッチできる ENI の数には制限があり、クラスターには利用可能な ENI 容量があるコンテナインスタンスはありません。
個別のコンテナインスタンスの ENI 制限は、以下の条件によって異なります。
+ `awsvpcTrunking` アカウント設定を**オプトインしていない**場合、各コンテナインスタンスの ENI 制限は、インスタンスタイプによって異なります。詳細については、*Amazon EC2 ユーザーガイド*の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしている**が、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動していない**場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、*Amazon EC2 ユーザーガイド*の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしていて**、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動している**場合、追加の ENI オプトインを利用できます。詳細については、「[Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス](eni-trunking-supported-instance-types.md)」を参照してください。
`awsvpcTrunking` アカウント設定のオプトインの詳細については、「[Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす](container-instance-eni.md)」を参照してください。
クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。
コンテナインスタンスに必須の属性がない
一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに `ECS_AVAILABLE_LOGGING_DRIVERS` エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とするパラメータが含まれており、この要件を満たすことができるコンテナインスタンスがない場合、そのタスクは配置できません。
このエラーの一般的な原因は、サービスが `awsvpc` ネットワークモードを使うタスクを使用中で、EC2 と指定のクラスターに登録されたコンテナインスタンスが、サービス作成時に `awsvpcConfiguration` で指定された同じサブネット内に存在していないことです。
トラブルシューティングには、AWSSupport-TroubleshootECSContainerInstance ランブックを使用できます。ランブックでは、インスタンスのユーザーデータに正しいクラスター情報が含まれているかどうか、インスタンスプロファイルに必要なアクセス権限が含まれているかどうか、およびネットワーク設定の問題が確認されます。詳細については、*「AWS Systems Manager オートメーションランブックリファレンスユーザーガイド」*の「[AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html)」を参照してください。
特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「[Fargate での Amazon ECS タスク定義パラメータ](task_definition_parameters.md)」と「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由: 現在、容量は使用できません。後でもう一度試すか、別のアベイラビリティーゾーンで試してください。
現在、サービスを実行できる容量がありません。
次のいずれかを行うことができます。
+ Fargate 容量または EC2 コンテナインスタンスが使用可能になるまでお待ちください。
+ サービスを再起動し、追加のサブネットを指定します。
## サービス (*service-name*) のデプロイに失敗しました:タスクを開始できませんでした。
サービスのタスクが開始できませんでした。
停止タスクをデバッグする方法については、「[Amazon ECS の停止したタスクのエラーメッセージ](stopped-task-error-codes.md)」を参照してください。
## サービス (*service-name*) が、Amazon ECS エージェントの開始を待ってタイムアウトになりました。/var/log/ecs/ecs-agent.log でログを確認してください。"
タスク配置に最も一致するコンテナインスタンス上の Amazon ECS コンテナエージェントが切断されています。コンテナインスタンスに SSH で接続できる場合は、エージェントログを調べることができます。詳細については、「[Amazon ECS コンテナエージェントのログ設定パラメータ](ecs-agent-versions.md#agent-logs)」を参照してください。エージェントがインスタンスで実行されていることも確認する必要があります。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` が原因で、ターゲットグループ (*targetGroup-ARN*) 内のサービス (*service-name*) のタスクセット (*TaskSet-ID*) (task *task-id*) に異常があります。
ターゲットグループが見つからなかったため、サービスのタスクセットはヘルスチェックに合格できません。メッセージには、どの特定のタスクがヘルスチェックに失敗しているかを識別するのに役立つタスク ID が含まれています。サービスを削除して再作成してください。対応する Amazon ECS サービスが既に削除されていない限り、Elastic Load Balancing のターゲットグループを削除しないでください。
## `TARGET IS NOT FOUND` が原因で、ターゲットグループ (*targetGroup-ARN*) 内のサービス (*service-name*) のタスクセット (*TaskSet-ID*) (task *task-id*) に異常があります。
ターゲットが見つからなかったため、サービスのタスクセットはヘルスチェックに合格できません。メッセージには、どの特定のタスクがヘルスチェックに失敗しているかを識別するのに役立つタスク ID が含まれています。
## IAM アクセス許可ポリシーが正しく設定されていないか変更されているため、ECS はサービスを維持できなくなりました
IAM アクセス許可ポリシーの設定ミスまたは変更により、サービスはタスクを維持できません。ECS サービスまたはタスクに関連付けられた IAM ロールに必要なアクセス許可がない可能性があります。
この問題を解決するには、IAM ロールに必要なアクセス許可を追加します。IAM アクセス許可ポリシーの管理について詳しくは、「*IAM ユーザーガイド*」の「[IAM ID のアクセス許可の追加および削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
## IAM 信頼関係が正しく設定されていないか変更されているため、ECS はサービスを維持できなくなりました。
設定ミスや IAM 信頼関係の変更により、サービスはタスクを維持できません。ECS サービスまたはタスクに関連付けられた IAM ロールの信頼ポリシーが正しくない可能性があります。
この問題を解決するには、タスク定義で使用されるロールの信頼ポリシーを設定します。信頼ポリシーの作成について詳しくは、「*IAM ユーザーガイド*」の「[Creating a role for a custom use case](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
## サービス (*service–name*) は、デプロイ *deployment–id* のタスク *number* 件を起動できませんでした。
このイベントメッセージは、デプロイワークフローが一部のタスクを正常に開始したが、容量不足エラーが原因でリクエストされたすべてのタスクを起動できなかった場合、サービススケジューラにより送信されます。これは通常、サーキットブレーカーが有効になっており、デプロイが失敗またはロールバックされる理由が可視化されている場合に発生します。
メッセージには、具体的な障害の原因 (CPU 不足、メモリ不足、その他のリソース制約など) が含まれています。これを確認することで、デプロイの問題を解決するために対処する必要があるリソースを理解できます。
詳細については、「[サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。](#service-event-messages-1)」を参照してください。
## サービス (*service–name*) は、タスクのプロビジョニング容量の制限を超えたため、クラスターにタスクを配置できませんでした。
このイベントメッセージは、クラスターが同時に `PROVISIONING` 状態になることができる制限値 (タスク 500 件) に達した場合、サービススケジューラにより送信されます。これはクラスターレベルの制限です。サービス固有の問題ではありません。
通常このイベントは、タスクに事前プロビジョニング済みの容量制限がある状態で多数のタスクを実行するサービスを開始した場合や、複数のサービスを同時に開始したためにタスクが大量に作成される場合に発生します。
この問題を解決するには。
+ 既存のタスクのプロビジョニングが完了し、`RUNNING` 状態に移行するまで待機します。
+ プロビジョニングの制限に達しないよう、サービスのスケーリング速度を低下させることを検討してください。
+ クラスターのキャパシティプロバイダー設定を確認して、適切なリソースが使用可能になっていることを確認します。
Amazon ECS Service Quotas の詳細については、「*Amazon Web Services 全般リファレンス*」の「[Amazon Elastic Container Service のエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html)」を参照してください。
# Amazon ECS サービス異常イベントメッセージ
以下は、サービス異常イベントメッセージの例です。
## EC2: (service *service-name*) (task *task-id*) (instance *instance-id*) (port *port-number*) は (target-group *target-group-name*) で異常があり、その原因は (reason *failure-reason*) です。
このメッセージは、EC2 インスタンスで実行されているタスクがヘルスチェックに失敗したことを示します。詳細については次を参照してください:
+ [EC2 を使用する Amazon ECS タスクが、Application Load Balancer のヘルスチェックにパスするにはどうすればよいですか?](https://repost.aws/knowledge-center/troubleshoot-unhealthy-checks-ecs)
## taskSet: (service *service-name*, taskSet *taskSet-id*) (task *task-id*) (instance *instance-id*) (port *port-number*) の EC2 が (target-group *target-group-name*) で異常であり、その原因は (reason *failure-reason*) です。
このメッセージは、EC2 インスタンスで実行されているタスクセット内のタスクがヘルスチェックに失敗していることを示します。詳細については次を参照してください:
+ [EC2 を使用する Amazon ECS タスクが、Application Load Balancer のヘルスチェックにパスするにはどうすればよいですか?](https://repost.aws/knowledge-center/troubleshoot-unhealthy-checks-ecs)
## Fargate: (service *service-name*) (task *task-id*) (port *port-number*) が (target-group *target-group-name*) で異常であり、その原因は (reason *failure-reason*) です
このメッセージは、Fargate タスクがヘルスチェックに失敗したことを示します。
Fargate タスクでのヘルスチェックの失敗のトラブルシューティングの詳細については、「[Fargate 上の Amazon ECS タスクがヘルスチェックにパスできない問題をトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/ecs-fargate-health-check-failures)」を参照してください。
## taskSet: (service *service-name*, taskSet *taskSet-id*) (task *task-id*) (port *port-number*) の Fargate が、(target-group *target-group-name*) で異常であり、その原因は (reason *failure-reason*) です
このメッセージは、Fargate で実行されているタスクセット内のタスクがヘルスチェックに失敗していることを示します。
Fargate タスクでのヘルスチェックの失敗のトラブルシューティングの詳細については、「[Fargate 上の Amazon ECS タスクがヘルスチェックにパスできない問題をトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/ecs-fargate-health-check-failures)」を参照してください。
# Amazon ECS アベイラビリティーゾーンサービスの再調整サービスイベントメッセージ
以下は、表示される可能性があるサービスイベントメッセージの例です。
## サービス (*service-name*) は、*Availability Zone 1* の *number-tasks* タスク、*Availability Zone 2* の *number-tasks* タスク、*Availability Zone 3* の *number-tasks* タスクで AZ が調整されていません。AZ の再調整は進行中です。
サービススケジューラは、タスク数がアベイラビリティーゾーン間で均等に分散されていない場合、`service (service-name) is not AZ balanced` サービスイベントを送信します。実行するアクションはありません。これは情報イベントです。
## サービス (*service-name*) は、*Availability Zone 1* の *number-tasks* タスク、*Availability Zone 2* の *number-tasks* タスク、*Availability Zone 3* の *number-tasks* タスクで AZ が調整されています。
サービススケジューラは、アベイラビリティーゾーンのサービスの再調整が完了すると、`service (service-name) is AZ balanced` サービスイベントを送信します。実行するアクションはありません。これは情報イベントです。
## *service-name* は、AZ の再調整のために *Availability Zone* の *number-tasks* タスクを開始しました: *task-ids*。
サービススケジューラは、サービスの再調整のためにアベイラビリティーゾーンのタスクを開始する際、*service–name*/*task–set–name* が *Availability Zone* の *number* 件のタスクを開始したことを知らせるサービスイベントを送信します。実行するアクションはありません。これは情報イベントです。
## *service-name* は、AZ の再調整のために *Availability Zone* の実行中の *number-tasks* タスクを停止しました: *task-ids*。
サービススケジューラは、サービスの再調整のためにアベイラビリティーゾーンにあるタスクを停止する際、*service–name*/*task–set–name* が*アベイラビリティーゾーン*の *number* 件のタスクを停止したことを知らせるサービスイベントを送信します。実行するアクションはありません。これは情報イベントです。
## サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、*Availability Zone* にタスクを配置できません。
サービススケジューラは、すべての要件を満たしたコンテナインスタンスがないため、*service-name* で *Availability Zone* にタスクを配置できないというサービスイベントを送信します。問題に対処するには、アベイラビリティーゾーンでインスタンスを起動します。
## サービス (*service-name*) で、*Availability Zone* にタスクを配置できません。
サービススケジューラは、Fargate 起動タイプの使用中に利用可能なキャパシティがない場合、*service–name* で *Availability Zone* にタスクを配置できないというサービスイベントを送信します。
追加のキャパシティを取得するには、エラーメッセージでアベイラビリティーゾーンにサブネットを追加するか、サポートにお問い合わせください。
## サービス (*service-name*) で、*task-set-name* が *reason* によりスケールインできなかったため、AZ を再調整できませんでした。
サービススケジューラは、タスクスケールイン保護を使用するときに、*task-set-name* が *reason* によりスケールインできなかったため、*service-name* で AZ を再調整できなかったというサービスイベントを送信します。
次のいずれかを行うことができます。
+ 現在のタスクの保護が期限切れになり、タスクを終了できるようになるまでお待ちください。
+ どのタスクを停止できるかを判断し、`UpdateTaskProtection` API で `protectionEnabled` オプションを `false` に設定し、これらのタスクに対する保護を設定解除します。
+ サービスの必要なタスク数を増やして、保護されているタスクの数よりも多くします。
## サービス (*service-name*) が AZ の再調整を停止しました。
サービススケジューラは、アベイラビリティーゾーンの再調整オペレーションが停止すると、*service-name* が AZ の再調整を停止したというサービスイベントを送信します。これは情報イベントです。Amazon ECS は、詳細情報を提供する追加のイベントを送信します。
# Amazon ECS のサービスロードバランサーのトラブルシューティング
Amazon ECS サービスは、Elastic Load Balancing のロードバランサーにタスクを登録することができます。ロードバランサーの設定エラーは、タスクが停止された一般的な原因です。ロードバランサーを使用するサービスによって停止されたタスクが開始された場合は、以下の原因が考えられます。
**Amazon ECS サービスにリンクされたロールは存在しません**
Amazon ECS サービスにリンクされたロールを使用すると、Amazon ECS サービスが Elastic Load Balancing ロードバランサーにコンテナインスタンスを登録できます。サービスにリンクされたロールはアカウントに作成される必要があります。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
**コンテナインスタンスのセキュリティグループ**
コンテナがコンテナインスタンスのポート 80 にマッピングされている場合、コンテナインスタンスのセキュリティグループでは、ロードバランサーのヘルスチェックに合格するように、ポート 80 上の受信トラフィックを許可する必要があります。
**一部のアベイラビリティゾーンで、Elastic Load Balancing ロードバランサーが設定されていません**
リージョン内のすべてのアベイラビリティーゾーンを使用するように、または少なくとも、コンテナインスタンスが存在するすべてのアベイラビリティーゾーンを使用するように、ロードバランサーが設定されている必要があります。サービスでロードバランサーを使用し、ロードバランサーを使用するように設定されていないアベイラビリティーゾーンにあるコンテナインスタンスでタスクが開始されると、そのタスクはヘルスチェックに合格できません。これにより、タスクは強制終了されます。
**Elastic Load Balancing ロードバランサー ヘルスチェックが正しく設定されていません**
ロードバランサーのヘルスチェックパラメータが過度に制限されているか、存在しないリソースを指している可能性があります。コンテナインスタンスが異常であると判断されると、そのコンテナインスタンスはロードバランサーから削除されます。以下のパラメータがサービスロードバランサーに対して正しく設定されていることを確認してください。
ping ポート
ロードバランサーのヘルスチェックの [**Ping Port (ping ポート)**] 値は、ロードバランサーが正常であるかどうかを判断するために確認するコンテナインスタンス上のポートです。このポートの設定が正しくないと、多くの場合、ロードバランサーからコンテナインスタンスが登録解除されます。このポートは、ヘルスチェックで使用しているサービスのタスク定義内のコンテナで `hostPort` 値を使用するように設定する必要があります。
ping パス
これはロードバランサーのヘルスチェックの一部です。これは、アプリケーションが正常な場合に、成功のステータスコード (200 など) を返すことができる、アプリケーション上のエンドポイントです。この値はよく `index.html` に設定されることがありますが、サービスがそのリクエストに応答しない場合、ヘルスチェックは失敗します。コンテナに `index.html` ファイルがない場合は、これを `/` に設定して、コンテナインスタンスのベース URL をターゲットにすることができます。
応答タイムアウト
これは、コンテナがヘルスチェック ping に対する応答を返す必要のある時間です。この値が応答に必要な時間よりも短い場合、ヘルスチェックは失敗します。
ヘルスチェック間隔
これは、ヘルスチェック ping 間の時間です。ヘルスチェックの間隔が短くなるほど、コンテナインスタンスが [**Unhealthy Threshold (非正常のしきい値)**] に達するのが速くなります。
非正常のしきい値
これは、コンテナインスタンスが異常と見なされるまでに、ヘルスチェックが失敗できる回数です。異常と見なされるまでのしきい値が 2、ヘルスチェックの間隔が 30 秒の場合、コンテナインスタンスが異常と見なされるまでに、タスクはヘルスチェック ping に 60 秒間応答します。異常と見なされるまでのしきい値を増やすか、ヘルスチェックの間隔を長くすると、タスクが ping に応答する時間が長くなります。
*servicename* **サービスを更新できません****: タスク定義でロードバランサーのコンテナ名またはポートが変更されました**
サービスでロードバランサーを使用している場合は、AWS CLI または SDK を使用してロードバランサーの設定を変更できます。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) を参照してください。サービスのタスク定義を更新する場合は、ロードバランサー設定で指定されたコンテナ名とコンテナポートはタスク定義のままにしておく必要があります。
**同時に実行できるタスク数の上限に達しました。**
新しいアカウントの場合、クォータがサービスクォータよりも低くなることがあります。Service Quotas コンソールでは、アカウントのサービスクォータを表示できます。クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) を参照してください。
# Amazon ECS のサービス自動スケーリングのトラブルシューティング
Amazon ECS デプロイの進行中、Application Auto Scaling はスケールインプロセスをオフにします。このプロセスは、デプロイの完了後に再開されます。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。詳細については、「[Application Auto Scaling のスケーリングの中断と再開](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)」を参照してください。
# コンソールの Amazon ECS イベントキャプチャ
Amazon ECS コンソールには、サービスアクションやタスク状態の変更など、Amazon ECS が生成したイベントを EventBridge 経由で Amazon CloudWatch Logs に保存するイベントキャプチャ機能が用意されています。この機能には、モニタリングとトラブルシューティングのためのフィルタリング機能を備えたクエリインターフェイスが含まれています。
イベントは、サービスのデプロイ、サービス、タスク、インスタンスの動作に関する詳細情報を提供します。この情報を使用して、タスクまたはサービスのデプロイの失敗をトラブルシューティングできます。
イベントキャプチャを有効にすると、選択した保持期間中に Amazon ECS が生成するすべてのイベントにアクセスできるようになります。これにより、フィルタリングされていない 100 件を超える過去のイベントにアクセスでき、また、停止したタスクは 1 時間以上表示可能になります。
## 仕組み
イベントキャプチャは EventBridge を使用して、事前定義された Amazon CloudWatch Logs ロググループにイベントを保存します。Amazon ECS コンソールは、事前に構築されたクエリとフィルタリングオプションを提供し、イベントを関連付けて直感的な形式でタスクライフサイクルを提供します。
次のタイプのイベントをクエリして取得できます。
+ **サービスアクションイベント** – プロビジョニングまたはリソース割り当ての問題を特定するのに役立ちます
+ **タスクライフサイクルイベント** – タスクまたはコンテナが起動または実行停止に失敗する理由を特定するのに役立ちます
Amazon ECS コンソールを使用すると、ワンクリックでイベントキャプチャを設定し、一般的に使用されるクエリやフィルタリングを利用できます。クエリ言語の習得は不要で、複数のコンソール間を移動する必要もありません。
## イベントタイプ
イベントキャプチャは、Amazon ECS で生成されたすべてのイベントを次のカテゴリに保存します。
タスク状態変更イベント
コンテナの停止およびその他の終了イベント。トラブルシューティングやタスクのライフサイクルタイムラインのモニタリングに使用できます。
サービスアクション
定常状態に達する、タスク配置の失敗、リソースの制約などのイベント。
サービスデプロイの状態の変更
サービスデプロイの状態をモニタリングするために、サーキットブレーカーとロールバック設定によってトリガーされるイベント (進行中のデプロイ、完了したデプロイ、失敗したデプロイなど)。
コンテナインスタンス状態の変更
EC2 および Amazon ECS マネージドインスタンスのワークロードの場合、イベントには接続と切断の状態が表示されます。
## ロググループ設定
イベントキャプチャを有効にすると、Amazon ECS は次のリソースを自動的に作成します。
+ `/aws/events/ecs/containerinsights/${clusterName}/performance` という名前の Amazon CloudWatch Logs ロググループ
+ `aws.ecs` ソースからすべてのイベントを取り込みロググループに転送する EventBridge ルール
ロググループの保持期間は 1 日から 10 年の間で指定できます。デフォルトの保持期間は 7 日間です。
## 考慮事項
イベントキャプチャを使用する場合は、以下の点を考慮してください。
+ イベントキャプチャは、簡素化の目的ですべてのイベントを保存します。Amazon ECS コンソールで、特定のイベントのみをキャプチャするルールを設定することはできません。
+ Amazon ECS コンソールには、事前定義済みのクエリ条件が用意されています。高度なクエリの場合は、Amazon CloudWatch Logs Insights を使用してロググループに直接クエリを実行します。
+ ライブテール機能は Amazon ECS コンソールでは使用できません。ライブテールには Amazon CloudWatch Logs を直接使用します。
+ イベントキャプチャを無効にすると、EventBridge ルールは削除されます。
+ イベントキャプチャでは、EventBridge のデータ取り込み、Amazon CloudWatch Logs ストレージ、クエリの実行に追加のコストが発生します。
EventBridge の料金の詳細については、「[EventBridge の料金](https://aws.amazon.com/eventbridge/pricing/)」を参照してください。
CloudWatch の料金の詳細については、「[CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
## イベントベースのトラブルシューティング
Amazon ECS で生成されたイベントを活用して、一般的なトラブルシューティングの疑問に対応します。
### タスク障害分析
`STOPPED` タスクの状態変更イベント、停止コード、コンテナ終了コードを確認して、タスクが起動に失敗した理由や、実行中に失敗した理由を特定できます。
配置の失敗およびリソース制約情報に関するサービスアクションイベントを確認して、リソースの制約が原因でタスクが配置に失敗した理由を特定できます。
### 一般的なタスク障害シナリオ
最も一般的に発生する異常なタスク障害は、次の問題に関連しています。
+ CI/CD サービスのデプロイの失敗
+ 自動スケーリングの失敗
+ タスクの再調整の失敗
+ out–of–memory (OOM) エラーなど、異常なコンテナの終了
異常なタスク障害は、`EssentialContainerExited` または `TaskFailedToStart` の停止コードを含む `STOPPED` タスク状態変更イベントを生成します。これらの停止コードでフィルタリングして、コンテナの実行と停止の動作を調べることができます。
# 既存の Amazon ECS クラスターのイベントキャプチャを有効にする
既存の Amazon ECS クラスターのイベントキャプチャを有効にして、EventBridge を通じて Amazon ECS で生成されたイベントを Amazon CloudWatch Logs に保存できます。この機能は、タスクの障害、サービスのデプロイ、その他のクラスターアクティビティのモニタリングおよびトラブルシューティングに役立ちます。
イベントキャプチャを有効にすると、Amazon ECS は次のリソースを作成します。
+ `/aws/events/ecs/containerinsights/${clusterName}/performance` という名前の Amazon CloudWatch Logs ロググループ
+ `aws.ecs` ソースからすべてのイベントをキャプチャする EventBridge ルール
クラスタービューに **[履歴]** タブが表示され、タスクライフサイクルイベントとサービスアクションにクエリを実行できます。イベントキャプチャは直ちに開始され、指定した保持期間に従って Amazon ECS が生成したすべてのイベントを保存します。
## 前提条件
+ 既存の Amazon EKS クラスター
+ クラスター設定を変更し、Amazon CloudWatch Logs リソースを作成するための適切な IAM アクセス権限
## コンソールを使用してイベントキャプチャを有効にする
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. イベントキャプチャを有効にするクラスターを選択します。
クラスター詳細のページが表示されます。
1. **[設定]** を選択します。
1. **[ECS イベント]** セクションで、**[イベントキャプチャをオンにする]** を選択します。
**[イベントキャプチャをオンにする]** のダイアログボックスが表示されます。
1. **[イベントを失効]** で、Amazon CloudWatch Logs ロググループの保持期間を選択します。デフォルトは 7 日間です。
1. **[オンにする]** を選択します。
# Amazon ECS サービスおよびタスクの状態変更イベントを表示する
Amazon ECS コンソールには、サービスアクションやタスク状態の変更など、Amazon ECS が生成したイベントを EventBridge 経由で Amazon CloudWatch Logs に保存するイベントキャプチャ機能が用意されています。この機能には、モニタリングとトラブルシューティングを拡張するフィルタリング機能を備えたクエリインターフェイスが含まれています。
イベントは、サービスのデプロイ、サービス、タスク、インスタンスの動作に関する詳細情報を提供します。この情報を使用して、タスクまたはサービスのデプロイの失敗をトラブルシューティングできます。
次のいずれかの基準を使用して、イベントをフィルタリングできます。
+ デプロイ ID (これは [サービス詳細] ページでのみ使用できます)
+ 開始時間
+ 終了時間
+ サービス名 ([クラスターの詳細] ページ、[サービス詳細] ページでのみ使用できます。デフォルトで現在のサービスになります)
+ タスク ID
+ タスクの最終状態
+ タスク定義ファミリー
+ タスク定義リビジョン
## クラスターレベルでのイベントを表示する
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. **[クラスター]** を選択します。
クラスターリストページが表示されます。
1. クラスターを選択します。
クラスター詳細のページが表示されます。
1. **[履歴]** で、表示するイベントを決定します。
1. サービスアクションイベントを表示するには、**[サービスアクションイベント]** を選択します。
1. タスク状態の変更イベントを表示するには、**[タスク状態の変更イベント]** を選択します。
1. (オプション) **[クエリ基準]** に、表示するイベントのフィルターを入力します。
1. **[Run query]** (クエリの実行) を選択します。
イベントがリストに表示されます。
1. イベントの詳細をすべて表示するには、イベントを選択します。
## サービスレベルで表示する
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. **[Clusters]** (クラスター) ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービスの詳細] ページが表示されます。
1. **[履歴]** で、表示するイベントを決定します。
1. サービスアクションイベントを表示するには、**[サービスアクションイベント]** を選択します。
1. タスク状態の変更イベントを表示するには、**[タスク状態の変更イベント]** を選択します。
1. (オプション) **[クエリ基準]** に、表示するイベントのフィルターを入力します。
1. **[Run query]** (クエリの実行) を選択します。
イベントがリストに表示されます。
1. イベントの詳細をすべて表示するには、イベントを選択します。
# Amazon ECS タスク定義の無効な CPU またはメモリエラーをトラブルシューティングする
Amazon ECS API または AWS CLI を使用してタスク定義を登録する場合、無効な`cpu`または`memory`値を指定すると、以下のエラーが返されます。
```
An error occurred (ClientException) when calling the RegisterTaskDefinition operation: Invalid 'cpu' setting for task.
```
**注記**
Terraform の使用時に、以下のエラーが返される可能性があります。
```
Error: ClientException: No Fargate configuration exists for given values.
```
この問題を解決するには、タスク定義でタスクの CPU とメモリにサポートされている値を指定する必要があります。`cpu` 値はタスク定義で、CPU ユニットまたは vCPU で表すことができます。タスク定義が登録されると、CPU ユニットを示す整数に変換されます。`memory` 値はタスク定義で、MiB または GB で表すことができます。タスク定義が登録されると、MiB を示す整数に変換されます。
`requiresCompatibilities` パラメータに `FARGATE` を指定しているタスク定義については (`EC2` も指定されている場合も)、次の表のいずれかの値を使用する必要があります。これらの値は、CPU とメモリのパラメータでサポートされる値の範囲を決定します。
Fargate でホストされるタスクの場合、次の表に有効な CPU とメモリの組み合わせを示します。JSON ファイルのメモリ値は MiB 単位で指定されます。この値に 1024 を掛けると、GB 値を MiB に変換できます。例えば、1 GB = 1024 MiB です。
| CPU の値 | メモリの値 | AWS Fargate でサポートされるオペレーティングシステム |
| --- | --- | --- |
| 256 (.25 vCPU) | 512 MiB、1 GB、2 GB | Linux |
| 512 (.5 vCPU) | 1 GB、2 GB、3 GB、4 GB | Linux |
| 1,024 (1 vCPU) | 2 GB、3 GB、4 GB、5 GB、6 GB、7 GB、8 GB | Linux、Windows |
| 2,048 (2 vCPU) | 4 GB ～ 16 GB (1 GB のインクリメント) | Linux、Windows |
| 4,096 (4 vCPU) | 8 GB ～ 30 GB (1 GB のインクリメント) | Linux、Windows |
| 8192 (8 vCPU) このオプションには Linux プラットフォーム `1.4.0` 以降が必要です。 | 16 GB～60 GB (4 GB のインクリメント) | Linux |
| 16384 (16vCPU) このオプションには Linux プラットフォーム `1.4.0` 以降が必要です。 | 32 GB～120 GB (8 GB のインクリメント) | Linux |
Amazon EC2 でホストされているタスクでサポートされるタスク CPU の値は、0.25 vCPU ～ 192 vCPU です。
CPU 制御メカニズムは、EC2 と Fargate で異なります。
+ Amazon EC2 でホストされているタスクの場合: Amazon ECS は、CPU 期間と CPU クォータを使用して、タスクサイズの CPU ハード制限を制御します。タスク定義で vCPU を指定すると、Amazon ECS は `cgroup` に適用される CPU 期間と CPU クォータの設定に値を変換します。
+ Fargate でホストされているタスクの場合: Amazon ECS は CPU 共有を使用して CPU 割り当てを制御します。CPU クォータと期間値は、Fargate タスクの CPU 制限には使用されません。
Amazon EC2 タスクの場合、CPU クォータは特定の CPU 期間中に `cgroup` に付与される CPU 時間を制御します。どちらの設定も、マイクロ秒単位で表されます。CPU クォータが CPU 期間と等しい場合、`cgroup` は 1 つの vCPU で最大 100% (または複数の vCPU の場合は合計で 100% になる割合) まで実行できます。CPU クォータは最大 1,000,000 マイクロ秒で、CPU 期間は最小 1 ミリ秒です。これらの値を使用して CPU 数の制限を設定できます。CPU クォータを変更せずに CPU 期間を変更する場合、有効になる制限はタスク定義で指定した制限とは異なります。
100 ミリ秒の期間では、0.125～10 の vCPU を使用できます。
**注記**
タスクレベル CPU およびメモリのパラメータは Windows コンテナでは無視されます。
# Amazon ECS コンテナエージェントログの表示
Amazon ECS によってログはコンテナインスタンスの `/var/log/ecs` フォルダに保存されます。Amazon ECS コンテナエージェントから得られるログと、コンテナインスタンスのエージェントの状態 (スタート/停止) を制御する `ecs-init` サービスから得られるログがあります。これらのログファイルは、コンテナインスタンスに SSH で接続することにより表示できます。
**注記**
コンテナインスタンスのログをすべて収集する方法がわからない場合は、Amazon ECS ログコレクターを使用できます。詳細については、「[Amazon ECS ログコレクターを使用したコンテナログの収集](ecs-logs-collector.md)」を参照してください。
## Linux オペレーティングシステム
`ecs-init` プロセスはログを `/var/log/ecs/ecs-init.log` に保存します。
`ecs-init.log` ファイルには、コンテナエージェントのライフサイクル管理、設定、ブートストラップに関する情報が含まれています。
ログファイルを表示するには、次のコマンドが使用できます。
```
cat /var/log/ecs/ecs-init.log
```
出力:
```
2018-02-16T18:13:54Z [INFO] pre-start
2018-02-16T18:13:56Z [INFO] start
2018-02-16T18:13:56Z [INFO] No existing agent container to remove.
2018-02-16T18:13:56Z [INFO] Starting Amazon Elastic Container Service Agent
```
## Windows オペレーティングシステム
Windows 用の Amazon ECS ログコレクターを使用できます。詳細については、Github の「[Amazon ECS Logs Collector For Windows](https://github.com/awslabs/aws-ecs-logs-collector-for-windows?tab=readme-ov-file#aws-ecs-logs-collector-for-windows)」を参照してください。
1. インスタンスに接続します。
1. PowerShell を開き、管理者権限で次のコマンドを実行します。このコマンドは、スクリプトをダウンロードし、ログを収集します。
```
Invoke-WebRequest -OutFile ecs-logs-collector.ps1 https://raw.githubusercontent.com/awslabs/aws-ecs-logs-collector-for-windows/master/ecs-logs-collector.ps1
.\ecs-logs-collector.ps1
```
Amazon ECS エージェントおよび Docker デーモンのデバッグログを有効にできます。このオプションを使用すると、スクリプトはデバッグモードを有効にする前にログを収集できます。スクリプトは Docker デーモンと Amazon ECS エージェントを再起動し、インスタンスで実行されているすべてのコンテナを終了します。次のコマンドを実行する前に、コンテナインスタンスをドレインし、重要なタスクを他のコンテナインスタンスに移動します。
次のコマンドを実行して、ログ記録をオンにします。
```
.\ecs-logs-collector.ps1 -RunMode debug
```
# Amazon ECS ログコレクターを使用したコンテナログの収集
**注記**
Amazon ECS マネージドインスタンスで Amazon ECS ログコレクターを使用することはできません。
コンテナインスタンスのさまざまなログをすべて収集する方法がわからない場合は、Amazon ECS ログコレクターを使用できます。[Linux](https://github.com/awslabs/ecs-logs-collector) 用と [Windows](https://github.com/awslabs/aws-ecs-logs-collector-for-windows) 用のいずれも GitHub で入手できます。スクリプトは一般的なオペレーティングシステムログおよび Docker と Amazon ECS コンテナエージェントログを収集します。これらは、AWS サポート ケースのトラブルシューティングに役立ちます。次に、収集された情報が、診断目的で簡単に共有することができる 1 つのファイルに圧縮およびアーカイブされます。また、Docker デーモン、および Amazon Linux バリアントで Amazon ECS コンテナエージェント (Amazon ECS 最適化 AMI など) に対してデバッグモードを有効にすることもできます。
**注記**
Amazon Linux Amazon ECS 最適化 AMI のバージョン 20250909 以降では、Amazon ECS ログコレクターが `/opt/amazon/ecs/ecs-logs-collector.sh` にあらかじめインストールされているため、GitHub からダウンロードしなくても使用をすぐに開始できます。詳細については、ECS 最適化 AMI ドキュメントの「[ECS Logs Collector](https://github.com/aws/amazon-ecs-ami?tab=readme-ov-file#ecs-logs-collector)」を参照してください。
現在、Amazon ECS ログコレクターでは以下のオペレーティングシステムがサポートしています:
+ Amazon Linux
+ Red Hat Enterprise Linux
+ Ubuntu
+ Windows サーバー
**Linux 用 Amazon ECS ログコレクターを実行するには (ECS 最適化 AMI)**
1. コンテナインスタンスに接続します。
1. スクリプトを実行してログを収集し、アーカイブを作成します。
**注記**
Docker デーモンと Amazon ECS コンテナエージェントに対してデバッグモードを有効にするには、次のコマンドに `--mode=enable-debug` オプションを追加します。これにより、Docker デーモンが再起動され、インスタンスで実行されているすべてのコンテナが強制終了されます。デバッグモードを有効にする前に、コンテナインスタンスをドレインし、重要なタスクを他のコンテナインスタンスに移動することを検討してください。詳細については、「[Amazon ECS コンテナインスタンスをドレインする](container-instance-draining.md)」を参照してください。
```
[ec2-user ~]$ sudo /opt/amazon/ecs/ecs-logs-collector.sh
```
スクリプトを実行した後、スクリプトによって作成された `collect` フォルダに収集されたログを調べることができます。`collect.tgz` ファイルはすべてのログの圧縮アーカイブであり、AWS サポートと共有することで診断に役立ちます。
**LinuxにAmazon ECS ログコレクターをダウンロードして実行するには**
1. コンテナインスタンスに接続します。
1. Amazon ECS ログ コレクタースクリプトをダウンロードします。
```
curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh
```
1. スクリプトを実行してログを収集し、アーカイブを作成します。
```
$ sudo bash ./ecs-logs-collector.sh
```
**WindowsでAmazon ECS ログコレクターをダウンロードして実行するには**
1. コンテナインスタンスに接続します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[RDP を使用した Windows インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)」を参照してください。
1. PowerShell を使用して、Amazon ECSログコレクターのスクリプトをダウンロードします。
```
Invoke-WebRequest -OutFile ecs-logs-collector.ps1 https://raw.githubusercontent.com/awslabs/aws-ecs-logs-collector-for-windows/master/ecs-logs-collector.ps1
```
1. スクリプトを実行してログを収集し、アーカイブを作成します。
**注記**
Docker デーモンと Amazon ECS コンテナエージェントに対してデバッグモードを有効にするには、次のコマンドに `-RunMode debug` オプションを追加します。これにより、Docker デーモンが再起動され、インスタンスで実行されているすべてのコンテナが強制終了されます。デバッグモードを有効にする前に、コンテナインスタンスをドレインし、重要なタスクを他のコンテナインスタンスに移動することを検討してください。詳細については、「[Amazon ECS コンテナインスタンスをドレインする](container-instance-draining.md)」を参照してください。
```
.\ecs-logs-collector.ps1
```
スクリプトを実行した後、スクリプトによって作成された `collect` フォルダに収集されたログを調べることができます。`collect.tgz` ファイルはすべてのログの圧縮アーカイブであり、診断に役立つように AWS サポートと共有できます。
# エージェントのイントロスペクションを使用して Amazon ECS 診断の詳細を取得する
Amazon ECS エージェントのイントロスペクション API は、Amazon ECS エージェントとコンテナインスタンスの全体的な状態に関する情報を提供します。
エージェントのイントロスペクション API を使用して、タスク内のコンテナの Docker ID を取得できます。コンテナインスタンスに SSH で接続することにより、エージェントイントロスペクション API を使用できます。
**重要**
イントロスペクション API に到達するには、コンテナインスタンスにAmazon ECS にアクセスできる IAM ロールが必要です。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
次の例では、2 つのタスクを示しています。1 つは現在実行中のタスク、もう 1 つは停止されたタスクです。
**注記**
次のコマンドは、読みやすくするために **python -mjson.tool** によりパイプされています。
```
curl http://localhost:51678/v1/tasks | python -mjson.tool
```
出力:
```
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1095 100 1095 0 0 117k 0 --:--:-- --:--:-- --:--:-- 133k
{
"Tasks": [
{
"Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/090eff9b-1ce3-4db6-848a-a8d14064fd24",
"Containers": [
{
"DockerId": "189a8ff4b5f04affe40e5160a5ffadca395136eb5faf4950c57963c06f82c76d",
"DockerName": "ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600",
"Name": "simple-app"
},
{
"DockerId": "f7f1f8a7a245c5da83aa92729bd28c6bcb004d1f6a35409e4207e1d34030e966",
"DockerName": "ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01",
"Name": "busybox"
}
],
"Family": "console-sample-app-static",
"KnownStatus": "STOPPED",
"Version": "6"
},
{
"Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/1810e302-eaea-4da9-a638-097bea534740",
"Containers": [
{
"DockerId": "dc7240fe892ab233dbbcee5044d95e1456c120dba9a6b56ec513da45c38e3aeb",
"DockerName": "ecs-console-sample-app-static-6-simple-app-f0e5859699a7aecfb101",
"Name": "simple-app"
},
{
"DockerId": "096d685fb85a1ff3e021c8254672ab8497e3c13986b9cf005cbae9460b7b901e",
"DockerName": "ecs-console-sample-app-static-6-busybox-92e4b8d0ecd0cce69a01",
"Name": "busybox"
}
],
"DesiredStatus": "RUNNING",
"Family": "console-sample-app-static",
"KnownStatus": "RUNNING",
"Version": "6"
}
]
}
```
上記の例では、停止されたタスク (*090eff9b-1ce3-4db6-848a-a8d14064fd24*) には 2 つのコンテナがあります。**docker inspect *container-ID*** を使用して、各コンテナの詳細情報を表示できます。詳細については、「[Amazon ECS コンテナの詳細分析](ecs-agent-introspection.md)」を参照してください。
# Amazon ECS の Docker 診断
Docker には、コンテナやタスクに関する問題のトラブルシューティングに役立つ診断ツールがいくつか用意されています。使用できるすべての Docker コマンドラインユーティリティの詳細については、Docker ドキュメントの [Docker CLI リファレンス](https://docs.docker.com/reference/cli/docker/)を参照してください。コンテナインスタンスに SSH で接続することにより、Docker コマンドラインユーティリティにアクセスできます。
Docker コンテナからレポートされる終了コードからも診断情報を得られます (例えば、終了コード 137 は、コンテナが `SIGKILL` 信号を受信したことを意味します)。詳細については、Docker ドキュメントの「[終了ステータス](https://docs.docker.com/reference/cli/docker/container/run/#exit-status)」を参照してください。
## Amazon ECS の Docker コンテナを一覧表示する
コンテナインスタンスの **docker ps** コマンドを使用して、実行中のコンテナを一覧表示できます。次の例では、Amazon ECS コンテナエージェントのみが実行されています。詳細については、Docker ドキュメントの「[docker ps](https://docs.docker.com/reference/cli/docker/#ps)」を参照してください。
```
docker ps
```
出力:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent
```
**docker ps -a** コマンドを使用して、すべてのコンテナ (停止されたコンテナまたは強制終了されたコンテナも含む) を表示できます。この情報は、予期せず停止されたコンテナを一覧表示するために役立ちます。以下の例では、コンテナ `f7f1f8a7a245` は 9 秒前に終了したため、`-a` フラグのない **docker ps** 出力には表示されません。
```
docker ps -a
```
出力:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db4d48e411b1 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 19 seconds ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-c09288a6b0cba8a53700
f7f1f8a7a245 busybox:buildroot-2014.02 "\"sh -c '/bin/sh -c 22 hours ago Exited (137) 9 seconds ago ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01
189a8ff4b5f0 httpd:2 "httpd-foreground" 22 hours ago Exited (137) 40 seconds ago ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600
0c7dca9321e3 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 22 hours ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-90fefaa68498a8a80700
cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent
```
## Amazon ECS で Docker ログを表示する
**docker logs** コマンドを使用して、コンテナの `STDOUT` および `STDERR` ストリームを表示できます。この例では、ログは *dc7240fe892a* コンテナのものが表示され、見やすくするために **head** コマンドによりパイプされています。詳細については、Docker ドキュメントの「[Docker ログ](https://docs.docker.com/reference/cli/docker/#logs)」を参照してください。
**注記**
デフォルトの `json` ログドライバーを使用している場合、Docker ログはコンテナインスタンスのみで利用できます。`awslogs` ログドライバーを使用するようにタスクを設定している場合には、コンテナログは CloudWatch Logs で使用できます。詳細については、「[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)」を参照してください。
```
docker logs dc7240fe892a | head
```
出力:
```
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message
[Thu Apr 23 19:48:36.956682 2015] [mpm_event:notice] [pid 1:tid 140327115417472] AH00489: Apache/2.4.12 (Unix) configured -- resuming normal operations
[Thu Apr 23 19:48:36.956827 2015] [core:notice] [pid 1:tid 140327115417472] AH00094: Command line: 'httpd -D FOREGROUND'
10.0.1.86 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:49:28 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:49:29 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:49:50 +0000] "-" 408 -
10.0.0.154 - - [23/Apr/2015:19:49:50 +0000] "-" 408 -
10.0.1.86 - - [23/Apr/2015:19:49:58 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:49:59 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:50:28 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:50:29 +0000] "GET / HTTP/1.1" 200 348
time="2015-04-23T20:11:20Z" level="fatal" msg="write /dev/stdout: broken pipe"
```
## Amazon ECS で Docker コンテナを検査する
コンテナの Docker ID がある場合は、**docker inspect** コマンドを使用してコンテナを検査できます。コンテナを検査すると、コンテナが起動された環境の最も詳細なビューを得られます。詳細については、Docker ドキュメントの「[Docker の検査](https://docs.docker.com/reference/cli/docker/#inspect)」を参照してください。
```
docker inspect dc7240fe892a
```
出力:
```
[{
"AppArmorProfile": "",
"Args": [],
"Config": {
"AttachStderr": false,
"AttachStdin": false,
"AttachStdout": false,
"Cmd": [
"httpd-foreground"
],
"CpuShares": 10,
"Cpuset": "",
"Domainname": "",
"Entrypoint": null,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/apache2/bin",
"HTTPD_PREFIX=/usr/local/apache2",
"HTTPD_VERSION=2.4.12",
"HTTPD_BZ2_URL=https://www.apache.org/dist/httpd/httpd-2.4.12.tar.bz2"
],
"ExposedPorts": {
"80/tcp": {}
},
"Hostname": "dc7240fe892a",
...
```
# Amazon ECS の Docker デーモンからの詳細な出力の設定
Docker コンテナまたはイメージに問題がある場合は、Docker デーモンに対してデバッグモードをオフにすることができます。デバッグを使用すると、デーモンからより詳細な出力が得られます。これを使用して、Amazon ECR などのコンテナレジストリから送信されるエラーメッセージを取得できます。
**重要**
この手順は、Amazon ECS 最適化 Amazon Linux AMI 用に書かれています。他のオペレーティングシステムについては、Docker ドキュメントの「[デバッグの有効化](https://docs.docker.com/engine/admin/#enable-debugging)」と「[systemd による Docker の制御と設定]()」を参照してください。
**Amazon ECS に最適化された Amazon Linux AMI で Docker デーモンのデバッグモードを使用するには**
1. コンテナインスタンスに接続します。
1. Docker options ファイルを **vi** などのテキストエディタで開きます。Amazon ECS 最適化 Amazon Linux AMI の場合、Docker options ファイルは`/etc/sysconfig/docker`にあります。
1. Docker options ステートメントを見つけ、引用符の中の文字列に `-D` オプションを追加します。
**注記**
Docker options ステートメントが `#` で始まっている場合、その文字を削除してそのステートメントをコメント解除し、オプションを有効にします。
Amazon ECS 最適化 Amazon Linux AMI では、Docker options ステートメントを `OPTIONS` と呼びます。例えば、次のようになります。
```
# Additional startup options for the Docker daemon, for example:
# OPTIONS="--ip-forward=true --iptables=true"
# By default we limit the number of open files per container
OPTIONS="-D --default-ulimit nofile=1024:4096"
```
1. ファイルを保存し、テキストエディタを終了します。
1. Docker デーモンを再び開始します。
```
sudo service docker restart
```
出力は次のとおりです。
```
Stopping docker: [ OK ]
Starting docker: . [ OK ]
```
1. Amazon ECS エージェントを再び開始します。
```
sudo service ecs restart
```
これで、Docker ログにはより詳細な出力が表示されます。
```
time="2015-12-30T21:48:21.907640838Z" level=debug msg="Unexpected response from server: \"{\\\"errors\\\":[{\\\"code\\\":\\\"DENIED\\\",\\\"message\\\":\\\"User: arn:aws:sts::1111:assumed-role/ecrReadOnly/i-abcdefg is not authorized to perform: ecr:InitiateLayerUpload on resource: arn:aws:ecr:us-east-1:1111:repository/nginx_test\\\"}]}\\n\" http.Header{\"Connection\":[]string{\"keep-alive\"}, \"Content-Type\":[]string{\"application/json; charset=utf-8\"}, \"Date\":[]string{\"Wed, 30 Dec 2015 21:48:21 GMT\"}, \"Docker-Distribution-Api-Version\":[]string{\"registry/2.0\"}, \"Content-Length\":[]string{\"235\"}}"
```
# Amazon ECS の Docker `API error (500): devmapper` のトラブルシューティング
以下の Docker エラーは、コンテナインスタンスのシンプールストレージがいっぱいで、Docker デーモンが新しいコンテナを作成できないことを示しています。
```
CannotCreateContainerError: API error (500): devmapper: Thin Pool has 4350 free data blocks which is less than minimum required 4454 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior
```
デフォルトでは、バージョン `2015.09.d`以降の Amazon ECS 最適化 Amazon Linux AMIs は、`/dev/xvda`に添付されファイルシステムのルートとしてマウントされたオペレーティングシステム用の8 GiB ボリュームで起動します。また、Docker がイメージとメタデータの保存に使用する `/dev/xvdcz`に添付された22 GiB のボリュームが追加されています。このストレージ領域がいっぱいになると、Docker デーモンは新しいコンテナを作成できません。
コンテナインスタンスにストレージを追加する最も簡単な方法は、既存のインスタンスを終了し、サイズを増加したデータストレージボリュームで新しいインスタンスを起動することです。ただし、この方法を実行できない場合は、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」の手順に従って、Docker が使用するボリュームグループにストレージを追加し、その論理ボリュームを拡張できます。
コンテナインスタンスストレージがあまりにも速くいっぱいになる場合は、以下のいくつかの対処方法があります。
+ thin poll情報を表示するには、コンテナインスタンスで次のコマンドを実行します。
```
docker info
```
+ (Amazon ECS コンテナエージェント 1.8.0 以降) 停止または終了したコンテナがコンテナインスタンスに残る時間を短縮できます。`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` エージェント設定変数で、タスクが停止されてから Docker コンテナが削除されるまでの時間を設定します (デフォルトでは、この値は 3 時間です)。これにより Docker コンテナのデータは削除されます。この値が低すぎると、ログを削除するまでは停止したコンテナを検査したり、ログを表示したりすることができない場合があります。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
+ 実行されていないコンテナと未使用のイメージをコンテナインスタンスから削除できます。次のコマンドの例を使用して、停止したコンテナと未使用のイメージを手動で削除することができます。削除されたコンテナを後から検査することはできませんので、削除されたイメージは、新しいコンテナをスタートする前に、再度プルする必要があります。
実行中ではないコンテナを削除するには、コンテナインスタンスで以下のコマンドを実行します。
```
docker rm $(docker ps -aq)
```
使用しないイメージを削除するには、コンテナインスタンスで以下のコマンドを実行します。
```
docker rmi $(docker images -q)
```
+ コンテナ内で使用されていないデータブロックは削除できます。以下のコマンドを使用して、実行中のコンテナで **fstrim** を実行し、コンテナファイルシステムによって使用されていないデータブロックを破棄できます。
```
sudo sh -c "docker ps -q | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/"
```
# Amazon ECS Exec に関する問題のトラブルシューティング
ECS Exec の使用時にエラーが発生する理由を診断するトラブルシューティングに関する注意事項を以下に示します。
## Execチェッカーを使用して検証する
ECS Exec チェッカー スクリプトを使用すると、Amazon ECS クラスターとタスクが ECS Exec 機能を使用するための前提条件を満たしていることを確認および検証できます。ECS Exec チェッカースクリプトは、AWS CLI 環境およびクラスターを両方認証し、お客様に代わってさまざまな API を呼び出すことで、タスクが ECS Exec に対応できるようにします。このツールには、AWS CLIの最新バージョンと`jq`が利用可能であることが必要です。詳細については、GitHub で「[ECS Exec チェッカー](https://github.com/aws-containers/amazon-ecs-exec-checker)」を参照してください。
## `execute-command` 呼び出し時のエラー
`The execute command failed` エラーが発生した場合は、以下の原因が考えられます。
+ タスクに必要なアクセス許可がありません。タスクの起動に使用されるタスク定義にタスク IAM のロールが定義されていること、およびロールに必要なアクセス許可があることを確認します。詳細については、「[ECS Exec のアクセス許可](task-iam-roles.md#ecs-exec-required-iam-permissions)」を参照してください。
+ SSM エージェントがインストールされていないか、実行されていません。
+ Amazon ECS 用のインターフェイス Amazon VPC エンドポイントはありますが、システムマネージャーセッションマネージャー用のエンドポイントはありません。
# Amazon ECS Anywhere に関する問題のトラブルシューティング
Amazon ECS Anywhere は、オンプレミスサーバーや仮想マシン (VM) などの*外部インスタンス*を Amazon ECS クラスターに登録するためのサポートを提供します。以下は、発生する可能性のある一般的な問題と、一般的なトラブルシューティングの推奨事項です。
**Topics**
+ [外部インスタンス登録の問題](#ecs-anywhere-troubleshooting-registration)
+ [外部インスタンスネットワークの問題](#ecs-anywhere-troubleshooting-networking)
+ [外部インスタンスでのタスクの実行に関する問題](#ecs-anywhere-troubleshooting-runtask)
## 外部インスタンス登録の問題
Amazon ECS クラスターに外部インスタンスを登録する場合、次の要件を満たす必要があります:
+ *アクティベーション ID* および*アクティベーションコード*で構成される、AWS Systems Manager のアクティベーションを取得する必要があります。Systems Manager マネージドインスタンスとして、外部 インスタンスを登録するために使用します。Systems Manager の有効化が要求されたら、登録制限と有効期限を指定します。登録制限は、アクティベーションを使用して登録できるインスタンスの最大数を指定します。登録制限のデフォルト値は `1` instance です。有効期限は、アクティベーションが期限切れになる日付です。デフォルト値は 24 時間です。外部インスタンスの登録に使用している Systems Manager のアクティベーションが有効でない場合は、新しいものをリクエストします。詳細については、「[Amazon ECS クラスターに外部インスタンスを登録する](ecs-anywhere-registration.md)」を参照してください。
+ IAM ポリシーは、外部インスタンスが AWS API 操作との通信に必要なアクセス許可を提供するために使用されます。このマネージド ポリシーが正しく作成されず、必要なアクセス権限が含まれていない場合、外部インスタンスの登録は失敗します。詳細については、「[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md)」を参照してください。
+ Amazon ECS には、Docker、Amazon ECS コンテナエージェント、および Systems Manager Agent を外部インスタンスにインストールするインストールスクリプトが用意されています。インストールスクリプトが失敗した場合、エラーが発生しなくても、同じインスタンスでスクリプトを再実行できない可能性があります。このような場合は、クリーンアッププロセスに従ってAWSリソースをインスタンスから削除して、再度インストールスクリプトを実行できます。詳細については、「[Amazon ECS 外部インスタンスの登録を解除する](ecs-anywhere-deregistration.md)」を参照してください。
**注記**
インストールスクリプトが Systems Manager のアクティベーションを正常に要求し、使用した場合、インストールスクリプトを 2 回実行すると Systems Manager のアクティベーションが再び使用されることに注意してください。これにより、順番にアクティベーションの登録制限に達する可能性があります。この制限に達した場合、新しいアクティベーションを作成する必要があります。
+ GPU ワークロードの外部インスタンスでインストールスクリプトを実行するときに、NVIDIA ドライバが検出されない、または正しく設定されていない場合、エラーが発生します。インストールスクリプトは `nvidia-smi` コマンドを実行して、NVIDIA ドライバの存在を確認します。
## 外部インスタンスネットワークの問題
変更内容を伝えるには、外部インスタンスはAWSにネットワーク接続が必要です。外部インスタンスがAWSへのネットワーク接続が切断された場合、マニュアルで停止しない限り、インスタンスで実行されているタスクは、引き続き実行されます。AWS への接続後が復元されると、外部インスタンスの Amazon ECS コンテナエージェントと Systems Manager Agent によって使用される AWS 認証情報は自動的に更新されます。外部インスタンスとAWSの間の通信に使用されるAWSドメインの詳細については、「[ネットワーク](ecs-anywhere.md#ecs-anywhere-networking)」を参照してください。
## 外部インスタンスでのタスクの実行に関する問題
タスクまたはコンテナが外部インスタンスで実行されない場合、最もよくある原因はネットワークまたはアクセス許可に関連しています。コンテナがAmazon ECRからイメージを引き出している場合や、コンテナのログをCloudWatch Logsに送信するように設定されている場合は、タスク定義で有効なタスク実行IAMロールを指定する必要があります。有効なタスク実行 IAM ロールがない場合、コンテナは起動しません。ネットワーク関連の問題の詳細については、「[外部インスタンスネットワークの問題](#ecs-anywhere-troubleshooting-networking)」を参照してください。
**重要**
Amazon ECS には、Amazon ECS ログ収集ツールが用意されています。これを使用して、トラブルシューティングの目的で外部インスタンスからログを収集することができます。詳細については、「[Amazon ECS ログコレクターを使用したコンテナログの収集](ecs-logs-collector.md)」を参照してください。
# Fargate での Java クラス読み込みに関する問題のトラブルシューティング
Fargate で実行されている Java アプリケーションでは、特にアプリケーションが非決定論的クラスの読み込み動作に依存している場合、プラットフォームの更新後にクラス読み込みの問題が発生する可能性があります。これは、依存関係インジェクションエラー、Spring Boot 障害、または以前のデプロイで存在しなかったその他のランタイム例外として現れる可能性があります。
## 症状
次の症状が発生する場合があります。
+ Spring Boot 依存関係インジェクションエラー
+ ClassNotFoundException または NoClassDefFoundError 例外
+ 以前は Fargate で動作していたアプリケーションが断続的に失敗するようになった
+ 同じコンテナイメージが Amazon EC2 では動作するが、Fargate では失敗する
+ 同一のコンテナイメージを使用したデプロイ間で動作に一貫性がない
## 原因
これらの問題は通常、次の原因で発生します。
+ **非決定論的クラスの読み込み:** クラスが JAR ファイルからロードされる順序に依存する Java アプリケーションは、基盤となるプラットフォームでファイルへのアクセス方法やキャッシュ方法が変更されると失敗する可能性があります。
+ **プラットフォームの更新:** Fargate プラットフォームバージョンの更新により、基盤となるファイルシステムの動作が変更され、クラスの検出と読み込みの順序に影響を及ぼす可能性があります。
+ **JAR ファイルの順序付けにおける依存関係:** 明示的な依存関係管理を行わずに、特定の JAR 読み込みっ順序に暗黙的に依存するアプリケーション。
## 解決策
Fargate での Java クラス読み込みの問題を解決するには、決定論的クラスの読み込みプラクティスを実装します。
### 即時修正
即時の回避策が必要な場合は次の操作を実行します。
1. **JAR 読み込み順序を適用する:** アプリケーションのクラスパス設定で JAR ファイルを読み込む順序を明示的に指定します。
1. **明示的な依存関係管理を使用する:** 推移的な依存関係に依存するのではなく、すべての依存関係がビルド設定 (Maven、Gradle など) で明示的に宣言されていることを確認します。
### 長期的なベストプラクティス
以下のプラクティスを実装すると、今後のクラス読み込みの問題を防ぐことができます。
1. **クラスの読み込みを決定論的にする**
+ ビルドファイルで明示的な依存関係宣言を使用します
+ クラスパスのスキャン順序に依存しないようにします
+ 依存関係管理ツールを使用してバージョン競合を解決します
+ `-verbose:class` などの Java 仮想マシン (JVM) オプションを使用して、JVM で読み込まれたクラスに関する情報を取得します。
1. **Spring Boot アプリケーション**
+ 明示的なベースパッケージで `@ComponentScan` を使用します
+ 明示的に Bean を設定して自動設定の競合を回避します
+ `@DependsOn` 注釈を使用して Bean の初期化順序を制御します
1. **ビルド設定**
+ Maven または Gradle の依存関係管理セクションを使用します
+ 競合の原因となる推移的な依存関係を除外します
+ Maven Enforcer Plugin などのツールを使用して依存関係の問題を検出します
1. **テスト**
+ さまざまな JVM 実装でアプリケーションをテストします
+ さまざまなデプロイ環境をシミュレートする統合テストを実行します
+ ツールを使用して開発中のクラスパスの競合を分析します
## 防止
今後のデプロイで Java クラス読み込みの問題を防ぐには、以下を実行します。
+ **決定論的クラスの読み込みプラクティスに従う:** クラスパスからクラスを読み込む順序に依存しないようにアプリケーションを設計します。
+ **明示的な依存関係管理を使用する: **ビルド設定で、必要なすべての依存関係とそのバージョンを常に明示的に宣言します。
+ **環境間でテストする:** さまざまな環境やプラットフォームバージョンでアプリケーションを定期的にテストして、潜在的な問題を早期に特定します。
+ **プラットフォームの更新をモニタリングする:** Fargate プラットフォームの更新に関する最新情報を入手し、本番環境のワークロードに影響を与える前に新しいプラットフォームバージョンでアプリケーションをテストします。
# AWS Fargate スロットリングのクォータ
AWS Fargate は、リージョンごとに各 AWS アカウントの[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用して、Amazon ECS タスクと Amazon EKS ポッドの起動レートをクォータ (以前は制限と呼ばれていました) に制限します。このアルゴリズムでは、アカウントには、特定の数のトークンを保持するバケットがあります。バケット内のトークンの数は、特定の秒におけるレートクォータを表します。各カスタマーアカウントには、タスクとポッドのトークンバケットがあり、カスタマーアカウントが起動したタスクとポッドの数に応じて枯渇していきます。このトークンバケットは、定期的により多くのリクエストを行うことができるバケットの最大値と、必要に応じて一定数のリクエストを維持できるリフィルレートを持ちます。
例えば、Fargate カスタマーアカウントのタスクとポッドトークンのバケットサイズは 100 トークンで、リフィルレートは毎秒 20 トークンです。したがって、カスタマーアカウントごとに最大 100 の Amazon ECS タスクと Amazon EKS ポッドをすぐに起動できます。持続的な起動レートは、1 秒あたり 20 の Amazon ECS タスクと Amazon EKS ポッドです。
| アクション | バケット最大容量 (またはバーストレート) | バケット補充率 (または持続率) |
| --- | --- | --- |
| オンデマンドの Amazon ECS タスクおよび Amazon EKS ポッドの Fargate リソースレートクォータ[1](#fargate-throttling-note-1) | 100 | 20 |
| スポット Amazon ECS タスクの Fargate リソースレートクォータ | 100 | 20 |
1Amazon EKS ポッドのみを起動するアカウントのバーストレートは 20 で、[Amazon EKS プラットフォームバージョン](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)で呼び出されるプラットフォームバージョンを使用する場合、1 秒あたりの持続的なポッド起動レートは 20 です。
## Fargate での `RunTask` API のスロットリング
さらに、Fargate は Amazon ECS `RunTask` API を使用したタスクの起動時に、別のクォータを使用してリクエストレートを制限します。Fargate は、リージョンごとに、各 AWS アカウントの Amazon ECS `RunTask` API リクエストを制限します。各リクエストは、バケットから 1 つのトークンが削除されます。これは、サービスのパフォーマンスを向上し、Fargate のすべてのお客様に平等にご利用いただくために行います。API コールは、呼び出し元が Amazon Elastic Container Service コンソール、コマンドラインツール、サードパーティーアプリケーションのどれであるかに関係なく、リクエストクォータの対象となります。Amazon ECS `RunTask` API への呼び出しのレートクォータは毎秒 20 コール (バーストおよび持続的) です。ただし、この API を呼び出すたびに、最大 10 のタスクを起動できます。つまり、この API に 10 回の呼び出しを行い、各呼び出しで 10 のタスクを起動するように要求することで、1 秒で 100 のタスクを起動できます。同様に、この API に 20 回の呼び出しを行い、各呼び出しで 5 つのタスクを起動するように要求することもできます。Amazon ECS `RunTask` API の API スロットリングの詳細については、Amazon ECS API リファレンスの「[API リクエストのスロットリング](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)」を参照してください。
実際には、タスクやポッドの起動レートは、ダウンロードおよび解凍するコンテナイメージ、ヘルスチェック、タスクやポッドをロードバランサーに登録するなどの統合を有効にする他の考慮事項にも依存します。お客様が有効にした機能により、以前のクォータに比べるとタスクとポッドの起動レートにばらつきが見られます。
## Fargate でのレートクォータの調整
AWS アカウントの Fargate レートスロットリングクォータの増加をリクエストできます。詳細については、「*サービスクォータ ユーザーガイド*」の「[Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。
# Amazon ECS マネージドインスタンスのトラブルシューティング
次の手順を使用して、一般的な問題、診断手法、解決手順など、Amazon ECS マネージドインスタンスのトラブルシューティングを行います。
## 前提条件
Amazon ECS マネージドインスタンスのトラブルシューティングを行う前に、次の要件を満たしていることを確認してください。
+ AWS CLI が適切なアクセス許可でインストールおよび設定されている
詳細については、「*AWS Command Line Interfaceユーザーガイド*」の「[AWS Command Line Interfaceの最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
+ Amazon ECS マネージドインスタンスキャパシティプロバイダーによるクラスターへのアクセス 詳細については、「[Amazon ECS マネージドインスタンスのクラスターを作成する](create-cluster-managed-instances.md)」を参照してください。
## 一般的なトラブルシューティングのシナリオ
### Amazon ECS マネージドインスタンスコンテナエージェントログの表示
これらの Amazon ECS ログファイルは、インスタンスで実行されている特権コンテナに接続することで、Amazon ECS マネージドインスタンスで表示できます。
#### 診断手順
**Amazon ECS タスクとして権限と Linux 機能を備えたデバッグコンテナをデプロイします。**
次の環境変数を設定します。
*user-input* を独自の値に置き換えます。
```
export ECS_CLUSTER_NAME="your-cluster-name"
export AWS_REGION="your-region"
export ACCOUNT_ID="your-account-id"
```
`node-debugger.json` という CLI JSON ファイルを使用してタスク定義を作成します。
```
cat << EOF > node-debugger.json
{
"family": "node-debugger",
"taskRoleArn": "arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole",
"executionRoleArn": "arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole",
"cpu": "256",
"memory": "1024",
"networkMode": "host",
"pidMode": "host",
"requiresCompatibilities": ["MANAGED_INSTANCES", "EC2"],
"containerDefinitions": [
{
"name": "node-debugger",
"image": "public.ecr.aws/amazonlinux/amazonlinux:2023",
"essential": true,
"privileged": true,
"command": ["sleep", "infinity"],
"healthCheck": {
"command": ["CMD-SHELL", "echo debugger || exit 1"],
"interval": 30,
"retries": 3,
"timeout": 5
},
"linuxParameters": {
"initProcessEnabled": true
},
"mountPoints": [
{
"sourceVolume": "host-root",
"containerPath": "/host",
"readOnly": false
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/aws/ecs/node-debugger",
"awslogs-create-group": "true",
"awslogs-region": "${AWS_REGION}",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"volumes": [
{
"name": "host-root",
"host": {
"sourcePath": "/"
}
}
]
}
EOF
```
タスクを登録して実行します。以下のコマンドを実行します。
```
aws ecs register-task-definition --cli-input-json file://node-debugger.json
TASK_ARN=$(aws ecs run-task \
--cluster $ECS_CLUSTER_NAME \
--task-definition node-debugger \
--enable-execute-command \
--capacity-provider-strategy capacityProvider=managed-instances-default,weight=1 \
--query 'tasks[0].taskArn' --output text)
# Wait for task to be running
aws ecs wait tasks-running --cluster $ECS_CLUSTER_NAME --tasks $TASK_ARN
```
コンテナに接続します。以下のコマンドを実行してください。
```
aws ecs execute-command \
--cluster $ECS_CLUSTER_NAME \
--task $TASK_ARN \
--container node-debugger \
--interactive \
--command "/bin/sh"
```
**Amazon ECS エージェントログを確認します。**
コンテナのインタラクティブセッションで、次のコマンドを実行します。
```
# Install required tools
yum install -y util-linux-core
# View ECS agent logs
nsenter -t 1 -m -p cat /var/log/ecs/ecs-agent.log | tail -50
# Check agent registration
nsenter -t 1 -m -p grep "Registered container instance" /var/log/ecs/ecs-agent.log
Example Output:
{"level":"info","time":"2025-10-16T12:39:37.665","msg":"Registered container instance with cluster!"}
# Verify capabilities
nsenter -t 1 -m -p grep "Response contained expected value for attribute" /var/log/ecs/ecs-agent.log
```
**エージェントメトリクスを確認します。**
次のコマンドを実行して、ログを表示します。
```
# View metrics logs
nsenter -t 1 -m -p cat /var/log/ecs/metrics.log | tail -20
```
### タスク配置の問題
以下は、タスク配置の問題で見られる症状です。
+ タスクが保留中状態でスタックする
+ Amazon ECS マネージドインスタンスでタスク開始に失敗する
+ リソース不足のエラーが発生する
#### 診断手順
次のコマンドを実行して、タスク配置の問題を診断し、クラスター容量、コンテナインスタンス、システムサービスに関する情報を収集します。
```
# Check cluster capacity
aws ecs describe-clusters --clusters cluster-name --include STATISTICS
# Check cluster capacity providers
aws ecs describe-clusters --clusters cluster-name --include STATISTICS --query 'clusters[].capacityProviders'
# List container instances
aws ecs list-container-instances --cluster cluster-name
# Check container instance details
aws ecs describe-container-instances --cluster cluster-name --container-instances container-instance-arn
# Check container instance remaining resources CPU/Mem
aws ecs describe-container-instances --cluster $ECS_CLUSTER_NAME --container-instances container-instance-arn --query 'containerInstances[].remainingResources'
# Check container instance Security Group
aws ecs describe-container-instances --cluster $ECS_CLUSTER_NAME --container-instances container-instance-arn --query 'containerInstances[].ec2InstanceId' --output text
aws ec2 describe-instances --instance-ids instance-id --query 'Reservations[0].Instances[0].SecurityGroups'
aws ec2 describe-security-groups --group-ids security-group-id
```
**システムサービスのモニタリング:**
```
# Check Containerd status
nsenter -t 1 -m -p systemctl status containerd.service
# Check Amazon ECS container agent status
nsenter -t 1 -m -p systemctl status ecs
```
#### 解決策
タスク配置の問題を解決するには、以下の手順に従って、適切な設定と容量であることを確認してください。
+ タスクリソースの要件と使用可能な容量を検証する
+ 配置の制約と戦略を確認する
+ Amazon ECS マネージドインスタンスのキャパシティプロバイダーが設定されていることを確認する
+ タスクとコンテナインスタンスのセキュリティグループに、Amazon ECS エージェント管理エンドポイントのトラフィックを許可するアウトバウンドルールがあることを確認する
### ネットワーキングの問題
ネットワークの問題では、次のような症状が見られます。
+ タスクが外部サービスに到達できない
+ DNS 解決に問題がある
#### 診断手順
**ネットワーク接続のテスト:**
デバッグコンテナで次のコマンドを実行します。
**注記**
キャパシティプロバイダーまたは Amazon ECS タスクにアタッチされたセキュリティグループがトラフィックを許可していることを確認します。
```
# Install DNS Utility
yum install bind-utils -y
# Test DNS resolution
nslookup amazon.com
# Test external connectivity
curl -I https://amazon.com
```
### リソースの制約
ネットワークの問題では、次のような症状が見られます。
+ タスクがメモリ制限により強制終了される
+ CPU スロットリングが発生する
+ ディスク容量に問題がある
#### 診断手順
コマンドを実行して、リソースとコンテナの制限をモニタリングします。
**リソースのモニタリング:**
```
# Check memory usage
nsenter -t 1 -m -p free -h
# Check disk usage
nsenter -t 1 -m -p lsblk
# Check disk usage
nsenter -t 1 -m -p df -h
```
**コンテナの制限:**
```
# Check OOM kills
nsenter -t 1 -m -p dmesg | grep -i "killed process"
```
### コンテナインスタンスエージェントが切断される問題
コンテナインスタンスエージェントの切断の問題には、次のような症状が見られます。
+ Amazon ECS コンソールで、コンテナインスタンスが切断されたと表示される
+ 特定のインスタンスにタスクを配置できない
+ ログでエージェント登録が失敗している
#### 診断手順
ECS Exec がアクセス可能なホストで既存の権限タスクが実行中の場合は、次のコマンドを実行してエージェント接続の問題を診断します。
```
# check service status
nsenter -t 1 -m -p systemctl restart ecs
nsenter -t 1 -m -p systemctl restart containerd
# restart stopped services
nsenter -t 1 -m -p systemctl restart ecs
nsenter -t 1 -m -p systemctl restart containerd
```
それ以外の場合は、Amazon ECS マネージドインスタンスを強制的に登録解除します。次のコマンドを実行します。
```
# list ECS Managed Instance container
aws ecs list-container-instances --cluster managed-instances-cluster --query 'containerInstanceArns' --output text
# deregister the specific container instance
aws ecs deregister-container-instance \
--cluster $ECS_CLUSTER_NAME \
--container-instance container-instance-arn \
--force
```
#### 解決策
エージェントの切断の問題を解決するには、次の手順に従います。
+ コンテナインスタンスの IAM ロールのアクセス許可を検証する
+ セキュリティグループルールが、ECS エンドポイントへのアウトバウンド HTTPS トラフィックを許可していることを確認する
+ AWS サービスへのネットワーク接続を確認する
+ 必要に応じて、`nsenter -t 1 -m -p systemctl restart ecs` で ECS エージェントサービスを再起動する
+ /etc/ecs/ecs.config の ECS\$1CLUSTER 設定がクラスター名と一致することを確認する
## Amazon ECS マネージドインスタンスのログ分析
### システムログ
次のコマンドを使用して、システムログを確認し、マネージドインスタンスの潜在的な問題を特定します。
```
# Check system messages
nsenter -t 1 -m -p journalctl --no-pager -n 50
# Check kernel logs
nsenter -t 1 -m -p dmesg | tail -20
# Check for disk space errors
nsenter -t 1 -m -p journalctl --no-pager | grep -i "no space\|disk full\|enospc"
```
## EC2 AWS CLI を使用して Amazon ECS マネージドインスタンスからコンソール出力を取得する
Amazon EC2 インスタンス ID を使用してコンソール出力を取得します。
*user-input* を独自の値に置き換えます。
```
aws ec2 get-console-output --instance-id instance-id --latest --output text
```
## クリーンアップ
以下を実行して、デバッグタスクを停止し、タスク定義を登録解除します。
```
# Stop debug task
aws ecs stop-task --cluster $ECS_CLUSTER_NAME --task $TASK_ARN
# Deregister task definition (optional)
aws ecs deregister-task-definition --task-definition node-debugger
```
## その他のリソース
Amazon ECS マネージドインスタンスのトラブルシューティングの詳細については、次のリソースを参照してください。
+ [Amazon ECS Amazon ECS マネージドインスタンスエラーのトラブルシューティング](managed-instances-errors.md)
+ [Amazon ECS トラブルシューティング](troubleshooting.md)
+ [Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)
+ [ECS Exec を使用して Amazon ECS コンテナをモニタリングする](ecs-exec.md)
# Amazon ECS マネージドインスタンスのトラブルシューティング
Amazon ECS マネージドインスタンスでタスクを起動する場合、Amazon ECS は、まず既存の容量へのタスク配置を試行し、配置できないタスクに対する追加の容量を要求します。インスタンスのプロビジョニングが失敗した場合、Amazon EC2 リクエスト ID がタスク失敗メッセージに含まれています。このリクエスト ID を使用して、CloudTrail で失敗したリクエストの詳細を検索し、トラブルシューティングに活用することができます。
**注記**
`AmazonECSInstanceRolePolicyForManagedInstances` 管理ポリシーを使用する代わりに、アクセスの最小特権を適用し、インスタンスプロファイルに独自のアクセス許可を指定する場合は、次のアクセス権限を追加して、Amazon ECS マネージドインスタンスのタスク関連の問題のトラブルシューティングに役立てることができます。
`ecs:StartTelemetrySession`
`ecs:PutSystemLogEvents`
## タスク定義に Amazon ECS マネージドインスタンスとの互換性がありません
### 一般的な原因
このエラーは、Amazon ECS マネージドインスタンスでサポートされていないパラメータや設定がタスク定義に含まれている場合に発生します。一般的には、サポートされていないネットワークモード、タスクロール、リソース要件などが互換性のない原因になります。
### 解決策
1. タスク定義で、`MANAGED_INSTANCES` に設定した `requiresCompatibilities` を使用していることを確認します。
1. タスク定義で `awsvpc` ネットワークモードを使用していることを確認します。
1. CPU とメモリの値が、Amazon ECS マネージドインスタンスのサポート範囲内にあることを確認します。
1. 特定の互換性問題の詳細については、エラーメッセージの細部を確認してください。
## キャパシティプロバイダーがクラスターに関連付けられていません
### 一般的な原因
このエラーは、キャパシティプロバイダー戦略で指定されたキャパシティプロバイダーがクラスターに関連付けられていないか、当該のプロバイダーが存在しない場合に発生します。
### 解決策
1. キャパシティプロバイダーがアカウントとリージョンに存在することを確認します。
1. Amazon ECS コンソールまたは CLI を使用して、キャパシティプロバイダーをクラスターに関連付けます。
1. 使用する前に、キャパシティプロバイダーが `ACTIVE` 状態であることを確認します。
## インフラストラクチャロールのアクセス許可エラー
### 一般的な原因
このエラーは、Amazon ECS インフラストラクチャロールに、ユーザーに代わって Amazon EC2 オペレーションを実行するために必要なアクセス許可がない場合、または信頼関係の問題によりロールを引き受けることができない場合に発生します。
### 解決策
1. インフラストラクチャロールに Amazon ECS との適切な信頼関係があることを確認します。
1. ロールに必要な Amazon EC2 アクセス許可 (`ec2:RunInstances`、`ec2:DescribeInstances`、`iam:PassRole` など) があることを確認します。
1. 特定のアクセス許可の詳細については、CloudTrail のエンコードされた認可失敗メッセージを確認してください。
1. ロールポリシーを更新して、不足しているアクセス許可 (エラーメッセージで確認する) を含めます。
## VcpuLimitExceeded エラー
### 一般的な原因
このエラーは、現在のリージョンでインスタンスタイプファミリーの vCPU サービスクォータに達した場合に発生します。Amazon ECS マネージドインスタンスは、容量が利用可能になるまで追加のインスタンスを起動できません。
### 解決策
1. AWS サポートセンターを通じて、影響を受けるインスタンスタイプファミリー用のサービスクォータの引き上げをリクエストします。
1. 異なる vCPU クォータカテゴリに分類されるインスタンスタイプを別に使用することを検討してください。
1. 未使用の Amazon EC2 インスタンスを終了して vCPU 容量を解放します。
1. vCPU 要件が低いインスタンスタイプを使用する場合は、キャパシティプロバイダーの設定を確認します。
## InsufficientCapacity と関連するキャパシティエラー
### 一般的な原因
これらのエラーは、インスタンスリクエストに対応する十分な容量が AWS にない場合に発生します。この場合、リクエストされたアベイラビリティーゾーンのインスタンス容量、アドレス容量、ボリューム容量などが不足してる可能性があります。
### 解決策
1. キャパシティプロバイダーで複数のサブネットを設定して、別のアベイラビリティーゾーンでインスタンスを起動してみてください。
1. 使用可能な容量が多い可能性のある別のインスタンスタイプを使用することを検討してください。
1. キャパシティの可用性は頻繁に変化しますので、オペレーションを待機して再試行します。
1. 永続的な容量が必要な場合は、リザーブドインスタンスまたは Savings Plans の使用を検討してください。
## UnauthorizedOperation エラー
### 一般的な原因
このエラーは、Amazon ECS サービスに Amazon EC2 オペレーションを実行した場合や、IAM ロールを渡すために必要なアクセス許可がない場合に発生します。一般的なシナリオとして、インスタンスプロファイルの `ec2:RunInstances` アクセス許可または `iam:PassRole` アクセス許可が不足していることが挙げられます。
### 解決策
1. Amazon ECS インフラストラクチャロールに、Amazon EC2 インスタンスの起動に必要なアクセス許可があることを確認します。
1. インフラストラクチャロールに、Amazon ECS マネージドインスタンスで使用されるインスタンスプロファイルに対する `iam:PassRole` アクセス許可があることを確認します。
1. 特定のアクセス許可の詳細については、CloudTrail のエンコードされた認可失敗メッセージを確認してください。
1. ロールポリシーを更新して、不足しているアクセス許可 (エラーメッセージで確認する) を含めます。
## キャパシティの待機中にタスクがタイムアウトしました
### 一般的な原因
このエラーは、インスタンスの起動とクラスターへの登録に想定以上の時間を要する場合に発生します。これは、Amazon EC2 の容量の制約、インスタンスの起動の失敗、ネットワーク接続の問題が原因で発生する可能性があります。
### 解決策
1. 進行中の問題がないか、リージョンの Amazon EC2 サービスの健全性を確認します。
1. サブネットに十分な IP アドレスがあることを確認します。
1. セキュリティグループで Amazon ECS エージェント通信に必要なトラフィックを許可していることを確認します。
1. キャパシティの可用性を向上させるには、複数のアベイラビリティーゾーンを使用することを検討してください。
1. キャパシティの制約は一時的である場合が多いため、タスク起動オペレーションを再試行します。
## ネットワーク設定エラー
### 一般的な原因
これらのエラーは、タスクのネットワーク要件と、キャパシティプロバイダーのネットワーク設定の間に不一致がある場合に発生します (VPC の不一致やネットワーク設定の不足など)。
### 解決策
1. キャパシティプロバイダーが正しい VPC とサブネットで設定されていることを確認します。
1. セキュリティグループとサブネットが同じ VPC に属していることを確認します。
1. タスク定義のネットワーク設定にキャパシティプロバイダーとの互換性があることを確認します。
1. 正しいネットワーク設定でキャパシティプロバイダー設定を更新します。
## インスタンスがスタックしているためキャパシティプロバイダーを削除できません
### 一般的な原因
これらのエラーは、Amazon ECS マネージドインスタンスが `ACTIVE` または `DRAINING` の状態でスタックしているが、インスタンスに実行中のタスクがない場合に発生します。
### 解決策
キャパシティプロバイダーの削除を続行できるようにするには、次のコマンドを使用して、スタックしているインスタンスを強制的に登録解除します。
```
aws ecs deregister-container-instance \
--cluster arn:aws:ecs:us-east-1:111122223333:cluster/MyCluster \
--container-instance arn:aws:ecs:us-east-1:111122223333:container-instance/a1b2c3d4-5678-90ab-cdef-11111EXAMPLE \
--force
```
# Amazon ECS Amazon ECS マネージドインスタンスエラーのトラブルシューティング
Amazon ECS マネージドインスタンスのエラーメッセージと、エラーを修正するために実行できるアクションの一部を以下に示します。
## クラスター名のない Amazon ECS マネージドインスタンスプロバイダーはサポートされません
このエラーは、Amazon ECS マネージドインスタンスプロバイダーのパラメータを使用して、クラスターフィールドなしでキャパシティプロバイダーを作成しようとすると発生します。
この問題を解決するには、キャパシティプロバイダーの作成時に有効なクラスター名を指定します。
## Amazon ECS マネージドインスタンスキャパシティプロバイダーの作成には Amazon ECS マネージドインスタンスプロバイダーの詳細が必要です
このエラーは、Amazon ECS マネージドインスタンスプロバイダーで、実際のオブジェクトを指定せずにキャパシティプロバイダーを作成しようとした場合に表示されます。
この問題を修正するには、有効な Amazon ECS マネージドインスタンスプロバイダーの詳細を指定して、もう一度試してください。
## Amazon ECS マネージドインスタンスキャパシティプロバイダーはインスタンスプロファイルを指定する必要があります
このエラーは、Amazon ECS マネージドインスタンスプロバイダーで、Ec2InstanceProfile を指定せずにキャパシティプロバイダーを作成しようとした場合に表示されます。
これを解決するには、Amazon ECS マネージドインスタンスキャパシティプロバイダーの有効な EC2 インスタンスプロファイルを指定します。詳細については、「[Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md)」を参照してください。
## Amazon ECS マネージドインスタンスキャパシティプロバイダーは InfrastructureRole を指定する必要があります
このメッセージは、Amazon ECS マネージドインスタンスプロバイダーで、InfrastructureRole を指定せずにキャパシティプロバイダーを作成しようとした場合に表示されます。
これを修正するには、Amazon ECS マネージドインスタンスキャパシティプロバイダーの有効なインフラストラクチャロールを指定します。詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。
## Amazon ECS マネージドインスタンスキャパシティプロバイダーはネットワーク設定を指定する必要があります
このエラーは、Amazon ECS マネージドインスタンスプロバイダーで、ネットワーク設定を指定せずにキャパシティプロバイダーを作成しようとした場合に発生します。
これを解決するには、Amazon ECS マネージドインスタンスキャパシティプロバイダーに、空のサブネットがない有効なネットワーク設定を指定します。詳細については、「[Amazon ECS マネージドインスタンスの Amazon ECS タスクネットワーキング](managed-instance-networking.md)」を参照してください。
## Amazon ECS マネージドインスタンスキャパシティプロバイダーに指定されたインスタンス要件を満たすインスタンスタイプがありません
これは、Amazon ECS マネージドインスタンスプロバイダーでキャパシティプロバイダーを作成しようとしたが、インスタンス要件を満たす EC2 インスタンスタイプがない場合に発生します。
これに対処するには、使用可能な EC2 インスタンスタイプに合わせてインスタンス要件を確認し、調整します。
## 指定されたインフラストラクチャロール ARN が無効です
このエラーは、InfrastructureRole が特定の ARN 形式に従っていない場合に発生します。
必要な形式は `arn:partition:iam::account-id:role/role-name` です。有効なロール ARN を指定して、もう一度試してください。詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。
## 指定されたインスタンスプロファイルロール ARN が無効です
このエラーは、インスタンスプロファイルが特定の ARN 形式に従っていない場合に発生します。
必要な形式は `arn:partition:iam::account-id:instance-profile/profile-name` です。有効なロール ARN を指定して、もう一度試してください。詳細については、「[Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md)」を参照してください。
## 指定されたセキュリティグループ ID が無効です
このエラーは、セキュリティグループ ID が特定の形式に従っていない場合に発生します。
想定される形式は、`sg-xxxxxxxx` または `sg-xxxxxxxxxxxxxxxxxx` (「sg–」以降は文字 (小文字) と数字を含む 8 文字または 17 文字) です。セキュリティグループ ID を指定して、もう一度試してください。
## 指定されたサブネット ID が無効です
このエラーは、サブネット ID が特定の形式に従っていない場合に発生します。
想定される形式は、`subnet-xxxxxxxx` または `subnet-xxxxxxxxxxxxxxxxxx` (「subnet–」以降は文字 (小文字) と数字を含む 8 文字または 17 文字) です。サブネット ID を指定して、もう一度試してください。
## Amazon ECS マネージドインスタンスキャパシティプロバイダーはサブネットが空ではないネットワーク設定を指定する必要があります
このエラーは、ネットワーク設定のサブネットが空の状態のまま Amazon ECS マネージドインスタンスプロバイダーでキャパシティプロバイダーを作成しようとすると発生します。
これを解決するには、Amazon ECS マネージドインスタンスキャパシティプロバイダーに、空のサブネットがない有効なネットワーク設定を指定します。
## Amazon ECS マネージドインスタンスキャパシティプロバイダーのタグ数は最大許容値を超えることはできません
このエラーは、タグの最大許容数 (45) を超えるキャパシティプロバイダーを作成しようとすると発生します。
これを解決するには、タグの数を 45 以下に減らして、もう一度試してください。
## propagateTags の値が無効です
このエラーは、無効な propagateTags 値を持つキャパシティプロバイダーを作成しようとすると発生します。
値は有効な propagateTags 値のいずれかである必要があります。有効な値を指定して、もう一度試してください。
## 指定されたキャパシティプロバイダーがクラスタースコープに既に存在します
このエラーは、クラスター名なしで Amazon ECS マネージドインスタンスキャパシティプロバイダーを作成、更新、削除しようとした際に、既存のクラスタースコープにキャパシティプロバイダーが存在する場合に発生します。
キャパシティプロバイダーの設定を変更または削除するには、クラスターパラメータを使用して、キャパシティプロバイダーを更新または削除します。
## 指定されたキャパシティプロバイダーがアカウントまたは別のクラスターに既に存在します
このエラーは、クラスターフィールドを使用して Amazon ECS マネージドインスタンスキャパシティプロバイダーを作成、更新、削除しようとした際に、既存のアカウントスコープのキャパシティプロバイダーか、別のクラスター用の既存のクラスタースコープのキャパシティプロバイダーが存在する場合に発生します。
これを解決するには、別のキャパシティプロバイダー名を使用するか、既存のキャパシティプロバイダーを操作します。
## キャパシティプロバイダーのアクティブなクラスター名がリクエストのクラスター名と一致しません
このエラーは、キャパシティプロバイダーのアクティブなクラスター名が、リクエストで指定されたクラスター名と一致しない場合に発生します。
リクエストのクラスター名が、関連付けられたキャパシティプロバイダーのクラスターと一致していることを確認します。
## キャパシティプロバイダーが、Amazon ECS マネージドインスタンスのキャパシティプロバイダーではありません
このエラーは、Amazon ECS マネージドインスタンスのキャパシティプロバイダーが必要な場面で、それ以外のキャパシティプロバイダーを使おうとすると発生します。
リクエストで、有効な Amazon ECS マネージドインスタンスキャパシティプロバイダーを使用していることを確認します。
## CapacityProvider 名は空白にできません
このエラーは、キャパシティプロバイダー名を指定せずにキャパシティプロバイダーを作成しようとすると発生します。
有効なキャパシティプロバイダー名を指定して、もう一度試してください。
## キャパシティプロバイダーの更新には名前が必要です
このエラーは、キャパシティプロバイダー名を指定せずにキャパシティプロバイダーを更新しようとすると発生します。
有効な名前を使用してもう一度試してください。
## タグは null にできません。また、null 要素を含むこともできません
このエラーは、キャパシティプロバイダーに null 値をタグ付けしようとすると発生します。
すべてのタグ値が正しく指定され、null ではないことを確認します。
# Amazon ECS での API エラーの原因
Amazon ECS API、コンソール、または AWS CLI でトリガーした API アクションが `failures` エラーメッセージを表示して終了した場合、以下が原因のトラブルシューティングに役立つことがあります。失敗すると、その理由と、その失敗に関連付けられたリソースの Amazon リソースネーム (ARN) が返されます。
多くのリソースはリージョン固有であるため、コンソールを使用するときは、リソースに正しいリージョンを設定してください。AWS CLI コマンドを使用するときは、AWS CLI コマンドが `--region region` パラメータで正しいリージョンに送信されるようにします。
`Failure`データ型の構造の詳細については、「*Amazon Elastic Container サービス API リファレンス*」の[[Failure(失敗)](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Failure.html)]を参照してください。
次の内容は、API コマンド実行時に受信する場合がある障害メッセージの例です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/api_failures_messages.html)
**注記**
ここで説明した障害シナリオの他に、API 操作が例外によってエラーとなり、エラー応答が発生することもあります。このような例外のリストについては、「[一般的なエラー](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/CommonErrors.html)」を参照してください。
# Amazon Q Developer のトラブルシューティング
Amazon ECS コンソールで [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) を使用すると、Amazon ECS リソースに関する問題の診断と解決に役立ちます。コンテナ、タスク、サービス、デプロイ、タスク定義に関する特定のエラーとステータスメッセージについては、コンソールに **[Amazon Q Developer を使用して検査する]** オプションが表示されます。このオプションを選択すると、Amazon Q Developer が問題をコンテキストで分析し、考えられる原因と修復手順を提案します。
## 必要なアクセス許可
+ クラスター、サービス、タスク、タスク定義など、トラブルシューティング対象の Amazon ECS リソースを表示するアクセス許可。
+ コンソールで [Amazon Q Developer を使用するアクセス許可](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/security_iam_permissions.html)。
+ (推奨) 次のような関連するログとメトリクスを表示するアクセス許可。
+ CloudWatch Logs
+ CloudWatch
## 手順
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) でコンソールを開きます。
1. トラブルシューティングするリソースを決定します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/troubleshooting-with-Q.html)
1. [リソース詳細] ページで、問題を説明する状態または健全性の理由を見つけます。
1. 状態の理由をクリックして、ポップ画面を開きます。
1. 可能な場合は、**[Amazon Q Developer を使用して検査する]** を選択します。
1. Amazon Q Developer が提供する説明と、推奨される修復手順を確認します。環境に応じて、設定または運用上の変更を適用します。
## 考慮事項
Amazon ECS で Amazon Q Developer を使用する場合は、次の点を考慮してください。
+ **ボタンの可用性** – [Amazon Q Developer を使用して検査する] ボタンは、問題発生の可能性があるリソースに対してのみ表示されます。このオプションは、正常なリソースでは使用できません。
+ **読み取り専用オペレーション** – Amazon Q Developer 統合では、読み取りオペレーションのみを実行します。変更アクションや書き込みアクションは実行しません。
+ **クロスリージョン処理** – Amazon Q Developer は、AI を活用した分析を提供するために、AWS リージョン間でデータを処理することがあります。詳細については、「[Amazon Q Developer でのクロスリージョン処理](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/cross-region-processing.html)」を参照してください。
+ **コンソール専用** – この統合はコンソールでのみ使用できます。AWS CLI、AWS API、Infrastructure as Code ツールでは使用できません。
## 詳細情報
Amazon Q Developer の操作方法の詳細については、「[AWS に関する Amazon Q Developer とのチャット](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html)」を参照してください。