BigQueryの料金体系(BigQuery Editions)を徹底解説

G-genの杉村です。Google Cloud (旧称 GCP) のフルマネージドなデータウェアハウスサービスである BigQuery の新しい料金体系「BigQuery Editions」が 2023年3月29日に発表され、2023年7月5日に施行されました。当記事ではその仕組みと、従来の料金体系との違いなどについて解説します。

概要

新しい価格体系

2023年3月29日 (米国時間) の Google Data Cloud & AI Summit において、BigQuery の新しい料金体系である BigQuery Editions が発表されました。

これに加えて既に発表済みのいくつかの新機能を合わせることで、2023年7月までに BigQuery の価格体系が以下のように変更されます。

• コンピュート料金はオンデマンドまたは BigQuery Editions (3 つのエディション) から選択
  • 従来の Flat-rate pricing は廃止され BigQuery Editions へ移行
  • BigQuery Autoscaler によるスロットのオートスケーリングによる柔軟な課金が前提
  • オンデマンドは引き続き利用可能だが、単価が変更される
• ストレージ料金は新しく Physical storage (圧縮後データ容量) 課金が選択可能

変更は以下のようなタイムラインで行われる予定です。

日付	内容
2023/03/29	・BigQuery Editions の販売開始
2023/07/05	・Physical storage 課金の Preview 終了と GA (一般公開) ・Flat-rate の新規販売の終了 　・Flex slots は Editions に移行 　・Monthly/Annual slots は期間終了すると Editions に移行 ・オンデマンド課金の価格変更が適用

以下は、公式の発表へのリンクです。

• 参考 : Introduction to BigQuery editions
• 参考 : New BigQuery editions: flexibility and predictability for your data cloud

何が変わるか

前提知識として BigQuery の利用料金は以下の 2 つで決定されます。

1. ストレージ料金 (格納したデータサイズに応じた課金)
2. コンピュート料金 (処理能力に対する課金)

すなわち、保存したデータ容量に応じて発生する「ストレージ料金」と、クエリを処理する際に必要なコンピュート能力に対して発生する「コンピュート料金」の2通りです。この基本構造は 新しい料金体系でも同様 です。

※「コンピュート料金」は従来、オンデマンド課金の場合「クエリ料金」「スキャン料金」のように表現されていましたが、本質的にはコンピュートリソースに対する課金の意味合いであることから当記事では統一してコンピュート料金と表現します。

新旧の課金方法を比較すると、以下のようになります。

比較項目	従来	新
ストレージ料金	Logical storage (圧縮前の額面データサイズに対して課金)	Physical storage (圧縮後の実データサイズに対して課金) か Logical storage から選択
コンピュート料金	オンデマンド または Flat-rate	オンデマンド または BigQuery Editions
コンピュートの柔軟性	・オンデマンド : 利用状況に応じて柔軟にスケール ・Flat-rate : 事前にスロットを購入して定額利用	・オンデマンド : 利用状況に応じて柔軟にスケール ・BigQuery Editions : 事前にスロットを購入して定額利用 または BigQuery Autoscaler により柔軟にスケール
オンデマンドの扱い	-	・オンデマンド課金単価が約25%値上げ ・利用可能な機能は Enterprise Plus Edition と同様

値上げか、値下げか

課金体系が大きく変更されるため、既存の BigQuery ユーザーにとってはこの変更が「値上げにあたるのか、値下げに当たるのか」という点が最も気になります。

結論から言うと「ケースバイケースではあるが 最適化を行うことで多くのケースで結果的に安価になる可能性が高い」と言うことができます。

この点は、後述の各変更の詳細な説明のなかで詳しく解説していきます。

当記事での解説

BigQuery の価格体系の理解にあたり、当記事では以下のキーワードを解説します。

• Physical storage (ストレージ料金体系の理解)
• BigQuery Editions (コンピュート料金体系の理解)
• BigQuery Autoscaler (コンピュート料金の最適化の理解)

また料金を事前に見積もったり適切な Edition を選ぶための手法も併せて解説します。

Physical storage

圧縮後データに対する課金

デフォルトでは、BigQuery のストレージ課金は Logical storage (論理ストレージ) に対して計算されます。Logical storage はデータが圧縮される前のデータサイズの論理値を意味します。しかし実際には BigQuery に格納されたデータは透過的（ユーザーが意識することなく）に圧縮されています。

2023年7月に Physical storage 課金モデルが GA になりました。Physical storage 課金モデルとは、圧縮後のサイズ（実際にストレージを占有しているデータサイズ）に対して課金される課金モデルのことです。データセットごとに Logical storage 課金か Physical storage 課金を選択することができます。

重要な点として、Physical storage 課金を選択したか否かに関わらず、BigQuery のデータは圧縮されています。Logical storage 課金か Physical storage 課金かの選択は、あくまで課金方法の選択であり、この選択により圧縮有無が変わったり、パフォーマンスが変わるものではありません。

• 参考 : Dataset storage billing models

制約

制約として同じ Google Cloud 組織内の同じリージョンのいずれかのプロジェクトで Flat-rate が使用されている場合は、Physical storage 課金が利用できません。

同組織・同リージョン内に Flat-rate が残っていなければオンデマンドモードでも Physical storage を使うことは可能です。

Active と Long-term

BigQuery のストレージ課金には従来より Active storage と Long-term storage (長期保存) がありました。

