このページは Cloud Translation API によって翻訳されました。

既知の問題

このページでは、Batch の使用中に発生する可能性のある既知の問題について説明します。

Batch の使用についてさらにサポートが必要な場合は、トラブルシューティングのドキュメントをご覧いただくか、サポートにお問い合わせください。

Pub/Sub は、クイック変更中の中間状態の通知を送信しない場合があります

ジョブまたはタスクが非常に速く変化する場合、Pub/Sub はすべての中間状態の通知を送信しないことがあります。たとえば、タスクの状態が ASSIGNED、RUNNING、FAILED とすばやく変化するとします。このシナリオでは、タスクが RUNNING 状態になったという通知が届かないことがあります。

この問題を軽減するには、ジョブまたはタスクの完全な状態履歴を確認する場合は、Pub/Sub 通知ではなくステータスイベントを表示することをおすすめします。

Pub/Sub 通知の詳細については、Pub/Sub 通知と BigQuery を使用してジョブのステータスをモニタリングするをご覧ください。

タイムアウトログに、タスクのタイムアウトと実行可能ファイルのタイムアウトのどちらが超過したかが示されない

タイムアウトを超えたためにジョブが失敗した場合、ジョブに関連付けられたログには、失敗の原因が関連するタスクのタイムアウトか、関連する実行可能ファイルのタイムアウトかは示されません。

この問題を回避するには、タスクと実行可能オブジェクトに異なるタイムアウト値を設定します。次の手順で、関連するタスクまたは実行可能ファイルのタイムアウトを超えたことが原因で障害が発生したかどうかを特定できます。

タイムアウト超過エラーのタスク、実行可能ファイル、時刻を特定します。
1. ジョブのログを表示する。
2. タイムアウト超過の終了コード 50005 が記載されているログを見つけます。このログには、次のようなメッセージを含む textPayload があります。
```
Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
```
  そのログから、TASK_INDEX を失敗したタスク、RUNNABLE_INDEX を失敗した実行可能ファイル、ログの timestamp 値をタイムアウト超過による失敗の時刻として記録します。
失敗したタスクの開始時刻を特定します。
1. 失敗したタスクのステータスイベントを表示します。
2. 次のメッセージを含むステータスイベントを見つけます。
```
Task state is updated from ASSIGNED to RUNNING
```
  そのステータスイベントから、eventTime フィールドを失敗したタスクの開始時刻として記録します。
次の式を使用して、失敗したタスクの合計実行時間 \({failedTaskRunTime}\)を計算します。

\[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]

次の値を置き換えます。
- \({failureTime}\): タイムアウト超過時の失敗時刻。
- \({failedTaskStartTime}\): 失敗したタスクの開始時刻。
超過したタイムアウトを特定します。
- \({failedTaskRunTime}\) が、失敗したタスクに構成したタイムアウトと一致する場合、そのタスクのタイムアウトは超過し、失敗の原因になっています。
- それ以外の場合、失敗した実行可能ファイルに構成したタイムアウトが超過し、失敗の原因になっています。

予約を使用するジョブが遅延するか、阻止される可能性がある

Compute Engine の予約を消費するジョブを作成して実行しようとすると、Batch によってジョブが誤って遅延したり、実行されなくなったりすることがあります。具体的には、Batch では、リソースの割り当てが未使用の予約で使用されている場合でも、プロジェクトに十分な Compute Engine リソースの割り当てが必要です。

問題の回避策

ジョブのこの問題を回避するには、goog-batch-skip-quota-check という名前ラベルと値 true をジョブレベル labels フィールドに追加します。このラベルを指定すると、Batch はジョブの作成を試みる前に、プロジェクトのリソース割り当ての検証をスキップします。

