翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ジョブ ジョブは、 によって開始される作業の単位です AWS Batch。ジョブは、ECSクラスター内のAmazon ECSコンテナインスタンス上で実行されるコンテナ化されたアプリケーションとして呼び出すことができます。 コンテナ化されたジョブは、コンテナイメージ、コマンド、およびパラメータを参照できます。詳細については、「[JobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_JobDefinition.html)」を参照してください。 多数の独立したシンプルなジョブを送信できます。 **Topics** + [チュートリアル: ジョブを送信する](submit_job.md) + [のサービスジョブ AWS Batch](service-jobs.md) + [ジョブの状態](job_states.md) + [AWS Batch ジョブ環境変数](job_env_vars.md) + [ジョブの再試行の自動化](job_retries.md) + [ジョブの依存関係](job_dependencies.md) + [ジョブのタイムアウト](job_timeouts.md) + [Amazon EKS ジョブ](eks-jobs.md) + [マルチノード並列ジョブ](multi-node-parallel-jobs.md) + [Amazon EKS のマルチノード並列ジョブ](mnp-eks-jobs.md) + [配列ジョブ](array_jobs.md) + [GPU ジョブを実行する](gpu-jobs.md) + [AWS Batch ジョブキューでジョブを表示する](view-jobs.md) + [ジョブキュー内のジョブ AWS Batch を検索する](searching-filtering-jobs.md) + [AWS Batch ジョブのネットワークモード](networking-modes-jobs.md) + [CloudWatch Logs で AWS Batch ジョブログを表示する](review-job-logs.md) + [AWS Batch ジョブ情報の確認](review-job-info.md) # チュートリアル: ジョブを送信する ジョブ定義を登録したら、 AWS Batch ジョブとして ジョブキューに送信できます。ジョブ定義で指定されたパラメーターの多くは、実行時にオーバーライドできます。 **ジョブを送信する方法** 1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。 1. ナビゲーションバーから、 AWS リージョン 使用する を選択します。 1. ナビゲーションペインで **ジョブ**を選択します。 1. **ジョブの送信**を選択します。 1. **名前** に、一意のジョブ定義名を入力します。名前の最大長は 128 文字です。大文字、小文字、数字、ハイフン (-)、アンダースコア (\$1) を含めることができます。 1. **ジョブ定義**で、作成済みのジョブ定義を選択します。詳細については、[シングルノードのジョブ定義を作成する](create-job-definition.md)を参照してください。 1. **ジョブキュー**で、既存のジョブキューを選択します。詳細については、[ジョブキューを作成する](create-job-queue.md)を参照してください。 1. **[ジョブ依存関係]** で **[ジョブ依存関係を追加]** を選択します。 1. **ジョブ ID**には、すべての依存関係のジョブ ID を入力します。次に **ジョブの依存関係を追加** を選択します。ジョブは最大 20 個の依存関係を持つことができます。詳細については、[ジョブの依存関係](job_dependencies.md)を参照してください。 1. (配列ジョブのみ) **[Array size]** (配列サイズ) で、配列サイズを 2 から 10,000 の間で指定します。 1. (オプション)**タグ**を展開し、**タグを追加** を選択してリソースにタグを追加します。キーとオプショナル値を入力し、**新しいタグを追加**を選択します。 1. **次のページ** を選択します。 1. **ジョブオーバーライド**セクションで: 1. (オプショナル) **スケジュールの優先度** には、0 から 100 までのスケジューリング優先度の値を入力します。値が大きいほど優先度が高くなります。 1. (オプショナル) **Job 試行回数** には、 AWS Batch ジョブをステータスに移行しようとする`RUNNABLE` 最大回数を入力します。1から10までの数字を入力できます。詳細については、[ジョブの再試行の自動化](job_retries.md)を参照してください。 1. (オプション) **実行タイムアウト** で、タイムアウト値 (秒単位) を入力します。実行タイムアウトは、未完了のジョブが終了するまでの時間です。試行がタイムアウト時間を超えた場合、試行は中止され、`FAILED`のステータスに移行します。詳細については、[ジョブのタイムアウト](job_timeouts.md)を参照してください。最小値は 60 秒です。 **重要** Fargateリソースで実行されるジョブが14日以上実行されることを当てにしないでください。14日後、ファーゲートのリソースは使用できなくなり、仕事が打ち切られる可能性があります。 1. (オプション) **タグを伝播** をオンにして、タグをジョブとジョブ定義から Amazon ECS タスクに伝達することができます。 1. **[Additional configuration]** (追加設定) を展開します。 1. (オプション) **再試行戦略の条件** では、**終了時に評価を追加** を選択します。少なくとも 1 つのパラメータ値を入力し、**アクション** を選択します。条件セットごとに、**アクション** を **再試行** または **終了** に設定する必要があります。これらのアクションは、以下のことを意味します。 + **再試行 — **指定したジョブ試行回数に達するまで AWS Batch 再試行します。 + **終了** – ジョブの再試行を AWS Batch 停止します。 **重要** **終了時に評価を追加** を選択した場合は、少なくとも 1 つのパラメータを設定して**アクション** を選択するか、**終了時に評価を削除** を選択します。 1. **パラメーター** で **パラメーターの追加** を選択し、パラメーター置換プレースホルダーを追加します。**キー**を入力し、オプションで **値**を入力します。 1. **コンテナオーバーライド**セクションで: 1. **[コマンド]** では、コマンドを **JSON** 文字列配列に相当するものとしてフィールドに入力します。 このパラメータは、[Docker Remote API](https://docs.docker.com/engine/api/v1.38/) の [コンテナの作成](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) セクションにある `Cmd` にマッピングされ、`COMMAND` パラメータは [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/) にマッピングされます。Docker `CMD` パラメータの詳細については、[https://docs.docker.com/engine/reference/builder/\$1cmd](https://docs.docker.com/engine/reference/builder/#cmd) を参照してください。 **注記** このパラメータには空の文字列を含めることはできません。 1. **vCPU** で、コンテナ用に予約する vCPU の数を指定します。このパラメータは、[Docker Remote API](https://docs.docker.com/engine/api/v1.38/) の [コンテナの作成](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) セクションにある `CpuShares` にマッピングされ、`--cpu-shares` オプションは [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/) にマッピングされます。各 vCPU は 1,024 個の CPU 配分に相当します。少なくとも 1 つの vCPU を指定する必要があります。 1. **メモリ** で、コンテナで使用できるメモリ制限を入力します。コンテナは、ここで指定したメモリを超えようとすると、停止されます。このパラメータは、[Docker Remote API ](https://docs.docker.com/engine/api/v1.38/)の[コンテナの作成](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate)セクションの `Memory` にマップされ、`--memory` オプションは [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/) にマップされます。ジョブに対して少なくとも 4 MiB のメモリを指定する必要があります。 **注記** 特定のインスタンスタイプのジョブにメモリの優先順位を付けることで、リソース使用率を最大化できます。詳細については、[コンピューティングリソースメモリの管理](memory-management.md)を参照してください。 1. (オプショナル) **GPU の数** には、コンテナ用に予約する GPU の数を選択します。 1. (オプション) **環境変数** で **環境変数を追加** を選択し、環境変数を名前と値のペアとして追加します。これらの変数は、コンテナに渡されます。 1. **次のページ** を選択します。 1. **ジョブレビューについては**、設定手順を確認してください。変更する必要がある場合は、**[Edit]** (編集) を選択します。完了したら、**ジョブ定義の作成** を選択します。 # のサービスジョブ AWS Batch AWS Batch サービスジョブを使用すると、 AWS Batch ジョブキューを介して AWS サービスにリクエストを送信できます。現在、 は SageMaker トレーニングジョブをサービスジョブとして AWS Batch サポートしています。が基盤となるコンテナ実行 AWS Batch を管理するコンテナ化されたジョブとは異なり、サービスジョブでは AWS Batch がジョブのスケジュールとキューイング機能を提供できますが、ターゲット AWS サービス (SageMaker AI など) は実際のジョブ実行を処理します。 AWS Batch SageMaker トレーニングジョブの場合、データサイエンティストは優先順位を付けてトレーニングジョブを設定可能なキューに送信できるため、リソースが利用可能になるとすぐにワークロードが介入なしで実行されます。この機能は、リソースの調整、偶発的な過剰支出の防止、予算の制約への対応、リザーブドインスタンスによるコストの最適化、チームメンバー間の手動調整の必要性の排除といった一般的な課題に対処します。 サービスジョブは、いくつかの重要な点でコンテナ化されたジョブとは異なります。 + **ジョブの送信**: サービスジョブは [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html) API を使用して送信する必要があります。サービスジョブは AWS Batch コンソールから送信できません。 + **ジョブ実行**: サービスジョブを AWS Batch スケジュールしてキューに入れますが、ターゲット AWS サービスは実際のジョブワークロードを実行します。 + **リソース識別子**: サービスジョブは、「job」ではなく「service-job」を含む ARN を使用して、コンテナ化されたジョブとの区別を行います。 SageMaker Training AWS Batch のサービスジョブの使用を開始するには、「」を参照してください[SageMaker AI AWS Batch での の開始方法](getting-started-sagemaker.md)。 **Topics** + [のサービスジョブペイロード AWS Batch](service-job-payload.md) + [でサービスジョブを送信する AWS Batch](service-job-submit.md) + [AWS Batch サービスジョブのステータスを SageMaker AI ステータスにマッピングする](service-job-status.md) + [のサービスジョブの再試行戦略 AWS Batch](service-job-retries.md) + [AWS Batch キュー内のサービスジョブをモニタリングする](monitor-sagemaker-job-queue.md) + [サービスジョブを終了する](terminate-service-jobs.md) # のサービスジョブペイロード AWS Batch [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html) を使用してサービスジョブを送信するときは、ジョブを定義する 2 つの主要なパラメータとして `serviceJobType`、`serviceRequestPayload` を指定します。 + は、ジョブを実行する AWS サービス`serviceJobType`を指定します。SageMaker トレーニングジョブの場合、この値は `SAGEMAKER_TRAINING` です。 + `serviceRequestPayload` は、通常はターゲットサービスに直接送信される完全なリクエストを含む JSON エンコードされた文字列です。SageMaker トレーニングジョブの場合、このペイロードには SageMaker AI [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html) API で使用するのと同じパラメータが含まれています。 使用可能なすべてのパラメータの完全なリストとその説明については、SageMaker AI [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html) API リファレンスを参照してください。`CreateTrainingJob` でサポートされているすべてのパラメータをサービスジョブのペイロードに含めることができます。 その他のトレーニングジョブの設定例については、「[SageMaker AI デベロッパーガイド](https://docs.aws.amazon.com/sagemaker/latest/dg/gs.html)」の「[API、CLI、SDK](https://docs.aws.amazon.com/sagemaker/latest/dg/api-and-sdk-reference-overview.html)」を参照してください。 PySDK にはヘルパークラスとユーティリティがあるため、サービスジョブの作成には PySDK を使用することをお勧めします。PySDK の使用例については、GitHub の「[SageMaker AI の例](https://github.com/aws/amazon-sagemaker-examples)」を参照してください。 ## サービスジョブのペイロードの例 次の例は、「hello world」トレーニングスクリプトを実行する SageMaker トレーニングジョブのシンプルなサービスジョブのペイロードを示しています。 このペイロードは、`SubmitServiceJob` を呼び出すときに `serviceRequestPayload` パラメータに JSON 文字列として渡されます。 ``` { "TrainingJobName": "my-simple-training-job", "RoleArn": "arn:aws:iam::123456789012:role/SageMakerExecutionRole", "AlgorithmSpecification": { "TrainingInputMode": "File", "TrainingImage": "763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-cpu-py310", "ContainerEntrypoint": [ "echo", "hello world" ] }, "ResourceConfig": { "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "VolumeSizeInGB": 1 }, "OutputDataConfig": { "S3OutputPath": "s3://your-output-bucket/output" }, "StoppingCondition": { "MaxRuntimeInSeconds": 30 } } ``` # でサービスジョブを送信する AWS Batch サービスジョブを送信するには AWS Batch、[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html) API を使用します。 AWS CLI または SDK を使用してジョブを送信できます。 実行ロールがまだない場合は、サービスジョブを送信する前に作成する必要があります。SageMaker AI 実行ロールを作成するには、「*[SageMaker AI デベロッパーガイド](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)*」の「[SageMaker AI 実行ロールの使用方法](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html)」を参照してください。 ## サービスジョブの送信ワークフロー サービスジョブを送信すると、 は次のワークフロー AWS Batch を実行します。 1. AWS Batch は`[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)`リクエストを受け取り、 AWS Batch特定のパラメータを検証します。`serviceRequestPayload` は検証なしで渡されます。 1. ジョブは `SUBMITTED` 状態になり、指定されたジョブキューに配置されます。 1. AWS Batch は、キューの前面にある`RUNNABLE`ジョブに対してサービス環境に使用可能な容量があるかどうかを評価します。 1. 容量が利用可能な場合、ジョブは `SCHEDULED` に移動し、ジョブは SageMaker AI に渡されます。 1. 容量が取得され、SageMaker AI がサービスジョブデータをダウンロードすると、サービスジョブは初期化を開始し、ジョブは `STARTING` に変更されます。 1. SageMaker AI がジョブの実行を開始すると、ステータスは `RUNNING` に変更されます。 1. SageMaker AI がジョブを実行する間、 は進行状況 AWS Batch を監視し、サービスの状態を AWS Batch ジョブの状態にマッピングします。サービスジョブの状態のマッピング方法の詳細については、「[AWS Batch サービスジョブのステータスを SageMaker AI ステータスにマッピングする](service-job-status.md)」を参照してください。 1. サービスジョブが完了すると、`SUCCEEDED` に移動し、出力をダウンロードする準備が整います。 ## 前提条件 サービスジョブを送信する前に、以下があることを確認してください。 + **サービス環境** – 容量制限を定義するサービス環境。詳細については、「[でサービス環境を作成する AWS Batch](create-service-environments.md)」を参照してください。 + **SageMaker ジョブキュー** – ジョブスケジューリングを提供する SageMaker ジョブキュー。詳細については、「[AWS Batch で SageMaker トレーニングジョブのキューを作成する](create-sagemaker-job-queue.md)」を参照してください。 + **IAM アクセス許可** – AWS Batch ジョブキューとサービス環境を作成および管理するためのアクセス許可。詳細については、「[AWS Batch IAM ポリシー、ロール、アクセス許可](IAM_policies.md)」を参照してください。 ## CLI AWS を使用してサービスジョブを送信する AWS CLI を使用してサービスジョブを送信する方法を以下に示します。 ``` aws batch submit-service-job \ --job-name "my-sagemaker-training-job" \ --job-queue "my-sagemaker-job-queue" \ --service-job-type "SAGEMAKER_TRAINING" \ --service-request-payload '{\"TrainingJobName\": \"sagemaker-training-job-example\", \"AlgorithmSpecification\": {\"TrainingImage\": \"123456789012.dkr.ecr.us-east-1.amazonaws.com/pytorch-inference:1.8.0-cpu-py3\", \"TrainingInputMode\": \"File\", \"ContainerEntrypoint\": [\"sleep\", \"1\"]}, \"RoleArn\":\"arn:aws:iam::123456789012:role/SageMakerExecutionRole\", \"OutputDataConfig\": {\"S3OutputPath\": \"s3://example-bucket/model-output/\"}, \"ResourceConfig\": {\"InstanceType\": \"ml.m5.large\", \"InstanceCount\": 1, \"VolumeSizeInGB\": 1}}' --client-token "unique-token-12345" ``` `serviceRequestPayload` パラメータの詳細については、「[のサービスジョブペイロード AWS Batch](service-job-payload.md)」を参照してください。 # AWS Batch サービスジョブのステータスを SageMaker AI ステータスにマッピングする [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html) を使用して SageMaker ジョブキューにジョブを送信すると、 はジョブのライフサイクル AWS Batch を管理し、 AWS Batch [ジョブの状態](job_states.md)を同等の SageMaker トレーニングジョブの状態にマッピングします。SageMaker トレーニングジョブなどのサービスジョブは、従来のコンテナジョブとは異なる状態ライフサイクルに従います。サービスジョブはほとんどの状態をコンテナジョブと共有しますが、`SCHEDULED` 状態を導入し、特にターゲットサービスからの容量不足エラーを処理するために、さまざまな再試行動作を示します。 次の表は、 AWS Batch ジョブの状態と対応する SageMaker Status/SecondaryStatus を示しています。 | バッチステータス | SageMaker AI プライマリステータス | SageMaker AI セカンダリステータス | 説明 | | --- | --- | --- | --- | | SUBMITTED | 該当なし | 該当なし | ジョブがキューに送信され、スケジューラの評価を待機しています。 | | RUNNABLE | 該当なし | 該当なし | ジョブはキューに入れられ、スケジューリングの準備が整います。この状態のジョブは、サービス環境で十分なリソースが使用可能になるとすぐに開始されます。十分なリソースが使用不可の場合、この状態が無限に続くことがあります。 | | SCHEDULED | InProgress | Pending | サービスジョブが SageMaker AI に正常に送信されました | | STARTING | InProgress | Downloading | データとイメージをダウンロード中の SageMaker トレーニングジョブ。トレーニングジョブの容量が取得され、ジョブの初期化が開始されました。 | | RUNNING | InProgress | Training | SageMaker トレーニングジョブの実行アルゴリズム | | RUNNING | InProgress | Uploading | トレーニング完了後に出力アーティファクトをアップロードする SageMaker トレーニングジョブ | | SUCCEEDED | Completed | Completed | SageMaker トレーニングジョブが正常に完了しました。出力アーティファクトのアップロードが完了しました。 | | FAILED | Failed | Failed | SageMaker トレーニングジョブで回復不可能なエラーが発生しました。 | | FAILED | Stopped | Stopped | SageMaker トレーニングジョブが StopTrainingJob を使用して手動で停止されました。 | # のサービスジョブの再試行戦略 AWS Batch サービスジョブの再試行戦略により AWS Batch 、 は特定の条件下で失敗したサービスジョブを自動的に再試行できます。 サービスジョブには、いくつかの理由で複数回の試行が必要になる場合があります。 + **一時的なサービスの問題**: 内部サービスエラー、スロットリング、または一時的な停止により、送信中または実行中にジョブが失敗する可能性があります。 + **トレーニング初期化の失敗**: イメージのプルの問題や初期化エラーなど、ジョブの起動中の問題は再試行時に解決される可能性があります。 適切な再試行戦略を設定することで、ジョブの成功率を向上させ、特に長時間実行されるトレーニングのワークロードにおける手動介入の必要性を減らすことができます。 **注記** サービスジョブは、設定された再試行を消費することなく、容量不足エラーなど、特定のタイプの失敗を自動的に再試行します。再試行戦略は、アルゴリズムエラーやサービスの問題などの他のタイプの失敗を主に処理します。 ## 再試行戦略の設定 サービスジョブの再試行戦略は、シンプルな再試行回数と条件付き再試行ロジックの両方をサポートする [ServiceJobRetryStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ServiceJobRetryStrategy.html) を使用して設定されます。 ### 再試行設定 最も簡単な再試行戦略では、サービスジョブが失敗した場合に実行する再試行回数を指定します。 ``` { "retryStrategy": { "attempts": 3 } } ``` この設定では、サービスジョブが失敗した場合に最大 3 回再試行できます。 **重要** `attempts` 値は、最初の試行を含め、ジョブを `RUNNABLE` 状態に配置できる合計回数を表します。3 の値は、ジョブが最初に 1 回試行され、失敗するとさらに 2 回再試行されることを意味します。 ### evaluateOnExit で設定を再試行する `evaluateOnExit` パラメータを使用して、ジョブを再試行するか、失敗を許可する条件を指定できます。これは、さまざまなタイプの失敗で異なる処理が必要な場合に便利です。 `evaluateOnExit` 配列には最大 5 つの再試行戦略を含めることができ、それぞれがステータス理由に基づいてアクション (`RETRY` または `EXIT`) と条件を指定します。 ``` { "retryStrategy": { "attempts": 5, "evaluateOnExit": [ { "action": "RETRY", "onStatusReason": "Received status from SageMaker: InternalServerError*" }, { "action": "EXIT", "onStatusReason": "Received status from SageMaker: ValidationException*" }, { "action": "EXIT", "onStatusReason": "*" } ] } } ``` この設定では、次のようになります。 + SageMaker AI の内部サーバーエラーが原因で失敗したジョブを再試行する + 検証例外 (再試行によって解決されないクライアントエラー) が発生したジョブをすぐに失敗させる + 他の失敗タイプに対して終了するキャッチオールルールを含める #### ステータス理由のパターンマッチング `onStatusReason` パラメータは、最大 512 文字のパターンマッチングをサポートします。パターンはワイルドカード (\$1) を使用し、SageMaker AI によって返されるステータス理由と照合できます。 サービスジョブの場合、SageMaker AI からのステータスメッセージには、SageMaker からのステータスの受信: AWS Batch」というプレフィックスが付けられ、生成されたメッセージと区別されます。一般的なパターンは次のとおりです。 + `Received status from SageMaker: InternalServerError*` - 内部サービスエラーの一致 + `Received status from SageMaker: ValidationException*` - クライアント検証エラーの一致 + `Received status from SageMaker: ResourceLimitExceeded*` - リソース制限エラーの一致 + `*CapacityError*` - 容量関連の失敗の一致 **ヒント** 特定のパターンマッチングを使用して、さまざまなエラータイプを適切に処理します。例えば、内部サーバーエラーを再試行しますが、ジョブパラメータの問題を示す検証エラーですぐに失敗します。 # AWS Batch キュー内のサービスジョブをモニタリングする `list-service-jobs` および `get-job-queue-snapshot` を使用して、SageMaker トレーニングジョブキュー内のジョブのステータスをモニタリングできます。 キューで実行中のジョブを表示します: ``` aws batch list-service-jobs \ --job-queue my-sm-training-fifo-jq \ --job-status RUNNING ``` キューで待機しているジョブを表示する: ``` aws batch list-service-jobs \ --job-queue my-sm-training-fifo-jq \ --job-status RUNNABLE ``` SageMaker に送信されたものの、まだ実行されていないジョブを表示します: ``` aws batch list-service-jobs \ --job-queue my-sm-training-fifo-jq \ --job-status SCHEDULED ``` キューの前面でジョブのスナップショットを取得します: ``` aws batch get-job-queue-snapshot --job-queue my-sm-training-fifo-jq ``` このコマンドは、キュー内の今後のサービスジョブの順序を示します。 ## 詳細なサービスジョブ情報を取得する [https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html) オペレーションを使用して、現在のステータス、サービスリソース識別子、詳細な試行情報など、特定のサービスジョブに関する包括的な情報を取得します。 特定のジョブに関する詳細情報を表示する: ``` aws batch describe-service-job \ --job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d ``` このコマンドは、次のようなジョブに関する包括的な情報を返します。 + ジョブ ARN と現在のステータス + サービスリソース識別子 (SageMaker トレーニングジョブ ARN など) + 優先度と再試行設定のスケジューリング + 元のサービスパラメータを含むサービスリクエストペイロード + 開始時刻と停止時刻を含む詳細な試行情報 + ターゲットサービスからのステータスメッセージ ## SageMaker トレーニングジョブをモニタリングする を使用して SageMaker トレーニングジョブをモニタリングする場合 AWS Batch、 AWS Batch ジョブ情報と基盤となる SageMaker トレーニングジョブの詳細の両方にアクセスできます。 ジョブ詳細のサービスリソース識別子には、SageMaker トレーニングジョブ ARN が含まれます。 ``` { "latestAttempt": { "serviceResourceId": { "name": "TrainingJobArn", "value": "arn:aws:sagemaker:us-east-1:123456789012:training-job/my-training-job" } } } ``` この ARN を使用して、SageMaker から直接追加の詳細を取得できます。 ``` aws sagemaker describe-training-job \ --training-job-name my-training-job ``` AWS Batch ステータスと SageMaker Training ジョブのステータスの両方を確認して、ジョブの進行状況をモニタリングします。 AWS Batch ジョブのステータスはジョブのライフサイクル全体を示し、SageMaker トレーニングジョブのステータスはトレーニングプロセスに関するサービス固有の詳細を提供します。 # サービスジョブを終了する [https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html) オペレーションを使用して、実行中のサービスジョブを停止します。 特定のサービスジョブを終了する: ``` aws batch terminate-service-job \ --job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d \ --reason "Job terminated by user request" ``` サービスジョブを終了すると、 はジョブ AWS Batch を停止し、ターゲットサービスに通知します。SageMaker トレーニングジョブの場合、これにより SageMaker AI のトレーニングジョブも停止します。 # ジョブの状態 ジョブキューに AWS Batch ジョブを送信すると、ジョブは `SUBMITTED`状態になります。その後、以下の状態を経由して完了 (コード `0` で終了) または失敗 (0 以外のコードで終了) します。 AWS Batch ジョブの各状態は以下のとおりです。 `SUBMITTED` キューに送信され、まだスケジューラによって評価されていないジョブです。スケジューラは、ジョブを評価し、他のジョブの正常な完了に依存するかどうか (未処理の依存関係があるかどうか) を判断します。依存関係がある場合、ジョブの状態は `PENDING` に移行します。依存関係がない場合、ジョブの状態は `RUNNABLE` に移行します。 `PENDING` ジョブはキュー内にあり、別のジョブやリソースへの依存関係があるため、まだ実行できません。依存関係が満たされると、ジョブの状態は `RUNNABLE` に移行します。 配列ジョブの親は、子ジョブが に更新`PENDING`されると に更新`RUNNABLE`され、子ジョブの実行中に `PENDING`ステータスのままになります。これらのジョブを表示するには、すべての子ジョブが終了状態になるまで`PENDING`ステータスでフィルタリングします。 `RUNNABLE` ジョブはキュー内にあり、未処理の依存関係はありません。したがって、ホストにスケジューリングされる準備ができています。この状態のジョブは、ジョブのキューにマッピングされたコンピューティング環境のいずれかで十分なリソースが使用可能になり次第、開始されます。ただし、十分なリソースが使用不可の場合、この状態が無限に続くことがあります。 ジョブが `STARTING` に進行しない場合は、トラブルーシューティングセクションの[`RUNNABLE` 状態でジョブが止まる](job_stuck_in_runnable.md)を参照してください。 `STARTING` これらのジョブはホストにスケジュールされており、関連するコンテナ初期化操作が進行中です。コンテナイメージがプルされてコンテナが稼働状態になると、ジョブの状態は `RUNNING` に移行します。 イメージのプル期間、Amazon EKS initContainer の完了期間、Amazon ECS containerDependency 解決期間は STARTING 状態で発生します。ジョブのイメージをプルするのにかかる時間は、ジョブが STARTING 状態にある時間と同じです。 例えば、ジョブのイメージをプルするのに 3 分かかる場合、ジョブは 3 分間 STARTING 状態になります。initContainers の完了に合計 10 分かかる場合、Amazon EKS ジョブは 10 分間 STARTING 状態になります。Amazon ECS ジョブに複数の Amazon ECS containerDependencies がある場合、すべてのコンテナ依存関係 (それらのランタイム) が解決されるまで、ジョブは STARTING 状態になります。STARTING はタイムアウトに含まれないため、期間は RUNNING から始まります。詳細については、「[ジョブの状態](https://docs.aws.amazon.com/batch/latest/userguide/job_states.html)」を参照してください。 `RUNNING` ジョブは、コンピューティング環境内の Amazon ECS コンテナインスタンスでコンテナジョブとして実行中です。ジョブのコンテナが終了すると、プロセス終了コードでジョブの正否が判定されます。終了コードの `0` は成功を示し、ゼロ以外の終了コードは失敗を示します。試行が失敗したジョブの再試行戦略に設定されている再試行回数が残っている場合は、ジョブの状態が `RUNNABLE` に移行します。詳細については、[ジョブの再試行の自動化](job_retries.md)を参照してください。 `RUNNING` ジョブのログは クラウドウォッチのログ(CloudWatch Logs) で確認できます。ロググループは `/aws/batch/job`、ログストリーム名形式は `first200CharsOfJobDefinitionName/default/ecs_task_id` です。この形式は将来変わる可能性があります。 ジョブが `RUNNING` ステータスになったら、[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API オペレーションを使用してそのログストリーム名をプログラムで取得できます。詳しくは、*Amazon CloudWatch Logs ユーザーガイド*の[CloudWatch Logs に送信されたログデータを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)を参照してください。デフォルトでは、これらのログには有効期限はありません。ただし、保存期間を変更することは可能です。詳細については、*Amazon CloudWatch Logs ユーザーガイド*の [CloudWatch Logs でのログデータ保管期間の変更](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) を参照してください。 `SUCCEEDED` ジョブは、終了コード `0` で正常に完了しました。ジョブの`SUCCEEDED`ジョブ状態は、少なくとも 7 日間 AWS Batch に保持されます。 `SUCCEEDED` ジョブのログは クラウドウォッチのログ(CloudWatch Logs) で確認できます。ロググループは `/aws/batch/job`、ログストリーム名形式は`first200CharsOfJobDefinitionName/default/ecs_task_id`です。この形式は将来に変更される可能性があります。 ジョブが `RUNNING` ステータスになったら、[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API オペレーションを使用してそのログストリーム名をプログラムで取得できます。詳しくは、*Amazon CloudWatch Logs ユーザーガイド*の[CloudWatch Logs に送信されたログデータを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)を参照してください。デフォルトでは、これらのログの有効期限はありません。ただし、保存期間を変更することは可能です。詳細については、*Amazon CloudWatch Logs ユーザーガイド*の [CloudWatch Logs でのログデータ保管期間の変更](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) を参照してください。 `FAILED` ジョブのすべての使用可能な試行が失敗しました。`FAILED` のジョブの状態は、少なくとも7日間 AWS Batch に保存されます。 `FAILED` ジョブのログは クラウドウォッチのログ(CloudWatch Logs) で確認できます。ロググループは `/aws/batch/job`、ログストリーム名形式は`first200CharsOfJobDefinitionName/default/ecs_task_id`です。この形式は将来に変更される可能性があります。 ジョブが `RUNNING` ステータスになったら、[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API オペレーションを使用してそのログストリームをプログラムで取得できます。詳しくは、*Amazon CloudWatch Logs ユーザーガイド*の[CloudWatch Logs に送信されたログデータを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)を参照してください。デフォルトでは、これらのログには有効期限はありません。ただし、保存期間を変更することは可能です。詳細については、*Amazon CloudWatch Logs ユーザーガイド*の [CloudWatch Logs でのログデータ保管期間の変更](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) を参照してください。 # AWS Batch ジョブ環境変数 AWS Batch は、コンテナジョブに特定の環境変数を設定します。これらの環境変数は、ジョブ内のコンテナに対するイントロスペクションを提供します。これらの変数の値は、アプリケーションのロジックで使用できます。が AWS Batch 設定するすべての変数は`AWS_BATCH_`、 プレフィックスで始まります。これは、保護された環境変数プレフィックスです。このプレフィックスは、ジョブ定義やオーバーライド内の独自の変数には使用できません。 ジョブコンテナでは、次の環境変数を使用できます。 `AWS_BATCH_CE_NAME` この変数は、ジョブが配置されるコンピューティング環境の名前に設定されます。 `AWS_BATCH_JOB_ARRAY_INDEX` この変数は、子配列ジョブでのみ設定されます。配列ジョブのインデックスは 0 から始まり、各子ジョブは一意のインデックス番号を受け取ります。例えば、10 の子を持つ配列ジョブのインデックス値は 0 〜 9 です。このインデックス値を使用して、配列ジョブの子がどのように区別されるかを制御できます。詳細については、[配列ジョブインデックスを使用してジョブの区別を制御する](array_index_example.md)を参照してください。 `AWS_BATCH_JOB_ARRAY_SIZE` この変数は、親配列ジョブのサイズに設定されます。親配列ジョブのサイズは、この変数の子配列ジョブに渡されます。 `AWS_BATCH_JOB_ATTEMPT` この変数は、ジョブ試行番号に設定されます。最初の試行番号は 1 となります。詳細については、「[ジョブの再試行の自動化](job_retries.md)」を参照してください。 `AWS_BATCH_JOB_ID` この変数は AWS Batch ジョブ ID に設定されます。 `AWS_BATCH_JOB_KUBERNETES_NODE_UID` この変数は、ポッドが実行されている Kubernetes クラスター内にあるノードオブジェクトの Kubernetes クラスター UID として設定されます。この変数は、Amazon EKS リソースで実行されるジョブにのみ設定されます。詳細については、「*Kubernetes ドキュメンテーション*」の「[UID](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)」を参照してください。 `AWS_BATCH_JOB_MAIN_NODE_INDEX` この変数はマルチノード並列ジョブの子ノードでのみ設定されます。この変数は、ジョブの主要なノードのインデックス番号に設定されます。アプリケーションコードは、`AWS_BATCH_JOB_MAIN_NODE_INDEX` と `AWS_BATCH_JOB_NODE_INDEX` を単一ノードで比較して、これが主要なノードであるかを確認できます。 `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` この変数はマルチノード並列ジョブの子ノードでのみ設定されます。この変数はメインノードには存在しないが、ジョブのメインノードのプライベートIPv4アドレスに設定されます。子ノードのアプリケーションコードは、このアドレスを使用して主要なノードと通信できます。 `AWS_BATCH_JOB_NODE_INDEX` この変数はマルチノード並列ジョブの子ノードでのみ設定されます。この変数は、ノードのノードインデックス番号に設定されます。ノードインデックスは 0 で始まり、各ノードは一意のインデックス番号を受け取ります。例えば、10 の子を持つマルチノード並列ジョブのインデックス値は 0 〜 9 です。 `AWS_BATCH_JOB_NUM_NODES` この変数はマルチノード並列ジョブの子ノードでのみ設定されます。この変数は、マルチノード並列ジョブにリクエストしたノードの数に設定されます。 `AWS_BATCH_JQ_NAME` この変数は、ジョブが送信されたジョブキューの名前に設定されます。 # ジョブの再試行の自動化 ジョブおよびジョブ定義に再試行戦略を適用し、失敗したジョブを自動的に再試行できます。考えられる故障のシナリオは以下の通りです： + コンテナジョブのゼロ以外の終了コード + Amazon EC2 インスタンスの障害または終了 + 内部 AWS サービスエラーまたは停止 ジョブがジョブキューに送信されて `RUNNING` 状態になると、1 回の試行とみなされます。デフォルトでは、各ジョブは 1 回の試行で `SUCCEEDED` または `FAILED` のいずれかの状態に移行します。ただし、ジョブ定義とジョブ送信の両方のワークフローで、1〜10 回の再試行戦略を指定できます。[EvaluateOnExit](job_definition_parameters.md#retryStrategy-evaluateOnExit) を指定すると、最大 5 つの再試行戦略を含めることができます。[EvaluateOnExit](https://docs.aws.amazon.com/batch/latest/APIReference/API_EvaluateOnExit.html)が指定されているが、いずれの再試行方法も一致しない場合、ジョブは再試行されます。終了と一致しないジョブについては、何らかの理由で終了する最後のエントリを追加します。例えば、`evaluateOnExit` このオブジェクトには、アクションがの 2 `RETRY` つのエントリと、`EXIT` アクションがの最後のエントリがあります。 ``` "evaluateOnExit": [ { "action": "RETRY", "onReason": "AGENT" }, { "action": "RETRY", "onStatusReason": "Task failed to start" }, { "action": "EXIT", "onReason": "*" } ] ``` ランタイムに、`AWS_BATCH_JOB_ATTEMPT` 環境変数がコンテナの対応するジョブ試行番号に設定されます。最初の試行は `1` 番となり、後続の試行は昇順の番号 (2、3、4 など) になります。 例えば、何らかの理由でジョブの試行が失敗し、再試行設定で指定されている試行回数がその `AWS_BATCH_JOB_ATTEMPT` 回数よりも多いとします。その後、ジョブは元の `RUNNABLE` 状態に戻ります。詳細については、[ジョブの状態](job_states.md)を参照してください。 **注記** ジョブをキャンセルまたは終了した場合、ジョブは再試行されません。無効なジョブ定義のためにジョブが失敗した場合も、ジョブは再試行されません。 詳細については、[再試行戦略](job_definition_parameters.md#retryStrategy)、[シングルノードのジョブ定義を作成する](create-job-definition.md)、[チュートリアル: ジョブを送信する](submit_job.md) および[停止したタスクのエラーコード](https://docs.aws.amazon.com/AmazonECS/latest/userguide/stopped-task-error-codes.html) を参照してください。 # ジョブの依存関係 AWS Batch ジョブを送信するときに、ジョブが依存するジョブ IDs を指定できます。これを行うと、ス AWS Batch ケジューラは、指定された依存関係が正常に完了した後にのみジョブが実行されるようにします。成功すると、依存するジョブが `PENDING` から `RUNNABLE` に移行し、その後 `STARTING`、`RUNNING` と移行します。いずれかのジョブ依存関係が失敗すると、依存するジョブは自動的に `PENDING` から `FAILED` に移行します。 例えば、ジョブ A は実行前に成功する必要がある他のジョブとの依存関係を最大 20 個記述できます。その後、ジョブ A および他の 19 個のジョブに依存する追加ジョブを送信できます。 配列ジョブの場合、ジョブ ID を指定せずに `SEQUENTIAL` タイプの依存関係を指定できます。こうすることで各子配列ジョブがインデックス 0 から開始して連続的に完了します。また、ジョブ ID を使用して `N_TO_N` タイプの依存関係を指定することもできます。この場合、このジョブの各インデックスの子は各依存関係の対応するインデックスの子が完了するまで待機してから開始されます。詳細については、「[配列ジョブ](array_jobs.md)」を参照してください。 依存関係を持つ AWS Batch ジョブを送信するには、「」を参照してください[チュートリアル: ジョブを送信する](submit_job.md)。 [リソース認識型スケジューリング](resource-aware-scheduling.md) では、ジョブの実行に必要な消費型リソースに基づいてジョブをスケジュールできます。ジョブの実行に必要な消費型リソースを指定すると、Batch はジョブをスケジュールするときにこれらのリソースの依存関係を考慮します。必要なすべてのリソースが利用可能なジョブのみを割り当てることで、コンピューティングリソースの使用率の低下を抑制できます。リソース対応スケジューリングは、FIFO スケジューリングポリシーと公平配分スケジューリングポリシーの両方で使用でき、EKS、ECS、Fargate など、Batch でサポートされているすべてのコンピューティングプラットフォームで使用できます。配列ジョブ、マルチノード並列 (MNP) ジョブ、および通常の Batch ジョブで使用できます。 # ジョブのタイムアウト この期間を超えてジョブが実行されると AWS Batch でジョブが終了するように、ジョブのタイムアウト期間を設定できます。例えば、15 分で完了することがわかっているジョブがあるとします。アプリケーションがループ状態に止まり、永続的に実行される場合に、止まったジョブを終了するためにタイムアウトを 30 分に設定できます。 **重要** デフォルトでは、 AWS Batch にはジョブのタイムアウトはありません。ジョブタイムアウトを定義しない場合、ジョブはコンテナが終了するまで実行されます。 `attemptDurationSeconds` パラメータを指定します。ジョブ定義の際、またはジョブ送信時に行い、60 秒以上にする必要があります。ジョブ試行の`startedAt`タイムスタンプの後にこの秒数が経過すると、 はジョブ AWS Batch を終了します。コンピューティングリソースで、ジョブのコンテナは `SIGTERM` シグナルを受け取り、アプリケーションが適切にシャットダウンできるようにします。30 秒後にコンテナがまだ実行されている場合、`SIGKILL` シグナルが送信されてコンテナを強制的にシャットダウンします。 タイムアウトの終了はベストエフォートベースで処理されます。ジョブ試行がタイムアウトするタイミングでタイムアウトが終了するとは限りません (数秒長くかかることがあります)。アプリケーションで正確にタイムアウトを実行する必要がある場合は、アプリケーション内にこのロジックを実装します。多数のジョブを同時にタイムアウトする場合、タイムアウトの終了は先入れ先出しキューとして行われ、ジョブはバッチで終了します。 **注記** AWS Batch ジョブの最大タイムアウト値はありません。 タイムアウト期間の超過で終了したジョブは再試行されません。ジョブ自体が原因でジョブ試行に失敗した場合、再試行が有効であれば再試行され、新しいジョブ試行のタイムアウトカウントダウンが開始します。 **重要** Fargate リソースで実行されるジョブは、14 日を超えて実行することはできません。タイムアウト期間が 14 日を超えると、Fargate リソースが使用できなくなり、ジョブが終了します。 配列ジョブの場合、子ジョブは、親ジョブと同様にタイムアウト設定されています。 タイムアウト設定で AWS Batch ジョブを送信する方法については、「」を参照してください[チュートリアル: ジョブを送信する](submit_job.md)。 # Amazon EKS ジョブ ジョブは、作業の最小単位です AWS Batch。Amazon EKS の AWS Batch ジョブには、ポッドへの one-to-one Kubernetes のマッピングがあります。 AWS Batch ジョブ定義は、 AWS Batch ジョブのテンプレートです。 AWS Batch ジョブを送信するときは、ジョブ定義を参照し、ジョブキューをターゲットにして、ジョブの名前を指定します。Amazon EKS の AWS Batch ジョブのジョブ定義では、[eksProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) パラメータは、Amazon EKS AWS Batch ジョブで がサポートするパラメータのセットを定義します。[SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) リクエストでは、[eksPropertiesOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html) パラメーターを使用するといくつかの一般的なパラメーターをオーバーライドできます。これにより、複数のジョブにジョブ定義のテンプレートを使用できます。ジョブが Amazon EKS クラスターにディスパッチされると、 はジョブを `podspec` () AWS Batch に変換します`Kind: Pod`。は、いくつかの追加の AWS Batch パラメータ`podspec`を使用して、ジョブが正しくスケーリングおよびスケジュールされるようにします。 AWS Batch はラベルとテイントを組み合わせて、ジョブが AWS Batch マネージドノードでのみ実行され、他のポッドがそれらのノードで実行されないようにします。 **重要** Amazon EKS ジョブ定義で `hostNetwork`パラメータが明示的に設定されていない場合、 のポッドネットワークモードは AWS Batch デフォルトでホストモードになります。具体的には、`hostNetwork=true` と `dnsPolicy=ClusterFirstWithHostNet` という設定が適用されます。 AWS Batch は、ポッドがジョブを完了するとすぐにジョブポッドをクリーンアップします。ポッドアプリケーションログを表示するには、クラスターのロギングサービスを設定します。詳細については、「[CloudWatch Logs を使用して Amazon EKS ジョブ AWS Batch をモニタリングする](batch-eks-cloudwatch-logs.md)」を参照してください。 **Topics** + [チュートリアル: 実行中のジョブをポッドとノードにマップする](eks-jobs-map-running-job.md) + [チュートリアル: 実行中のポッドをそのジョブにマップし直す](eks-jobs-map-running-pod-to-job.md) # チュートリアル: 実行中のジョブをポッドとノードにマップする 実行中のジョブの `podProperties` には現在のジョブ試行用に `podName` と `nodeName` のパラメータが設定されています。これらのパラメータを表示するには、[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API オペレーションを使用してください。 以下は出力の例です。 ``` $ aws batch describe-jobs --job 2d044787-c663-4ce6-a6fe-f2baf7e51b04 { "jobs": [ { "status": "RUNNING", "jobArn": "arn:aws:batch:us-east-1:123456789012:job/2d044787-c663-4ce6-a6fe-f2baf7e51b04", "jobDefinition": "arn:aws:batch:us-east-1:123456789012:job-definition/MyJobOnEks_SleepWithRequestsOnly:1", "jobQueue": "arn:aws:batch:us-east-1:123456789012:job-queue/My-Eks-JQ1", "jobId": "2d044787-c663-4ce6-a6fe-f2baf7e51b04", "eksProperties": { "podProperties": { "nodeName": "ip-192-168-55-175.ec2.internal", "containers": [ { "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "resources": { "requests": { "cpu": "1", "memory": "1024Mi" } } } ], "podName": "aws-batch.b0aca953-ba8f-3791-83e2-ed13af39428c" } } } ] } ``` リトライが有効なジョブの場合、`podName`、`nodeName` の完了したすべての試行の終了は [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API `eksAttempts` オペレーションのリストパラメータに含まれます。現在実行中の `podName`、`nodeName` の試行の終了は `podProperties` オブジェクト内にあります。 # チュートリアル: 実行中のポッドをそのジョブにマップし直す ポッドには、それが属するコンピューティング環境`uuid`の `jobId`と を示すラベルがあります。 AWS Batch は、ジョブのランタイムがジョブ情報を参照できるように環境変数を挿入します。詳細については、「[AWS Batch ジョブ環境変数](job_env_vars.md)」を参照してください。以下のコマンドを実行すれば、この情報を見ることができる。出力は次のとおりです。 ``` $ kubectl describe pod aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1 -n my-aws-batch-namespace Name: aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1 Namespace: my-aws-batch-namespace Priority: 0 Node: ip-192-168-45-88.ec2.internal/192.168.45.88 Start Time: Wed, 26 Oct 2022 00:30:48 +0000 Labels: batch.amazonaws.com/compute-environment-uuid=5c19160b-d450-31c9-8454-86cf5b30548f batch.amazonaws.com/job-id=f980f2cf-6309-4c77-a2b2-d83fbba0e9f0 batch.amazonaws.com/node-uid=a4be5c1d-9881-4524-b967-587789094647 ... Status: Running IP: 192.168.45.88 IPs: IP: 192.168.45.88 Containers: default: Image: public.ecr.aws/amazonlinux/amazonlinux:2 ... Environment: AWS_BATCH_JOB_KUBERNETES_NODE_UID: a4be5c1d-9881-4524-b967-587789094647 AWS_BATCH_JOB_ID: f980f2cf-6309-4c77-a2b2-d83fbba0e9f0 AWS_BATCH_JQ_NAME: My-Eks-JQ1 AWS_BATCH_JOB_ATTEMPT: 1 AWS_BATCH_CE_NAME: My-Eks-CE1 ... ``` **AWS Batch Amazon EKS ジョブがサポートする機能** 以下は、Amazon EKS で実行されるKubernetesジョブにも共通する AWS Batch 特定の機能です。 + [ジョブの依存関係](job_dependencies.md) + [配列ジョブ](array_jobs.md) + [ジョブのタイムアウト](job_timeouts.md) + [ジョブの再試行の自動化](job_retries.md) + [公平配分スケジューリングを使用してジョブをスケジュールする](fair-share-scheduling.md) **Kubernetes および `Secrets` `ServiceAccounts`** AWS Batch は、 Kubernetes`Secrets`および の参照をサポートしています`ServiceAccounts`。サービスアカウントの Amazon EKS IAM ロールを使用するようにポッドを設定できます。詳細については、[https://docs.aws.amazon.com/eks/latest/userguide/](https://docs.aws.amazon.com/eks/latest/userguide/) の [Kubernetes サービスアカウントを使用するポッドの設定](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html) を参照してください。 **関連ドキュメント** + [Amazon EKS の AWS Batch におけるメモリと vCPU に関する考慮事項](memory-cpu-batch-eks.md) + [GPU ジョブを実行する](gpu-jobs.md) + [`RUNNABLE` 状態でジョブが止まる](job_stuck_in_runnable.md) # マルチノード並列ジョブ マルチノード並列ジョブでは、複数の Amazon EC2 インスタンスにまたがる単一のジョブを実行できます。 AWS Batch のマルチノード並列ジョブ (*ギャングスケジューリング*とも呼ばれる) では、Amazon EC2 リソースを直接起動、設定、管理する必要なく、ラージスケールで密結合された高パフォーマンスのコンピューティングアプリケーションと分散された GPU モデルトレーニングを実行できます。 AWS Batch マルチノードの並列ジョブは、IP ベースのノード間通信をサポートするフレームワークと互換性があります。例としては、アパッチ MX ネット(Apache MXNet)、TensorFlow、Caffe2、メッセージパッシングインターフェイス (MPI) などがあります。 マルチノード並列ジョブは、単一のジョブとして送信されます。ただし、ジョブ定義 (あるいは、ジョブ送信ノードの上書き) は、ジョブに作成するノードの数および作成するノードグループを指定します。各マルチノード並列ジョブには**主要なノード**が含まれ、まずこれが起動されます。主要なノードが確立したら、子ノードが起動されて開始します。ジョブは、メインノードが終了した場合にのみ終了します。その後、すべての子ノードが停止します。詳細については、[ノードグループ](mnp-node-groups.md)を参照してください。 マルチノード並列ジョブは、シングルテナントです。つまり、各 Amazon EC2 インスタンスごとに、単一のジョブコンテナのみが実行されます。 最終的なジョブステータス (`SUCCEEDED` あるいは `FAILED`) は、主要なノードの最終的なジョブステータスによって決定されます。マルチノード並列ジョブのステータスを取得するには、ジョブの送信時に返されるジョブ ID を使用して、ジョブを記述できます。子ノードの詳細が必要な場合には、各子ノードごとに個別に記述する必要があります。ノードは `#N` 表記を使用して対処されます (0 から開始)。たとえば、ジョブの 2 番目のノードの詳細にアクセスするには、 AWS Batch [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API オペレーションを使用して *aws\$1batch\$1job\$1id*\$11 を記述します。マルチノード並列ジョブの `started`、`stoppedAt`、`statusReason`、`exit` 情報は、主要なノードから入力されます。 ジョブの再試行を指定した場合、メインノードに障害が発生すると、別の試行が行われます。子ノードに障害が発生しても、再試行回数は発生しません。マルチノード並列ジョブの新しい試行ごとに、関連付けられた子ノードに対応する試行が更新されます。 マルチノード並列ジョブを実行するには AWS Batch、アプリケーションコードに分散通信に必要なフレームワークとライブラリが含まれている必要があります。 **Topics** + [環境変数](mnp-env-vars.md) + [ノードグループ](mnp-node-groups.md) + [MNP ジョブのライフサイクル](job-lifecycle.md) + [を使用した MNP のコンピューティング環境に関する考慮事項 AWS Batch](mnp-ce.md) # 環境変数 実行時に、各ノードには、すべての AWS Batch ジョブが受け取る標準環境変数が設定されます。さらに、ノードは、マルチノード並列ジョブに固有の次の環境変数で構成されます。 `AWS_BATCH_JOB_MAIN_NODE_INDEX` この変数は、ジョブの主要なノードのインデックス番号に設定されます。アプリケーションコードは、`AWS_BATCH_JOB_MAIN_NODE_INDEX` と `AWS_BATCH_JOB_NODE_INDEX` を単一ノードで比較して、これが主要なノードであるかを確認できます。 `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` この変数はマルチノード並列ジョブの子ノードでのみ設定されます。この変数は、メインノードには存在しません。この変数はメインノードには存在しないが、ジョブのメインノードのプライベートIPv4アドレスに設定されます。子ノードのアプリケーションコードは、このアドレスを使用して主要なノードと通信できます。 `AWS_BATCH_JOB_NODE_INDEX` この変数は、ノードのノードインデックス番号に設定されます。ノードインデックスは 0 で始まり、各ノードは一意のインデックス番号を受け取ります。例えば、10 の子を持つマルチノード並列ジョブのインデックス値は 0 〜 9 です。 `AWS_BATCH_JOB_NUM_NODES` この変数は、マルチノード並列ジョブにリクエストしたノードの数に設定されます。 # ノードグループ ノードグループとは、同じコンテナプロパティを共有するジョブノードの同一グループです。 では、ジョブごとに 5 つまでの個別のノードグループを指定できます。を使用して AWS Batch 、ジョブごとに最大 5 つの異なるノードグループを指定できます。 各グループでは、独自のコンテナイメージ、コマンド、環境変数などを持つことができます。例えば、`c5.xlarge` メインノードに 1 つのインスタンス、5 `c5.xlarge` つのインスタンスの子ノードに必要なジョブを送信できます。これらのノードグループはそれぞれ、ジョブごとに異なるコンテナイメージやコマンドを実行するように指定できます。 あるいは、ジョブ内のすべてのノードで 1つのノードグループを使用することもできます。さらに、アプリケーションコードではメインノードや子ノードなどのノードロールを区別できます。そのためには、`AWS_BATCH_JOB_MAIN_NODE_INDEX` 環境変数を `AWS_BATCH_JOB_NODE_INDEX` の独自の値と比較します。単一のジョブでは最大で 1000 までのノードを使用できます。これは、Amazon ECS クラスターのインスタンスのデフォルト制限です。この制限はリクエストに応じて増やすことができます。[この制限の引き上げをリクエストすることができます](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)。 **注記** 現在のところ、マルチノード並列ジョブのすべてのノードグループでは、同じインスタンスタイプを使用する必要があります。 # MNP ジョブのライフサイクル マルチノード並列ジョブを送信すると、ジョブは `SUBMITTED` ステータスになります。その後、ジョブは、ジョブの依存関係がすべて終了するのを待ちます。ジョブも `RUNNABLE` ステータスに移行します。最後に、 はジョブの実行に必要なインスタンス容量を AWS Batch プロビジョニングし、これらのインスタンスを起動します。 各マルチノード並列ジョブには**主要なノード**が含まれます。メインノードは、 が AWS Batch 監視して送信されたマルチノードジョブの結果を決定する単一のサブタスクです。主要なノードは最初に起動され、`STARTING` ステータスに移行します。`attemptDurationSeconds` パラメータで指定されたタイムアウト値は、ジョブ全体に適用され、ノードには適用されません。 主要なノードが `RUNNING` ステータスに到達すると (ノードのコンテナが実行されてから)、子ノードが起動され、これもまた `STARTING` ステータスに移行します。子ノードはランダムな順序で始まります。子ノードの起動のタイミングや順序は保証できません。ジョブのすべてのノードが `RUNNING` ステータスにあること (ノードのコンテナが実行されたあと) を確認するには、アプリケーションコードで AWS Batch API をクエリして主要なノードおよび子ノードの情報を取得するか、あるいはアプリケーションコード内で整合して、分散された処理タスクを開始する前にすべてのノードがオンラインになるまで待機することができます。あるいは、アプリケーションコードは、すべてのノードがオンラインになるまで待ってから、分散処理タスクを開始することもできます。主要なノードのプライベート IP アドレスは、子ノードごとの `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` 環境変数で利用可能です。アプリケーションコードでは、この情報を各タスク間の整合と通信に使用できます。 個別のノードが存在する場合、これらは終了コードに応じて `SUCCEEDED` あるいは `FAILED` に移行します。主要なノードが終了すると、ジョブは完了したと見なされ、すべての子ノードは停止します。子ノードが死亡した場合、 AWS Batch はジョブ内の他のノードに対してアクションを実行しません。ノード数を減らしてジョブを続行しない場合、これをアプリケーションコードに組み来み、ジョブを終了あるいはキャンセルする必要があります。これを行うと、ジョブは終了またはキャンセルされます。 # を使用した MNP のコンピューティング環境に関する考慮事項 AWS Batch AWS Batchでマルチノード並列ジョブを実行するためのコンピューティング環境を設定するときに、いくつかの考慮事項があります。 + マルチノード並列ジョブは、スポットインスタンスを使用する `UNMANAGED` コンピューティング環境ではサポートされていません。 + マルチノード並列ジョブをコンピューティング環境に送信する場合、単一のアベイラビリティゾーンで*クラスター*プレースメントグループを作成して、これをコンピューティングリソースに関連付けることを検討します。これにより、論理的グループ化されたインスタンス上のマルチノード並列ジョブが、潜在的に高度なネットワークフローにより近くなります。詳細については、*Amazon EC2 ユーザーガイド*の[プレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)を参照してください。 + マルチノード並列ジョブは、スポットインスタンスを使用するコンピューティング環境ではサポートされていません。 + AWS Batch マルチノード並列ジョブは Amazon ECS `awsvpc`ネットワークモードを使用します。これにより、マルチノード並列ジョブコンテナに Amazon EC2 インスタンスと同じネットワークプロパティが提供されます。各マルチノード並列ジョブコンテナは、独自の Elastic Network Interface、プライマリプライベート IP アドレス、および内部の DNS ホスト名を取得します。ネットワークインターフェイスは、ホストコンピューティングリソースと同じ VPC サブネットで作成されます。 + コンピューティング環境には、最大で 5 つまでのセキュリティグループが関連付けられている場合があります。MNP タスクに作成およびアタッチされたエラスティックネットワークインターフェイスは、コンピューティング環境で指定されたセキュリティグループを使用します。セキュリティグループを指定しない場合、VPC のデフォルトのセキュリティグループが使用されます。 + `awsvpc` ネットワークモードでは、マルチノード並列ジョブ用にパブリック IP アドレスを使用する Elastic Network Interface を用意していません。インターネットにアクセスするには、NAT ゲートウェイを使用するよう設定されたプライベートサブネットでコンピューティングリソースを起動する必要があります。詳細については、*Amazon VPC ユーザーガイド* の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) を参照してください。ノード間の通信には、プライベート IP アドレス、あるいはノードの DNS ホスト名を使用する必要があります。パブリックサブネット内のコンピューティングリソースで実行されるマルチノード並列ジョブには、アウトバウンドのネットワークアクセスがありません。プライベートサブネットの VPC および NAT ゲートウェイを作成するには、[仮想プライベートクラウドを作成する](create-public-private-vpc.md)を参照してください。 + 作成されてコンピューティングリソースにアタッチされた Elastic Network Interface は、手動でデタッチしたり、ユーザーのアカウントを使用して変更することはできません。これは、実行中のジョブに関連付けられている Elastic Network Interface が誤って削除されることを回避するためです。Elastic Network Interface を解放するには、ジョブを終了します。 + コンピューティング環境には、マルチノード並列ジョブをサポートするために十分な最大数の vCPU があることが必要です。 + Amazon EC2 インスタンスクォータには、ジョブを実行するために必要なインスタンスの数が含まれます。例えば、30 個のインスタンスを必要とするジョブで、リージョンではアカウントが 20 個のインスタンスのみを実行できる場合、このジョブは ステータスで停止します。そうなると、`RUNNABLE` ジョブは、ステータスのままになります。 + マルチノード並列ジョブでノードグループにインスタンスタイプを指定する場合、コンピューティング環境がそのインスタンスタイプを起動できることが必要です。 # Amazon EKS のマルチノード並列ジョブ Amazon Elastic Kubernetes Service AWS Batch で を使用して、マネージドKubernetesクラスターでマルチノード並列 (MNP) ジョブ (*ギャングスケジューリング*とも呼ばれます) を実行できます。このオプションは一般に、単一の Amazon Elastic Compute Cloud インスタンスでは実行できない、大規模で密結合されたハイパフォーマンスのジョブに使用されます。詳細については、「[マルチノード並列ジョブ](multi-node-parallel-jobs.md)」を参照してください。 この機能を使用して、Amazon EKS マネージドの Kubernetes 固有の高性能コンピューティングアプリケーション、大規模言語モデルトレーニング、その他の人工知能 (AI)/機械学習 (ML) ジョブを実行できます。 **Topics** + [MNP ジョブの実行](mnp-eks-running-mnp-jobs.md) + [Amazon EKS MNP ジョブ定義を作成する](mnp-eks-create-eks-mnp-job-definition.md) + [Amazon EKS MNP ジョブを送信する](mnp-eks-submit-eks-mnp-job.md) + [Amazon EKS MNP ジョブ定義を上書きする](mnp-eks-override-eks-mnp-job-definition.md) # MNP ジョブの実行 AWS Batch は、Amazon EC2 を使用した Amazon Elastic Container Service および Amazon EKS での MNP ジョブをサポートします。以下で、この機能のインスタンスとコンテナパラメータの詳細を説明します。 ## Amazon EKS での MNP のインスタンスクォータ + 1 つの MNP ジョブに、最大 1,000 個のインスタンスを使用できます。 + 1 つの Amazon EKS クラスターに最大 5,000 個のインスタンスが参加できます。 + 最大 5 つのコンピューティング環境をクラスター化して、ジョブキューにアタッチできます。 例えば、1 つのジョブキューにクラスター化されたコンピューティング環境を 5 つまで、各コンピューティング環境に 1,000 インスタンスまでスケールアップできます。 インスタンスのパラメータに加えて、どちらのサービスでも MNP ジョブに Fargate を使用できないことに注意してください。 MNP ジョブごとに使用できるインスタンスタイプは 1 つのみです。インスタンスタイプは、コンピューティング環境の更新時、または新しいコンピューティング環境の定義時に変更できます。また、インスタンスタイプを指定し、ジョブ定義の作成時に vCPU とメモリの要件を指定することもできます。 ## Amazon EKS での MNP コンテナクォータ + マルチノード並列ジョブでは、ノードごとに 1 つのポッドがサポートされます。 + ポッドごとに最大 10 個のコンテナ (または 10 個の init コンテナ。詳細については、*Kubernetes のドキュメント*の「[Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)」を参照してください)。 + MNP ジョブごとに最大 5 つのノード範囲。 + ノード範囲ごとに最大 10 個の個別のコンテナイメージ。 例えば、5 つのノード範囲と合計 50 個の一意のイメージを含む 1 つの MNP ジョブでは最大 10,000 個のコンテナを実行できます。 ## プライベート Amazon VPC と Amazon EKS クラスターでの MNP ジョブの実行 MNP ジョブは任意の Amazon EKS クラスターで、パブリックインターネットの有無にかかわらず実行できます。プライベートネットワークアクセスのみを持つ Amazon EKS クラスターを使用する場合は、 AWS Batch が Amazon EKS コントロールプレーンとマネージド Kubernetes API サーバーにアクセスできることを確認してください。Amazon Virtual Private Cloud エンドポイントを通じて必要なアクセス権限を付与できます。詳細については、「[エンドポイントサービスを設定する](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html)」を参照してください。 プライベート VPC にはインターネットアクセスがないため、Amazon EKS のクラスターポッドはパブリックソースからイメージをダウンロードできません。Amazon EKS クラスターは Amazon VPC 内のコンテナレジストリからイメージを取得する必要があります。Amazon VPC に [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) を作成し、コンテナイメージをここにコピーすることでノードにアクセスできます。 また、Amazon ECR を使用してプルスルーキャッシュルールを作成することもできます。外部パブリックレジストリのプルスルーキャッシュルールが作成されたら、Amazon ECR プライベートレジストリ URI を使用して、その外部パブリックレジストリからイメージをプルします。その後、Amazon ECR でリポジトリが作成され、イメージがキャッシュされます。キャッシュされたイメージが Amazon ECR プライベートレジストリ URI を使用してプルされると、Amazon ECR はリモートレジストリをチェックしてイメージの新しいバージョンがあるかどうかを確認し、24 時間ごとに 1 回までプライベートレジストリを更新します。詳細については、「[Creating a pull through cache rule in Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html)」を参照してください。 ## エラー通知 MNP ジョブがブロックされると、 AWS マネジメントコンソール と Amazon EventBridge を通じて通知を受け取ることができます。例えば、MNP ジョブがキューの先頭で停止した場合、問題とその原因に関する情報の通知を受け取り、迅速にアクションを起こしてジョブキューのブロックを解除できます。または、特定の時間内にアクションを実行しない場合、MNP ジョブを自動的に終了することもできます。この時間はジョブキューテンプレートで定義できます。詳細については、[ジョブキューのブロックイベント](batch-job-queue-blocked-events.md) を参照してください。 # Amazon EKS MNP ジョブ定義を作成する Amazon EKS で MNP ジョブを定義して実行するため、[https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html) と [https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) API オペレーション内に新しいパラメータができました。 + [https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html) セクションの [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) を使用すると MNP ジョブ定義を定義できます。 + [https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html](https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html) セクションの [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html) を使用すると、MNP ジョブを送信するときに、ジョブ定義で定義されたパラメータを上書きできます。 これらのアクションは、API オペレーションと AWS マネジメントコンソールを使用して定義できます。 ## リファレンス: Amazon EKS MNP ジョブ定義リクエストのペイロードを登録する 以下の例は、Amazon EKS MNP ジョブ定義を 2 つのノードに登録する方法を示しています。 ``` { "jobDefinitionName": "MyEksMnpJobDefinition", "type": "multinode", "nodeProperties": { "numNodes": 2, "mainNode": 0, "nodeRangeProperties": [ { "targetNodes" : "0:", "eksProperties": { "podProperties": { "containers": [ { "name": "test-eks-container-1", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "command": [ "sleep", "60" ], "resources": { "limits": { "cpu": "1", "memory": "1024Mi" } }, "securityContext":{ "runAsUser":1000, "runAsGroup":3000, "privileged":true, "readOnlyRootFilesystem":true, "runAsNonRoot":true } } ], "initContainers": [ { "name":"init-ekscontainer", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "command": [ "echo", "helloWorld" ], "resources": { "limits": { "cpu": "1", "memory": "1024Mi" } } } ], "metadata": { "labels": { "environment" : "test" } } } } } ] } } ``` を使用してジョブ定義を登録するには AWS CLI、*MyEksMnpJobDefinition.json* という名前のローカルファイルに定義をコピーし、次のコマンドを実行します。 ``` aws batch register-job-definition --cli-input-json file://MyEksMnpJobDefinition.json ``` 以下のような JSON レスポンスを受け取ります。 ``` { "jobDefinitionName": "MyEksMnpJobDefinition", "jobDefinitionArn": "arn:aws:batch:us-east-1:0123456789:job-definition/MyEksMnpJobDefinition:1", "revision": 1 } ``` # Amazon EKS MNP ジョブを送信する 登録されたジョブ定義を使用してジョブを送信するには、以下のコマンドを入力します。 の値を、Amazon EKS コンピューティング環境に関連付けられた既存のジョブキューの名前または ARN に置き換えます。 ``` aws batch submit-job --job-queue \ --job-definition MyEksMnpJobDefinition \ --job-name myFirstEksMnpJob ``` 以下のような JSON レスポンスを受け取ります。 ``` { "jobArn": "arn:aws:batch:region:account:job/9b979cce-9da0-446d-90e2-ffa16d52af68", "jobName": "myFirstEksMnpJob", "jobId": "" } ``` 返された jobId と以下のコマンドを使用して、ジョブのステータスをチェックできます。 ``` aws batch describe-jobs --jobs ``` # Amazon EKS MNP ジョブ定義を上書きする 必要に応じて、ジョブ定義の詳細を上書きできます (MNP ジョブサイズや子ジョブの詳細の変更など)。以下は、5 ノードの MNP ジョブを送信するための JSON リクエストのペイロード例と、`test-eks-container-1` コンテナのコマンドの変更を示しています。 ``` { "numNodes": 5, "nodePropertyOverrides": [ { "targetNodes": "0:", "eksPropertiesOverride": { "podProperties": { "containers": [ { "name": "test-eks-container-1", "command": [ "sleep", "150" ] } ] } } } ] } ``` これらのオーバーライドを含むジョブを送信するには、例をローカルファイル *eks-mnp-job-nodeoverride.json* に保存し、 AWS CLI を使用してオーバーライドを含むジョブを送信します。 # 配列ジョブ 配列ジョブは、ジョブ定義、vCPU、メモリなどの共通パラメータを共有するジョブです。これは、関連しているが個別の基本ジョブのコレクションとして実行されます。複数のホストに分散されたり、同時に実行される場合もあります。配列ジョブは、モンテカルロシミュレーションジョブ、パラメータスイープジョブ、大規模なレンダリングジョブなど、大量の並列ジョブを実行するもっとも効率的な方法です。 AWS Batch 配列ジョブは、通常のジョブと同様に送信されます。ただし、配列内で実行する子ジョブの数を定義する配列サイズ (2 ～ 10,000) を指定します。配列サイズが 1,000 以内のジョブを送信する場合は、単一ジョブが実行され 1,000 個の子ジョブが生成されます。配列ジョブは、すべての子ジョブを管理するリファレンスまたはポインタです。これにより、1つのクエリで大量のワークロードを送信することができます。`attemptDurationSeconds`パラメータで指定されたタイムアウトは、それぞれの子ジョブに適用されます。親アレイジョブには、タイムアウトはありません。 配列ジョブを送信すると、親配列ジョブは通常の AWS Batch ジョブ ID を取得します。子ジョブのベース ID は、それぞれ同じです。各子ジョブは同じベース ID を持ちますが、子ジョブの配列インデックスが親 ID の末尾に付加されます。例えば、配列の最初の子ジョブは`example_job_ID:0`です。 親アレイジョブは、 `SUBMITTED`、 `PENDING`、`FAILED`、または `SUCCEEDED` ステータスを入力できます。アレイの親ジョブは、`PENDING` 子ジョブが `RUNNABLE` に更新されるとに更新されます。これらの依存関係の詳細については、[ジョブの依存関係](job_dependencies.md)を参照してください。 実行時、`AWS_BATCH_JOB_ARRAY_INDEX` 環境変数がコンテナの対応するジョブ配列インデックス番号に設定されます。最初の配列ジョブインデックスは `0` 番となり、後続の試行は昇順の番号 (1、2、3 など) になります。このインデックス値を使用して、配列ジョブの子がどのように区別されるかを制御できます。詳細については、[配列ジョブインデックスを使用してジョブの区別を制御する](array_index_example.md)を参照してください。 配列ジョブの依存関係では、依存関係のタイプを指定できます (`SEQUENTIAL` または `N_TO_N` など)。`SEQUENTIAL` タイプの依存関係 (ジョブ ID を指定しない) を指定できます。こうすることで各子配列ジョブがインデックス 0 から開始して連続的に完了します。例えば、配列サイズが 100 の配列ジョブを送信する場合、依存関係を `SEQUENTIAL` タイプに指定すると、100 個の子ジョブが連続押して生成され、最初の子ジョブが成功してから次の子ジョブが開始されます。以下の図で示すジョブ A は、配列サイズが 10 である配列ジョブです。ジョブ A の子インデックスの各ジョブは、前の子ジョブに依存します。ジョブ A:1 はジョブ A:0 が完了するまで開始できません。 ![\[Flowchart showing Job-A with sequential child jobs A:0 through A:9, connected by arrows.\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/images/sequential-dep.png) また、アレイジョブのジョブ ID を使用して `N_TO_N` タイプの依存関係を指定することもできます。この場合、このジョブの各インデックスの子は各依存関係の対応するインデックスの子が完了するまで待機してから開始されます。以下の図で示すジョブ A およびジョブ B は、配列サイズがそれぞれ 10,000 である 2 つの配列ジョブです。ジョブ B の子インデックスの各ジョブは、ジョブ A の対応するインデックスに依存します。ジョブ B:1 はジョブ A:1 が完了するまで開始できません。 ![\[Two array jobs, Job-A and Job-B, with 10,000 indexed tasks each, showing N_TO_N dependency.\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/images/n-to-n-dep.png) 親配列ジョブをキャンセルまたは終了した場合、子ジョブもすべてキャンセルまたは終了します。個々の子ジョブを、他の子ジョブに影響を与えずにキャンセルまたは終了できます (`FAILED` ステータスに移動させる)。ただし、子配列ジョブが失敗した場合 (それ自身の失敗または手動でキャンセルもしくは終了した場合)、親ジョブも失敗します。このシナリオでは、すべての子ジョブが完了すると、親ジョブは `FAILED` に移行します。 配列ジョブの検索とフィルタリングの詳細については、「」を参照してください[ジョブキュー内のジョブを検索する](searching-filtering-jobs.md)。 **Topics** + [配列ジョブワークフローの例](example_array_job.md) + [配列ジョブインデックスを使用してジョブの区別を制御する](array_index_example.md) # 配列ジョブワークフローの例 AWS Batch お客様にとって一般的なワークフローは、前提条件のセットアップジョブを実行し、多数の入力タスクに対して一連のコマンドを実行し、結果を集約して概要データを Amazon S3、DynamoDB、Amazon Redshift、または Aurora に書き込むジョブで終了することです。 例えば、次のようになります。 + `JobA`: 配列ではない標準的なジョブです。Amazon S3 バケット、`BucketA` 内のオブジェクトの高速リスト化およびメタデータ検証を実行します。[ジョブの JSON 送信構文](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) は、次のとおりです。 ``` { "jobName": "JobA", "jobQueue": "ProdQueue", "jobDefinition": "JobA-list-and-validate:1" } ``` + `JobB` : `JobA` に依存する 10,000 個のコピーを持つ配列ジョブです。CPU 負荷の高いコマンドを `BucketA` の各オブジェクトに対して実行し、結果を `BucketB` にアップロードします。[ジョブの JSON 送信構文](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) は、次のとおりです。 ``` { "jobName": "JobB", "jobQueue": "ProdQueue", "jobDefinition": "JobB-CPU-Intensive-Processing:1", "containerOverrides": { "resourceRequirements": [ { "type": "MEMORY", "value": "4096" }, { "type": "VCPU", "value": "32" } ] } "arrayProperties": { "size": 10000 }, "dependsOn": [ { "jobId": "JobA_job_ID" } ] } ``` + `JobC`: `JobB` に `N_TO_N` 依存関係モデルで依存する 10,000 個のコピーを持つ別の配列ジョブです。メモリ負荷の高いコマンドを `BucketB` の各項目に対して実行し、メタデータを DynamoDB に書き込んで、結果の出力を `BucketC` にアップロードします。[ジョブの JSON 送信構文](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) は、次のとおりです。 ``` { "jobName": "JobC", "jobQueue": "ProdQueue", "jobDefinition": "JobC-Memory-Intensive-Processing:1", "containerOverrides": { "resourceRequirements": [ { "type": "MEMORY", "value": "32768" }, { "type": "VCPU", "value": "1" } ] } "arrayProperties": { "size": 10000 }, "dependsOn": [ { "jobId": "JobB_job_ID", "type": "N_TO_N" } ] } ``` + `JobD`: 10 個の検証ステップを実行する配列ジョブです。検証ステップはそれぞれ DynamoDB にクエリする必要があり、上記の Amazon S3 バケットのいずれかとやり取りする可能性があります。の各ステップは同じコマンドを `JobD` 実行します。しかし、ジョブのコンテナ内の環境変数`AWS_BATCH_JOB_ARRAY_INDEX`の値によって動作は異な異なります。これらの検証ステップは順番に実行されます (例えば、`JobD:0` の次に `JobD:1`)。[ジョブの JSON 送信構文](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) は、次のとおりです。 ``` { "jobName": "JobD", "jobQueue": "ProdQueue", "jobDefinition": "JobD-Sequential-Validation:1", "containerOverrides": { "resourceRequirements": [ { "type": "MEMORY", "value": "32768" }, { "type": "VCPU", "value": "1" } ] } "arrayProperties": { "size": 10 }, "dependsOn": [ { "jobId": "JobC_job_ID" }, { "type": "SEQUENTIAL" }, ] } ``` + `JobE`: 最終的な配列ではないジョブです。シンプルなクリーンアップオペレーションをいくつか実行し、パイプラインが完了したことおよび出力 URL へのリンクを記載したメッセージを含む Amazon SNS 通知を送信します。[ジョブの JSON 送信構文](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) は、次のとおりです。 ``` { "jobName": "JobE", "jobQueue": "ProdQueue", "jobDefinition": "JobE-Cleanup-and-Notification:1", "parameters": { "SourceBucket": "s3://amzn-s3-demo-source-bucket", "Recipient": "pipeline-notifications@mycompany.com" }, "dependsOn": [ { "jobId": "JobD_job_ID" } ] } ``` # 配列ジョブインデックスを使用してジョブの区別を制御する このチュートリアルでは、`AWS_BATCH_JOB_ARRAY_INDEX` 環境変数を使用して子ジョブを区別する方法を説明します。各子ジョブは、この変数に割り当てられます。この例では、子ジョブのインデックス番号を使用して、ファイル内の特定の行を読み込みます。次に、その行番号に関連付けられたパラメータを、ジョブのコンテナ内のコマンドで置き換えます。その結果、同じ Docker イメージとコマンド引数を実行する複数の AWS Batch ジョブを持つことができます。ただし、配列ジョブインデックスが修飾子として使用されるため、結果が異なります。 このチュートリアルでは、虹のすべての色を持つテキストファイルを作成します。次に、インデックスをカラーファイルの行番号に使用できる値に変換する Dockerコンテナ 用のエントリポイントスクリプトを作成します。インデックスはゼロから始まりますが、行番号は 1 から始まります。カラーファイルとインデックスファイルをコンテナイメージにコピーし、イメージの `ENTRYPOINT` をエントリポイントスクリプトに設定する Dockerfile を作成します。Dockerfile とリソースは Amazon ECR にプッシュされる Docker イメージに組み込まれています。次に、新しいコンテナイメージを使用するジョブ定義を登録し、そのジョブ定義で AWS Batch 配列ジョブを送信して、結果を表示します。 **Topics** + [前提条件](array-tutorial-prereqs.md) + [コンテナイメージの構築](build-index-container.md) + [Amazon ECR にイメージをプッシュします](push-array-image.md) + [ジョブ定義を作成および登録する](create-array-job-def.md) + [AWS Batch 配列ジョブを送信する](submit-array-job.md) + [配列ジョブログを表示する](#array-tutorial-logs) # 前提条件 このチュートリアルのワークフローには、次のような前提条件があります。 + AWS Batch コンピューティング環境。詳細については、「[コンピューティング環境を作成する](create-compute-environment.md)」を参照してください。 + AWS Batch ジョブキューと関連するコンピューティング環境。詳細については、「[ジョブキューを作成する](create-job-queue.md)」を参照してください。 + ローカルシステムに AWS CLI インストールされている 。詳細については、「*AWS Command Line Interface ユーザーガイド*」の「[> AWS Command Line Interfaceのインストール](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)」を参照してください。 + Docker は、ローカルシステムにインストールされます。詳細については、Docker ドキュメントの[Docker CE について](https://docs.docker.com/install/)を参照してください。 # コンテナイメージの構築 コマンドパラメータのジョブ定義を `AWS_BATCH_JOB_ARRAY_INDEX` で使用できます。 ただし、エントリポイントスクリプトで変数を使用するコンテナイメージを作成することをお勧めします。このセクションでは、そのようなコンテナイメージを作成する方法について説明します。 **Docker コンテナイメージを構築するには** 1. Docker イメージワークスペースとして使用する新しいディレクトリを作成し、そのディレクトリに移動します。 1. WorkSpace ディレクトリで、`colors.txt`という名前のファイルを作成し、以下を貼り付けます。 ``` red orange yellow green blue indigo violet ``` 1. WorkSpace ディレクトリで、`print-color.sh`という名前のファイルを作成し、以下を貼り付けます。 **注記** 配列インデックスは 0 から始まり、行番号は 1 から始まるため、`LINE` 変数は `AWS_BATCH_JOB_ARRAY_INDEX` \$11 に設定されます。`COLOR` 変数は、行番号に関連付けられている`colors.txt`の色に設定されます。 ``` #!/bin/sh LINE=$((AWS_BATCH_JOB_ARRAY_INDEX + 1)) COLOR=$(sed -n ${LINE}p /tmp/colors.txt) echo My favorite color of the rainbow is $COLOR. ``` 1. WorkSpace ディレクトリで、`Dockerfile`という名前のファイルを作成し、以下を貼り付けます。この Dockerfile は、以前のファイルをコンテナにコピーし、コンテナの起動時に実行するようにエントリポイントスクリプトを設定します。 ``` FROM busybox COPY print-color.sh /tmp/print-color.sh COPY colors.txt /tmp/colors.txt RUN chmod +x /tmp/print-color.sh ENTRYPOINT /tmp/print-color.sh ``` 1. Docker イメージをビルドします。 ``` $ docker build -t print-color . ``` 1. 次のスクリプトを使用してコンテナをテストします。このスクリプトは、`AWS_BATCH_JOB_ARRAY_INDEX` 変数をローカルで 0 に設定し、それをインクリメントして 7 つの子 が を行う配列ジョブが何をするのかをシミュレートします。 ``` $ AWS_BATCH_JOB_ARRAY_INDEX=0 while [ $AWS_BATCH_JOB_ARRAY_INDEX -le 6 ] do docker run -e AWS_BATCH_JOB_ARRAY_INDEX=$AWS_BATCH_JOB_ARRAY_INDEX print-color AWS_BATCH_JOB_ARRAY_INDEX=$((AWS_BATCH_JOB_ARRAY_INDEX + 1)) done ``` 出力を次に示します。 ``` My favorite color of the rainbow is red. My favorite color of the rainbow is orange. My favorite color of the rainbow is yellow. My favorite color of the rainbow is green. My favorite color of the rainbow is blue. My favorite color of the rainbow is indigo. My favorite color of the rainbow is violet. ``` # Amazon ECR にイメージをプッシュします Docker コンテナを構築してテストしたので、それをイメージリポジトリにプッシュする必要があります。この例では Amazon ECR を使用していますが、DockerHub などの別のレジストリを使用することもできます。 1. コンテナイメージを保存する Amazon ECR イメージを作成します。この例では のみを使用していますが AWS CLI、 を使用することもできます AWS マネジメントコンソール。詳細については、*Amazon Elastic Container Registry ユーザーガイド*の[リポジトリの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)を参照してください。 ``` $ aws ecr create-repository --repository-name print-color ``` 1. 前のステップから返されたAmazon ECR リポジトリ URI を使用して、`print-color` イメージにタグを付けます。 ``` $ docker tag print-color aws_account_id.dkr.ecr.region.amazonaws.com/print-color ``` 1. Amazon ECR レジストリにログインします。詳細については、*Amazon Elastic Container Registry ユーザーガイド*の[レジストリの認証](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth)を参照してください。 ``` $ aws ecr get-login-password \ --region region | docker login \ --username AWS \ --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com ``` 1. Amazon ECR にイメージをプッシュします。 ``` $ docker push aws_account_id.dkr.ecr.region.amazonaws.com/print-color ``` # ジョブ定義を作成および登録する Docker イメージがイメージレジストリにあるので、 AWS Batch ジョブ定義で指定できます。次に、配列ジョブを実行するために後でそれを使用できます。この例では、 AWS CLIを使用します。ただし、 AWS マネジメントコンソールを使用することもできます。詳細については、「[シングルノードのジョブ定義を作成する](create-job-definition.md)」を参照してください。 **ジョブ定義を作成するには** 1. WorkSpace ディレクトリで、`print-color-job-def.json` という名前のファイルを作成し、以下を貼り付けます。イメージリポジトリの URI を自分のイメージの URI に置き換えます。 ``` { "jobDefinitionName": "print-color", "type": "container", "containerProperties": { "image": "aws_account_id.dkr.ecr.region.amazonaws.com/print-color", "resourceRequirements": [ { "type": "MEMORY", "value": "250" }, { "type": "VCPU", "value": "1" } ] } } ``` 1. ジョブ定義を に登録します AWS Batch。 ``` $ aws batch register-job-definition --cli-input-json file://print-color-job-def.json ``` # AWS Batch 配列ジョブを送信する ジョブ定義を登録したら、新しいコンテナイメージを使用する AWS Batch 配列ジョブを送信できます。 **AWS Batch 配列ジョブを送信するには** 1. WorkSpace ディレクトリで、`print-color-job.json`という名前のファイルを作成し、以下を貼り付けます。 **注記** この例では、[前提条件](array-tutorial-prereqs.md) セクションで説明したジョブキューを使用しています。 ``` { "jobName": "print-color", "jobQueue": "existing-job-queue", "arrayProperties": { "size": 7 }, "jobDefinition": "print-color" } ``` 1. ジョブを AWS Batch ジョブキューに送信します。出力で返されるジョブ ID を書き留めておいてください。 ``` $ aws batch submit-job --cli-input-json file://print-color-job.json ``` 1. ジョブのステータスを記述し、ジョブが `SUCCEEDED` に移動するのを待ちます。 ## 配列ジョブログを表示する ジョブが `SUCCEEDED` ステータスになったら、ジョブのコンテナから CloudWatch Logs を表示できます。 **CloudWatch Logs でジョブのログを表示するには** 1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) で AWS Batch コンソールを開きます。 1. 左のナビゲーションペインで **ジョブ** を選択します。 1. **Job queue]** (ジョブキュー) で、キューを選択します。 1. **Status]** (ステータス) セクションで、**succeeded]** (成功) を選択します。 1. 配列ジョブのすべての子ジョブを表示するには、前のセクションで返されたジョブ ID を選択します。 1. ジョブのコンテナからログを表示するには、子ジョブのいずれかを選択し、**View logs]** (ログの表示) を選択します。 ![\[Array ジョブコンテナログ\]](http://docs.aws.amazon.com/ja_jp/batch/latest/userguide/images/array-logs.png) 1. 他の子ジョブのログを表示します。各ジョブは、虹の別の色を返します。 # GPU ジョブを実行する GPU ジョブを使用して、インスタンスの GPU を使用するジョブを実行できます。 以下の Amazon EC2 GPU ベースのインスタンスタイプがサポートされています。詳細については、[Amazon EC2 G3 インスタンス](https://aws.amazon.com/ec2/instance-types/g3/)、[Amazon EC2 G4 インスタンス](https://aws.amazon.com/ec2/instance-types/g4/)、[Amazon EC2 G5 インスタンス](https://aws.amazon.com/ec2/instance-types/g5/)、[Amazon EC2 G6 インスタンス](https://aws.amazon.com/ec2/instance-types/g6/)、[Amazon EC2 P2 インスタンス](https://aws.amazon.com/ec2/instance-types/p2/)、[Amazon EC2 P3 インスタンス](https://aws.amazon.com/ec2/instance-types/p3/)、[Amazon EC2 P4d インスタンス](https://aws.amazon.com/ec2/instance-types/p4/)、[Amazon EC2 P5 インスタンス](https://aws.amazon.com/ec2/instance-types/p5/)、[Amazon EC2 P6 インスタンス](https://aws.amazon.com/ec2/instance-types/p6/)、[Amazon EC2 Trn1 インスタンス](https://aws.amazon.com/ec2/instance-types/trn1/)、[Amazon EC2 Trn2 インスタンス](https://aws.amazon.com/ec2/instance-types/trn2/)、[Amazon EC2 Inf1インスタンス](https://aws.amazon.com/ec2/instance-types/inf1/)、[Amazon EC2 Inf2 インスタンス](https://aws.amazon.com/ec2/instance-types/inf2/)、[Amazon EC2 Dl1 インスタンス](https://aws.amazon.com/ec2/instance-types/dl1/)、[Amazon EC2 Dl2 インスタンス](https://aws.amazon.com/ec2/instance-types/dl2q/) を参照してください。 | インスタンスタイプ | GPUs | GPU メモリ | vCPU | メモリ | ネットワーク帯域幅 | | --- | --- | --- | --- | --- | --- | | g3s.xlarge | 1 | 8 GiB | 4 | 30.5 GiB | 10 Gbps | | g3.4xlarge | 1 | 8 GiB | 16 | 122 GiB | 最大 10 Gbps | | g3.8xlarge | 2 | 16 GiB | 32 | 244 GiB | 10 Gbps | | g3.16xlarge | 4 | 32 GiB | 64 | 488 GiB | 25 Gbps | | g4dn.xlarge | 1 | 16 GiB | 4 | 16 GiB | 最大 25 Gbps | | g4dn.2xlarge | 1 | 16 GiB | 8 | 32 GiB | 最大 25 Gbps | | g4dn.4xlarge | 1 | 16 GiB | 16 | 64 GiB | 最大 25 Gbps | | g4dn.8xlarge | 1 | 16 GiB | 32 | 128 GiB | 50 Gbps | | g4dn.12xlarge | 4 | 64 GiB | 48 | 192 GiB | 50 Gbps | | g4dn.16xlarge | 1 | 16 GiB | 64 | 256 GiB | 50 Gbps | | g5.xlarge | 1 | 24 GiB | 4 | 16 GiB | 最大 10 Gbps | | g5.2xlarge | 1 | 24 GiB | 8 | 32 GiB | 最大 10 Gbps | | g5.4xlarge | 1 | 24 GiB | 16 | 64 GiB | 最大 25 Gbps | | g5.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbps | | g5.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbps | | g5.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gbps | | g5.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbps | | g5.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbps | | g5g.xlarge | 1 | 16 GiB | 4 | 8 GiB | 最大 10 Gbps | | g5g.2xlarge | 1 | 16 GiB | 8 | 16 GiB | 最大 10 Gbps | | g5g.4xlarge | 1 | 16 GiB | 16 | 32 GiB | 最大 10 Gbps | | g5g.8xlarge | 1 | 16 GiB | 32 | 64 GiB | 12 Gbps | | g5g.16xlarge | 2 | 32 GiB | 64 | 128 GiB | 25 Gbps | | g5g.metal | 2 | 32 GiB | 64 | 128 GiB | 25 Gbps | | g6.xlarge | 1 | 24 GiB | 4 | 16 GiB | 最大 10 Gbps | | g6.2xlarge | 1 | 24 GiB | 8 | 32 GiB | 最大 10 Gbps | | g6.4xlarge | 1 | 24 GiB | 16 | 64 GiB | 最大 25 Gbps | | g6.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbps | | g6.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbps | | g6.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gbps | | g6.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbps | | g6.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbps | | g6e.xlarge | 1 | 48 GiB | 4 | 32 GiB | 最大 20 Gbps | | g6e.2xlarge | 1 | 48 GiB | 8 | 64 GiB | 最大 20 Gbps | | g6e.4xlarge | 1 | 48 GiB | 16 | 128 GiB | 20 Gbps | | g6e.8xlarge | 1 | 48 GiB | 32 | 256 GiB | 25 Gbps | | g6e.16xlarge | 1 | 48 GiB | 64 | 512 GiB | 35 Gbps | | g6e.12xlarge | 4 | 192 GiB | 48 | 384 GiB | 100 Gbps | | g6e.24xlarge | 4 | 192 GiB | 96 | 768 GiB | 200 Gbps | | g6e.48xlarge | 8 | 384 GiB | 192 | 1536 GiB | 400 Gbps | | gr6.4xlarge | 1 | 24 GiB | 16 | 128 GiB | 最大 25 Gbps | | gr6.8xlarge | 1 | 24 GiB | 32 | 256 GiB | 25 Gbps | | p2.xlarge | 1 | 12 GiB | 4 | 61 GiB | 高 | | p2.8xlarge | 8 | 96 GiB | 32 | 488 GiB | 10 Gbps | | p2.16xlarge | 16 | 192 GiB | 64 | 732 GiB | 20 Gbps | | p3.2xlarge | 1 | 16 GiB | 8 | 61 GiB | 最大 10 Gbps | | p3.8xlarge | 4 | 64 GiB | 32 | 244 GiB | 10 Gbps | | p3.16xlarge | 8 | 128 GiB | 64 | 488 GiB | 25 Gbps | | p3dn.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 100 Gbps | | p4d.24xlarge | 8 | 320 GiB | 96 | 1152 GiB | 400 Gbps | | p4de.24xlarge | 8 | 640 GiB | 96 | 1152 GiB | 400 Gbps | | p5.48xlarge | 8 | 640 GiB | 192 | 2 TiB | 3200 Gbps | | p5e.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbps | | p5en.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbps | | p6-b200.48xlarge | 8 | 1440 GiB | 192 | 2 TiB | 100 Gbps | | trn1.2xlarge | 1 | 32 GiB | 8 | 32 GiB | 最大 12.5 Gbps | | trn1.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 800 Gbps | | trn1n.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 1600 Gbps | | trn2.48xlarge | 16 | 1.5 TiB | 192 | 2 TiB | 3.2 Tbps | | inf1.xlarge | 1 | 8 GiB | 4 | 8 GiB | 最大 25 Gbps | | inf1.2xlarge | 1 | 8 GiB | 8 | 16 GiB | 最大 25 Gbps | | inf1.6xlarge | 4 | 32 GiB | 24 | 48 GiB | 25 Gbps | | inf1.24xlarge | 16 | 128 GiB | 96 | 192 GiB | 100 Gbps | | inf2.xlarge | 1 | 32 GiB | 4 | 16 GiB | 最大 15 Gbps | | inf2.8xlarge | 1 | 32 GiB | 32 | 128 GiB | 最大 25 Gbps | | inf2.24xlarge | 6 | 192 GiB | 96 | 384 GiB | 50 Gbps | | inf2.48xlarge | 12 | 384 GiB | 192 | 768 GiB | 100 Gbps | | dl1.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 400 Gbps | | dl2q.24xlarge | 8 | 128 GiB | 96 | 768 GiB | 100 Gbps | **注記** GPU ジョブでは、NVIDIA GPUs を持つインスタンスタイプ AWS Batch のみをサポートします。例えば、[https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances) ファミリーは GPU スケジューリングではサポートされていません。ジョブ定義で vcpu とメモリの要件のみを定義し、Amazon ECS または Amazon EKS コンピューティング最適化 AMI、または AMD GPUs を使用するためのカスタマイズされた AMI を使用して Amazon EC2 [起動テンプレートのユーザーデータ](launch-templates.md#lt-user-data.title)をカスタマイズすることでホスト GPUs に直接アクセス AWS Batch することで、 [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances)で を引き続き使用できます。 Amazon EC2 ARM64 アーキテクチャを使用するインスタンスタイプは、カスタマイズされたコードと設定によって GPU にアクセスするために AWS Batch または Amazon EC2 ユーザーデータに提供されるカスタム AMIs の GPUs ジョブでサポートされています。例えば、[https://aws.amazon.com/ec2/instance-types/g5g/](https://aws.amazon.com/ec2/instance-types/g5g/) インスタンスファミリーです。 ジョブ定義の [[resourceRequirements]](job_definition_parameters.md#ContainerProperties-resourceRequirements) パラメータは、コンテナに固定される GPU の数を指定します。この GPU の数は、そのジョブの期間中にインスタンスで実行される他のジョブでは使用できません。GPU ジョブを実行するコンピューティング環境のすべてのインスタンスタイプは `p6`、`p3`、`p4`、`p5`、`g3`、`g3s`、`g4`、`g5`、`g6` インスタンスファミリーのいずれかにする必要があります。これを行わないと、GPU ジョブが `RUNNABLE` 状態で固まる可能性があります。 GPU を使用しないジョブは GPU インスタンスで実行できます。ただし、類似の GPU 以外のインスタンスで実行するよりも、GPU インスタンスで実行する方がコストがかかる場合があります。特定の vCPU、メモリ、および所要時間によっては、このような GPU を使用しないジョブによって GPU ジョブの実行がブロックされる場合があります。 **Topics** + [Amazon EKS で GPU ベースの Kubernetes クラスターを作成する](create-gpu-cluster-eks.md) + [Amazon EKS GPU ジョブ定義を作成する](create-eks-gpu-job-definition.md) + [Amazon EKS クラスターで GPU ジョブを実行する](run-gpu-job-eks-cluster.md) # Amazon EKS で GPU ベースの Kubernetes クラスターを作成する Amazon EKS で GPU ベースの Kubernetes クラスターを作成する前に、[Amazon EKS AWS Batch での の開始方法](getting-started-eks.md) のステップを完了しておく必要があります。また、次の操作を行います。 + AWS Batch では、NVIDIA GPUs。 + デフォルトでは、 は Amazon EKS クラスターコントロールプレーンKubernetesのバージョンに一致するバージョンで Amazon EKS 高速 AMI AWS Batch を選択します。 ``` $ cat < ./batch-eks-gpu-ce.json { "computeEnvironmentName": "My-Eks-GPU-CE1", "type": "MANAGED", "state": "ENABLED", "eksConfiguration": { "eksClusterArn": "arn:aws:eks:::cluster/", "kubernetesNamespace": "my-aws-batch-namespace" }, "computeResources": { "type": "EC2", "allocationStrategy": "BEST_FIT_PROGRESSIVE", "minvCpus": 0, "maxvCpus": 1024, "instanceTypes": [ "p3dn.24xlarge", "p4d.24xlarge" ], "subnets": [ "" ], "securityGroupIds": [ "" ], "instanceRole": "" } } EOF $ aws batch create-compute-environment --cli-input-json file://./batch-eks-gpu-ce.json ``` AWS Batch はユーザーに代わって NVIDIA GPU デバイスプラグインを管理しません。このプラグインを Amazon EKS クラスターにインストールし、 AWS Batch ノードをターゲットにする必要があります。詳細については、GitHub Kubernetes の[GPU Support の有効化](https://github.com/NVIDIA/k8s-device-plugin#enabling-gpu-support-in-kubernetes) を参照してください。 AWS Batch ノードをターゲットにするようにNVIDIAデバイスプラグイン (`DaemonSet`) を設定するには、次のコマンドを実行します。 ``` # pull nvidia daemonset spec $ curl -O https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.12.2/nvidia-device-plugin.yml # using your favorite editor, add Batch node toleration # this will allow the DaemonSet to run on Batch nodes - key: "batch.amazonaws.com/batch-node" operator: "Exists" $ kubectl apply -f nvidia-device-plugin.yml ``` コンピューティングベース (CPU とメモリ) のワークロードと GPU ベースのワークロードを、コンピューティング環境とジョブキューを同じ組み合わせで混在させることはお勧めしません。これは、コンピューティングジョブが GPU の容量を使い果たす可能性があるためです。 ジョブキューをアタッチするには、以下のコマンドを実行します。 ``` $ cat < ./batch-eks-gpu-jq.json { "jobQueueName": "My-Eks-GPU-JQ1", "priority": 10, "computeEnvironmentOrder": [ { "order": 1, "computeEnvironment": "My-Eks-GPU-CE1" } ] } EOF $ aws batch create-job-queue --cli-input-json file://./batch-eks-gpu-jq.json ``` # Amazon EKS GPU ジョブ定義を作成する 現時点では `nvidia.com/gpu` のみサポートされており、設定するリソース値は整数でなければなりません。GPU の一部を使用することはできません。詳細については、*Kubernetes ドキュメント* の [GPUのスケジュール](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/) を参照してください。 Amazon EKS に GPU ジョブ定義を登録するには、以下のコマンドを実行します。 ``` $ cat < ./batch-eks-gpu-jd.json { "jobDefinitionName": "MyGPUJobOnEks_Smi", "type": "container", "eksProperties": { "podProperties": { "hostNetwork": true, "containers": [ { "image": "nvcr.io/nvidia/cuda:10.2-runtime-centos7", "command": ["nvidia-smi"], "resources": { "limits": { "cpu": "1", "memory": "1024Mi", "nvidia.com/gpu": "1" } } } ] } } } EOF $ aws batch register-job-definition --cli-input-json file://./batch-eks-gpu-jd.json ``` # Amazon EKS クラスターで GPU ジョブを実行する GPU リソースは非圧縮です。 は GPU ジョブのポッド仕様 AWS Batch を作成します。**リクエスト**の値は**制限**の値と等しくなります。Kubernetes は必須です。 ジョブを再起動するには、以下のコマンドを実行します。 ``` $ aws batch submit-job --job-queue My-Eks-GPU-JQ1 --job-definition MyGPUJobOnEks_Smi --job-name My-Eks-GPU-Job # locate information that can help debug or find logs (if using Amazon CloudWatch Logs with Fluent Bit) $ aws batch describe-jobs --job | jq '.jobs[].eksProperties.podProperties | {podName, nodeName}' { "podName": "aws-batch.f3d697c4-3bb5-3955-aa6c-977fcf1cb0ca", "nodeName": "ip-192-168-59-101.ec2.internal" } ``` # AWS Batch ジョブキューでジョブを表示する AWS Batchでジョブを表示およびフィルタリングできます。この機能は、既存のジョブキューを表示し、そのジョブを 3 つのオプションのいずれかでフィルタリングするオプションを提供します。 検索とフィルターは、終了状態 (`SUCCEEDED` または `FAILED`) ではないジョブを取得できます。ジョブの状態が `SUCCEEDED` または `FAILED` になると、最大 7 日間ジョブを取得できるようになります。ジョブの CloudWatch または Amazon EventBridge ログは引き続き表示できます。 この手順を使用して、 AWS Batch コンソールのジョブキュー内のすべてのジョブを一覧表示します。必要に応じて、**[フィルター結果]** フィールドを使用して、指定した基準で結果を絞り込みます。 1. [AWS Batch コンソール](https://console.aws.amazon.com/batch/home)に移動します。 1. ナビゲーションペインで **[ジョブ]** を選択します。 1. **[ジョブキュー]** ドロップダウンリストを展開し、検索するジョブキューを選択します。 **注記** 一度に検索できるジョブキューは 1 つのみです。 1. Filter **results** フィールドに、結果に含めるキーワードを入力します。このフィールドを使用して、**ジョブ名**、**ステータス**、または**ジョブ ID** でフィルタリングできます。プロパティによっては、等号 (=) や包含 (:) など、定義する必要のある追加の演算子がある場合があります。 **注記** SageMaker トレーニングジョブキューは、**[ジョブ名]** と **[ジョブ ID]** によるフィルタリングのみをサポートします 1. **[検索]** を選択してください。 # ジョブキュー内のジョブ AWS Batch を検索する ジョブ検索 AWS Batch を使用して、 でジョブを検索およびフィルタリングできます。この機能は、既存のジョブキュー内で検索し、そのジョブをフィルタリングするオプションを提供します。 検索とフィルターは、終了状態 (`SUCCEEDED` または `FAILED`) ではないジョブを取得できます。ジョブの状態が `SUCCEEDED` または `FAILED` になると、最大 7 日間ジョブを取得できるようになります。ジョブの CloudWatch または Amazon EventBridge ログは引き続き表示できます。 複数の条件を同時に使用して検索するには、**[高度な検索]** 機能を使用します。例えば、**[ステータス]**、**[日付範囲]**、**[追加条件]** ([ジョブ名]、[ジョブ定義]、[ジョブ ID] など) のいずれかまたはすべてを含めることができます。 ## 検索 AWS Batch ジョブ (AWS コンソール) コンソールでジョブキュー内のジョブを検索するには、この手順を使用します AWS Batch 。 1. [AWS Batch コンソール](https://console.aws.amazon.com/batch/home)に移動します。 1. ナビゲーションペインで **[ジョブ]** を選択します。 1. **[高度な検索]** をオンにします。 1. **[ジョブキュー]** ドロップダウンリストを展開し、検索するジョブキューを選択します。 **注記** 一度に検索できるジョブキューは 1 つのみです。 1. **[検索オプション]** の場合: 1. **[ステータス]** ドロップダウンリストでは、フィルタリングするステータスを 1 つ以上選択できます。詳細については、「[ジョブの状態](job_states.md)」および「[サービスジョブのステータス](service-job-status.md)」を参照してください。 **注記** 配列ジョブの親は、子ジョブが に更新`PENDING`されると に更新`RUNNABLE`され、子ジョブの実行中に `PENDING`ステータスのままになります。これらのジョブを表示するには、すべての子ジョブが終了状態になるまで`PENDING`ステータスでフィルタリングします。 1. **[日付範囲]** を選択して、日付と時刻の範囲に基づいて結果をフィルタリングします。 + **[相対モード]** を選択すると、現在の日付と時刻からさかのぼった時間範囲に含まれる作成日を持つジョブを検索できます。 + **[絶対モード]** を選択すると、指定した日時の範囲に含まれる作成日を持つジョブを検索できます。 1. **[追加条件]** フィールドに、検索結果に含めるキーワードを入力します。たとえば、このフィールドを使用して、**ジョブ名**、**ジョブ定義**、**ジョブ ID**、または**共有識別子**で検索できます。プロパティによっては、等号 (=) や包含 (:) など、定義する必要のある追加の演算子がある場合があります。 **注記** SageMaker トレーニングジョブキューは、**[ジョブ名]** と **[ジョブ ID]** によるフィルタリングのみをサポートします **注記** **共有識別子**でフィルタリングする場合、ジョブのステータスを指定することもできます。これは、他のフィルターがジョブステータスフィルタリングを除外する制限の例外です。 1. **[検索]** を選択してください。 ## AWS Batch ジョブの検索とフィルタリング (AWS CLI) この手順を使用して、 AWS CLIでジョブキュー内のすべてのジョブを一覧表示します。必要に応じて、**-filters** パラメータを使用して、指定した基準で結果を絞り込みます。 ------ #### [ Search job queue (AWS CLI) ] [list-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-jobs.html) コマンドを使用して、ジョブキューを検索およびフィルタリングできます。 例えば、ジョブ名に基づいてジョブキューを検索できます。 ``` aws batch list-jobs \ --job-queue my-job-queue \ --filters name=JOB_NAME,values="my-job" ``` 共有識別子でジョブをフィルタリングします。 ``` aws batch list-jobs \ --job-queue my-job-queue \ --filters name=SHARE_IDENTIFIER,values="my-share" ``` 共有識別子でフィルタリングする場合、ジョブステータスを含めることができます。 ``` aws batch list-jobs \ --job-queue my-job-queue \ --job-status RUNNING \ --filters name=SHARE_IDENTIFIER,values="my-share" ``` 上のコマンドに、以下の変更を加えます。 + *my-job-queue* をジョブキューの名前に置き換えます。 + *my-job* をジョブの名前に置き換えます。 + *my-share* をフィルタリングする共有識別子に置き換えます。 ------ #### [ Search service job queue (AWS CLI) ] [list-service-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-service-jobs.html) コマンドを使用して、サービスジョブキューを検索およびフィルタリングできます。 例えば、ジョブ名に基づいてサービスジョブキューを検索できます。 ``` aws batch list-service-jobs \ --job-queue my-sm-queue \ --filters name=JOB_NAME,values="my-sm-job" ``` 共有識別子でサービスジョブをフィルタリングします。 ``` aws batch list-service-jobs \ --job-queue my-sm-queue \ --filters name=SHARE_IDENTIFIER,values="my-share" ``` 上のコマンドに、以下の変更を加えます。 + *my-sm-queue* をサービスジョブキューの名前に置き換えます。 + *my-sm-job* をサービスジョブに置き換えます。 + *my-share* をフィルタリングする共有識別子に置き換えます。 ------ # AWS Batch ジョブのネットワークモード 次の表に、 AWS Batch ジョブタイプのネットワークモードと一般的な使用方法を示します。考慮事項と動作の詳細については、「ジョブタイプ」列のリンクを参照してください。 | ジョブタイプ | サポートされているネットワークモード | 一般的な使用法 | | --- | --- | --- | | [ECS-EC2 シンプルジョブ](jobs.md) | host | コンピューティング環境で定義された vpc への出力のみを必要とする、最もスケーラブルで厄介な並列バッチワークロードに使用されます。 | | [ECS-EC2 マルチノード並列ジョブ](multi-node-parallel-jobs.md) | awsvpc | タスクノード間の通信が調整された単一ジョブとしてモデル化された、緊密に結合されたマルチホスト (ノード) 分散ワークロードに使用されます。 | | [ECS-Fargate シンプルジョブ](when-to-use-fargate.md) | awsvpc | 厄介な並列バッチワークロード向けの真のサーバーレス。通常、TCO が最も低く、最も高度なコンテナ分離ジョブモデルです。 | | [EKS-EC2 シンプルジョブ](eks-jobs.md) | ホストとポッド | コンピューティング環境で定義された vpc への出力のみを必要とする、極めてスケーラブルで厄介な並列バッチワークロードに使用されます。デフォルトはホストネットワークです。 | | [EKS-EC2 マルチノード並列ジョブ](mnp-eks-jobs.md) | ホストとポッド | ポッドノード間の通信が調整された単一ジョブとしてモデル化された、緊密に結合されたマルチホスト (ノード) 分散ワークロードに使用されます。デフォルトはホストネットワークです。 | # CloudWatch Logs で AWS Batch ジョブログを表示する Amazon CloudWatch Logs にログ情報を送信するように[AWS Batch ジョブを設定できます](using_cloudwatch_logs.md#using_cloudwatch_logs.title)。これにより、1 つの便利な場所でジョブからのさまざまなログを表示できます。詳細については、「[での CloudWatch Logs の使用 AWS Batch](using_cloudwatch_logs.md)」を参照してください。 AWS Batch コンソールの**ジョブログ**を使用して、 AWS Batch ジョブをモニタリングまたはトラブルシューティングすることもできます。 1. [AWS Batch コンソール](https://console.aws.amazon.com/batch/home) を開きます。 1. **ジョブ** を選択します。ジョブキューでのジョブのソートとフィルタリングの詳細については、「[AWS Batch ジョブキューでジョブを表示する](view-jobs.md)」および「[ジョブキュー内のジョブを検索する](searching-filtering-jobs.md)」を参照してください。 1. **Job キュー** で、目的のジョブキューを選択します。 **ヒント** ジョブキューに複数のジョブがある場合は、**検索とフィルタリングをオンにすると**、ジョブをすばやく検出できます。詳細については、「[ジョブキュー内のジョブ AWS Batch を検索する](searching-filtering-jobs.md)」を参照してください。 1. **ステータス** では、目的のジョブステータスを選択します。 1. 目的のジョブを選択すると、**[詳細]** ページが開きます。 1. **[詳細]** ページで **[ログストリーム名]** までスクロールし、リンクを選択します。リンクをクリックすると、ジョブの Amazon CloudWatch Logs ページが開きます。 1. (オプション) ログを初めて表示する場合は、許可を求められることがあります。 **[権限が必要です]** には「**OK**」と入力し、**[承認]** を選択して Amazon CloudWatch の料金を承認します。 **注記** CloudWatch 料金の承認を取り消すには: 左側のナビゲーションペインで、**を選択します**。 **ジョブ・ログ** の場合は、**編集** を選択します。 **CloudWatch を使用するようにBatch を承認** チェックボックスをオフにします。 **[Save changes]** (変更の保存) をクリックします。 # AWS Batch ジョブ情報の確認 ステータス、 AWS Batch ジョブ定義、コンテナ情報などのジョブ情報を確認できます。 1. [AWS Batch コンソール](https://console.aws.amazon.com/batch/home) を開きます。 1. **ジョブ** を選択します。 1. **Job キュー** で、目的のジョブキューを選択します。 **ヒント** ジョブキューに複数のジョブがある場合は、**[検索とフィルター]** をオンにすると、ジョブをすばやく検索できます。詳細については、「[ジョブキュー内のジョブ AWS Batch を検索する](searching-filtering-jobs.md)」を参照してください。 1. 必要な色を選択します。 **注記** AWS Command Line Interface (AWS CLI) を使用して、 AWS Batch ジョブの詳細を表示することもできます。詳細については、[AWS CLI コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/) の [describe-domain](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/batch/describe-jobs.html) を参照してください。