スキップしてコンテンツを表示
AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post
re:Postに関して

AWS Batch ジョブが RUNNABLE ステータスから移行できない場合のトラブルシューティング方法を教えてください。

所要時間4分
0

AWS Batch ジョブが RUNNABLE ステータスから移行できません。

簡単な説明

ジョブに保留中の依存関係が存在せず、AWS Batch によるスケジュールが可能な場合、AWS Batch はそのジョブを RUNNABLE ステータスに移行します。RUNNABLE ステータスのジョブは、ジョブのキューにマッピングされたいずれかのコンピューティング環境で十分なリソースが利用可能になり次第、開始します。

ジョブの実行に必要なリソースが利用できない場合、そのジョブは RUNNABLE ステータスから移行できない可能性があります。

注: 次の解決策は、Amazon Elastic Container Service (Amazon ECS) コンテナで実行される AWS Batch ジョブのトラブルシューティング手順です。これらのコンテナは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたは AWS Fargate コンピューティング環境で実行できます。Amazon Elastic Kubernetes Service (Amazon EKS) で実行される AWS Batch をトラブルシューティングする場合は、「Amazon EKS における AWS Batch」を参照してください。

解決策

まず、停滞したジョブにより、先入れ先出し (FIFO) キューがブロックされるかどうかを確認します。問題が解決しない場合は、トラブルシューティングを自動化して問題を判断するか、手動トラブルシューティングを行います。

ブロックされた FIFO キューがないか確認する

次の問題が原因で、ジョブが先入れ先出し (FIFO) キューの先頭で RUNNABLE ステータスに停滞する可能性があります。

  • ジョブに公平配分スケジュールが適用されていないため、後続のすべてのジョブを実行できない。
  • AWS アカウントの構成ミス。
  • アカウントは、ジョブに必要なインスタンスにアクセスできない (例: アカウントに GPU インスタンスタイプが必要な場合)。

FIFO キューのブロックを解除するには、GetJobQueueSnapshot を使用してキューをブロックするジョブを特定し、そのジョブをシャットダウンします。

トラブルシューティングプロセスを自動化する

AWSSupport-TroubleshootAWSBatchJob ランブックを使用すると、RUNNABLE ステータスに留まっている AWS ジョブをトラブルシューティングできます。または、問題を手動でトラブルシューティングする場合は、次のセクションの手順を実行します。

コンピューティング環境のリソースがジョブの実行に十分かどうかを判断する

次の手順を実行します。

  1. AWS Batch コンソールを開きます。
  2. ナビゲーションパネルで [ダッシュボード] を選択します。
  3. [ジョブキューの概要] セクションの [RUNNABLE] 列から、RUNNABLE ステータスに留まっているジョブを選択します。ジョブの詳細ページが表示されます。
  4. [コンテナ] タブを選択し、vCPU、Memory、GPU の値を書き留めます。これらの値は、ステップ 9 ～ 10 の実行に使用します。
  5. ナビゲーションペインで [ジョブキュー] を選択し、目的のジョブキューを選択します。
  6. [環境の順序] タブを参照し、ジョブキューに関連付けられたコンピューティング環境を特定します。
  7. ナビゲーションペインで [環境] を選択し、コンピューティング環境を選択してその権限を確認します。
  8. [ステータス] セクションを参照し、コンピューティング環境の [ステータス] 列が Valid であることを確認します。
    注: エラーが断続的または一時的に発生した際、コンピューティング環境のステータスが Valid から Invalid に変化するまでに数分かかる場合があります。
  9. [詳細] タブを参照し、環境に関連付けられたサービスロールには、必要な権限がすべて含まれていることを確認します。
  10. [ステータス] セクションを参照し、[状態] 列が Enabled であることを確認します。
  11. [コンピューティングリソース] タブで Maximum vCPUs の値を確認します。この値は、AWS Batch がジョブを実行するために Desired vCPUs (目標とする vCPU 数) を増やせるよう、十分に高くする必要があります。
    注: Fargate コンピューティング環境を使用する場合は、「コンピューティング環境のネットワーク設定とセキュリティ設定を確認する」を参照してください。
  12. [Desired vCPUs] (目標 vCPU 数) の値は、ジョブが実行する必要のある vCPU 数以上であることを確認します。
  13. [目標 vCPU 数] が 0 の場合は、Amazon EC2 インスタンスタイプで使用できるメモリと CPU リソースの量を確認します。[目標 vCPU 数] が 0 を上回る場合、またはジョブのステータスが依然として RUNNABLE の場合は、次のセクションの手順を実行します。

