ジョブの作成と実行の概要

このドキュメントでは、ジョブの実行プロセスと作成オプションについて説明します。 Batch ジョブを使用すると、Google Cloud でバッチ処理ワークロードを実行できます。ジョブのコンポーネントと、Batch を使用する際の前提条件については、Batch を使ってみるをご覧ください。

ジョブの作成と実行の仕組み

Batch を使用するには、ワークロードとその要件を指定するジョブを作成すると、Batch が自動的に実行されます。

ジョブの作成と実行の仕組みの詳細については、次のセクションで説明します。

ジョブのライフサイクル

このセクションでは、ジョブとそのタスクのライフサイクルのその作成から削除までについて説明します。

Batch で実行するワークロードごとに、次の基本的なプロセスを行います。

  1. ジョブを作成する: ジョブの実行可能ファイル、タスク、その他の要件を指定して、実行するワークロードを定義します。ジョブの作成の詳細は、このドキュメントのジョブ作成オプション セクションで紹介しています。
  2. ジョブのモニタリングとトラブルシューティング: ジョブの作成が完了すると、ジョブは自動的にキューに格納され、スケジュールが設定され、指定したリソースで実行されます。作成されたジョブの詳細やタスクの詳細を表示して、現在の状態を確認できます。ジョブの実行または終了後、ログを使用してジョブのモニタリングと分析を行うこともできます。ジョブが失敗した場合は、ジョブを再作成する前に、エラー メッセージ、ステータス イベント、ログを使用して問題を診断し、問題を診断できます。
  3. ジョブの削除またはエクスポート: ジョブのログは、Cloud Logging の保持ポリシーに従って自動的に保持および削除されます。ジョブの他の情報は、ユーザーまたは Google Cloud によって削除されるまで Batch で引き続き使用できます。Google Cloud は、ジョブの終了から 60 日後にジョブを自動的に削除します。その前に、自分でジョブを削除することもできます。また、情報を保持する必要がある場合は、ジョブを削除する前にエクスポートできます。

ジョブを作成した後は、次の状態に進みます。

  1. キューに格納済み（QUEUED）:ジョブ リクエストが承認され、キュー内で待機しています。必要なリソースが使用可能になり、その前のジョブが評価されるまで、ジョブはキューに残ります。
  2. スケジュール済み（SCHEDULED）: ジョブが実行のためにキューから選択され、リソースが割り当てられます。

  3. 実行（RUNNING）: ジョブのリソースが正常に作成され、そのタスクの実行が開始できます。

    ジョブの実行中、各タスクは次の状態に進みます。

    1. 保留中（PENDING）: タスクは VM の実行を待機しています。
    2. 割り当て済み（ASSIGNED）:タスクを実行する VM が割り当てられています。
    3. 実行（RUNNING）:タスクが VM で実行されています。
    4. タスクは次のいずれかの状態で終了します。
      • 正常終了（SUCCEEDED）: 各実行可能ファイルが成功した（終了コードが 0 だった）か、終了ステータス（ignoreExitStatus）フィールドを無視して、重要でないとマークが付けられて、タスクが正常終了しました。
      • 失敗（FAILED）: 重要な実行可能ファイルの少なくとも 1 つが失敗しました（タスクはゼロ以外の終了コードを返しました）。

  4. ジョブは次のいずれかの状態で終了します。

    • 正常終了（SUCCEEDED）:　ジョブのすべてのタスクが成功しました。
    • 失敗（FAILED）:ジョブに対して少なくとも 1 つのタスクが失敗しました。

詳細については、リファレンス ドキュメントのジョブの状態とタスクの状態をご覧ください。

ジョブのキューイングとスケジューリング

通常、ジョブが小さく、共通リソースが少ない場合、ジョブの実行と終了が早くなる可能性が高くなります。Batch ドキュメント内のサンプル ジョブは、通常は非常に小さく、最小限のリソースしか使用しないので、数分で完了する場合があります。

