ワークロード管理の概要

BigQuery のワークロード管理では、組織内のデータ分析に使用できるリソースと機能を制御し、課金モデルを定義できます。BigQuery のコンピューティング容量はスロット単位で測定され、予約とコミットメントで購入できます。購入したコンピューティング容量は、ジョブを実行するために組織全体に割り当てます。

BigQuery には、「コンピューティング」とも呼ばれる、データ分析用のワークロード管理の 2 つのモデルが用意されています。 オンデマンド課金では、データのクエリで処理されたバイト数に対して料金が発生します。容量ベースの課金では、容量を自動的にスケールアップまたはスケールダウンするオプションを使用して、ワークロードの処理容量を予約します。

オンデマンド課金モデルと容量ベースの課金モデルはいつでも切り替えることができます。また、この 2 つのモデルを組み合わせることもできます。容量ベースのモデルではスロットと処理容量を明示的に制御できますが、オンデマンド モデルではできません。

以下のモデルでは、ワークロードの管理方法と課金方法が定義されます。

• オンデマンド料金: デフォルトでは、クエリでスキャンされたデータに対して課金されます。プロジェクトごとにクエリの処理容量が固定されており、使用時の処理バイト数分だけ料金が発生します。

• 容量ベースの料金: 専用または自動スケーリングのクエリ処理容量を割引料金で購入します。容量は、ワークロードまたは組織の一部に割り当てるスロット単位で測定されます。容量ベースの課金にはコミットメントのオプションが用意されています。このオプションでは、1 年間または 3 年間にわたって一定レベルの処理容量を割引価格で確約できます。容量ベースのモデルを使用する場合、処理されたバイト数には課金されません。容量ベースの料金のメリットは次のとおりです。

  • 費用。費用を削減するため、BigQuery の容量ベースのコミットメントとして、毎月の分析の最小使用量を設定することをおすすめします。
  • 予測可能性。容量ベースのスロットを使用すると、月額料金がより安定します。
  • 一元購入: スロットをまとめて購入し、BigQuery を使用するプロジェクトごとではなく、組織全体に割り振ることができます。
  • 柔軟性。ワークロードに割り当てる容量を選択するか、ワークロードの要件に基づいて BigQuery が自動的に容量をスケーリングするようにします。最小使用期間は 1 分間で、秒単位で課金されます。

BigQuery のエディションを利用する予約を扱う場合は、容量コミットメントの作成は任意ですが、定常状態のワークロードの費用は削減できます。

課金モデルを組み合わせて使用できます。たとえば、一部のワークロードをオンデマンド料金で実行して、それ以外は容量ベースの料金で実行できます。課金モデルはプロジェクトごとに指定されるため、クエリジョブに複数のプロジェクトを使用する必要があります。予約に関する BigQuery の料金について詳しくは、以下をご覧ください。

• オンデマンド料金
• 容量ベースの料金
• 費用の見積もりと管理
• カスタムコスト管理を作成する

スロット

BigQuery の処理容量はスロット単位で測定されます。スロットは、データのクエリに使用される仮想 CPU を表します。一般に、アクセスできるスロットが多いほど、同時実行できるクエリの数が増え、複雑なクエリをより高速に実行できます。容量ベースの料金モデルでは、大量のスロットを予約できます。クエリはその容量内で実行され、デプロイされる 1 秒ごとに容量に対して継続的に支払います。たとえば、BigQuery スロットを 2,000 購入した場合、集計したクエリはいつでも 2,000 の仮想 CPUに制限されます。この容量は削除するまで保持され、削除するまで 2,000 スロットに対して支払います。

スロットとその使用方法について詳しくは、スロットについてをご覧ください。

スロットの割り当て

スロットの割り当てにより、BigQuery の安全性が確保されます。割り当てタイプは、スロットの料金モデルによって異なります。

• オンデマンド料金モデル: ほとんどのユーザーは、一時的なバースト機能を備えたプロジェクトごとのスロットの割り当てで十分です。ワークロードによっては、アクセスできるスロットが多いほど、クエリのパフォーマンスが向上します。アカウントで使用しているスロットの数を確認するには、BigQuery のモニタリングをご覧ください。

• 容量ベースの料金モデル: 予約の割り当てと上限によって、ロケーションで購入できるスロットの最大数が決まります。割り当てではなく、予約とコミットメントに対してのみ課金されます。

スロットの割り当てを増やす方法については、割り当ての増加リクエストをご覧ください。

予約

