このページの一部またはすべての情報は、S3NS の Trusted Cloud に適用されない場合があります。

予約を使用したワークロード管理

このページでは、スロット予約を使用して BigQuery ワークロードを管理する方法について説明します。

スロットの予約

BigQuery では、スロットは予約と呼ばれるプールに割り当てられます。予約を使用すると、組織に適した方法で容量を管理し、ワークロードを分離できます。たとえば、本番環境ワークロード用に prod という名前の予約と、テスト用に test という名前の別の予約を作成します。これにより、テストジョブが本番環境ジョブとリソースを奪い合うことを避けられます。または、組織内の部門ごとに予約を作成してコンピューティングコストを割り当てることもできます。

予約と呼ばれてはいるものの、予約内の容量が必ずしも予約されているわけではありません。自動スケーリング予約を使用すると、需要に応じて容量が自動的にスケールアップまたはスケールダウンされます。また、アイドルスロットを予約間で共有できます。

予約の割り当て

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

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

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

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

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

QUERY: この予約は、SQL、DDL、DML、BigQuery ML（組み込みモデル）クエリなどの非継続的クエリジョブに使用します。
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 ジョブをそれらのスロットに割り当てることができます。[アイドルスロットを無視する] を有効にして、追加の専用予約を作成することをおすすめします。アイドルスロットの詳細については、アイドルスロットをご覧ください。

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

特定の割り当てにスロットを割り当てることはできません。BigQuery スケジューラは、予約を使用するジョブのスロット割り当てを処理します。スロットの使用方法の詳細については、BigQuery での公平なスケジューリングをご覧ください。

予約を柔軟に割り当てる

この機能に関するサポートのリクエストやフィードバックを行う場合は、bigquery-wlm-feedback@google.com にお問い合わせください。

BigQuery では、実行時にどの予約でクエリを実行するかを指定できます。これにより、リソース割り当てをより詳細に制御し、不要なプロジェクトの作成を回避できます。CLI、UI、SQL、API を使用して実行時に予約を指定し、プロジェクト、フォルダ、組織のデフォルトの予約割り当てをオーバーライドできます。割り当てられた予約は、実行するクエリと同じリージョンに存在する必要があります。これらの割り当ては、すべてのエディションでサポートされています。

クエリの実行時に予約を使用するには、予約へのアクセス権が必要です。

予約を柔軟に割り当てるには、インタラクティブクエリを実行して予約を指定します。

予約とオンデマンド課金を組み合わせる

あるリージョンでは容量ベースを使用し、別のリージョンではオンデマンドを使用できます。デフォルトでは、すべてのプロジェクトでオンデマンド課金が使用されます。プロジェクト、フォルダ、または組織を予約に割り当てることで、特定のリージョンで容量ベースの課金を選択できます。たとえば、米国のマルチリージョンでスロットコミットメントを購入し、デフォルトの予約に組織を割り当てた場合、組織は米国のマルチリージョンでは容量ベースの課金になり、それ以外のリージョンではオンデマンド課金が継続されます。

特定のリージョンでは、明示的にプロジェクトを予約に割り当てることで、容量ベースの課金とオンデマンド課金を組み合わせて使用できます。予約に割り当てられていないプロジェクトでは、オンデマンド課金が継続されます。予約 ID none を割り当てることにより、オンデマンド課金を使用するように、明示的にプロジェクトを割り当てることもできます。これは、フォルダまたは組織を予約に割り当てる際、そのフォルダまたは組織内の一部のプロジェクトでオンデマンド課金を使用したい場合に有効です。詳細については、プロジェクトを None に割り当てるをご覧ください。

オンデマンド課金のプロジェクトでは、コミットされた容量とは別の容量を使用します。これらのプロジェクトは、コミットされた容量の可用性に影響しません。

管理プロジェクトを指定する

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

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

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

管理プロジェクトは、commit したスロットに応じて課金されます。スロットを使用するプロジェクトは、スロットではなくストレージに応じて課金されます。複数のプラン（1 年と 3 年など）を購入し、スロットを同じ管理プロジェクトに配置できます。

管理プロジェクトの数を制限することをおすすめします。制限することで、課金管理とスロットの割り当てが簡素化されます。可能であれば、組織のすべての予約に対して 1 つの管理プロジェクトを作成することを推奨します。複雑な組織では、管理要件や課金要件を満たすために、追加の管理プロジェクトが必要になる場合があります。

複数の管理プロジェクトを使用する

場合によっては、複数の管理プロジェクトを作成することをおすすめします。

複数の予約とコミットメントの費用を異なる組織部門に分割する。
1 つまたは複数のスロットのコミットメントを特定の予約セットにマッピングする。

アイドルスロットの容量は、異なる管理プロジェクトの予約間で共有されません。

