翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
コンピューティング環境にコンピューティングリソースがあるのに、ジョブが RUNNABLE
の状態よりも先に進まないとします。その場合、ジョブがコンピューティングリソースに配置されるのが何かの原因で妨げられ、ジョブキューがブロックされている可能性があります。ここでは、ジョブが順番を待っているのか、スタックしてキューをブロックしているのか確認する方法を説明します。
が先頭にRUNNABLE
ジョブがあり、キューをブロックしていること AWS Batch を検出すると、Amazon CloudWatch Events から の理由を含むリソース: ジョブキューのブロックイベントイベントを受け取ります。同じ理由が、ListJobs
と DescribeJobs
の API コールの一部として statusReason
フィールドに挿入されます。
必要に応じて、CreateJobQueue
と UpdateJobQueue
の API アクションを使用して jobStateTimeLimitActions
パラメータを設定できます。
注記
現在、jobStateLimitActions.action
で使用できるアクションはジョブのキャンセルのみです。
jobStateTimeLimitActions
パラメータは、特定の状態のジョブに対して が AWS Batch 実行する一連のアクションを指定するために使用されます。maxTimeSeconds
フィールドを使用して時間のしきい値を秒単位で設定できます。
ジョブが定義された RUNNABLE
の状態にある場合statusReason
、 maxTimeSeconds
は経過後に指定されたアクションを実行 AWS Batch します。
例えば、jobStateTimeLimitActions
パラメータを使用すると、ジョブが十分な容量を利用できるようになるまで、RUNNABLE
状態で最大 4 時間待機するように設定できます。これを行うには、ジョブがキャンセルされて次のジョブがジョブキューの先頭に進む前に、statusReason
を CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY
に、maxTimeSeconds
を 144000 に設定します。
以下は、ジョブキューがブロックされていることを が検出 AWS Batch したときに が提供する理由です。このリストでは ListJobs
と DescribeJobs
の API アクションから返されるメッセージを示しています。また、これらは jobStateLimitActions.statusReason
パラメータに定義できる値と同じです。
-
理由: 接続されているすべてのコンピューティング環境で、容量不足のエラーが出ています。リクエストされると、 は容量不足エラーが発生した Amazon EC2 インスタンス AWS Batch を検出します。ジョブを手動でキャンセルすると、後続のジョブはキューの先頭に移動できますが、サービスロールの問題を解決せずに (複数可)、次のジョブもブロックされる可能性があります。この問題については、手動で調査して解決することをお勧めします。
-
ジョブがスタックしているときの
statusReason
メッセージ:CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]
-
jobStateTimeLimitActions
に使用されるreason
:CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY
-
ジョブがキャンセルされた後の
statusReason
メッセージ:Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY
メモ:
-
AWS Batch サービスロールには、この検出が機能するための
autoscaling:DescribeScalingActivities
アクセス許可が必要です。のサービスにリンクされたロールのアクセス許可 AWS Batch のサービスにリンクされたロール (SLR) または AWS マネージドポリシー: AWSBatchServiceRole ポリシー の管理ポリシーを使用する場合、アクセス許可ポリシーが更新されるためアクションは必要ありません。 -
SLR または管理ポリシーを使用する場合は、
autoscaling:DescribeScalingActivities
とec2:DescribeSpotFleetRequestHistory
のアクセス許可を追加して、RUNNABLE
のときにブロックされたジョブキューイベントと更新されたジョブステータスを受信できるようにする必要があります。さらに、 AWS Batch では、ジョブキューで設定されていてもjobStateTimeLimitActions
パラメータを使用してcancellation
アクションを実行するため、これらのアクセス許可が必要です。 -
マルチノード並列 (MNP) ジョブの場合、アタッチされた高優先度の Amazon EC2 コンピューティング環境で
insufficient capacity
エラーが発生すると、優先度の低いコンピューティング環境でこのエラーが発生してもキューがブロックされます。
-
-
理由: すべてのコンピューティング環境に、ジョブ要件よりも小さい
maxvCpus
パラメータがあります。手動でジョブをキャンセルするか、statusReason
にjobStateTimeLimitActions
パラメータを設定してキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。必要に応じて、プライマリコンピューティング環境のmaxvCpus
パラメータを増やして、ブロックされたジョブのニーズを満たすことができます。-
ジョブがスタックしているときの
statusReason
メッセージ:MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.
-
jobStateTimeLimitActions
に使用されるreason
:MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE
-
ジョブがキャンセルされた後の
statusReason
メッセージ:Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE
-
-
理由: ジョブの要件を満たすインスタンスが、どのコンピューティング環境にもありません。ジョブがリソースをリクエストすると、 はアタッチされたコンピューティング環境が受信ジョブに対応できないことを AWS Batch 検出します。手動でジョブをキャンセルするか、
statusReason
にjobStateTimeLimitActions
パラメータを設定してキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。必要に応じて、コンピューティング環境で許可されるインスタンスタイプを再定義して、必要なジョブリソースを追加できます。-
ジョブがスタックしているときの
statusReason
メッセージ:MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT - The job resource requirement (vCPU/memory/GPU) is higher than that can be met by the CE(s) attached to the job queue.
-
jobStateTimeLimitActions
に使用されるreason
:MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT
-
ジョブがキャンセルされた後の
statusReason
メッセージ:Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT
-
-
理由: すべてのコンピューティング環境にサービスロールの問題があります。これを解決するには、サービスロールのアクセス許可を AWS の マネージドポリシー AWS Batch と比較して、ギャップがあれば対処します。注: このエラーを解決するために
jobStateTimeLimitActions
パラメータを使用してプログラム可能なアクションを設定することはできません。同様のエラーを避けるため、のサービスにリンクされたロールのアクセス許可 AWS Batch を使用するのがベストプラクティスです。
手動でジョブをキャンセルするか、
statusReason
にjobStateTimeLimitActions
パラメータを設定してキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。サービスロールの問題をすべて解決しないと、次のジョブもブロックされる可能性があります。この問題は手動で調査して解決することをお勧めします。-
ジョブがスタックしているときの
statusReason
メッセージ:MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.
-
-
理由: すべてのコンピューティング環境が無効です。詳細については、「INVALIDコンピューティング環境」を参照してください。注意: このエラーを解決するために、
jobStateTimeLimitActions
パラメータを使用してプログラム可能なアクションを設定することはできません。-
ジョブがスタックしているときの
statusReason
メッセージ:ACTION_REQUIRED - CE(s) associated with the job queue are invalid.
-
-
理由: AWS Batch はブロックされたキューを検出しましたが、理由を特定できません。注意: このエラーを解決するために、
jobStateTimeLimitActions
パラメータを使用してプログラム可能なアクションを設定することはできません。トラブルシューティングの詳細については、re:Post の「AWSAWS Batch ジョブが [RUNNABLE] ステータスでスタックしているのはなぜですか?」を参照してください。 -
ジョブがスタックしているときの
statusReason
メッセージ:UNDETERMINED - Batch job is blocked, root cause is undetermined.
-
CloudWatch Events からイベントを受信しなかった場合、または原因不明のイベントを受信した場合、一般に以下のようないくつかの原因が考えられます。
awslogs
のログドライバーが、コンピューティングリソースで設定されていない-
AWS Batch ジョブはログ情報を CloudWatch Logs に送信します。この機能を有効にするには、
awslogs
のログドライバーを使用するようにコンピューティングリソースを設定する必要があります。コンピューティングリソース AMI を、Amazon ECSに最適化されたAMI (または Amazon Linux) に基づいて作成すると仮定します。次に、このドライバーはデフォルトによりecs-init
のパッケージに登録されます。ここで、別のベース AMI を使用すると仮定します。別の基本 AMI を使用する場合、Amazon ECS コンテナエージェントが開始するときに、awslogs
ログドライバーが、ECS_AVAILABLE_LOGGING_DRIVERS
環境変数で使用可能なログドライバーとして指定されていることを検証する必要があります。詳細については、コンピューティングリソースの AMI 仕様 およびチュートリアル: コンピューティングリソース AMI を作成するを参照してください。 - リソースが不十分である
-
コンピューティングリソースが割り当てることができるリソースを超えた CPU、またはメモリリソースがジョブ定義に指定されている場合、ジョブは配置されません。たとえば、ジョブが 4 GiB のメモリを指定し、コンピューティングリソースで使用できるのがそれ以下の場合を考えます。そうなると、そのジョブをそれらのコンピューティングリソースに配置できない場合があります。この場合、ジョブ定義に指定するメモリを減らすか、あるいは環境のコンピューティングリソースを追加する必要があります。一部のメモリは、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に予約されています。詳細については、コンピューティングリソースメモリの管理を参照してください。
- コンピューティングリソースのインターネットアクセスがない
コンピューティングリソースには、Amazon ECS サービスエンドポイントと通信するために外部ネットワークアクセスが必要です。これは、インターフェイス VPC エンドポイントを介して、またはパブリック IP アドレスを持つコンピュートリソースを通じて可能になります。
インターフェイス VPC エンドポイントの詳細については、Amazon Elastic Container Service 開発者ガイドのAmazon ECS インターフェイス VPC エンドポイント (AWS PrivateLink)を参照してください。
インターフェイス VPC エンドポイントが設定されておらず、コンピューティングリソースがパブリック IP アドレスを持たない場合は、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、Amazon VPC ユーザーガイドのNAT ゲートウェイを参照してください。詳細については、チュートリアル: VPC を作成するを参照してください。
- Amazon EC2 インスタンス制限に達している
-
アカウントが で起動できる Amazon EC2 インスタンスの数 AWS リージョン は、EC2 インスタンスのクォータによって決まります。特定のインスタンスタイプには、インスタンスタイプごとの制限もあります。ユーザーのアカウントの Amazon EC2 インスタンスクォータの詳細 (制限の引き上げをリクエストする方法を含む) については、「Amazon EC2 ユーザーガイド」の「Amazon EC2 の Service Quotas」を参照してください。
- Amazon ECS コンテナエージェントが存在しない
-
AWS Batch ジョブを実行するには、Amazon ECS コンテナエージェントは Amazon マシンイメージ (AMI) にインストールされる必要があります。Amazon ECS コンテナエージェントが Amazon ECSに最適化 AMI にデフォルトでインストールされます。詳細については、Amazon ECS コンテナエージェントの構成 を参照してくださいAmazon Elastic Container Service デベロッパーガイドにあります。
詳細については、re:Post の AWS Batch 「ジョブがRUNNABLE
ステータスのままになるのはなぜですか?