90 日間以上変更なしで保存されているデータは Long-term storage (長期保存) 扱いになり、料金単価が安くなります。

Physical storage 課金においても、Active と Long-term の概念は引き続き存在します。

タイムトラベル・フェイルセーフへの課金

BigQuery には タイムトラベル機能 があり、データを削除・変更してもデフォルトでは過去 7 日間のデータが保存されています。

データセットの課金モデルを Physical storage にするとこのタイムトラベルのデータにも課金が発生します (Logical storage モードでは課金されません)。課金は、Active storage の単価で行われます。

ストレージ料金を節約するために タイムトラベルの保存期間を変更 することも可能です。

さらに BigQuery には フェイルセーフ機能 があります。タイムトラベル期間終了後の7日間のデータがバックエンドで保存されており、Google Cloud サポートに問い合わせることでテーブル単位で復元することができます。Physical storage 課金では、このフェイルセーフのストレージにも課金が発生します。

単価の違いと圧縮率

単価の違い

Logical storage 課金と Physical storage 課金は単価が異なります。Logical storage は $0.023/GB、Physical storage は $0.052/GB です。

※上記はいずれも「東京リージョン」「Active ストレージ」「2023年7月現在」の単価です。最新の情報は 料金ページ をご確認ください。

上記を見ると Physical storage のほうが単価が高く、一見すると金額が上がってしまうように見えますが、実際には圧縮率によって課金対象の GB が小さくなるため 従来よりも安価になるケースが多い と言えます。

あくまで一般的な傾向ではありますが、圧縮によりデータは 4分の1 〜 12分の1 程度、あるいはそれ以上の圧縮率になる可能性が高いためです。

圧縮率の例

データ圧縮率の例をいくつか紹介します。

以下は、G-gen Tech Blog に設置した Google Analytics 4 のデータを BigQuery にエクスポートしたテーブルの情報です。ある日のテーブルは、論理バイト数は 11.69 MB ですが、物理バイト数は 638.69 KB であり、約 18 分の 1 になっています。

もう一つの例です。以下はパブリックデータセットの bigquery-public-data.baseball.games_wide テーブルの情報です。この例では 1.76 GB が 32.22 MB まで圧縮されており、約 56 分の 1 になっています。

データの圧縮率はデータの性質によって異なるため一概には言えませんが、多くのケースで Physical storage を選択することで安価になると考えられます。

Physical storage への移行

Physical storage の GA 以降もデフォルトは Logical storage 課金です。また以前から存在するデータセットの設定が Logical storage から勝手に Physical storage に変わることもありません。

既存の Logical storage 課金のデータセットは、Physical storage 課金に変更することができます。

BigQuery コンソールのデータセット詳細画面から鉛筆マークの「詳細を編集」リンクをクリックし、チェックボックス「物理ストレージの課金モデルを有効にする」をオンにして保存することで、課金体系が変更されます。

これにより圧縮後ストレージへの課金となりますが、同時にタイムトラベルと fail-safe 用ストレージのサイズにも課金が発生することにご留意ください。

• 参考 : Update storage billing models

BigQuery Editions

BigQuery Editions とは

BigQuery Editions は BigQuery のコンピュート処理能力に対する課金体系であり、従来の Flat-rate pricing を代替するものです。

単価の異なる3つの価格ティア (Standard / Enterprise / Enterprise Plus) から成り、利用可能な機能に違いがあります。

また Editions は後述の BigQuery Autoscaler 機能とセットのため、適切に設定すれば従量課金のメリットを受けることができ、料金の最適化に繋がります。

• 参考 : Introduction to BigQuery editions

3つのエディション・料金表

エディションごとの機能差異 (一部のみ抜粋) や料金は以下のとおりです。なお記載の情報は2023/05月現在のものです。最新情報は必ず以下の公式の料金表・ドキュメントをご参照ください。

• 参考 : BigQuery pricing
• 参考 : Editions features

比較項目	Standard	Enterprise	Enterprise Plus
単価 (US)	$0.04/slot/h	$0.06/slot/h	$0.10/slot/h
単価 (Tokyo)	$0.051/slot/h	$0.0765/slot/h	$0.1275/slot/h
1年/3年コミット	×	○	○
SLA	99.9%	99.99%	99.99%
スロット数	最大1,600slots	制限なし	制限なし
CMEK	×	×	○
VPC Service Controls	×	○	○
動的データマスキング	×	○	○
列レベルセキュリティ	×	○	○
行レベルセキュリティ	×	○	○
BI Engine	×	○	○
BigQuery ML	×	○	○
Object table	×	○	○

ポイントは Edition ごとに「単価が違う」ことと「利用可能な機能に差があること」です。

可能であれば単価が安いエディションを利用したいことになります。ただし、例として CMEK 暗号化 (Customer Managed Encryption Key ... KMS で管理する秘密鍵によるストレージの透過的暗号化) や VPC Service Controls といった重要なセキュリティ機能が Standard エディションでは使えないなど、機能の制約に着目して選択することになります。

なお Editions を選択せずオンデマンドモードで利用すると、Enterprise Plus 相当の機能が利用可能ですが、コストパフォーマンスは Editions のほうが勝ります。

その他の詳細な機能差異は、以下の公式 PDF 資料の p36, p37 に記載されていますので、ご確認ください。