BigQuery Trusted Cloud コンソールの [容量管理] ページでは、選択した管理プロジェクトの予約とコミットメントのみを表示できます。

スロット予約のサイズ設定

BigQuery は、リソースの増加に比例してスケールされるように設計されています。ワークロードによっては、容量が徐々に増加することで、得られるメリットも増えていく可能性があります。ただし、容量を追加するとコストも増加します。このため、最適な購入スロット数は、パフォーマンス、スループット、ユーティリティの要件によって異なります。

ベースラインスロットと自動スケーリングスロットを試して、スロットの最適な構成を決定できます。たとえば、500 ベースラインスロットでワークロードをテストし、次に 1,000 スロット、1,500 スロット、2,000 スロットと順にテストして、パフォーマンスへの影響を確認します。

スロットを購入して少なくとも 7 日間ワークロードを実行した後、スロット見積もりツールを使用してパフォーマンスを分析し、スロットの追加や削除の影響をモデル化できます。

選択した月額料金と一緒に、プロジェクトの現在のスロット使用量も確認できます。オンデマンドワークロードでのスロットの上限は 2,000 スロットですが、INFORMATION_SCHEMA.JOBS* ビュー、Cloud Logging、Jobs API、または BigQuery Audit のログを使用して、プロジェクトで実際に使用されているスロットの数を確認することが重要です。詳細については、予約をモニタリングするをご覧ください。

スロット使用のタイムライン。

予約を使用してワークロードを管理する

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

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

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

コミットメントを削除します。

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

複数のリージョンの予約を管理する

予約はリージョンリソースです。あるリージョンで購入されたスロットと作成された予約は、他のリージョンでは使用できません。プロジェクト、フォルダ、組織はすべて、同じリージョン内で予約に割り当て、別のリージョンでオンデマンドで実行できます。別のリージョンの予約を管理するには、BigQuery の [容量管理] ページでリージョンを変更する必要があります。

BigQuery コンソールで、[予約] をクリックします。
[ロケーション] 選択ツールをクリックし、予約を管理するリージョンを選択します。
リージョンを選択したら、スロットの購入、予約の作成、予約へのプロジェクトの割り当てを行えます。

複雑な組織で予約を管理する

予約は組織を対象にしたリソースです。予約を作成するときに、同じ Trusted Cloud組織内の任意のプロジェクトに容量を割り当てることができます。ほとんどの BigQuery ユーザーは、予約とコミットメントに単一の管理プロジェクトを使用します。管理プロジェクトには Cloud Billing アカウントが関連付けられており、容量に応じて課金されます。

ただし、複数の部門が独自の請求書を管理する複雑な組織の場合は、複数の管理プロジェクトを使用することをおすすめします。アイドルスロットは、同じ管理プロジェクトで作成された予約間でのみ共有できます。予約プロジェクトと管理プロジェクトの割り当てと上限に注意する必要があります。

複数の Trusted Cloud 組織を使用している場合は、組織ごとに少なくとも 1 つの管理プロジェクトを作成し、関連する管理プロジェクトで各組織の予約とコミットメントを管理する必要があります。組織間で容量を共有することはできません。

予約の拡張コントロールを管理する

この機能に関するサポートのリクエストやフィードバックを行う場合は、bigquery-wlm-feedback@google.com にお問い合わせください。

BigQuery の予約では、予約の使用方法をより詳細に制御でき、追加のセキュリティ機能も提供されます。特定の予約にアクセスして使用できるユーザーまたはグループを指定するポリシーを定義できます。これにより、機密データとワークロードが分離され、保護されます。予約管理者は、特定の予約の使用を許可するユーザーまたはサービスアカウント（プリンシパル）を正確に制御できます。これを行うには、管理プロジェクト（予約が管理されるプロジェクト）に適用される IAM 条件を使用します。

たとえば、名前が特定の接頭辞で始まるすべての予約に対して、特定のユーザーグループに reservations.use 権限を付与する IAM 条件を作成できます。これにより、関連する予約のセットへのアクセスを管理できます。

ジョブのデフォルトの予約をオーバーライドするには、ユーザーに reservations.use 権限が必要です。この権限は、roles/bigquery.resourceAdmin ロールと roles/bigquery.resourceEditor ロールで提供されます。個々のユーザー、グループ、サービスアカウントにアクセス権を付与できます。IAM 条件は属性ベースのアクセス制御をサポートしているため、名前などの予約属性に基づいてポリシーを定義することもできます。

予約に IAM 条件を付与するには、予約へのアクセスを制御するをご覧ください。

スロットのコミットメント

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