各コンピューティング環境で、ステップ 6～14 を繰り返します。

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

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

ジョブを実行しているコンピューティング環境において、次の手順を実行します。

  1. Amazon ECS コンソールを開きます。
  2. ナビゲーションペインで [クラスター] を選択し、ジョブが含まれるクラスターを選択します。
    注: クラスター名の先頭はコンピューティング環境名であり、その後に _Batch_ および数字と文字を含むランダムハッシュが続きます。
  3. [インフラストラクチャ] タブを選択します。
  4. [コンテナインスタンス] セクションで目的のコンテナインスタンスを探し、そのコンテナインスタンスがジョブを実行できることを確認します。

クラスターにジョブを実行できるコンテナインスタンスが含まれている場合は、Docker デーモンおよび Amazon ECS コンテナエージェントのステータスを確認します。詳細については、「Amazon ECS エージェントが切断される場合のトラブルシューティング方法を教えてください」を参照してください。

Amazon ECS クラスターにインスタンスがない場合は、コンピューティング環境にインスタンスを作成できるかどうかを確認します。

オンデマンドコンピューティング環境

次の手順を実行します。

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

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

  3. 検索ボックスに目的のコンピューティング環境名を入力し、表示されたコンピューティング環境を選択します。
    注: Amazon EC2 は、同じコンピューティング環境に対して複数の Auto Scaling グループを作成することができます。

  4. 各 Auto Scaling グループで [アクティビティ] タブを選択し、[アクティビティ履歴] セクションでブロックの原因となる問題を探します。
    注: インスタンスの起動を妨げる問題が存在する場合は、[ステータス] 列に 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 サービスクォータ」を参照してください。

Auto Scaling グループの [最近のイベント] に正常なイベントのみが表示される場合は、「コンテナインスタンスの IAM ロールを確認する」セクションの手順を実行します。

重要: 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 キーを使用する環境で必要となります。詳細については、「カスタマーマネージドキーへのアクセスを許可するキーポリシーセクション」を参照してください。

スポットコンピューティング環境

次の手順を実行します。

  1. Amazon EC2 コンソールを開きます。
  2. ナビゲーションペインで [スポットリクエスト] を選択します。
  3. [リクエストタイプ] を選択し、[Request type = fleet] を選択します。
  4. 目的のスポットリクエストを選択します。
  5. [ステータス] で [アクティブ] を選択します。
  6. [説明] を選択し、[合計ターゲット容量] の値を参照してスポットインスタンスのリクエストが充足されたかどうかを確認します。インスタンスが存在しない場合は、[履歴] ビューで原因を判断します。
    たとえば、リクエストが入札価格に達していない場合は、次の例に類似したメッセージが返されます。
    "m4.large, ami-aff65ad2, Linux/UNIX (Amazon VPC), us-east-1a, Spot bid price is less than Spot market price $0.0324"
  7. コンピューティング環境に応じて、適切な入札割合を選択します。入札料金を変更する場合は、新しくコンピューティング環境を作成する必要があります。詳細については、「スポットインスタンスの料金履歴」を参照してください。
    注: AWS Batch は、ユーザーに代わってSpot Fleet リクエストを作成します。コンピューティング環境が無効になる可能性があるため、Spot Fleet リクエストを手動で変更しないよう注意してください。

Auto Scaling グループの最新のイベントに正常なイベントのみが表示される場合は、次のセクションの手順を実行します。

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

