BigQuery ワークロード管理のトラブルシューティング

このドキュメントでは、予約の割り当てと割り当て、予約構成エラー、容量コミットメント、スロット競合、予約のモニタリングなど、BigQuery ワークロード管理に関する一般的な問題のトラブルシューティングを行う方法について説明します。

予約、コミットメント、管理リソースのグラフを表示して管理するには、管理プロジェクトに対する BigQuery リソース閲覧者（roles/bigquery.resourceViewer）ロールや BigQuery リソース管理者（roles/bigquery.resourceAdmin）ロールなど、必要な Identity and Access Management（IAM）ロールがあることを確認してください。詳細については、IAM によるアクセス制御をご覧ください。

予約に関する問題のトラブルシューティング

次の情報を使用して、予約に関する一般的な問題（スロットの追加時のエラー、BigQuery ジョブで予約が使用されない理由、認識されない予約など）のトラブルシューティングを行います。

予約サイズにスロットを追加できない

予約にスロットを追加しようとしたときに Failed to allocate slots for reservation in the current system state や Failed to update reservation: Failed to allocate slots for reservation などのエラーが発生した場合は、通常は一時的な問題です。この問題を軽減するには、次の操作を行います。

  • スロット数を減らして再試行してください。
  • スロット数を減らして試しても失敗した場合は、15 分待ってから操作を再試行します。

複数回再試行し、30 分待っても同じエラーが表示される場合は、Cloud カスタマーケアにお問い合わせください。

リクエストを完了するのに十分な割り当てがない

エラー メッセージに There is insufficient quota to complete this request と表示されている場合は、リクエストがプロジェクトに設定されている割り当て上限を超えています。

このエラーを解決するには、以下のいずれかを行います。

  • リクエストが割り当て上限を超えないように、予約に追加するスロットの数を減らす。
  • 対応するリージョンで割り当ての増加をリクエストする。詳細については、割り当ての増加をリクエストするをご覧ください。

予約が BigQuery でジョブの実行に使用されない

作成した予約を使用する代わりに、オンデマンド料金または無料の共有スロットプールを使用してジョブが実行されるシナリオは複数あります。

クエリと予約が異なるリージョンにある

予約はリージョン リソースです。クエリは、クエリで参照されるテーブルと同じロケーションで実行されます。

テーブルのロケーションが予約のロケーションと一致しない場合、クエリは予約を使用せず、オンデマンド料金（または、対象となるバッチ読み込みジョブとエクスポート ジョブの無料の共有スロットプール）を使用して実行されます。

BigQuery Omni テーブルのクエリ

BigQuery Omni テーブルにクエリを実行する場合は、予約がテーブルと同一のリージョンに作成されていることを確認してください。同じ場所に配置されたリージョンに作成されていると、クエリが失敗します。同じ場所に配置された BigQuery リージョンに予約を作成すると、クエリはオンデマンド料金を使用して実行されます。

予約は作成されたが、プロジェクトが割り当てられていない

予約のスロットを使用するには、プロジェクト、フォルダ、または組織を特定の予約に割り当てる割り当てを作成する必要があります。プロジェクトに、対応する予約の割り当てがあることを確認します。

ジョブタイプの不一致

割り当てを作成するときは、必ず正しいサービスの種類を選択してください。選択が正しくないと、ジョブは予約を使用しません。

たとえば、サービスの種類として PIPELINE を選択すると、すべてのクエリジョブがオンデマンド料金を使用して実行されます。割り当てタイプを QUERY に変更して、予約を使用してクエリジョブを実行します。

複数ステートメント クエリ

複数ステートメント クエリを実行している場合、子ジョブが予約によって実行されていても、親ジョブ オブジェクトには予約が関連付けられません。

ジョブが実際に予約を使用していたかどうかを確認するには、子ジョブのメタデータを確認します。

キャッシュに保存されている結果の取得

クエリジョブがキャッシュに保存された結果を取得する場合、BigQuery は計算を実行せず、結果を一時テーブルから直接取得するため、予約フィールドは空になります。

変更データ キャプチャの行変更オペレーション

変更データ キャプチャ（CDC）テーブルがある場合、BigQuery は max_staleness 間隔内の保留中の行変更を、BACKGROUND 割り当てタイプを使用するバックグラウンド ジョブとして適用します。BACKGROUND の割り当てがない場合、これらのジョブではオンデマンド料金が使用されます。予期しないオンデマンド コストを避けるため、プロジェクトに BACKGROUND 割り当てを作成することを検討してください。これらのジョブは、ジョブ識別子内の queueworker_cdc_background_merge_coalesce 部分文字列で識別できます。

