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

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

課金モデルを選択する

オンデマンドと定額の料金モデルはいつでも切り替えることができます。また、2 つのモデルを組み合わせて利用することもできます。2 つの料金モデルは相互補完的な関係にあります。オンデマンド課金は効率的であり、定額課金は予測可能です。

定額課金を選択する場合は、次の点を検討してください。

費用。毎月の分析費用が、概算で BigQuery 最小定額コミットメント以内となる場合におすすめします（現在、毎月 100 スロット）。
効率性。クエリごとの支払いになるため、効率性を重視する場合はオンデマンドを検討してください。
予測可能性。定額の月額料金制で支払うため、月額料金の予測可能性を重視する場合は、定額をおすすめします。
リソース。定額とオンデマンドの課金モデルは、容量の提供方法が異なります。詳細については、購入するスロット量の見積もりをご覧ください。

Reservations の決定フロー。

新規のお客様の場合、定額制での開始をおすすめします。オンデマンド課金にした場合の費用は随時確認できます。また、自分に適したモデルもいつでも選択できます。

使用量が安定しているワークロード構成を設定する前に、Flex Slots を試して、組織向けの定額制の料金とパフォーマンスをテストすることもできます。Flex Slots は特殊なコミットメントタイプです。

コミット期間は 60 秒のみです。
その後はいつでも Flex Slots のスロットをキャンセルできます。
コミットメントがデプロイされた期間中にのみ秒単位で課金されます。

Flex Slots のスロットコミットメントは、他の種類のコミットメントと組み合わせることができます。Flex Slots は、次のような一度に数分から数日の範囲で実施される短期間のユースケースに最適です。

税務申告の時期、ブラックフライデー、人気のメディアイベント、ビデオゲームのリリースなど、主要なカレンダーイベントの計画を立てる。
月曜日の朝など、分析の需要が高い周期的な期間に対応する。
データウェアハウスの評価を実施し、最適な利用スロット数をダイヤルインする。

ワークロードまたはビジネスユニットを別々のプロジェクトまたはフォルダに整理して、それぞれを予約またはオンデマンド課金に割り当てることで、ワークロードレベルまたはビジネスユニットレベルでオンデマンドと定額の課金モデルを組み合わせることもできます。

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

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

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

期限切れのコミットメント

定額コミットメントがある場合、更新プランが指定されていないと、コミットメントが削除されます。キャパシティを失わないようにするため、余分なスロットは、システムによって作成された system-created-Enterprise という予約のベースラインに移動します。コミットメントが期限切れになった後、請求は次の 3 つの部分で構成されます。

残りのコミットメント。
残りのコミットメントの対象ではないベースラインスロット。
スケーリングされるスロットは自動スケーリングによって管理されます。

シナリオ 1: コミットメントが合計ベースラインと等しい

期限切れとなる 100 スロットのコミットメントが 1 件、100 ベースラインスロットの予約が 1 件あるとします。

100 スロットが削除され、100 ベースラインに基づいて課金されるようになります。

シナリオ 2: 合計ベースラインよりも大きいコミットメント

期限切れとなる 200 スロットのコミットメントが 1 件、100 ベースラインスロットの予約が 1 件あるとします。

200 スロットが削除され、100 ベースラインで system-created-Enterprise が作成されます。ベースラインの合計 200 に基づいて課金されます。

シナリオ 3: 年単位の定額更新プランでのコミットメント

100 スロットおよび年単位の定額更新プランを含む年単位の定額コミットメントが 1 つあり、これが期限切れになるとします。

100 スロットが、年単位の更新プランを含む Enterprise 年間コミットメントに移動します。

管理プロジェクトの作成

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

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

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

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

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

購入するスロット数の見積もり

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

Flex Slots を使用して、最適なスロット構成を試すことができます。たとえば、500 スロットでワークロードをテストし、次に 1,000 スロット、1,500 スロット、2,000 スロットと順にテストして、パフォーマンスへの影響を確認します。

月額の希望料金と一緒に、プロジェクトの現在のスロット使用量も確認できます。オンデマンドワークロードでのスロットの上限は 2,000 スロットですが、ビューの INFORMATION_SCHEMA.JOBS*、Cloud Logging、Jobs API、または BigQuery Audit のログを使用して、プロジェクトで実際に使用されているスロットの数を確認することが重要です。詳細については、利用可能なスロットと割り当てられているスロットの表示をご覧ください。

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

スロットを購入して少なくとも 7 日間ワークロードを実行した後、スロット見積もりツール（プレビュー）を使用してパフォーマンスを分析し、スロットの追加や削除の影響をモデル化できます。詳細については、スロットの容量要件の見積もりをご覧ください。

予約を使用したワークロードと部門の管理

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

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

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

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

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

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

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

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

複雑な組織用の BigQuery Reservations

BigQuery Reservations は、組織を対象にしたリソースです。commit された容量を一元的に購入して組織全体で使用します。commit された容量を購入し、その容量を部門や部署全体に分配することで、個々の部門や部署に BigQuery Reservations の管理を求めることができます。Cloud 請求先アカウントには、管理プロジェクトが関連付けられており、容量に対して課金されます。

部署ごとに別個の Google Cloud 組織を使用できます。このシナリオでは、組織ごとに管理プロジェクトを定義し、その管理プロジェクトからその組織の BigQuery Reservations を管理します。複数の組織間で、commit された容量や未使用の容量が共有されることはありません。

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