G-gen の杉村です。当記事は「BigQuery Reservation (Flat-rate pricing)」について説明する記事です。

注意 : BigQuery の料金体系について

当記事で解説されている「BigQuery Reservation (Flat-rate pricing)」は 2023/07/05 で販売が終了 し、以後は BigQuery Editions が Flat-rate pricing に代わる仕組みとなります。

以降の当記事の記載は、古い制度のものですのでご注意ください (アーカイブの意味合いで残しています)。

現在の BigQuery の料金体系は、以下の記事を参考にしてください。

blog.g-gen.co.jp

BigQuery Reservations とは

BigQuery Reservations とは事前に BigQuery のクエリ処理容量を購入することで BigQuery のクエリ料金を定額 (flat-rate) 化できる機能です。

オンデマンド課金では BigQuery が処理したバイト数に応じて従量で課金が決まるのに対して flat-rate 課金では 事前にクエリ処理容量を購入 することになります。

なお BigQuery Reservations という言葉と Flat-rate pricing という言葉があります。 BigQuery Reservations は機能名であり、この機能を使うことで Flat-rate pricing に料金体系を切り替えられる、と理解すればよいでしょう。 Flat-rate pricing (定額課金) の対義語は On-demand pricing (従量課金) です。

なお BigQuery Reservations で予約できるのは クエリ処理の課金に対してのみ です。
ストレージの課金は別途、従量課金で発生します のでご注意ください。

用語

コミットメント (Commitment)

コミットメント (Commitment) とは BigQuery の処理容量の購入単位です。

BigQuery では スロット という概念があります。スロットは単純に言うと BigQuery で使用される仮想 CPU であり、 BigQuery のクエリを処理する頭脳たちです。このスロットを事前購入することを「コミットメントを作成 (購入) する」のように表します。

コミットメントプランは以下の 3 つが存在します。

年間
月次
Flex

年間では 365 日間、月間では 30 日間、 Flex では 60 秒間が購入の 最小単位 となります。
この最小単位の期間が過ぎれば、コミットメントをキャンセルしたりプラン変更することができます。
コミット期間が長いほど、スロットあたりの料金が安くなります。

なお最小期間が過ぎてもキャンセルになるわけではなく、スロットは保持されて課金されます (参照)。

Flex は 60 秒単位で購入可能なため、ワークロード管理のテスト用にスロット購入したい場合や、税務申告など季節性・短期の処理増加への対応などに適しています。また応用的な使い方として「重いバッチ処理の直前に Flex スロットを購入して割り当てる。バッチ処理が終わったらスロットをキャンセルする (スロットの購入・キャンセルはワークフローツールで自動的に行う) 。」といった使い方も可能です。

予約 (Reservation)

予約 (Reservation) とは購入したコミットメントをプロジェクトに割り当てるための管理単位です。

例えばボリュームの異なるコミットメントを 2 つ購入してそれぞれ prod と test という予約に割り当て、 prod は本番環境用プロジェクトに、 test はテスト環境用プロジェクトに割り当てる、といったことが可能です。

なおコミットメントを購入すると最初に default という名前の予約に割り当てられます。

割り当て (Assignment)

割り当て (Assignment) とは予約 (Reservation) を「プロジェクト」「フォルダ」「組織」のいずれかに割り当てることを意味します。

一つの予約を複数の「プロジェクト」「フォルダ」「組織」に割り当てることも可能です。

割り当てには継承の概念があり、例えばあるプロジェクトに予約の割り当てが存在しない場合、上位のフォルダか組織の割り当てが適用されます。

明示的に割り当てを None に指定することもできます。例えば組織全体に予約を割り当てているが、一部プロジェクトだけ None に設定すれば、そのプロジェクトだけは購入したスロットを使わずオンデマンド課金を使わせる、といったことが可能です。

料金

BigQuery Reservation の料金

年間、月間、 Flex の順で、コミット期間が長いほどスロットあたりの料金が安くなります。
2022 年 4 月現在の金額では 100 スロットあたりの金額は以下です。

Plan	Price	単位
年間	$2,040	100 スロット / 月額
月間	$2,400	100 スロット / 月額
Flex	$3,504	100 スロット / 月額

最新の料金は公式ページをご参照ください。

cloud.google.com

購入是非の判断

BigQuery Reservations (Flat-rate pricing) はどのようなときに使うべきなのでしょうか。

以下のいずれかに当てはまるときだと言えます。

BigQuery の料金を定額・予測可能にしたいとき
多重実行されるジョブ (クエリ) が非常に多く、オンデマンドプランのスロット上限である 2,000 スロットを定常的に超えるとき