外部サービスを使用する BigQuery ML モデルタイプ

プロジェクトに ML_EXTERNAL サービスの種類 の予約割り当てが見つからない場合、外部モデル作成ジョブはオンデマンド料金を使用して実行されます。QUERY ジョブタイプの割り当ては、標準の BigQuery ML モデルと行列分解モデル（Enterprise エディションまたは Enterprise Plus エディションの予約が必要）に適用されます。一方、外部モデルには ML_EXTERNAL の割り当てが必要です。詳細については、BigQuery ワークロードへのスロットの割り当てをご覧ください。

プロジェクトで認識できない予約が特定された

BigQuery が所有する予約があり、それが BigQuery の特定のオペレーションで使用される無料の共有スロットプールに対応する場合です。

default-pipeline

デフォルトでは、BigQuery でデータのバッチ読み込みまたはバッチ エクスポートを行うと、共有の無料スロットプールが使用されます。これらの読み込みジョブまたは抽出ジョブを検査すると、予約フィールドに default-pipeline が表示されます。

共有スロットプールの使用に料金はかかりません。一貫して予測可能なパフォーマンスが必要な場合は、PIPELINE 予約の購入を検討してください。

予約管理タスクのトラブルシューティング

予約の作成時または更新時に、次のエラーが発生することがあります。

予約サイズまたはベースライン スロットは 50 の倍数にする必要があります

エラー メッセージ

  • Max reservation size can only be configured in multiples of 50, except when covered by excess commitments.
  • Baseline slots can only be configured in multiples of 50, except when covered by excess commitments.

原因

スロットは常に 50 の倍数に自動スケーリングされます。BigQuery は、実際の使用量に基づいてスロットをスケールアップし、50 スロット単位で切り上げます。コミットメントがない場合や、コミットメントで増加に対応できない場合は、ベースライン スロットと自動スケーリング スロットを 50 の倍数でのみ増加できます。

baseline slots または max reservation size - baseline slots が 50 の倍数でない場合（超過容量コミットメントの対象でない場合）、予約は最大予約サイズまでスケールアップできず、このエラーが発生します。

解決策

次のいずれかを行います。

  • スロットの増加に対応するために、追加の容量コミットメントを購入します。
  • ベースライン スロットと最大スロットは 50 単位で選択します。

容量コミットメントのトラブルシューティング

このセクションでは、BigQuery 容量コミットメントで問題が発生した場合に役立つトラブルシューティングの手順について説明します。

購入したスロットは保留中です

スロットには利用可能な容量が適用されます。スロット コミットメントを購入して BigQuery で割り振ると、[ステータス] 列にチェックマークが表示されます。BigQuery がリクエストされたスロットをすぐに割り当てられない場合、[ステータス] 列は保留中のままになります。スロットが使用可能になるまで数時間かかることがあります。より早くスロットにアクセスする必要がある場合は、次のことを試してください。

  1. 保留中のコミットメントを削除します。
  2. スロット数を減らす場合は、新しいコミットメントを購入します。容量によっては、小さいコミットメントがすぐに有効になる場合があります。
  3. 残りのスロットは別のコミットメントとして購入します。これらのスロットは [ステータス] 列に保留中として表示されますが、通常は数時間以内にアクティブになります。
  4. 省略可: 両方のコミットメントが有効になったら、両方のコミットメントが同じリージョンとエディションにあり、同じコミットメント プランを使用している場合に、両方のコミットメントを 1 つのコミットメントに統合します。

スロット コミットメントが失敗した場合や、完了に時間がかかる場合は、一時的にオンデマンド料金の使用を検討してください。このソリューションを使用すると、予約に割り当てられていない別のプロジェクトで重要なクエリを実行したり、プロジェクトを None に割り当てたり、プロジェクトの割り当てを完全に削除したりできます。

スロット競合のトラブルシューティング

すべてのジョブを実行するのに十分なスロットがない場合、スロット競合が起こり、パフォーマンスの問題が発生する可能性があります。パフォーマンスの低下がワークロードの増加によるものか、環境構成の変更によるものかを分析するには、予約とプロジェクト間で 2 つのシステム間隔を比較します。

スロット競合の問題をトラブルシューティングするには、次の手順とベスト プラクティスを使用します。

これらのベスト プラクティスを試してもジョブのパフォーマンスの問題が解決しない場合は、サポートをリクエストしてください。

ジョブの同時実行数の急増