• 参考 : An insider’s guide to BigQuery cost optimization

また以下の公式ガイドにも整理されています。

• 参考 : Editions features

クエリがプロジェクトをまたぐ場合

BigQuery では異なる Google Cloud プロジェクトで保有しているテーブルに対するクエリを実行することができますが、データを持つ側とクエリする側のプロジェクトで異なるエディションが使われている場合はどうなるでしょうか。以下のようなケースを考えます。

• Google Cloud プロジェクト A
  • BigQuery は Enterprise Plus エディションを設定
  • データセット・テーブルを保有
  • テーブルには CMEK 暗号化や列レベルセキュリティが設定されている
• Google Cloud プロジェクト B
  • BigQuery は Standard エディションを設定
  • データセット・テーブルは存在しない

このときプロジェクト B の BigQuery にプロジェクト A のテーブルに対するクエリを投入すると、エラーになります。プロジェクト B では Standard エディションが設定されており、CMEK 暗号化や列レベルセキュリティはサポートされていないからです。すなわちクエリする側のプロジェクトも、機能をサポートするエディションに揃える必要があります。

いつ Editions を使い、いつオンデマンドを使うのか

オンデマンド課金とすべきか、Editions を購入すべきかの判断はどのようにすべきでしょうか。

オンデマンド課金モードには月あたり 1 TB のスキャンまでの無料枠 (Free tier) があります。スキャンのボリュームが 1 TB を超えない場合は、オンデマンドモードとすることで無料枠内で利用可能です。

一方で1ヶ月のうちでスキャンするデータの量が 1 TB を超える見込みの場合は、機能差異を確認していずれかの Edition を選択します。

ただし、1 TB を超える見込みでも例えば「Standard Edition を使っているが、VPC Service Controls の機能を検証したい」などの場合に、一時的にオンデマンドモードを利用することも考えられます。なぜなら、オンデマンドモードでは Enterprise Plus エディションと同等の機能が利用できるためです。VPC Service Controls や動的データマスキングなどのセキュリティ機能を利用する場合、オンデマンドモードは一時的には選択肢には成り得ます。

ただし Enterprise Plus Edition + Autoscaler で最適化したほうが、オンデマンドよりも利用料金が安価になる可能性が高くなるため、PoC が済んだら適切な Edition に切り替えることが推奨されます。

コミットメント

Enterprise / Enterprise Plus エディションでは1年/3年のコミットメントを購入できます。コミットメントは 100 スロット単位で購入でき、割引価格が適用されます。

コミットメントでスロットを購入すると、その分のスロットは常に確保され、Reservation (予約) というオブジェクトを作成して Baseline (後述) としてプロジェクトに割り当てることができます。

Baseline として確保されていても、スロットが未使用で遊んでいる場合は アイドルスロット の扱いになって組織内の他の Reservation (ただし同等エディションの場合のみ) で分け合って使われます。

• 参考 : アイドル スロット
• 参考 : スロット コミットメントの使用

BigQuery Autoscaler

BigQuery Autoscaler とは

BigQuery Editions は従来の Flat-rate pricing (定額料金制度) を置き換える概念ではありますが、新機能である BigQuery Autoscaler 機能により、費用を柔軟化・最適化することができます。

BigQuery Autoscaler は BigQuery Editions のスロット確保量を、クエリ要求に応じて自動で増減する機能です。

• スロット数の自動増減により利用した分だけ課金
• Baseline (最低確保量) と Max (上限) を設定可能
  • Baseline を 0 にすることでオンデマンドと同様な完全従量課金
  • Max 値の設定により想定を超えた突発課金を防ぐ
• 最低課金幅は 100 slot/1秒
  • ただし最低でも60秒分から課金され、その後1秒刻み (billed per second with a one minute minimum)

当機能により、BigQuery Editions をオンデマンド課金と同様に柔軟・効率的に利用できます。

• 参考 : Introduction to slots autoscaling
• 参考 : Capacity compute (analysis) pricing

Autoscaling による Editions 費用の最適化

Editions 利用時は Autoscaler の Baseline (最低値) を 0 slot とすることで、クエリが発生していない時間帯はスロット確保がゼロになるため課金が無くなり、オンデマンド料金と似た使い方ができます。また、Max 値の指定で、想定外の課金を防ぐことも可能です。

ただし制約として、Standard Edition だけは Baseline が必ず 0 になり、任意の Baseline を設定できません。

なおスロット確保量が Max 値に達した場合は、クエリがエラーになるわけではなく、投入済みのクエリはより時間をかけて計算が行われますし、新しいクエリはスロットが空くまで待たされます。

一方で夜間や休日を含めて定常的に BigQuery にクエリが発生している環境の場合、Editions の1年/3年コミットメントを購入して、購入した分のスロット数を Baseline として設定し、Baseline を超える分については Autoscaler で必要なときのみ確保することで、コスト効率よく利用することが可能になります。

ユースケース

ケース ①

BigQuery に対する夜間バッチ等が少なく、利用が日中帯に集中している場合は、以下のような利用方法になります。

• BigQuery Editions + BigQuery Autoscaler を利用
  • コミット購入なし
• Baseline を0に設定
• 安全柵として Max slot を設定
  • 設定値は数ヶ月間の Slot 利用実績を確認して調整

