AWS Batch ジョブが [RUNNABLE] ステータスでスタックしているのはなぜですか?

簡単な説明

ジョブに未解決の依存関係がなく、ホストにスケジュールされる準備ができている場合、AWS Batch はジョブを [RUNNABLE] ステータスに移行します。[RUNNABLE] ジョブは、ジョブのキューにマップされるコンピューティング環境のいずれかで十分なリソースが使用可能になるとすぐに開始されます。

ジョブを実行するために必要なリソースが利用できない場合、ジョブは無期限に [RUNNABLE] ステータスのままになる可能性があります。詳細については、「Jobs stuck in a RUNNABLE status」を参照してください。

[RUNNABLE] ステータスでスタックしている AWS Batch ジョブをトラブルシューティングするには、AWSSupport-TroubleshootAWSBatchJob runbook を使用してください。次に、[Outputs] セクションを参照して、問題の考えられる原因と解決手順を確認してください。

**注:**この記事では、Amazon Elastic Compute Cloud (Amazon EC2) 上の Amazon Elastic Container Service (Amazon ECS) と AWS Fargate 上の Amazon ECS のトラブルシューティングについて説明します。Amazon Elastic Kubernetes Service (Amazon EKS) 上の AWS Batch をトラブルシューティングするには、「Amazon EKS における AWS Batch」を参照してください。

解決策

AWSSupport-TroubleshootAWSBatchJob SAW ランブックを使用する

AWS サポートオートメーションワークフロー (SAW) を使用して、このトラブルシューティングプロセスを自動化します。AWSSupport-Troubleshoot-AWSBatchJob ランブックを使用するには、「How can I use a SAW runbook to troubleshoot my AWS Batch job stuck in the RUNNABLE status?」を参照してください。

このランブックが問題の特定に役立たない場合は、以下のセクションを参照して、スタックしたジョブを手動でトラブルシューティングしてください。

コンピューティング環境に、ジョブを実行するのに十分なリソースがあることを確認する

1.    AWS バッチコンソールを開きます。

2.    **[Dashboard]**を選択します。

3.    [Job queue overview] ペインの [RUNNABLE] 列で、[RUNNABLE] ステータスのままになっているジョブを選択します。[Job details] ページが表示されます。

4.    [Job details] ページの [コンテナ] セクションで、[vCPU]、[Memory]、[GPUs] の値を確認します。ステップ 9～10 を完了するには、これらの値が必要です。

5.    どのコンピューティング環境でもジョブが実行される可能性があるため、[Job queues] ページでジョブキューを選択し、関連付けられているコンピューティング環境を確認します。次に、各コンピューティング環境について、ステップ 6～10 を繰り返します。

6.    [Compute Environments] の ページで、コンピューティング環境を選択してその許可を確認します。

7.    コンピューティング環境の [Status] 列が **[VALID] に設定されていることを確認します。**また、環境に関連付けられているサービスロールに、すべての必要な許可が付与されていることを確認してください。

注:断続的または一時的なエラーがある場合、コンピューティング環境の [Status] が[VALID] から [INVALID] に変わるまでに数分かかることがあります。

8.    [State] 列が [ENABLED] に設定されていることを確認します。

9.    [Max vCpus] の値が、AWS Batch でジョブを実行するために [Desired vCPUs] の数を増やすのに十分な大きさであることを確認します。

注: AWS Fargate コンピューティング環境を使用している場合は、「Verify the network and security settings of the compute environment」セクションを参照してください。

10.    [Desired vCPU] の値が、ジョブが実行する必要がある vCPU 以上であることを確認します。

[Desired vCPUs] が [0] の場合は、Amazon EC2 インスタンスタイプで使用できるメモリと CPU リソースの量を確認します。

または

[Desired vCPU] が [0] より大きい場合、またはジョブがまだ [RUNNABLE] の場合は、次のセクションのステップを実行します。

**重要:**コンピューティング環境の少なくとも 1 つのインスタンス対応では、ジョブが指定したメモリより大きいメモリが必要です。また、インスタンスタイプに、ジョブが指定した以上の CPU リソースが必要です。少なくとも 1 つのインスタンスタイプに、ジョブを実行するのに十分なメモリまたは CPU リソースがない場合は、ジョブをキャンセルします。次に、必要な CPU またはメモリが少ない新しいジョブを実行します。または、ジョブを実行するのに十分なリソースを持つ新しいコンピューティング環境を作成してから、そのジョブを適切なジョブキューに割り当てます。

コンピューティング環境にインスタンスがあり、そのインスタンスがジョブを実行できることを確認する

ジョブを実行する必要があると特定したコンピューティング環境では、次の手順を実行します。

1.    Amazon ECS コンソールを開きます。

2.    ナビゲーションペインで、[Clusters] を選択します。次に、ジョブを含むクラスターを選択します。

一般的な ECS のトラブルシューティングの手順については、「Amazon ECS トラブルシューティング」を参照してください。