管理リソースグラフの詳細ビューを使用して、スロット使用量の急増が同時に発生しているジョブ実行の急増がないか確認します。このような急増は、予約で使用可能なスロットに対して競合するジョブが多すぎることを示している可能性があります。

ベスト プラクティス: リソースを大量に消費するクエリを最適化するか、予約のスロット容量を増やすことを検討してください。クエリ パフォーマンスの最適化の詳細については、クエリ計算を最適化するをご覧ください。

スロットの使用量が多い

詳細ビューを使用して、ジョブの所要時間の増加を確認します。特に、予約の最大容量を超えるジョブがないか確認します。スロット使用率が常に高い場合は、スロット競合が継続していることを示している可能性があります。

ベスト プラクティス: ジョブ エクスプローラのスロット競合フィルタを使用してクエリを確認し、スロットを最も多く消費しているクエリを特定して最適化します。

ジョブの所要時間が長い

ジョブの完了にかなり時間がかかっている場合は、詳細ビューを確認します。ジョブの同時実行数とスロット使用量の急増は、スロット競合を示している可能性があります。

ベスト プラクティス: 重要度の低いジョブを一時的に停止するか、ジョブの送信レート全体を減らして、重要なジョブを分離します。

スロット競合メッセージ

分析情報の表には、スロット競合の問題を示す There were NUMBER jobs detected with slot_contention in the reservation. などのメッセージが表示されます。ジョブ エクスプローラで、これらのメッセージでフラグが立てられた特定のジョブの詳細を確認します。

ベスト プラクティス: 特定されたクエリを最適化するか、予約のスロット割り当てを調整します。

予約モニタリングのトラブルシューティング

以降のセクションでは、BigQuery の予約とスロット使用率をモニタリングする際の一般的な問題の解決方法について説明します。

スロット使用率の指標が INFORMATION_SCHEMA と一致しない

リソースグラフのスロット使用率指標と INFORMATION_SCHEMA データに不一致がある場合は、次の操作を試してください。

  • 粒度を減らします。グラフの粒度を 1 時間間隔ではなく 1 秒間隔に変更します。
  • 集計を調整します。リソースグラフと INFORMATION_SCHEMA データの整合性が保たれる集計方法を使用していることを確認します。たとえば、リソースグラフのピーク使用量をより正確に反映するには、指標の集計を p99 または p90 に一貫して変更します。

アイドル状態のスロットが無効になっている場合、借用したスロットが表示される

1 つ以上の予約に ignore_idle_slots=true が設定されている場合でも、モニタリング グラフに borrowed_slots のゼロ以外の値が表示されることがあります。この設定により、予約がアイドル スロットを借用することはできなくなりますが、未使用のスロットを他の予約に貸し出すことはできます。

借用したスロットは、次の場合に表示されます。

  • 他の予約への貸し出し。ignore_idle_slots=true を含む予約は、同じ管理プロジェクト、リージョン、エディションにあり、アイドル スロットの借用（ignore_idle_slots=false）を許可している他の予約に、未使用のベースライン スロットを貸し出すことができます。管理プロジェクト、リージョン、エディションのすべての予約に ignore_idle_slots=true がある場合、アイドル スロットは共有されません。

    たとえば、予約 A に 100 スロットがあり、使用量が 0 で、ignore_idle_slots=true で構成されているとします。予約 B は、同じ管理プロジェクト、リージョン、エディションにあり、100 個のスロットがあり、ワークロードに 150 個のスロットが必要で、ignore_idle_slots=false で構成されています。予約 B は、予約 A から 50 個のアイドル スロットを借りて、ニーズを満たすことができます。この場合、モニタリング グラフには、予約 A の 50 個の lent_slots と予約 B の 50 個の borrowed_slots が報告されます。

  • 容量を超えた使用。予約のスロット使用量が一時的に容量（ベースライン + 自動スケーリングされたスロット）を超えると、モニタリング グラフにこの差が borrowed_slots として表示されます。この動作は、ignore_idle_slots=true を含む予約でも発生する可能性があります。

スロットの使用量は、ベースラインとスケーリングされたスロットの合計を超える場合があります。ベースラインとスケーリングされたスロットの合計を超えるスロットの使用量に対しては課金されません。

借りたスロットは、予約が完全に使用される前に表示される

モニタリング ダッシュボードではサンプリング データが使用されます。このデータは、サンプリング間隔内のスロット使用の正確なタイミングを正確に反映していない可能性があります。

スロット使用量をより正確に分析するには、INFORMATION_SCHEMA.RESERVATIONS_TIMELINE ビューの borrowed_slots 列や lent_slots 列など、アイドル スロットに関連する列をクエリします。

次のステップ