具体的には、ジョブのキューイングとスケジューリングが完了するまでにかかる時間は、ジョブによって、また次の要因に基づく時間によって異なります。

  • ジョブリソースの可用性: 許可されたロケーション内のジョブに必要なリソースの可用性。

    まず、そのロケーションで提供されていないリソースを指定すると、ジョブは実行できません。この場合、ジョブはゾーンの可用性エラーで失敗します。

    次に、リソースの可用性エラーによって、必要なリソースのいずれかが現在の需要に比べて容量が不足している場合、ジョブの遅延や失敗が発生する可能性があります。その結果、必要なリソースが少なく、一般的なリソースが必要で、ジョブがリージョン内のどのゾーンで実行しても制限されない場合、ジョブはより早く実行される可能性があります。

    ジョブのリソースの詳細については、このドキュメントのジョブ実行をご覧ください。バッチジョブとそのリソースに指定できるロケーションの詳細については、ロケーションページをご覧ください。

  • ジョブの優先度: プロジェクト内の他のジョブの優先度に対するジョブの優先度。

    必要に応じて、gcloud CLI の --priority フラグまたは priority JSON フィールドを指定して、ジョブの優先度を指定できます。ジョブの優先度は、0（最も低い優先度）から 99（最も高い優先度）の間の数値で定義できます。優先度の高いジョブを設定すると、プロジェクトで優先度の低いジョブよりも早くジョブを実行できます。

    ジョブの優先度を構成しない場合は、デフォルトで最も低い 0 が使用されます。2 つのキューに入れられたジョブの優先度が同じ場合、最初に作成されたジョブが優先されます。

  • 割り当てと上限: プロジェクトでの Google Cloud リソースとリクエストに対するしきい値。

    必要なリソースまたはリクエストの上限またはプロジェクトの割り当てを超えると、ジョブは実行できません。この場合、Batch はジョブを遅延させ、後でジョブを再試行するか、ジョブが失敗して関連するエラーが表示されることがあります。

    関連するすべての上限に準拠するジョブを作成し、プロジェクトに十分な関連する割り当てがあることを確認して、ジョブの遅延やエラーを防ぐことができます。詳細については、Batch　の割り当てと上限をご覧ください。

ジョブの実行

ジョブの実行にかかる時間は、タスクのスケジューリングとジョブのリソースによって異なります。

タスクのスケジュール設定

ジョブが実行されると、タスクはスケジュール ポリシー（schedulingPolicy）フィールドに従ってスケジュールされます。このフィールドでは次のいずれかのオプションを指定できます。

  • できるだけ早く（AS_SOON_AS_POSSIBLE）（デフォルト）: タスクはリソースが利用可能になるとすぐに実行され、並行して実行できます。一度に実行するタスクの量は、ジョブのリソースで許可される VM あたりの並列タスクと、このドキュメントのジョブリソースで説明するその他の構成オプションによって異なります。
  • 順番に（IN_ORDER）: タスクは、インデックスの昇順に 1 つずつ実行されます。

ジョブリソース

各バッチジョブは、リージョン マネージド インスタンス グループ（MIG）で実行されます。MIG は、含まれるゾーンの 1 つにある、1 つ以上の一致する Compute Engine 仮想マシン（VM）インスタンスのグループです。各 VM には、ジョブのパフォーマンスに影響を与える CPU コア（特に仮想 CPU（vCPU））、およびジョブを実行するためのオペレーティング システム（OS）イメージと手順を保存するブート ディスク用の専用ハードウェアがあります。

Batch は、ジョブの実行中に仕様を満たすリソースを自動的に作成、削除します。ジョブを作成する際、次のようにリソースの構成を行います。

  • デフォルト値で十分でない場合は、各タスクの実行に必要なコンピューティング リソース（vCPU、メモリ、必要に応じて追加のブートディスク ストレージ）を指定する必要があります。詳細については、タスクあたりのコンピューティング リソース（computeResource）フィールドとサブフィールドをご覧ください。

  • 必要に応じて、使用する VM のタイプと、各 VM の追加リソース（GPU やストレージ ボリュームなど）を指定することもできます。これらのオプションを指定しない場合、Batch は互換性のある VM タイプを選択し、追加のリソースは追加しません。詳細については、VM インスタンス リソース（instances[]）フィールドとサブフィールドをご覧ください。

各 VM で同時に実行できる VM の数とタスクの数は、タスクのスケジューリングと指定されたハードウェア要件に基づいた各ジョブよって異なります。ジョブのタスクに IN_ORDER を実行するように指定すると、ジョブには VM が 1 で、一度に 1 つのタスクしか実行されません。それ以外の場合は、ジョブのタスクが AS_SOON_AS_POSSIBLE で実行される場合、次の式を使用して、VM の数と同時タスクの数を見積もることができます。

\[{vmsPerJob}=\frac{taskCount}{parallelTasksPerVm}\]