注:クラスターの名前は、コンピューティング環境の名前で始まります。その後に_Batch_ と数字と文字のランダムなハッシュが続きます。

3.    [ECS インスタンス] ビューを選択します。次に、コンテナインスタンスがジョブを実行できることを確認します。

4.    ジョブを実行するために使用できるコンテナインスタンスがクラスターにある場合は、Docker デーモン のステータスを確認してください。その後、Amazon ECS コンテナエージェントのステータスを確認します。

**注:**詳細については、「切断された Amazon ECS エージェントのトラブルシューティングするにはどうすればよいですか?」を参照してください。

Amazon ECS クラスターにインスタンスがない場合は、ご利用のコンピューティング環境でインスタンスが作成できることを確認します。インスタンスを作成できることを確認するには、ご利用のコンピューティング環境に基づいて以下のいずれかの手順を実行します。

インスタンスがオンデマンドコンピューティング環境で作成できることを確認するには:

1.    Amazon EC2 コンソールを開きます。

2.    左のナビゲーションペインで、[Auto Scaling グループ] を選択します。

3.    [Filter] で、コンピューティング環境の名前を入力します。

**注:**Amazon EC2 は、同じコンピューティング環境に対して複数の Auto Scaling グループを作成することができます。

4.    Auto Scaling グループごとに、[Activity History] ビューを選択します。次に、ブロッキングの問題がないか確認します。

インスタンスの起動をブロックする何らかの問題がある場合は、[Status] に [Unsuccessful] と表示されます。

たとえば、アカウントのインスタンスの数が最大に達した場合、Amazon EC2 は次のようなメッセージを返す可能性があります。

Launching a new EC2 instance. Status Reason: Your quota allows for 0 more running instance(s). You requested at least 1. Launching EC2 instance failed.

このイベントには、ジョブを送信した時点のタイムスタンプが UTC で表示されます。

At 2018-09-03T05:54:30Z a user request update of AutoScalingGroup constraints to min: 0, max: 1, desired: 1 changing the desired capacity from 0 to 1.
At 2018-09-03T05:54:52Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1.

**注:**AWS Batch はユーザーに代わってインスタンスをリクエストします。Auto Scaling グループを手動で変更すると、コンピューティング環境が無効になる可能性があります。インスタンスの制限と制限の引き上げをリクエストする方法の詳細については、「Amazon EC2 Service Quotas」を参照してください。

5.    Auto Scaling グループの最近のイベントで成功したイベントのみが表示される場合は、次のセクションのステップを実行します。

**重要:**サービスにリンクされた AWS Identity and Access Management (IAM) ロール AWSServiceRoleForAutoScaling のために特定の許可を設定する必要があります。IAM ロール AWSServiceRoleForAutoScaling には、少なくともカスタマーマネージド AWS Key Management Service (AWS KMS) キーへのユーザーアクセスが必要です。これは、カスタム Amazon マシンイメージ (AMI)、暗号化された Amazon Elastic Block Store (Amazon EBS) ボリューム、およびカスタマーマネージド AWS KMS キーを使用する環境で必要です。詳細については、「Key policy sections that allow access to the customer managed key」を参照してください。

インスタンスがスポットコンピューティング環境で作成できることを確認するには:

1.    Amazon EC2 コンソールを開きます。

2.    ナビゲーションペインで [インスタンス] を選択します。次に、[スポットリクエスト] を選択します。

3.    フィルターの [リクエストタイプ] で [フリート] を選択します。

4.    [ステータス] で [アクティブ] を選択します。

5.    [説明] を選択します。次に、[合計ターゲット容量] の値を確認して、スポットインスタンスリクエストが処理されたかどうかを確認します。インスタンスが作成されていない場合は、[履歴] ビューでその理由を説明するメッセージを確認してください。たとえば、リクエストが入札料金に達することができない場合は、次のようなメッセージが返されます。

m4.large, ami-aff65ad2, Linux/UNIX (Amazon VPC), us-east-1a, Spot bid price is less than Spot market price $0.0324

6.    コンピューティング環境に適した入札割合を選択します。入札料金を変更する場合は、必ず新しいコンピューティング環境を作成してください。詳細については、「スポットインスタンスの料金履歴」を参照してください。

**注:**AWS Batch が、ユーザーに代わってスポットフリートリクエストを作成します。スポットフリートリクエストを手動で変更しないでください。コンピューティング環境が無効になる可能性があります。

7.    Auto Scaling グループの最新のイベントが成功したイベントだけを表示する場合は、次のセクションのステップを実行します。

コンテナインスタンスの IAM ロールを確認する

1.    AWS バッチコンソールを開きます。

2.    ナビゲーションペインで [コンピューティング環境] を選択します。次に、コンピューティング環境を選択します。

3.    [コンピューティング環境の詳細]セクションで、[インスタンスロール] の名前をコピーします。

