RUNNABLE 状態でジョブが止まる - AWS Batch

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

RUNNABLE 状態でジョブが止まる

コンピューティング環境にコンピューティングリソースがあるのに、ジョブが RUNNABLE の状態よりも先に進まないとします。その場合、ジョブがコンピューティングリソースに配置されるのが何かの原因で妨げられ、ジョブキューがブロックされている可能性があります。ここでは、ジョブが順番を待っているのか、スタックしてキューをブロックしているのか確認する方法を説明します。

が、先頭にRUNNABLEジョブがあり、キューをブロックしていること AWS Batch を検出すると、Amazon CloudWatch Events から理由付きのリソース: ジョブキューのブロックイベントイベントを受け取ります。同じ理由が、 ListJobsおよび API DescribeJobs 呼び出しの一部として statusReasonフィールドに更新されます。

オプションで、 CreateJobQueue および API UpdateJobQueue アクションを使用して 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および API DescribeJobs アクションから返されるメッセージを提供します。また、これらは jobStateLimitActions.statusReason パラメータに定義できる値と同じです。

  1. 理由: 接続されているすべてのコンピューティング環境で、容量不足のエラーが出ています。リクエストされると、 は容量不足エラーが発生した 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

    [Note:] (メモ:)

    1. AWS Batch サービスロールには、この検出が機能するためのautoscaling:DescribeScalingActivitiesアクセス許可が必要です。のサービスにリンクされたロールのアクセス許可 AWS Batch サービスにリンクされたロール (SLR) または AWS 管理ポリシー: AWSBatchServiceRole ポリシーマネージドポリシーを使用する場合、アクセス許可ポリシーが更新されるため、何もする必要はありません。

    2. SLR または 管理ポリシーを使用する場合は、 でブロックされたジョブキューイベントと更新されたジョブステータスを受信できるように、 autoscaling:DescribeScalingActivitiesおよび アクセスec2:DescribeSpotFleetRequestHistory許可を追加する必要がありますRUNNABLE。さらに、 AWS Batch では、ジョブキューで設定されていても jobStateTimeLimitActions パラメータを使用して cancellation アクションを実行するため、これらのアクセス許可が必要です。

    3. マルチノード並列 (MNP) ジョブの場合、アタッチされた優先度の高い Amazon EC2 コンピューティング環境でinsufficient capacityエラーが発生すると、優先度の低いコンピューティング環境でこのエラーが発生した場合でもキューがブロックされます。

  2. 理由: すべてのコンピューティング環境に、ジョブ要件よりも小さい 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

  3. 理由: ジョブの要件を満たすインスタンスが、どのコンピューティング環境にもありません。ジョブがリソースをリクエストすると、 はアタッチされたコンピューティング環境が受信ジョブに対応できないことを 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

  4. 理由: すべてのコンピューティング環境にサービスロールの問題があります。これを解決するには、サービスロールのアクセス許可を AWS の 管理ポリシー AWS Batch と比較して、ギャップがあれば対処します。注：このエラーを解決するために jobStateTimeLimitActionsパラメータを使用してプログラム可能なアクションを設定することはできません。

    同様のエラーを避けるため、のサービスにリンクされたロールのアクセス許可 AWS Batch を使用するのがベストプラクティスです。

    手動でジョブをキャンセルするか、statusReason に jobStateTimeLimitActions パラメータを設定してキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。サービスロールの問題をすべて解決しないと、次のジョブもブロックされる可能性があります。この問題は手動で調査して解決することをお勧めします。

    • ジョブがスタックしているときの statusReason メッセージ: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

  5. 理由: すべてのコンピューティング環境が無効です。詳細については、「INVALIDコンピューティング環境」を参照してください。注意: このエラーを解決するために、jobStateTimeLimitActions パラメータを使用してプログラム可能なアクションを設定することはできません。

    • ジョブがスタックしているときの statusReason メッセージ: ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  6. 理由： AWS Batch がブロックされたキューを検出しましたが、理由を特定できません。注意: このエラーを解決するために、jobStateTimeLimitActions パラメータを使用してプログラム可能なアクションを設定することはできません。トラブルシューティングの詳細については、 re:Post の「 でジョブ AWS Batch が RUNNABLE にスタックする理由 AWS」を参照してください。

    • ジョブがスタックしているときの statusReason メッセージ: UNDETERMINED - Batch job is blocked, root cause is undetermined.

