VM 予約を使用してリソースの可用性を確保する

このドキュメントでは、予約済みのリソースで実行するジョブの作成方法について説明します。

予約は Compute Engine の機能です。予約を使用すると、指定したハードウェア構成で 1 つ以上の VM の容量を確実に取得できます。VM の予約を行うと、予約を作成した時点から削除するまでの VM の料金が発生します。ただし、その VM を使用している間、合計費用は予約のない VM と同等になります。

一般に、予約は、容量の可用性が極めて重要である場合や、リソース取得時のエラーを防止する場合に役立ちます。特に Batch では、専用の予約を使用してジョブのスケジューリング時間を最小限に抑えるか、既存の予約を使用していないときに使用することを検討してください。予約が十分に活用されていない場合（確約利用割引に必要な予約など）、ジョブが使用されていないときに使用するようにジョブを構成でき、発生した費用を最適化するのに役立ちます。

予約の詳細については、Compute Engine の予約に関するドキュメントをご覧ください。

準備

制限事項

予約に関する一般的な制限に加えて、Batch には次の制限もあります。

要件

このセクションでは、ジョブの VM で予約を使用するための要件の概要について説明します。すべての要件の詳細については、Compute Engine のドキュメントの予約に関する一般的な要件とこのドキュメントの後半の構成の計画手順をご覧ください。

  • ジョブの VM で一般的に予約を使用できるようにするには、次のすべての条件を満たす必要があります。

    • ジョブと予約で、完全に一致する VM プロパティを指定する必要があります。

    • このドキュメントのすべての制限事項とその他すべての予約に関する一般的な要件を遵守する必要があります。

  • ジョブの各 VM で予約を正常に使用するには、VM の実行中に予約に使用できる未使用の容量が必要です。

    予約の未使用容量は、予約の VM 数と現在予約している VM の数の差です。VM は、未使用の予約容量があると、予約を使用しようとします。そのため、VM の作成時かその後の実行時に、予約の使用を開始できます。VM は、VM の実行が停止するか、予約が削除されるまで、予約の使用を停止しません。

    未使用の予約容量の合計に応じて、ジョブの VM は予約容量をまったく使用しないか、予約容量の一部またはすべてを使用します。予約済み VM の容量はジョブの実行時全体で異なる場合があります。