スロットが購入され、リソースに割り当てられ、予約と呼ばれるプールのジョブに割り振られます。予約を使用すると、組織に適した方法でスロットを割り当てることができます。たとえば、本番環境ワークロード用に prod という名前の予約と、テスト用に test という名前の別の予約を作成するとします。これにより、テストジョブが本番環境ワークロードのリソースに対して競合することがありません。または、組織内の部門ごとに予約を作成することもできます。

予約を作成する前にスロット コミットメントを購入すると、便宜上 default という名前の予約が自動的に作成されます。default 予約には特別な動作はありません。必要に応じて追加の予約を作成するか、デフォルトの予約を使用できます。

料金については、容量ベースの料金とオンデマンド料金をご覧ください。

予約の制限事項

• 作成した予約は他の組織と共有されません。
• 組織ごとに個別の予約と個別の管理プロジェクトを作成する必要があります。
• 各組織では、1 つのロケーションにアクティブなコミットメントを持つ管理プロジェクトを最大 10 個作成できます。
• アイドル状態の容量は、組織間や単一の組織内の異なる管理プロジェクト間で共有できません。
• コミットメントと予約はリージョン リソースです。あるリージョンまたはマルチリージョンで購入したコミットメントは、他のリージョンまたはマルチリージョンでは使用できません。単一リージョン ロケーションがマルチリージョン ロケーションに含まれている場合も同様です。たとえば、EU マルチリージョンで購入したコミットメントを europe-west1 の予約に使用することはできません。
• コミットメントと予約は、あるリージョンまたはマルチリージョンから別のリージョンまたはマルチリージョンに移動できません。
• ある管理プロジェクトで購入したコミットメントを別の管理プロジェクトに移動することはできません。
• あるエディションで購入したコミットメントは、別のエディションの予約で使用できません。
• アイドル スロットは、異なるエディションの予約間で共有されません。
• 自動スケーリングされたスロットは、不要になったときにスケールダウンするため、共有できません。

予約の割り当て

購入したスロットを使用するには、1 つ以上のプロジェクト、フォルダ、または組織を予約に割り当てる必要があります。スロット割り当てを指定するには少なくとも 1 件の予約が必要です。プロジェクト内のジョブが実行されると、割り当てられた予約のスロットが使用されます。リソースは、リソース階層内の親から割り当てを継承できます。プロジェクトが予約に割り当てられていない場合でも、親フォルダまたは組織の割り当てがある場合にはその割り当てが継承されます。

プロジェクトは、割り当てられているリソース階層内で最も明確な単一の予約を使用します。フォルダの割り当ては組織の割り当てをオーバーライドし、プロジェクトの割り当てはフォルダの割り当てをオーバーライドします。

プロジェクトに予約の割り当てや継承がない場合、ジョブはオンデマンド料金を使用します。リソース階層の詳細については、BigQuery リソースの整理をご覧ください。

割り当てがないことを表す None にリソースを割り当てることができます。None に割り当てられたプロジェクトでは、常にオンデマンド料金が使用されます。None 割り当ての一般的な使用例は、組織を予約に割り当て、None を使用してその予約から特定のプロジェクトまたはフォルダをオプトアウトするというものです。詳細については、プロジェクトを None に割り当てるをご覧ください。

割り当てを作成するときに、その割り当てのジョブタイプを指定します。

• BACKGROUND: この予約は、独自の予約を使用して、BigQuery 検索インデックス管理ジョブ、BigQuery 変更データ キャプチャ（CDC）、または BigLake メタデータ キャッシュ バックグラウンド ジョブを実行する場合に使用してください。また、BigQuery へのソース データベースを Datastream のバックグラウンド適用オペレーションでレプリケートする場合にも、この予約を使用します。BACKGROUND 予約は Standard Edition では使用できません。

• CONTINUOUS（プレビュー）: この予約は、継続的クエリジョブに使用します。継続的クエリを使用するには、機能プレビューに登録する必要があります。

• ML_EXTERNAL: この予約は、BigQuery の外部にあるサービスを使用する BigQuery ML CREATE MODEL クエリに使用します。詳細については、BigQuery ML ワークロードへのスロットの割り当てをご覧ください。ML_EXTERNAL 予約は Standard Edition では使用できません。