ベースラインが 0 のため、BigQuery が利用されていない間はコンピュート課金が発生しません。

利用ボリュームが小さいのにも関わらず Max 値に 800 などの高すぎる値を設定すると、ジョブ (クエリ) が散発的な場合、ジョブ実行時間が短くても 800 スロット × 60 秒の最低課金が発生してしまい、これが積み重なって料金が高くなってしまう場合があります。

まずは 100 (コンソール上では S と表現) や 200 (M と表現) などの小さい値から始め、ジョブ実行時間が実業務で耐えうる範囲なのかどうかを確認します。

事前に 管理リソースグラフ を確認し、組織のスロット使用状況を確認すると良いでしょう。

ケース ②

夜間・休日はバッチ処理が BigQuery に対して実行されており、日中帯は従業員のBIツールによる利用などがあるケースです。一日を通して、また月間を通して BigQuery の利用率が比較的大きく、常時スロットの利用が発生しているとします。

• BigQuery Editions + BigQuery Autoscaler を利用
• コミットメントを購入し、Baseline 値として設定
  • 常に確保しておくスロット
  • リソースグラフを確認して無駄なく使い切れる値に設定する
• 安全柵として Max slot を設定
  • 最も利用率が高い時間帯に合わせる
  • 設定値は数ヶ月間の Slot 利用実績を確認して調整
  • 値が高すぎると、クエリが散発的な場合でも60秒分の無駄な課金が発生するので注意

ケース ③

BigQuery の利用は一部部署のみ、もしくは PoC レベルであり無料枠に収まる可能性が高い場合

• オンデマンドモードを利用

まだ BigQuery の利用が小規模であり、スキャン量が 1 TB に満たない可能性がほとんどの場合は、無料枠が用意されているオンデマンドモードを利用します。ストレージ容量も、10 GB までは無料です。

従来プランからの移行

移行のタイムライン

2023/07/05 に以下が行われる予定です。

• Physical storage 課金の GA (一般公開)
• Flat-rate の新規販売の終了と Editions への自動移行開始
• オンデマンド課金の価格変更が適用

現在 Flat-rate を利用しているユーザーは全員、BigQuery Editions への移行を行う必要があります。

利用者により明示的な移行がされない場合、2023/07/05 に従来の Flex slots は Enterprise Editions に自動移行されます。Monthly/Annual slots は期間が終了次第、これも Enterprise Editions に自動的に移行されます。

• 参考 : New BigQuery editions: flexibility and predictability for your data cloud

移行要否の判断

Flat-rate 利用中の場合

現在の Flat-rate は 2023/07/05 に販売が終了し、前述の自動的な移行が始まります。今のうちから、移行先の Edition を検討する必要があるでしょう。

基本的には前掲のエディションごとの機能差をベースに、必要なエディションを決定します。

明示的に移行しない場合、Flex と Monthly の commitment は Editions Enterprise に移行されますが、commitment ではなくなります。既に作成済みの Reservation (予約) は Flat-rate のスロット数に合わせて Baseline が設定されている状態になり Autoscaler の単価で課金されるので、注意が必要です。Baseline 値を適切に変更することを検討してください。

Annual の commitment は Enterprise Edition の 1-year commitment に自動移行されます。

オンデマンド課金を利用中の場合

オンデマンド課金の単価は、2023/07/05 に約25%の値上げが適用されます。

しかしながら Physical storage 課金の適用と、適切な BigQuery Edition の選択 + BigQuery Autoscaler を利用することで、利用料金を安くできる可能性があります。

エディションの機能差を確認して移行先エディションを決め、まずは Baseline を 0 とした Autoscaling を有効にして BigQuery Editions に移行することを検討します。

移行の料金影響の例

以下は、BigQuery Reservation を使っているユーザーが、BigQuery Editions (Enterprise) + BigQuery Autoscaler + Physical storage に移行した場合の一例です。

上記の例では、ストレージ料金が圧縮の効果により約40%に削減されています。またコンピュート料金は Enterprise を採用したことによりスロット単価は上がっているものの、Autoscaling により利用ボリュームが最適化され、料金増額が抑えられています。

料金の見積もり (ストレージ料金)

新規ユーザの場合

まず、BigQuery に格納するデータサイズを確認します。BigQuery に格納したデータは圧縮されますので、Physical storage 課金を用いる前提で圧縮後のデータサイズで料金を見積もります。

圧縮率はやや保守的に 25％と想定し (実際にはより高い圧縮率になることが多いです) 投入対象のデータの圧縮前データサイズを 4 で割って、その値を 単価 に掛ければよいでしょう。

既存ユーザの場合

課金方式変更の判断

2023年7月に Physical storage 課金が GA になって以降は、既存データセットを Physical storage 課金に変更することができるようになります。

課金方式を変更するかどうか判断するため、現在 BigQuery が持っているデータサイズや圧縮率を確認する方法をいくつかご紹介します。

Web コンソール

最も簡単な方法は、BigQuery のコンソール画面にてテーブルを選択し、詳細タブを開くことです。

同タブでは「圧縮率の例」の項で掲載したスクリーンショットのように、合計論理バイト数と合計物理バイト数を確認することができます。

INFORMATION_SCHEMA へのクエリ

前述の Web コンソールによる確認方法ではテーブルごとにサイズを確認する必要がありますが、BigQuery のシステムビューである INFORMATION_SCHEMA にクエリすることで、Google Cloud 組織全体から情報を取得することも可能です。