予約済み VM を使用できるジョブを作成して実行する

  1. 構成を計画します。 ジョブと予約の互換性を確認するには、次の手順を実施します。

    既存の予約を使用する場合は、対応する構成でジョブを作成する必要があります。それ以外の場合、新しい予約を作成するように計画するには、必要な構成オプションを選択します。

    1. 予約のプロパティを決定します。制限があるため、共有タイプは単一プロジェクトにする必要があります。これは、予約のデフォルト オプションです。次の予約プロパティに使用する値を決定します。

      • 使用タイプ*
      • VM 数†

      * 予約の使用タイプ（明示的にターゲットを設定するか、または自動的に使用される）によって、VM で使用できる予約が決定します。

      †VM 数は、予約の合計容量を表します。この値を決定する際は、ジョブの VM 数を考慮してください。

    2. ジョブと予約の VM プロパティを決定します。 制限があるため、ジョブと予約のいずれも、コンパクト プレースメント ポリシーを指定できません。これは、予約とジョブの両方のデフォルトのオプションです。次の VM プロパティに使用する値を決定します。これは予約とジョブに対して正確に一致している必要があります。

      • プロジェクト
      • ゾーン*
      • マシンタイプ†
      • 最小 CPU プラットフォーム†（存在する場合‡）
      • GPU のタイプと数†（存在する場合‡）
      • ローカル SSD のタイプと数†（存在する場合‡）
      • 予約アフィニティ†#

      *ジョブ VM は予約済み VM と同じゾーンに配置する必要があります。このゾーンをジョブの allowedLocations[] フィールドに含めるか、allowedLocations[] フィールドを省略する場合は、ジョブのロケーションをこのゾーンを含むリージョンに設定する必要があります。

      †ジョブでは、policy サブフィールドまたは VM インスタンス テンプレートを使用して、これらのプロパティをすべて定義する必要があります。ジョブでは、policy サブフィールドとテンプレートの組み合わせを指定することはできません。

      ‡ オプション フィールドを 1 つのリソースに対して定義することはできません。また、他のリソースから省略することはできません。予約とジョブの両方に対してオプション フィールドを定義または省略します。ジョブが VM インスタンス テンプレートを指定している場合、これは指定されたテンプレートのフィールドにも適用されます。

      #予約の使用タイプによって、ジョブの VM に必要な予約アフィニティが決定されます。これは、次に示すように、ジョブで指定する必要があります。

      • ジョブが VM インスタンス テンプレートを使用している場合は、テンプレートで予約ドキュメントの説明に沿って予約アフィニティを構成する必要があります。
      • ジョブがテンプレートを使用していない場合、予約が明示的にターゲットになっている場合は、ジョブの reservation フィールドに予約の名前を指定します。
      • それ以外の場合は、ジョブがテンプレートを使用せず、予約が自動的に使用され、ジョブの reservation フィールドを省略します。

  2. 予約を準備します。まだ作成していない場合は、ジョブの VM で使用する予約を作成します。計画したプロパティが予約に含まれていることを確認します。

  3. ジョブを作成して実行します。gcloud CLI または Batch API を使用して、準備した予約から VM を使用するジョブを作成し、実行できます。

    gcloud

    1. 予約の VM プロパティと完全に一致するように VM インスタンス リソース（instances[]）サブフィールドを設定するジョブの構成の詳細を指定する JSON ファイルを作成します。

      たとえば、予約から VM を使用する基本的なスクリプト ジョブを作成するには、次の内容の JSON ファイルを作成します。

      {
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

      VM_RESOURCES は、前の手順で計画した instances[] サブフィールドを指定して、ジョブで使用する予約と一致する VM リソースに置き換えます。

      たとえば、VM_RESOURCES の次の値から始めます。

      "installGpuDrivers": INSTALL_GPU_DRIVERS,
"policy": {
  "machineType": "MACHINE_TYPE",
  "minCpuPlatform": "MIN_CPU_PLATFORM",
  "accelerators": [
    {
      "type": "GPU_TYPE",
      "count": GPU_COUNT
    }
  ],
  "disks": [
    {
      "newDisk": {
        "sizeGb": LOCAL_SSD_SIZE,
        "type": "local-ssd"
      },
      "deviceName": "LOCAL_SSD_NAME"
    }
  ],
  "reservation": "SPECIFIC_RESERVATION_NAME"
}

      この値を使用するには、次の変更をすべて行います。

      1. インスタンス テンプレートを使用しますか？

        • はい: policy フィールドを instanceTemplate フィールドに置き換え、予約と一致する既存の VM インスタンス テンプレートを指定します。例については、VM インスタンス テンプレートの使用のコードサンプルをご覧ください。予約で GPU またはローカル SSD を使用する場合は、ジョブの installGpuDrivers フィールドと volumes[] フィールドをそれぞれ構成する必要もあります。それ以外の場合は、残りの変更をスキップします。

        • いいえ: MACHINE_TYPE は、予約と同じマシンタイプに置き換えます。

      2. 予約に最小 CPU プラットフォームが含まれていますか？

        • はい: MIN_CPU_PLATFORM は、同じ最小 CPU プラットフォームに置き換えます。

        • いいえ: minCpuPlatform フィールドを削除します。

      3. 予約に GPU が含まれますか？

        • はい: INSTALL_GPU_DRIVERS、GPU_TYPE、GPU_COUNT は、予約と一致するように置き換えます。例については、GPU の使用のコードサンプルをご覧ください。

        • いいえ: installGpuDrivers フィールドと accelerators[] フィールドを削除します。

      4. 予約にローカル SSD が含まれていますか？

        • はい: LOCAL_SSD_SIZE と LOCAL_SSD_NAME は、予約と一致するように置き換え、volumes[] フィールドをジョブに追加してローカル SSD をマウントします。例については、ローカル SSD の使用のコードサンプルをご覧ください。

        • いいえ: disks[] フィールドを削除します。

      5. 予約で特定の使用タイプを使用していますか？

        • はい: SPECIFIC_RESERVATION_NAME は、予約の名前に置き換えます。

        • いいえ: reservation フィールドを削除します。

      たとえば、最小 CPU プラットフォーム、GPU、またはローカル SSD を指定しない n2-standard-32 VM の自動使用予約を使用しているとします。また、VM インスタンス テンプレートは指定しません。その場合は、VM_RESOURCES を次の値に置き換える必要があります。

      "policy": {
  "machineType": "n2-standard-32"
}

    2. ジョブを作成して実行するには、gcloud batch jobs submit コマンドを使用します。

      gcloud batch jobs submit JOB_NAME \
  --location LOCATION \
  --config JSON_CONFIGURATION_FILE

      以下を置き換えます。

      • JOB_NAME: ジョブの名前。

      • LOCATION: ジョブのロケーション。 ジョブが allowedLocations[] フィールドを指定しない限り、予約のゾーンを含むリージョンを指定する必要があります。

      • JSON_CONFIGURATION_FILE: ジョブの構成の詳細を含む JSON ファイルへのパス。

    API

    予約の VM プロパティと完全に一致するように、VM インスタンス リソース（instances[]）サブフィールドを設定する jobs.create メソッドに POST リクエストを送信します。

    たとえば、予約から VM を使用する基本的なスクリプト ジョブを作成するには、次のリクエストを行います。

    POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME
{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

    次のように置き換えます。

    • PROJECT_ID: プロジェクトのプロジェクト ID。

    • LOCATION: ジョブのロケーション。 ジョブが allowedLocations[] フィールドを指定しない限り、予約のゾーンを含むリージョンを指定する必要があります。

    • JOB_NAME: ジョブの名前。

    • VM_RESOURCES: 前の手順で計画した instances[] サブフィールドを指定して、ジョブで使用する予約と一致する VM リソース。

      たとえば、VM_RESOURCES の次の値から始めます。

      "installGpuDrivers": INSTALL_GPU_DRIVERS,
"policy": {
  "machineType": "MACHINE_TYPE",
  "minCpuPlatform": "MIN_CPU_PLATFORM",
  "accelerators": [
    {
      "type": "GPU_TYPE",
      "count": GPU_COUNT
    }
  ],
  "disks": [
    {
      "newDisk": {
        "sizeGb": LOCAL_SSD_SIZE,
        "type": "local-ssd"
      },
      "deviceName": "LOCAL_SSD_NAME"
    }
  ],
  "reservation": "SPECIFIC_RESERVATION_NAME"
}

      この値を使用するには、次の変更をすべて行います。

      1. インスタンス テンプレートを使用しますか？

        • はい: policy フィールドを instanceTemplate フィールドに置き換え、予約と一致する既存の VM インスタンス テンプレートを指定します。例については、VM インスタンス テンプレートの使用のコードサンプルをご覧ください。予約で GPU またはローカル SSD を使用する場合は、ジョブの installGpuDrivers フィールドと volumes[] フィールドをそれぞれ構成する必要もあります。それ以外の場合は、残りの変更をスキップします。

        • いいえ: MACHINE_TYPE は、予約と同じマシンタイプに置き換えます。

      2. 予約に最小 CPU プラットフォームが含まれていますか？

        • はい: MIN_CPU_PLATFORM は、同じ最小 CPU プラットフォームに置き換えます。

        • いいえ: minCpuPlatform フィールドを削除します。

      3. 予約に GPU が含まれますか？

        • はい: INSTALL_GPU_DRIVERS、GPU_TYPE、GPU_COUNT は、予約と一致するように置き換えます。例については、GPU の使用のコードサンプルをご覧ください。

        • いいえ: installGpuDrivers フィールドと accelerators[] フィールドを削除します。

      4. 予約にローカル SSD が含まれていますか？

        • はい: LOCAL_SSD_SIZE と LOCAL_SSD_NAME は、予約と一致するように置き換え、volumes[] フィールドをジョブに追加してローカル SSD をマウントします。例については、ローカル SSD の使用のコードサンプルをご覧ください。

        • いいえ: disks[] フィールドを削除します。

      5. 予約で特定の使用タイプを使用していますか？

        • はい: SPECIFIC_RESERVATION_NAME は、予約の名前に置き換えます。

        • いいえ: reservation フィールドを削除します。

      たとえば、最小 CPU プラットフォーム、GPU、またはローカル SSD を指定しない n2-standard-32 VM の自動使用予約を使用しているとします。また、VM インスタンス テンプレートは指定しません。その場合は、VM_RESOURCES を次の値に置き換える必要があります。

      "policy": {
  "machineType": "n2-standard-32"
}

次のステップ