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

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

課金モデルを選択する

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

Reservations のトレードオフ

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

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

Reservations の決定フロー。

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

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

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

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

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

オンデマンドと定額の課金モデルを混在させることも可能です。例:

  • 定期的なデータ処理や ELT など、予測可能なワークロードにはオンデマンド課金を使用します。
  • アドホックの分析やデータ サイエンス ワークロードには、定額課金を使用します。

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

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

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

管理プロジェクトの作成

コミットメントと予約を作成すると、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、Cloud Logging、Jobs API、または BigQuery Audit のログを使用して、プロジェクトで実際に使用されているスロットの数を確認することが重要です。詳細については、利用可能なスロットと割り当てられているスロットの表示をご覧ください。

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

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

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

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

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

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

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

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

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

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

複雑な組織用の BigQuery Reservations

BigQuery Reservations は、組織を対象にしたリソースです。commit された容量を一元的に購入して組織全体で使用します。commit された容量の購入と部署内での配分を各部署が行い、容量に応じた課金を受けるようにすることで、BigQuery Reservations の自己管理を個々の部署に求めることができます。

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

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