次の手順を実行します。

  1. AWS Batch コンソールを開きます。
  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"
    }
  ]
}
  1. 信頼ポリシーに上記のステートメントが含まれている場合は、[キャンセル] を選択します。信頼ポリシーに上記のステートメントが含まれていない場合は、そのステートメントをポリシーに追加します。次に、[ポリシーを更新] を選択します。

依然としてインスタンスが Amazon ECS クラスターに参加できない場合は、次のセクションの手順を実行します。

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

次の手順を実行します。

  1. AWS Batch コンソールを開きます。
  2. ナビゲーションペインで [環境] を選択し、コンピューティング環境を選択します。
  3. [コンピューティングリソース] セクションを参照し、[サブネット] と [セキュリティグループ] の値を書き留めます。
  4. Amazon Virtual Private Cloud (Amazon VPC) コンソールを開きます。
  5. ナビゲーションペインで [サブネット] を選択します。
  6. コンピューティング環境内の各サブネットを選択し、[詳細] タブで [パブリック IPv4 アドレスの自動割り当て] の値を確認します。
    [パブリック IPv4 アドレスの自動割り当て] の値が Yes の場合、サブネットで起動されるインスタンスは、次のプロパティを持ちます。
    パブリック IPv4 アドレス
    ルートの宛先が 0.0.0.0/0 であるルートテーブル
    ターゲットに設定されたインターネットゲートウェイ (例: igw-1a2b3c4d)
    [パブリック IPv4 アドレスの自動割り当て] の値が No の場合、サブネットで起動されるインスタンスは、次のプロパティを持ちます。
    プライベート IPv4 アドレス
    ルートの宛先が 0.0.0.0/0 であるルートテーブル
    ターゲットとして設定された NAT ゲートウェイ (例: nat-12345678901234567)
    注: 詳細については、「ルーティング」を参照してください。
  7. ナビゲーションペインで [セキュリティグループ] を選択します。
  8. コンピューティング環境内の各セキュリティグループにおいて、[アウトバウンドルール] タブを選択します。次に、以下の設定が含まれるルールが存在することを確認します。
    [タイプ]: All traffic
    [プロトコル]: ALL
    [ポート範囲]: All
    [宛先]: 0.0.0.0/0
    重要: このルールが存在しない場合は、[アクション] を選択し、[アウトバウンドルールを編集] を選択してルールを作成します。アウトバウンドトラフィックのルールを厳格にする場合は、[タイプ] に HTTPS (443) を、[宛先] に 0.0.0.0/0 を選択します。
  9. ナビゲーションペインで [ネットワーク ACL] を選択します。
  10. VPC のネットワークアクセスコントロールリスト (ネットワーク ACL) を選択します。
  11. [インバウンドルール] および [アウトバウンドルール] タブを参照し、ネットワーク ACL が、すべてのトラフィックが関連するサブネットとの送受信を許可していることを確認します。

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

インスタンスが依然として Amazon ECS クラスターに参加できない場合は、そのインスタンスに接続します。Docker デーモンおよび Amazon ECS コンテナエージェントのステータスを確認します。詳細については、「Amazon ECS エージェントが切断される場合のトラブルシューティング方法を教えてください」を参照してください。

注: RUNNABLE ステータスで停滞した AWS Batch ジョブのトラブルシューティングを進めるには、AWS CloudTrail を使用します。スケジュールされたタスク期間に発生するエラーを検出するために、Username 属性を aws-batch に設定します。

関連情報

SSH を使用して Linux インスタンスに接続する

RDP を使用して Windows インスタンスに接続する

AWS Batch でブロックされたジョブの検出、対処に便利な新しいアラートが導入されました

AWS Batch に Job Queue Snapshot 導入。ジョブキューの先頭にあるジョブを確認できます

トピック
Compute
タグ
AWS Batch
言語
日本語
AWS公式更新しました 8ヶ月前
コメントはありません

関連するコンテンツ