以下のサンプルクエリでは INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION から情報を取得しています (ただし 2023/03/30 時点で同ビューは Preview リリースの扱いである点にご留意ください)。

プロジェクトごとの「Logical storage (Active)」「Logical storage (Long term)」「Physical storage (Active)」「Physical storage (Long term)」を確認することができます。

DECLARE active_logical_pricing, longterm_logical_pricing, active_physical_pricing, longterm_physical_pricing NUMERIC;
SET active_logical_pricing    = 0.023;
SET longterm_logical_pricing  = 0.016;
SET active_physical_pricing   = 0.052;
SET longterm_physical_pricing = 0.026;
-- 上記は2023/07時点の東京リージョン価格。適宜変更してください
  
SELECT
 project_id,
 ROUND(SUM(total_logical_bytes/POW(1024, 3)), 2) AS total_logical_gigabytes,
 ROUND(SUM(total_physical_bytes/POW(1024, 3)), 2) AS total_physical_gigabytes,
 ROUND(SUM(total_logical_bytes)/SUM(total_physical_bytes), 2) AS compression_ratio,
 ROUND(SUM((active_logical_bytes/POW(1024, 3)) * active_logical_pricing + (long_term_logical_bytes/POW(1024, 3)) * longterm_logical_pricing), 2) AS total_logical_prices,
 ROUND(SUM((active_physical_bytes/POW(1024, 3)) * active_physical_pricing + (long_term_physical_bytes/POW(1024, 3))* longterm_physical_pricing), 2) AS total_active_prices,
FROM
 region-asia-northeast1.INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION
 -- 上記はデータセットのリージョンに合わせて適宜変更してください
GROUP BY
 1

• 参考 : TABLE_STORAGE_BY_ORGANIZATION view

注意点として INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION をクエリするには実行者は 組織レベル で bigquery.tables.get および bigquery.tables.list の権限を持っている必要があります。この権限を得るには、クエリするアカウントに対して組織レベルで BigQuery データ閲覧者 (roles/bigquery.dataViewer) ロールや BigQuery 管理者 (roles/bigquery.admin) を付与します。

なお組織レベルで オーナー (roles/owner) を付与されていても権限不足となりますのでご注意ください (オーナーには bigquery.tables.get が含まれていないためです)。

BigQuery の IAM 権限の詳細についてさらに知りたい場合は、以下をご参照ください。

blog.g-gen.co.jp

料金の見積もり (コンピュート料金・新規ユーザ向け)

オンデマンド料金の見積もり

この項では、まだ BigQuery を使っていない新規ユーザ向けの記載をします。

オンデマンド料金の見積もりは、スキャンしたデータ量に対する課金のため、対象データ量と利用用途 (ダッシュボード等) を考慮することで、概ねのスキャン量を算出します。

例えばある Looker Studio ダッシュボードは、表示したり集計軸を変更するたびに 100 GB 程度のデータマートのうち 1% 程度のデータ (=1GB) をスキャンするとします。このダッシュボードが一日に10回参照されると仮定し、それが 20 営業日とすれば、このダッシュボードは月に 200 GBのスキャンを BigQuery に対して発生させます。こうしたダッシュボードが10個ほどあれば、月のスキャン量はおよそ 2000 GB と言うことができます。

Editions の見積もり

BigQuery Editions による利用料金を見積もるには (スロット単価) × (スロット時間) で計算できます。

スロット単価は Edition によって異なりますので、料金ページを確認します。どの Edition を選択するかは、前掲の機能表を参考にしてください。

スロット時間は、もし既に BigQuery を利用中であれば、前述の SQL で実績を集計することができますが、これから初めて BigQuery を使う場合は以下のように利用料金の上限を定めてから、その上限に収まるように Autoscaler の Max 値を求めることができます。

• 予算の上限を決める
  • 例: $1,000
• 月間で BigQuery の処理が走る合計時間 (スロット時間) を見積もる
  • 例: 20営業日 × 4h = 80h と仮定
• 以下の計算式に基づき、Max 値を算出する
  • (スロット単価) × (スロット時間) × (Max 値) = (予算)
  • 例: $0.04(Standard, US) × 80h x (Max 値) = $1,000
    • → Max 値 = 312.5
    • → 設定は 100 スロット単位のため 300 で設定

上記の計算では $1,000 を上限と定めていますが、実際には Autoscaler により使っていない時間帯はスロット確保が 0 になりますので、実際の利用料金は予算よりは小さくなります。

料金の見積もり (コンピュート料金・既存ユーザ向け)

既存ユーザの見積もり

既に BigQuery をお使いの既存ユーザは、現在の BigQuery 使用量実績、すなわちスロット利用量の実績を集計することで、Editions に移行した後の料金の見積もりをすることができます。

実際に利用中の環境において BigQuery システムビューの INFORMATION_SCHEMA.JOBS_TIMELINE_BY_ORGANIZATION へクエリすることで、スロット利用実績を取得することで、スロット利用料金の参考にすることができます。

現在オンデマンドを利用しているか、Flat-rate を利用しているかによって試算用のクエリが異なりますので、それぞれ後述します。