この数式には次の値が含まれます。

  • \({vmsPerJob}\): ジョブの VM の最大数。ジョブ用に作成される VM の実際の量は、これより少なくなる場合があります。たとえば、Batch が、より多くのリソースを待つよりも、少ないリソースでジョブを実行する方が高速であると判断される場合です。この値は、ジョブあたりの同時 VM 数の上限によっても制限されます。
  • \({taskCount}\): ジョブのタスクの合計数。タスク数（taskCount）フィールドを使用して定義します。

  • \({parallelTasksPerVM}\): VM で同時に実行できるタスクの最大数。

    この値は、次のすべての基準によって決定されます。

    • 最小値は 1 タスクです。

    • 最大値は 20 タスクとジョブあたりの最大並列タスク数（parallelism）フィールドの値（定義されている場合）のうち小さい方です。

    • VM あたりの最大並列タスク（taskCountPerNode）フィールドが定義されている場合、その値が使用されます。

      それ以外の場合、taskCountPerNode が未定義の場合、Batch は VM あたりのコンピューティング リソース（具体的には vCPU）の合計数を各タスクに必要な量で除算して値を決定します。

      \[{parallelTasksPerVm}=\frac{vcpusPerVm}{vcpusPerTask}\]

      この数式には次の値が含まれます。

      • \({vcpusPerVm}\): VM あたりの vCPU の合計数。ジョブの VM のマシンタイプによって決まります。

      • \({vcpusPerTask}\): タスクあたりの vCPU の数。タスクあたりの vCPU（cpuMilli）フィールドの単位を変換することによって決定されます。

ジョブ作成オプション

基本的なジョブの作成と実行では、スクリプトまたはコンテナ イメージを使用して実行可能ファイルを定義する方法や、事前定義された環境変数またはカスタム環境変数を構成する方法などの基本事項について説明します。

ジョブ作成の基礎を理解したら、次の 1 つ以上の追加の構成オプションを使用するジョブを作成することを検討してください。

  • ジョブへのアクセス制御:

  • ジョブの追加オプションを構成します。

    • MPI ライブラリを使用してタスク通信を構成するでは、Message Passing Interface（MPI）ライブラリを使用して異なる VM 間で相互に通信する相互依存タスクでジョブを構成する方法について説明します。MPI の一般的なユースケースは、密結合なハイ パフォーマンス コンピューティング（HPC）ワークロードです。

    • ジョブが実行されるリソースをカスタマイズします。

      • VM インスタンス テンプレートを使用してジョブリソースを定義するでは、ジョブの作成時に Compute Engine VM テンプレートを指定してジョブのリソースを定義する方法について説明します。

      • ジョブに GPU を使用するでは、1 つ以上の画像処理装置（GPU）を使用するジョブを定義する方法について説明します。GPU を使用するジョブの一般的なユースケースには、集中的なデータ処理や機械学習（ML）のワークロードが含まれています。

      • ジョブにストレージ ボリュームを使用するでは、1 つ以上の外部ストレージ ボリュームにアクセスできるジョブを定義する方法について説明します。ストレージ オプションには、新規または既存の永続ディスク、新しいローカル SSD、既存の Cloud Storage バケット、Filestore ファイル共有などの既存のネットワーク ファイル システム（NFS）があります。

      • VM OS 環境の概要では、ジョブの VM オペレーティング システム（OS）環境（ジョブの VM OS イメージとブートディスクなど）をいつどのようにカスタマイズできるかの概要を説明します。

    • ジョブのさまざまな側面を最適化する。

      • モニタリングと分析を改善する:

      • タスクの再試行を自動化するでは、すべてまたは指定した失敗後にジョブのタスクを自動的に再試行する方法を説明します。自動再試行によって、トラブルシューティングの摩擦や、一時的なエラーが発生するジョブに必要な全体的な実行時間を短縮できます。 たとえば、Spot VM 上で実行されるジョブに対して自動再試行を使用します。これにより、大幅な割引がディスカウントが提供されますが、常に利用可能であるとは限らず、いつでもプリエンプトされます。

      • VM を同じロケーションに配置してレイテンシを短縮するでは、VM を物理的に近づけることで、ジョブの VM 間のネットワーク レイテンシを低減する方法について説明します。このパフォーマンスは、MPI ライブラリを使用して通信するタスクなど、VM 間でのネットワーク通信が頻繁に行われるジョブで特に役立ちます。

      • 予約された VM で実行できるジョブを構成する方法については、VM 予約を使用してリソースの可用性を確認するをご覧ください。予約済み VM を使用すると、ジョブのスケジューリング時間の最小化、リソース可用性エラーの防止、コストの最適化に役立ちます。

      • イメージ ストリーミングの使用では、Artifact Registry からコンテナ イメージをストリーミングすることによって、ジョブの起動時間を短縮する方法について説明しています。

  • ジョブを作成して実行するには、追加のサービスを使用します。

次のステップ