• PIPELINE: この予約は、読み込みジョブと抽出ジョブに使用します。

  デフォルトでは、読み込みジョブと抽出ジョブは無料であり、スロットの共有プールを使用します。BigQuery は、この共有プールの容量の可用性や、確認されるスループットを保証しません。大量のデータを読み込む場合は、スロットが使用可能になるまでジョブが待機することがあります。その場合は、専用スロットを購入して PIPELINE ジョブをそれらのスロットに割り当てることができます。[アイドル スロットを無視する] を有効にして、追加の専用予約を作成することをおすすめします。アイドル スロットの詳細については、アイドル スロットをご覧ください。

  読み込みジョブと抽出ジョブは、予約に割り当てられると無料のプールにアクセスできなくなります。無料のプールを使用する場合よりも優れたパフォーマンスを発揮できる十分な容量を予約に確保するには、リソースの使用率とジョブをモニタリングします。

• QUERY: この予約は、SQL、DDL、DML、BigQuery ML クエリなどの非継続的クエリジョブに使用します。

特定の割り当てにスロットを割り当てることはできません。BigQuery スケジューラは、予約の割り当てのスロット割り振りを処理します。スロットの使用方法については、予約内でのスロット割り当てをご覧ください。

ワークロード管理について

BigQuery の予約は、組織を対象にしたリソースであり、通常は 1 つのプロジェクトによって所有されますが、組織内の他のプロジェクトが使用できます。組織全体で使用する予約を一元的に購入します。コミット済み容量を購入し、その容量を部門や部署全体に割り当てることで、個々の部門や部署に各自の予約の管理を求めることができます。管理プロジェクトには Cloud 請求先アカウントにが関連付けられており、容量に応じて課金されます。

部署ごとに別個の Google Cloud 組織を使用できます。このシナリオでは、部門ごとに管理プロジェクトを定義し、その管理プロジェクトからその部門の予約を管理します。コミット済み容量やアイドル状態の容量が複数の組織間で共有されることはありません。

アイドル スロットと未割り当てのスロットは、同じ管理プロジェクト内で同じエディション内に作成された予約間でのみ共有されます。複数の管理プロジェクトを使用する場合、異なる管理プロジェクトの予約間でスロットが共有されることはありません。

組織のワークロードを管理する

コミットメントと予約を作成すると、Google Cloud プロジェクトに関連付けられます。このプロジェクトによって BigQuery Reservations リソースが管理されます。このプロジェクトはこれらのリソースに対する請求のプライマリ ソースになります。このプロジェクトは、BigQuery ジョブを保持するプロジェクトと同一である必要はありません。

予約リソース専用のプロジェクトを作成することをおすすめします。このプロジェクトは管理プロジェクトと呼ばれ、コミットメントの請求と管理を一元化します。このプロジェクトにわかりやすい名前を付けます（bq-COMPANY_NAME-admin など）。次に、BigQuery ジョブを保持する個別のプロジェクトを 1 つ以上作成します。

管理プロジェクトと同じ組織リソース内のプロジェクトのみ、予約に割り当てることができます。管理プロジェクトが組織の一部でない場合は、そのプロジェクトに割り当てられているスロットのみを使用できます。

管理プロジェクトは、コミット済みスロットに応じて課金されます。管理プロジェクトが所有する予約のスロットを使用するプロジェクトは、スロットに対して課金されません。複数の種類のプラン（1 年間のコミットメントと 3 年間のコミットメントなど）を購入し、スロットを同じ管理プロジェクトに配置できます。

すべての予約に対して 1 つの管理プロジェクトを作成することをおすすめします。単一の管理プロジェクトを使用すると、請求の管理とスロットの割り当てが簡素化されます。すべてのコミットメントが管理プロジェクトで管理されるようにするため、この管理プロジェクトでのみ BigQuery Reservations API を有効にしてください。

ワークロードと部門の管理

BigQuery の予約を使用して、コミット済み容量をワークロード、チーム、部門の間で分離できます。このためには、予約を追加作成し、それらの予約にプロジェクトを割り当てます。予約は独立したリソースプールであり、組織全体のアイドル容量を活用できるという利点があります。

たとえば、合計で 1,000 スロットのコミット済み容量があり、データ サイエンス、ELT、BI という 3 つのワークロードの種類があるとします。

• 500 個のスロットを使用して ds 予約を作成し、関連するすべての Google Cloud プロジェクトを ds 予約に割り当てることができます。
• 300 個のスロットを使用して elt 予約を作成し、ELT ワークロードに使用するプロジェクトを elt 予約に割り当てることができます。
• 200 個のスロットを使用して bi 予約を作成し、BI ツールに接続されているプロジェクトを bi 予約に割り当てることができます。

ワークロード全体で容量を分割するのではなく、個々のチームや部門用に予約を作成することもできます。

複数のリージョン間での予約の管理