CloudWatch Events からイベントを受信しなかった場合や、不明な理由イベントを受け取った場合は、この問題の一般的な原因をいくつか次に示します。

awslogs のログドライバーが、コンピューティングリソースで設定されていない

AWS Batch ジョブはログ情報を CloudWatch Logs に送信します。この機能を有効にするには、awslogsのログドライバーを使用するようにコンピューティングリソースを設定する必要があります。コンピューティングリソースの AMI を Amazon Word 最適化 AMIECS (または Amazon Linux) に基づいているとします。次に、このドライバーはデフォルトにより ecs-initのパッケージに登録されます。ここで、別の基本AMIを使用するとします。次に、Amazon ECS コンテナエージェントの起動時に、 ECS_AVAILABLE_LOGGING_DRIVERS 環境変数でログドライバーが使用可能なログドライバーとしてawslogs指定されていることを確認する必要があります。詳細については、コンピューティングリソースの AMI 仕様およびチュートリアル: コンピューティングリソース AMI を作成するを参照してください。

リソースが不十分である

ジョブ定義で、コンピューティングリソースが割り当てることができるよりも多くの CPU またはメモリリソースが指定されている場合、ジョブは配置されません。たとえば、ジョブが 4 GiB のメモリを指定し、コンピューティングリソースで使用できるのがそれ以下の場合を考えます。そうなると、そのジョブをそれらのコンピューティングリソースに配置できない場合があります。この場合、ジョブ定義に指定するメモリを減らすか、あるいは環境のコンピューティングリソースを追加する必要があります。一部のメモリは、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に予約されています。詳細については、「コンピューティングリソースメモリの管理」を参照してください。

コンピューティングリソースのインターネットアクセスがない

コンピューティングリソースは、Amazon ECS サービスエンドポイントと通信するためのアクセスが必要です。これは、インターフェイスの VPC エンドポイントまたはを介して、パブリック IP アドレスを持つリソースを計算できます。

インターフェイス VPC エンドポイントの詳細については、「Amazon Elastic Container Service デベロッパーガイド」の「Amazon ECS Interface VPC Endpoints (AWS PrivateLink）」を参照してください。

インターフェイス VPC エンドポイントが設定されておらず、コンピューティングリソースにパブリック IP アドレスがない場合は、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、「Amazon NAT ユーザーガイド」の「Word ゲートウェイ「」を参照してください。 VPC 詳細については、「チュートリアル: VPC を作成する」を参照してください。

Amazon EC2 インスタンスの制限に達しました

アカウントが で起動できる Amazon EC2 インスタンスの数 AWS リージョン は、EC2 インスタンスのクォータによって決まります。特定のインスタンスタイプには a per-instance-type クォータもあります。制限の引き上げをリクエストする方法など、アカウントの Amazon EC2 インスタンスクォータの詳細については、「Amazon EC2 ユーザーガイド」の「Amazon Word サービスの制限」を参照してください。 EC2

Amazon ECS コンテナエージェントがインストールされていない

Amazon ECS コンテナエージェントは、 でジョブ AWS Batch を実行するために Amazon マシンイメージ (AMI) にインストールする必要があります。Amazon ECS コンテナエージェントは、Amazon ECS 最適化 AMIs にデフォルトでインストールされます。Amazon ECS コンテナエージェントの詳細については、「Amazon Elastic Container Service デベロッパーガイド」の「Amazon ECS コンテナエージェント」を参照してください。

詳細については、 re:Post の AWS Batch 「ジョブがRUNNABLEステータスのままになるのはなぜですか？」を参照してください。