たとえば、予約を消費できる基本スクリプトジョブでこの問題を回避または解決するには、次の JSON 構成でジョブを作成して実行します。

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "labels": {
    "goog-batch-skip-quota-check": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

VM_RESOURCES は、ジョブで消費する予約と一致する VM リソースに置き換えます。

詳細については、予約済み VM を消費できるジョブを作成して実行するとジョブのカスタムラベルを定義するをご覧ください。

事象を特定する

この問題を示す特定のエラーメッセージはありません。代わりに、この問題は次のような状況で発生する可能性があります。

割り当てがあるすべてのリソースをプロジェクトで予約している場合、この問題により、ジョブでそれらのリソースを指定できなくなります。

たとえば、プロジェクトに次のものがあるとします。
- H100 GPU の最大割り当てが 16。
- 2 つの a3-highgpu-8g VM の未使用の単一プロジェクト予約。合計 16 個の H100 GPU が予約されます。
このシナリオでは、この問題により、予約済みの H100 GPU を消費するように正しく構成されているジョブをプロジェクトでスケジュールして実行することが妨げられます。
割り当てがある一部のリソースをプロジェクトで予約している場合、この問題により、それらのリソースを指定するジョブが妨げられたり、遅延したりする可能性があります。

たとえば、プロジェクトに次のものがあるとします。
- H100 GPU の最大割り当てが 16。
- 1 つの a3-highgpu-8g VM の未使用の単一プロジェクト予約。合計 8 個の H100 GPU を予約します。
- 予約を消費しないように構成され、削除されて再作成されることがある a3-highgpu-8g VM。（この VM は、8 個の未予約の H100 GPU を使用します（存在する場合））。
このシナリオでは、この問題により、a3-highgpu-8g VM が存在しない場合に、予約済みの H100 GPU のいずれかを消費するように正しく構成されているジョブをプロジェクトでスケジュールして開始することのみが可能になります。

古いカーネルの Compute Engine（またはカスタム）VM OS イメージを指定すると、ジョブが失敗する可能性がある

カーネルのバージョンが最新でない Compute Engine VM OS イメージを指定すると、ジョブが失敗する可能性があります。この問題は、Compute Engine VM OS イメージをベースにしたカスタムイメージにも影響します。この問題を引き起こす Compute Engine の公開イメージは簡単に特定できず、いつでも変更される可能性があります。

この問題を示す特定のエラーメッセージはありません。このため、予期せず失敗したジョブで、Compute Engine VM OS イメージまたは同様のカスタムイメージが指定されている場合は、この問題を検討してください。

この問題を回避または解決する手順は、以下のとおりです。

可能であれば、この問題の影響を受けない Batch イメージまたは Batch イメージをベースにしたカスタムイメージを使用してください。
Batch イメージを使用できない場合は、目的の Compute Engine イメージの最新バージョンを試してください。一般的に、新しいバージョンの Compute Engine イメージは、古いバージョンではなく最新バージョンのカーネルを使用している可能性が高くなります。
特定のイメージの最新バージョンが動作しない場合は、別の OS を試すか、カスタムイメージを作成する必要があるかもしれません。たとえば、最新バージョンの Debian 11 が機能しない場合は、Debian 11 が動作し、最新のカーネルバージョンを使用するように更新した Compute Engine VM からカスタムイメージを作成してみてください。

この問題は、VM OS イメージのカーネルバージョンが古く、VM が再起動することが原因で発生します。ジョブで Batch からのものでも Batch イメージをベースにしたものでもない VM OS イメージが指定されている場合、Batch は起動後に必要なパッケージをジョブの VM にインストールします。必要なパッケージはジョブによって異なり、時間とともに変化する可能性があります。また、VM OS イメージに最新のカーネルバージョンを指定する必要があります。この問題は、カーネルバージョンの更新時に VM の再起動が必要になり、パッケージのインストールとジョブが失敗する場合に発生します。

VM OS イメージの詳細については、ジョブの VM OS 環境の概要をご覧ください。

GPU と古いカーネルの VM OS イメージを使用するジョブが、ドライバの自動インストール時にのみ失敗する可能性がある

この問題は、カーネルが古い Compute Engine（またはカスタム）VM OS イメージを指定したジョブが失敗する可能性があることと密接に関連しています。具体的には、カーネルが最新ではない Compute Engine（またはカスタム）VM OS イメージを指定し、GPU を使用するジョブは、GPU ドライバを自動的にインストールしようとした場合にのみ失敗する可能性があります。このようなジョブでは、GPU ドライバを手動でインストールするだけで障害を解決できる可能性があります。

GPU の詳細については、GPU を使用するジョブを作成して実行するをご覧ください。