4.    IAM コンソールを開きます。

5.    検索ボックスで、[インスタンスロール] の名前を入力します。次に、結果からインスタンスロールを選択します。

6.    [アクセス許可] ビューを選択します。次に、AmazonEC2ContainerServiceforEC2Role マネージドポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、インスタンスロールは正しく設定されているので、ステップ 11 に進むことができます。

7.    [ポリシーをアタッチ] を選択します。

8.    検索ボックスに AmazonEC2ContainerServiceforEC2Role と入力します。

9.    AmazonEC2ContainerServiceforEC2Role ポリシーについては、チェックボックスをオンにします。次に、[ポリシーをアタッチ] を選択します。

10.    [信頼関係] ビューを選択します。次に、[信頼関係の編集] を選択します。

11.    信頼関係に次のポリシーが含まれていることを確認します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

12.    信頼関係が前述の例のポリシーと一致する場合は、[キャンセル] を選択します。

または

上記の例で、信頼関係がポリシーと一致しない場合は、[ポリシードキュメント] コンソールにポリシーをコピーします。次に、[信頼ポリシーを更新する] を選択します。

インスタンスが Amazon ECS クラスターにまだ参加しない場合は、次のセクションのステップを完了します。

コンピューティング環境のネットワークとセキュリティ設定を確認する

1.    AWS バッチコンソールを開きます。

2.    ナビゲーションペインで [コンピューティング環境] を選択します。次に、コンピューティング環境を選択します。

3.    [コンピューティングリソース] セクションで、[サブネット] と [セキュリティグループ] の値をコピーします。

4.    Amazon Virtual Private Cloud (Amazon VPC) コンソールを開きます。

5.    ナビゲーションペインで、[サブネット] を選択します。

6.    コンピューティング環境内の各サブネットについて、[説明] を選択します。次に、[パブリック IPv4 アドレスを自動的に割り当てる] の値を確認します。

[パブリック IPv4 アドレスを自動的に割り当てる] の値が [はい] の場合、サブネットで起動されるインスタンスは、次を持ちます。

• パブリック IPv4 アドレス
• ルートの送信先が 0.0.0.0/0 のルートテーブル
• [Target] に設定されたインターネットゲートウェイ (例:igw-1a2b3c4d)

[パブリック IPv4 アドレスを自動的に割り当てる] の値が [いいえ] の場合、サブネットで起動されるインスタンスは、次を持ちます。

• プライベート IPv4 アドレス
• ルートの送信先が 0.0.0.0/0 のルートテーブル
• [ターゲット] に設定された NAT ゲートウェイ (例:nat-12345678901234567)。

**注:**詳細については、Routing セクションを参照してください。例: プライベートサブネットにサーバーがある VPC および NAT。

7.    ナビゲーションペインで [セキュリティグループ] を選択します。

8.    コンピューティング環境で指定される各セキュリティグループについて、[アウトバウンドルール] ビューを選択します。次に、以下の設定のルールが存在することを確認します。

• [Type] で、[ALL Traffic] を選択する。
• [Protocol] で、[ALL] を選択する。
• [Port Range] で [ALL] を選択する。
• [Destination] で、[0.0.0.0/0 を選択する。

重要:ルールが存在しない場合は、[Edit] を選択します。次に、ルールを作成します。アウトバウンドトラフィックのより制限の厳しいルールについては、[Type] にHTTPS (443) を選択し、[Destination] に**[0.0.0.0/0]** を選択します。

9.    ナビゲーションペインで、[Network ACLs] を選択します。

10.    VPC のネットワークアクセスコントロールリスト (ネットワーク ACL) を選択します。

11.    デフォルトのネットワーク ACL が、すべてのトラフィックが関連するサブネットに出入りできるように設定されていることを確認します。

**重要:**ACL を変更した場合は、サブネットからインターネットへのアウトバウンド IPv4 HTTPS トラフィックを許可するルールを追加してください。詳細については、「セキュリティグループを使用して EC2 インスタンスへのトラフィックを制御する」および「ネットワーク ACL を使用してサブネットへのトラフィックを制御する」を参照してください。VPC、サブネット、またはセキュリティグループを変更するには、新しいコンピューティング環境を作成します。

それでもインスタンスが Amazon ECS クラスターに参加しない場合は、インスタンスに接続します。その後、Docker デーモンと Amazon ECS コンテナエージェントのステータスを確認します。

注:この記事の手順では、考えられるすべての根本原因とそのトラブルシューティング方法を網羅しているわけではありません。AWS Batch ジョブが [RUNNABLE] ステータスでスタックするという問題をさらに深く掘り下げる必要がある場合は、AWS CloudTrail が役に立つ場合があります。CloudTrail では、[Username] 属性が aws-batch に設定されているイベントを検索して、スケジュールされたタスク中に発生するエラーを調査します。

関連情報

Linux インスタンスへの接続

Windows インスタンスへの接続