年間契約。365 日間分のコミットメントを購入します。365 日後に、更新または別のタイプのコミットメントプランへの変更のいずれかを選択できます。
3 年間の確約利用。3 年間のコミットメントを購入します。3 年（1,095 日）後に、更新または別のタイプのコミットメントプランへの変更のいずれかを選択できます。

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

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

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

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

パフォーマンスと初期容量を最も予測しやすくするには、予約にゼロ以外のベースラインを割り当てることをおすすめします。ベースラインスロットをゼロに設定して予約を構成し、自動スケーリング機能を使用する目的で最大容量を設定できますが、このアプローチの有効性は、自動スケーリングが適正に有効化され、スロットを積極的に取得しているかどうかに完全に依存します。このようなゼロベースライン予約で自動スケーリングが効果的に機能しない場合、使用可能なアイドルスロット容量のみに依存する状態に戻ります。この状態ではパフォーマンスが保証されず、クエリ速度が予測不能になったり低下したりする可能性があります。

コミットメントの更新

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

なし。コミットメントが終了すると、コミットメントは削除されます。予約には影響しません。
年間。コミットメント期間の終了後、コミットメントはさらに 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 のサポートにお問い合わせください。

予約の制限事項

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

予約の予測可能性

この機能に関するサポートのリクエストやフィードバックを行う場合は、bigquery-wlm-feedback@google.com にお問い合わせください。

予約の予測可能性を使用するには、まず予約の公平性を有効にする必要があります。

予約の予測可能性を使用すると、予約で消費されるスロットの絶対最大数を設定できます。BigQuery は、ベースラインスロット、アイドルスロット、自動スケーリングスロットを潜在的な容量のリソースとして提供します。最大サイズで予約を作成する場合、過去のワークロードに基づいて、ベースラインスロットの数と、自動スケーリングおよびアイドルスロットの適切な構成を確認してください。

予約の予測可能性を有効にするには、予約の最大スロット数とスケーリングモードの両方の値を設定する必要があります。最大スロット数は正の数で、予約に割り当てられたベースラインスロット数より大きい値にする必要があります。予約の予測可能性の操作の詳細については、専用スロットを使用して予約を作成するをご覧ください。予約で最大スロット値を設定する際に、autoscale_max_slots の値を構成することはできません。

ignore_idle_slots の値はスケーリングモードと一致している必要があります。スケーリングモードが ALL_SLOTS または IDLE_SLOTS_ONLY の場合、ignore_idle_slots は false にする必要があります。スケーリングモードが AUTSOCALE_ONLY の場合、ignore_idle_slots は true にする必要があります。

予約を構成して、定義された最大値までの次の容量リソースの組み合わせのみを使用できます。

ベースラインスロット + アイドルスロット: 予約スロット容量が 0 より大きく、スケーリングモードが IDLE_SLOTS_ONLY です。予約では、ベースラインスロットと使用可能なアイドルスロットの構成された数が、スロットの最大数まで使用されます。十分な使用できるアイドルスロットがない場合は、予約が最大数に達しないことがあります。
ベースラインスロット + アイドルスロット + 自動スケーリングスロット: 予約スロット容量が 0 より大きく、スケーリングモードが ALL_SLOTS です。予約では、まず構成された数のベースラインスロット、次に使用可能なすべてのアイドルスロット、最後に自動スケーリングスロットが使用されます。
ベースラインスロット + 自動スケーリングスロット: 予約スロット容量が 0 より大きく、スケーリングモードが AUTOSCALE_ONLY です。予約では、まず構成されたベースラインスロット、次に自動スケーリングスロットが使用されます。
アイドルスロット + 自動スケーリングスロット: 予約スロット容量は 0 で、スケーリングモードは ALL_SLOTS です。予約では、まず使用可能なすべてのアイドルスロットが使用され、次に自動スケーリングスロットが使用されます。
アイドルスロット: 予約スロット容量が 0 で、スケーリングモードが IDLE_SLOTS_ONLY です。予約では、構成された最大数まで使用可能なアイドルスロットすべてが使用されます。十分な使用できるアイドルスロットがない場合は、予約が最大数に達しないことがあります。

次の図は、使用可能なさまざまな構成オプションを示しています。

予測可能な予約構成オプション。

図の 5 つの構成オプションは、BigQuery が構成された最大数までスロットを使用する方法を示しています。最初の 3 つのオプションにはベースラインスロットが含まれていますが、他のオプションにはベースラインスロットが構成されていません。

制限事項

予約の予測可能性には次の制限事項があります。

予約の予測可能性は、AUTOSCALE_ONLY オプションを選択しない限り、Enterprise エディションと Enterprise Plus エディションでのみ使用できます。
予約の予測可能性はベストエフォートです。全体的な使用量が構成された最大値を超える可能性があります。

次のステップ

予約の予測可能性の操作の詳細については、専用スロットを使用して予約を作成するをご覧ください。