なお同ビューへのクエリには組織レベルで bigquery.jobs.listAll の権限が必要なため、組織レベルで BigQuery リソース閲覧者(roles/bigquery.resourceViewer) や BigQuery 管理者 (roles/bigquery.admin) などのロール付与が必要です。

• 参考 : JOBS_TIMELINE_BY_ORGANIZATION view
• 参考 : Capacity compute (analysis) pricing

また、以下の公式記事で、BigQuery Editions を導入するプロセスについて解説されていますので、ご一読ください。

• 参考 : Optimizing BigQuery computational analysis costs

オンデマンド利用中のユーザ向け

以下のサンプルクエリは、当月を含む過去4ヶ月間のスロット利用ボリューム ( “スロット時間” ) を集計するクエリです。最初の変数を変更することで集計期間を変更できます。また実行リージョンは15行目のリージョンを変更してください。

/* オンデマンド課金利用組織向け
 3ヶ月前の月初日〜本日のスロット消費量調査クエリ */
DECLARE START_TIMESTAMP TIMESTAMP;
DECLARE END_TIMESTAMP TIMESTAMP;
SET START_TIMESTAMP = TIMESTAMP(DATE_TRUNC(DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 3 MONTH), MONTH));
SET END_TIMESTAMP = CURRENT_TIMESTAMP;
  
  
/* 毎分ごとのスロット秒を算出 */
WITH slot_sec_per_second AS (
  SELECT
    period_start,
    project_id,
    SUM(period_slot_ms)/1000 AS slot_sec
  FROM
    /* region-のあとの文字列は利用中のリージョン(ロケーション)に変更する */
    `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_ORGANIZATION
  WHERE
    /* パーティション列のためjob_creation_timeを含める
      ジョブ投入日からperiod_startまで日付がまたがる可能性を考慮し1日前から取得 */
    job_creation_time BETWEEN TIMESTAMP_SUB(START_TIMESTAMP, interval 1 DAY) AND END_TIMESTAMP
    AND period_start BETWEEN START_TIMESTAMP AND END_TIMESTAMP
    AND reservation_id IS NULL
    AND job_type = 'QUERY'
  GROUP BY
    1, 2
),
slot_sec_per_minute AS (
SELECT
  TIMESTAMP_TRUNC(period_start, MINUTE) AS period_minute,
  project_id,
  CEIL(SUM(slot_sec)/60/100)*100 AS slot_sec_average_in_minute,
  CEIL(MAX(slot_sec)/100)*100 AS slot_sec_max_in_minute
FROM
  slot_sec_per_second
GROUP BY
  1, 2
)
  
  
/* 悲観値(分の最大スロット消費がベース)と楽観値(分の平均スロット消費がベース)を表示 */
SELECT
  FORMAT_TIMESTAMP("%Y-%m", DATE(period_minute, 'Asia/Tokyo')) AS year_month,
  project_id,
  CEIL(SUM(slot_sec_average_in_minute)/3600*60*100)/100 AS slot_hour_optimistic,
  CEIL(SUM(slot_sec_max_in_minute)/3600*60*100)/100 AS slot_hour_pessimistic
FROM
  slot_sec_per_minute
GROUP BY
  1, 2
ORDER BY
  1, 2

以下は、SQLの結果例です。Editions + Autoscaler にしたときのスロット使用量見積もりが「楽観値」「悲観値」の2つで表示されており、それぞれに Editions のスロット時間単価をかけることで金額を見積もることができます。

 | year_month | project_id | slot_hour_optimistic | slot_hour_pessimistic | 
 | ----- | ----- | ----- | ----- | 
 | 2023-02 | my-bq-project | 23411.43 | 79211.31 | 
 | 2023-03 | my-bq-project | 19020.2 | 61382.89 | 
 | 2023-04 | my-bq-project | 21610.69 | 63210.08 | 
 | 2023-05 | my-bq-project | 14022.11 | 44231.78 | 

楽観値と悲観値を出している理由として、Autoscaler スロットは「最低でも60秒分から課金され、その後1秒刻みで課金される (billed per second with a one minute minimum)」「最低スケール単位が100スロット」という仕組みになっていることから、完全に予測することが難しいという事情があります。楽観値は実際のスロット確保実績のうち、1分間の平均をベースにして算出しています。悲観値は実際のスロット確保実績のうち、1分間の最高値をベースにして算出しています。

Autoscaler 設定の Max 設定値を低くすることで、悲観値から楽観値に近づけることが可能ですが、その分ジョブの実行時間は引き伸ばされてしまうので、ジョブ実行実績を見て適切な Max 値を設定することが必要です。クエリを別で実行して WITH 句 slot_sec_per_second の値を直接見ることで、ジョブによってどれくらいの長さでどれくらいのスロットが確保されているかを確認し、Max 設定値を検討していただくことも一手です。

Flat-rate 利用中のユーザ向け

以下は、Flat-rate 課金を利用中のユーザ向けの、当月を含む過去4ヶ月間のスロット利用ボリューム ( “スロット時間” ) を集計するクエリです。最初の変数を変更することで集計期間を変更できます。また実行リージョンは15行目のリージョンを変更してください。

解釈の仕方は前項に記載の通りですのでそちらをご参照ください。

/* Flat-rate 利用組織向け
 3ヶ月前の月初日〜本日のスロット消費量調査クエリ */
DECLARE START_TIMESTAMP TIMESTAMP;
DECLARE END_TIMESTAMP TIMESTAMP;
SET START_TIMESTAMP = TIMESTAMP(DATE_TRUNC(DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 3 MONTH), MONTH));
SET END_TIMESTAMP = CURRENT_TIMESTAMP;
  
  
/* 毎分ごとのスロット秒を算出 */
WITH slot_sec_per_second AS (
SELECT
  period_start,
  reservation_id,
  ARRAY_AGG(DISTINCT project_id) AS project_ids,
  ARRAY_AGG(DISTINCT job_type) AS job_types,
  SUM(period_slot_ms)/1000 AS slot_sec
FROM
  /* region-のあとの文字列は利用中のリージョン(ロケーション)に変更する */
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_ORGANIZATION
WHERE
  /* パーティション列のためjob_creation_timeを含める
     ジョブ投入日からperiod_startまで日付がまたがる可能性を考慮し1日前から取得 */
  job_creation_time BETWEEN TIMESTAMP_SUB(START_TIMESTAMP, interval 1 DAY) AND END_TIMESTAMP
  AND period_start BETWEEN START_TIMESTAMP AND END_TIMESTAMP
  AND reservation_id IS NOT NULL
  AND reservation_id != 'default-pipeline'
GROUP BY
  1, 2
),
slot_sec_per_minute AS (
SELECT
  TIMESTAMP_TRUNC(period_start, MINUTE) as period_minute,
  reservation_id,
  /* Resercationは複数PJ・ジョブタイプに紐付け可能なため集約する */
  ARRAY_CONCAT_AGG(project_ids) AS project_ids,
  ARRAY_CONCAT_AGG(job_types) AS job_types,
  CEIL(SUM(slot_sec)/60/100)*100 AS slot_sec_average_in_minute,
  CEIL(MAX(slot_sec)/100)*100 AS slot_sec_max_in_minute
FROM
 /* region-のあとの文字列は利用中のリージョン(ロケーション)に変更する */
 slot_sec_per_second
GROUP BY
  1, 2
),
slot_hour_per_month AS (
SELECT
  FORMAT_TIMESTAMP("%Y-%m", DATE(period_minute, 'Asia/Tokyo')) AS year_month,
  reservation_id,
  ARRAY_CONCAT_AGG(project_ids) AS project_ids,
  ARRAY_CONCAT_AGG(job_types) AS job_types,
  CEIL(SUM(slot_sec_average_in_minute)/3600*60*100)/100 AS slot_hour_optimistic,
  CEIL(SUM(slot_sec_max_in_minute)/3600*60*100)/100 AS slot_hour_pessimistic
FROM
  slot_sec_per_minute
GROUP BY
  1, 2
)
  
  
/* 悲観値(分の最大スロット消費がベース)と楽観値(分の平均スロット消費がベース)を表示 */
SELECT
year_month,
reservation_id,
/* プロジェクトおよびジョブタイプは対象をリストするだけであり実際の組み合わせの通りには表示されない */
(SELECT ARRAY_AGG(DISTINCT project_id_list) FROM UNNEST (project_ids) AS project_id_list) AS project_id_list,
(SELECT ARRAY_AGG(DISTINCT job_type_list) FROM UNNEST (job_types) AS job_type_list) AS job_type_list,
slot_hour_optimistic,
slot_hour_pessimistic
FROM
slot_hour_per_month
ORDER BY
1, 2

INFORMATION_SCHEMA.JOBS との違い (参考)

ジョブのスロット時間を取得するためのシステムビューとして、先に紹介したクエリで参照している JOBS_TIMELINE の他に INFORMATION_SCHEMA.JOBS も存在します (別名 : JOBS_BY_PROJECT)。

• 参考 : JOBS view

こちらにも total_slot_ms というカラムがあり、ジョブごとに消費したスロット時間を求めることが可能です。しかしながら、このビューから集計したスロット時間で BigQuery Editions の費用を見積もるのは適切ではありません。

JOBS ビューのレコードは以下のようになっています。1レコードは1ジョブに相当し、total_slot_ms カラムの値はそのジョブ全体で消費した総スロット数を表しています。

start_time	end_time	job_id	total_slot_ms
04-01 12:05:33	04-01 12:05:37	job_abc	1021
04-05 05:46:52	04-05 05:46:54	job_xyz	4106

※ 表を見やすくするために start_time end_time 列は 年 部分を削除して表記しています

一方で JOBS_TIMELINE の1レコードはあるジョブの1秒あたりの実行履歴となっており period_slot_ms カラムの値はあるジョブが1秒あたりに消費したスロット数を表しています。

period_start	job_start_time	job_end_time	job_id	period_slot_ms
04-01 12:05:33	04-01 12:05:33	04-01 12:05:37	job_abc	108
04-01 12:05:34	04-01 12:05:33	04-01 12:05:37	job_abc	275
04-01 12:05:35	04-01 12:05:33	04-01 12:05:37	job_abc	276
04-01 12:05:36	04-01 12:05:33	04-01 12:05:37	job_abc	276
04-01 12:05:37	04-01 12:05:33	04-01 12:05:37	job_abc	86
04-05 5:46:52	04-05 5:46:52	04-05 5:46:54	job_xyz	426
04-05 5:46:53	04-05 5:46:52	04-05 5:46:54	job_xyz	3183
04-05 5:46:54	04-05 5:46:52	04-05 5:46:54	job_xyz	497

※ 表を見やすくするために period_start job_start_time job_end_time 列は 年 部分を削除して表記しています

2つの表を見比べてみると、後者の表では同じジョブが1秒ごとに1レコードで表され、その秒あたりに使ったスロット数が period_slot_ms で表示されています。

BigQuery Editions の Autoscaler では最小課金単位が100スロット/1秒です。例えばあるジョブが5秒継続し、スロット数を合計200スロット使ったとします。

もし前者の JOBS ビューでスロットを集計してしまうと、例えば job_abc は 1021 スロットミリ秒 = 1.021 スロット秒 なので最小課金単位の 100 スロットで切り上げても 100 スロット秒しか使っていないことになってしまいます。

しかし後者の JOBS_TIMELINE ビューで集計すると、ジョブは5秒間継続しているので、それぞれの秒で 100 スロット秒に切り上げると、計500スロット秒が課金対象であることが分かります。後者のほうが、BigQuery Autoscaler の正しい課金体系を反映しています。

Max 値の決定

概要

BigQuery Editions では Reservation (予約) というオブジェクトを作成してプロジェクトに Editions を適用します。その際に Autoscaler の Baseline 値と Max 値を指定する必要があります。

Baseline 値は、1年/3年の Commitment を購入していれば、それを使い切るように設定すればよいものとなります。

一方の Max 値は、パフォーマンスとコスト (料金) を天秤にかけて決定する必要があります。

コンソール画面では、Max 値はプルダウンメニューで以下のように選択できるようになっています。

名称	スロット数
S	100
M	200
L	400
XL	800
2XL	1,600
3XL	3,200
4XL	4,800
Custom	任意の数値

S、M、L といった名称が付いてはいますが実際には利用環境に応じて適切な値を選択することが望ましいです。

考え方

まずは 100〜400 など小さめのスロット数でスモールスタートできるかを検討します。

BigQuery に対するクエリが散発的であるのにも関わらず 800 など大きめのスロット数を Max としてしまうと、以下のようなことが起こります。

• ある1個のクエリが投入される
• 800スロットが確保され、処理が1秒で終わる
• スロットの最低課金時間は60秒のため 800 スロット × 60秒の課金が発生

同時間帯に他のクエリが投入されない場合、1個のクエリを実行するために800 スロット × 60秒の課金が発生することになり、無駄が大きい状態になります。

一方で同じクエリを処理する場合で Max 値が200の場合、以下のような挙動になります。

• 先程と同じクエリが投入される
• 200スロットが確保され、処理が4秒で終わる
• スロットの最低課金時間は60秒のため 200 スロット × 60秒の課金が発生

この場合はスロット数が4分の1のため処理時間が4倍掛かっていますが、料金も4分の1です。

とはいえ、同時間帯に多数のクエリが投入されるような環境であれば、60秒間で確保されたスロットが無駄なく使われることになりますので、どのくらいの頻度・密度でクエリが実行されるかを考慮に入れて、Max 値を検討する必要があります。

過去実績の確認 (リソースグラフ)

既に BigQuery をご利用中の場合、前述の基本的な考え方を踏まえた上で、普段のクエリのスロット利用実績から Max 値の当たりをつけるのが適切です。

管理リソースグラフ (administrative resource charts) を使うことで、過去のスロット利用実績を確認可能です。

オンデマンドモードをご利用中の場合、セレクタで利用リージョンを選択のうえ、チャートを「オンデマンド料金」「スロットの使用状況」とすることで、過去のある時間帯の平均スロット利用量を確認できます。これにより、Max 値を例えば 100 に設定した際に、どの時間帯のジョブのパフォーマンスが落ちる可能性があるかを確認することができます。

リソースグラフの例

例えば上記の例だと、あるオンデマンド課金を利用している組織の、99パーセンタイル (全ジョブの中でスロット使用量が上位の1%のジョブ) の「平均スロット使用量」を表示しています。スパイク的に 2,000 近くまでスロットが確保されている時間帯がある一方で、ほとんどの時間帯は 100 以下に収まっていることが分かります。 選択した期間中の平均は 9.3 スロットでした。

このため Max 値を 例えば 100 スロットに設定することを検討します。しかし、スパイクしている時間帯のジョブはその分引き伸ばされてしまうことになります。具体的にどんなクエリが影響を受けるかは INFORMATION_SCHEMA.JOBS ビューなどで個別に確認し、多くのスロットを利用しているジョブを特定することになります。

• 参考 : 管理リソースグラフを使用する

Slot estimator の活用

BigQuery の Web コンソールには Slot estimator が用意されており、スロット量の見積もりに利用できます。

パフォーマンスをできるだけ落とさずにコスト最適化するための Baseline/Max の設定値を推奨してくれます。BigQuery コンソールの「容量管理」画面から「スロット見積もりツール」画面へ遷移することで閲覧が可能です。

ただし、あくまで目安であり、コストを優先したい場合は表示されているよりも Max 値を小さくして設定するなど、決断はあくまで運用者がする必要があります。

BigQuery slot estimator

なお Cost-optimal settings (コスト最適設定値) の表示機能は 2023年7月現在 Preview 公開であることにご留意ください。

• 参考 : Estimate slot capacity requirements

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。

Follow @y_sugi_it