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

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

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

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

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

ジョブのライフサイクル:

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

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

  1. ジョブを作成する: ジョブの実行可能ファイル、タスク、その他の要件を指定して、実行するワークロードを定義します。ジョブの作成の詳細については、このドキュメントのジョブの作成オプションをご覧ください。
  2. ジョブのモニタリングとトラブルシューティング: ジョブの作成が完了すると、ジョブは自動的にキューに入れられ、スケジュールが設定され、指定したリソースで実行されます。作成されたジョブまたはそのタスクの詳細を表示して、現在の状態を確認できます。必要に応じて、ジョブをキャンセル（プレビュー）して停止したり、実行を防いだりできます。ジョブの実行中または完了後に、ログを使用してジョブをモニタリングおよび分析することもできます。ジョブが失敗した場合は、ジョブを再作成する前に、エラー メッセージ、ステータス イベント、ログを使用してトラブルシューティングできます。
  3. ジョブの削除またはエクスポート: Batch のジョブの情報は、ユーザーまたは Google Cloud が削除するまで使用できます。 Google Cloud は、ジョブの終了から 60 日後にジョブを自動的に削除します。その前に必要に応じて自分でジョブを削除することができます。また、情報を保持する必要がある場合は、ジョブが削除される前にジョブの情報を Batch にエクスポートすることもできます。ジョブが削除されても、別の保持ポリシーが設定されていても、他の Google Cloud サービスに保存されているジョブの情報は影響を受けません。たとえば、ジョブのログは、Cloud Logging の保持ポリシーに従って自動的に保持および削除されます。

ジョブを作成すると、次の状態を遷移します。

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

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

    ジョブが実行されると、各タスクは次の状態を遷移します。

    1. 保留中（PENDING）:タスクが VM の実行を待機しています。
    2. 割り当て済み（ASSIGNED）: タスクに実行する VM が割り当てられています。
    3. 実行（RUNNING）:タスクが VM で実行されています。

    4. タスクは次のいずれかの状態で終了します。

      • 正常終了（SUCCEEDED）: 各実行可能ファイルが次のいずれかの条件を満たしたため、タスクが正常に完了しました。

        • 実行可能ファイルは正常終了しました（ゼロの終了コードが返された）。
        • 実行可能ファイルは失敗（ゼロ以外の終了コードが返された）したが、重要でない実行可能ファイルでした（実行可能ファイルの ignoreExitStatus フィールドが有効にされていた）。
        • 実行可能ファイルは完了しなかったが、バックグラウンド実行可能ファイルでした（実行可能ファイルの background フィールドが有効にされていた）。

      • 失敗（FAILED）: 少なくとも 1 つの実行可能ファイルが前述の条件を満たさなかったため、タスクが失敗し、実行が停止しました。

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

    • 正常終了（SUCCEEDED）: すべてのタスクが成功したため、ジョブは正常終了しました。
    • 失敗（FAILED）: 少なくとも 1 つのタスクが失敗したため、ジョブは失敗し、実行が停止しました。
    • キャンセル済み（CANCELLED）: ジョブが成功または失敗する前に、ユーザーがジョブをキャンセルしました（プレビュー）。

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

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

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

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

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

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

    2 つ目は、リソースの可用性エラーにより、必要なリソースのいずれかが現在の需要に比べて容量が少ない場合、ジョブが遅延または失敗する可能性が高くなります。 そのため、より少量でより共通のリソースを必要とし、リージョン内のどのゾーンでもジョブの実行を制限しない場合、ジョブはより早く実行される可能性があります。

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

  • ジョブの優先度: プロジェクト内の他のジョブの優先度と比較したジョブの優先度。

    必要に応じて、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 リソース ポリシー（instances[].policy）フィールドまたは代替の instances[].instanceTemplate フィールドを使用して、ジョブの VM（マシンタイプや OS など）や、GPU やストレージ ボリュームなどの追加リソースを指定することもできます。これらのフィールドを定義しない場合、Batch は互換性のある VM を選択し、追加のリソースを追加しません。

各 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 テンプレートを指定してジョブのリソースを定義する方法について説明します。これは、instances[].policy フィールドを使用してジョブのリソースを直接指定する方法の代替手段です。

      • ジョブに 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 からコンテナ イメージをストリーミングしてジョブの起動時間を改善する方法について説明します。

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

次のステップ