1つ目の「料金を定額・予測可能にしたいとき」の意味は読んで字のごとくです。BigQuery の特徴は従量課金ですが、これが会社の支払いの仕組みや財務上の理由で望ましくない場合は Flat-rate pricing が選択肢になります。

また、社内の BigQuery 利用者が多く、クエリのボリュームが予測困難である場合に安全柵としてスロット利用料を固定化する、という使い方も考えられるかもしれません。

2 つ目の「オンデマンドプランのスロット上限である 2,000 スロットを定常的に超えるとき」は性能上の理由です。

スロットのスケジューリングは BigQuery によって自動的に行われています。必ずしも多くのスロットがあると処理が早くなる、というわけではなく、複数クエリが効率的に実行されるように最適化されます。またスロットが一時的足りない場合は、実行できないクエリはエラーになるわけではなくキューで待たされて、最終的には実行されます。なおオンデマンドモードでの最大スロットはプロジェクトごとに 2,000 ですがベストエフォートで一時的に バースト します。

オンデマンドモードの上限である 2,000 スロットは相応に大きいものです。また、前述のように「 Flat-rate を購入すれば速くなる」わけではありませんし後述のように「 Flat-rate を購入すれば必ず安くなる」わけでもありません。 現在のスロット利用状況を確認 した上で 本当に Flat-rate の導入が必要かどうかを適切に判断 するべきです。

現在のクエリワークロードにおいてどのくらいのスロットが消費されているのかを確認するには、以下のような方法があります。

スロット見積もりツールを利用する
Cloud Monitoring の slots/allocated_for_project メトリクスで確認
INFORMATION_SCHEMA ビューで確認 (参考)

また、以下のツール "Slot Recommender" で購入すべきスロット数のリコメンデーションを受けることもできます。

スロットの推奨事項と分析情報の表示

安くなるのか？

Flat-rate を購入すれば必ず安くなる、というわけではありません。この点が、例えば Compute Engine の確約利用割引 (Committed Use Discounts) などのリソース予約購入制度とは異なる点です。

BigQuery の通常モードであるオンデマンド課金では「クエリでスキャンしたデータのサイズ」と「ストレージの料金」の 2 軸で課金されます。このうち BigQuery Reservation (Flat-rate) と関係があるのは前者です (2022 年 4 月現在の東京リージョンでは 1 TB あたり $6) 。

その一方で Flat-rate 料金は「スロットの予約を購入する」という概念であり、オンデマンド料金の「スキャンしたデータ量」とは計測の対象が異なります。そのため、どちらのほうがコストパフォーマンスがよくなるかは クエリの利用状況によって異なる のです。傾向としては、 定常的にクエリが発行されておりスロットの使用状況が一定であるほど Flat-rate のコストメリットが出てくる と言えます。

また Flat-rate とオンデマンド課金は組み合わせて使うこともできます。最適な利用方法を検討することが重要です。

制限

購入したスロットや予約は 他の「組織」とは共有できません 。
組織ごとにスロット購入や予約の管理を検討する必要があります。

またコミットメント (スロット購入) は リージョンリソース です。
例えば東京リージョンで購入したスロットを別のリージョンで使ったり、あるいは移動することはできません。

応用

管理プロジェクト

BigQuery のコミットメントや予約 (Reservation) といったリソースは、一つの 管理プロジェクト で集約管理することが推奨されています。

この管理プロジェクトでコミットメント購入や予約の作成を行い、 BigQuery ジョブが実行される各プロジェクトに予約を割り当てていくことが望ましいとされます。
これにより請求の管理やスロット割り当ての管理が中央集約され、シンプルになります。

ただし 1 つの組織の中で権限を複数部門に移譲しており、 BigQuery Reservations 機能の利用も各部門に任せ、請求負担も明確にしたい場合はこの限りではありません。自分の組織の運用形態に応じて、適切な管理方法を選ぶのが良いでしょう。

スロットスケジューリングとアイドルスロット

ある一つの予約 (Reservation) が複数プロジェクトに割り当てられているとします。

すると、その予約のスロットはまずプロジェクト間で均等に分配されます。
次にプロジェクト内で実行されているジョブ (クエリ等) に分配されます。
BigQuery 内部のスケジューラが分配をうまくコントロールし、不均衡や無駄が置きないように調整してくれます。

しかし気になるのは、このようなケースではないでしょうか。
例:

10,000 スロットを購入して 2 つの予約 ( batch , analyst ) にそれぞれ 7,000 、 3,000 で割り当てた
その予約 batch , analyst をそれぞれプロジェクト project-batch と project-bi に割り当てた
ある時間では project-batch はクエリがかなり回っていてスロットが足りない一方、タイミング的に project-bi はクエリが回っておらずスロットが余っている