予約はリージョン リソースです。あるリージョンで購入されたスロットと作成された予約は、他のリージョンでは使用できません。単一リージョン ロケーションがマルチリージョン ロケーションに含まれている場合でも、単一リージョン ロケーションはマルチリージョン ロケーションと一致しません。たとえば、EU マルチリージョンの予約を使用して europe-west1 でジョブを実行することはできません。プロジェクト、フォルダ、組織はすべて、同じリージョン内で予約に割り当て、別のリージョンでオンデマンドで実行できます。別のリージョンの予約を管理するには、次の操作を行います。

1. Google Cloud コンソールで [BigQuery] ページに移動します。

   [BigQuery] に移動

2. ナビゲーション メニューで、[容量管理] をクリックします。

3. [ロケーション] リストで、予約を管理するリージョンを選択します。

   リージョンを選択したら、予約の作成、コミットメントの作成、予約へのプロジェクトの割り当てを行うことができます。

コミットメント

容量コミットメントは、指定した期間のスロットを購入する方法です。スロットは 100 スロット単位で、スロット割り当てまで購入できます。容量コミットメントは任意ですが、定常状態のワークロードの費用を節約できます。作成できるコミットメントの数に上限はありません。課金は、コミットメントの購入が正常に終了した時点から始まります。最新の料金情報については、容量コミットメント料金をご覧ください。

• 3 年間のコミットメント。3 年間のコミットメントを購入します。3 x 365 日後に、更新または別のタイプのコミットメント プランへの変更のいずれかを選択できます。

• 年間コミットメント。365 日間分のコミットメントを購入します。365 日後に、更新または別のタイプのコミットメント プランへの変更のいずれかを選択できます。

コミットメント期間の終了時に、選択した更新プランに基づいてコミットメントが更新されます。

年間または 3 年間コミットメント プランの料金は月単位で請求されます。ただし、金銭的なコミットメントはコミットメント期間全体を対象としており、月単位でキャンセルすることはできません。使用量は請求レポートで毎日更新され、いつでも確認できます。

スロット コミットメントは容量の可用性の影響を受けます。スロット コミットメントの購入は必ずしも成功するとは限りません。ただし、コミットメントの購入が完了すると、確保した容量はコミットメントの有効期限が切れるまで利用できます。

コミットメントを更新する

コミットメントの購入時に更新プランを選択します。コミットメントの更新プランは、有効期限が終了するまでの間はいつでも変更できます。次の更新プランを利用できます。

• なし。コミットメントが終了すると、コミットメントは削除されます。予約には影響しません。
• 年間。コミットメント期間の終了後、コミットメントはさらに 1 年間更新されます。
• 3 年間。コミットメント期間の終了後、コミットメントはさらに 3 年間更新されます。

コミットメントの購入と更新については、容量コミットメントを作成するをご覧ください。

たとえば、2019 年 10 月 5 日の午後 6 時に年間コミットメントを購入すると、その時点から課金が開始されます。2020 年 10 月 4 日の午後 6 時以降、コミットメントを削除または更新できます（2020 年はうるう年です）。2020 年 10 月 4 日午後 6 時まで、更新プランを次のように変更できます。

• 年間コミットメントの更新の場合、2020 年 10 月 4 日午後 6 時にコミットメントが更新され、さらに 1 年間有効になります。
• 3 年間のコミットメントに更新する場合、2020 年 10 月 4 日の午後 6 時にコミットメントが更新され、さらに 3 年間有効になります。

注: 更新プロセスは、コミットメントの有効期限が切れてから最大で 1 時間ほどかかることがあります。たとえば、コミットメントが 2020 年 10 月 4 日午後 6 時に期限切れになる場合、更新されたコミットメント レコードは 2020 年 10 月 4 日午後 6 時から午後 7 時の間にシステムに表示されます。作成されたコミットメントの有効な開始時間が午後 6 時であるため、このデータ更新期間内はオンデマンド料金は発生しません。

コミットメントの有効期限

作成したコミットメントは、コミットメントの有効期限が切れるまで削除できません。年間コミットメントまたは 3 年間のコミットメントを削除するには、更新プランを NONE に設定します。期限切れになったコミットメントは、自動的に削除されます。コミットメントの有効期限の詳細については、コミットメントの有効期限をご覧ください。

コミットメントを誤って購入した場合や、コミットメントの構成を間違えた場合は、Cloud Billing のサポートにお問い合わせください。

次のステップ

• BigQuery の予約の利用を開始するには、予約のスタートガイドをご覧ください。
• スロットについて
• オンデマンド料金について確認する
• 容量ベースの料金について確認する
• 費用の見積もりと管理
• カスタムコスト管理を作成する