こんにちは。SCSKの山口です。
今回はBigQuery Editionsの料金体系についてのブログです。
これまでのオンデマンド課金やフラットレート課金と何が違うのか、そしてどのように活用すれば良いのか解説します。
BigQueryの従来の課金体系
BigQueryの分析料金には、主に2つの課金体系がありました。それぞれの特徴を簡単に見てみましょう。
1. オンデマンド課金（従量課金）
クエリがスキャンしたデータ量に応じて課金されます。料金は1TBあたり$6.25（東京リージョン）が目安です。
メリット:
- 使った分だけ支払うので、利用頻度が低い場合に効果的
- 事前のキャパシティ予約が不要
デメリット:
- データスキャン量が増えると、費用が急増する可能性
- クエリごとに料金が発生するため、コスト予測が難しい場合がある
2. フラットレート課金（キャパシティ課金）
月額固定料金でスロット（クエリ処理能力）を借り切る形式です。定額制なので、コストを予測しやすいのが特徴です。
メリット:
- 大量のデータ分析を行う場合、オンデマンドよりも安価になる可能性がある
- コスト予測が非常に立てやすい
デメリット:
- 利用が少ない月でも固定費用が発生
- 最低契約期間がある
BigQuery Editionsとは？
BigQuery Editionsは、これまでのフラットレート課金に代わって、より柔軟な料金体系を提供するために導入されました。
3つのエディションがあり、それぞれ異なるスロットのコミットメントレベルと料金設定がされています。
3つのエディション
- Standard Edition: 低頻度なワークロードや、開発環境・テスト環境向け。
- Enterprise Edition: ほとんどのエンタープライズ向けワークロードに適しており、高度なセキュリティ機能や管理機能が利用可能。
- Enterprise Plus Edition: 非常に要求の厳しいワークロード向けで、最高レベルのセキュリティ、コンプライアンス、信頼性を提供。
オンデマンド課金との違い
最も大きな違いは、「スロットの予約」と「料金体系」にあります。
オンデマンドはデータスキャン量に基づく従量課金ですが、Editionsは「分単位」または「秒単位」でのスロットの消費量に基づきます。
比較表
| 特徴 | オンデマンド | BigQuery Editions |
|---|---|---|
| 料金単位 | スキャンしたデータ量（TB） | 利用したスロット数（秒または分） |
| コスト予測 | 難しい | 比較的容易 |
| スロット予約 | 不要 | 必要（分単位、月単位など） |
| 用途 | 利用頻度が低い、開発・検証 | 本番環境、大規模な分析 |
💡 重要なポイント：
オンデマンド課金は「使ったデータの量」で支払うのに対し、Editionsは「確保した計算能力の時間」で支払います。これにより、大量のデータ分析を頻繁に行うユーザーは、コストを大幅に削減できる可能性があります。
BigQuery分析料金の課金体系フローチャート
ここまでの説明を踏まえて、BigQueryの分析料金の課金体系を決めるには、いくつかの判断ポイントがあります。
カンタンなフローチャートにまとめると下記のようになります。
上図を見てもわかる通り、「BigQuery Editionsを使おう」となってもその先にまた判断ポイントがあります。
です。（実は併用も可能ですが、詳細は後ほど説明します。）
BigQuery Editionsを従量課金で使用する
従量課金で利用する場合は、下記の設定値が重要になります。
- ベースライン（Baseline）
- ワークロードがアイドル時にオートスケーラーが維持する処理能力の量
- 特定のワークロードに対して最低限の処理能力を確保したい場合に設定
- 最大スロット（MAX）
- ワークロードがピーク時のパフォーマンスを達成するためにオートスケーラーが使用できる処理能力の量
- 予期せぬクエリの急増によるコストの急騰を防ぐために設定
- 最大スロット以上が要求されると、ジョブがスロットの空き待ちになる
以下のようなイメージです。
ベースラインのスロット数までは固定料金として支払いますが、ベースラインから最大スロット数までのは従量課金として支払うイメージです。
BigQuery Editionsでコミットメントを購入する
さらに、BigQuery Editionsには「コミットメント購入」という利用方法もあります。
カンタンにいうと、クエリ実行に必要な計算能力（スロット）を、長期的に確保することで割引を受ける仕組みです。
- スロットの事前購入: BigQueryのコンソールから、1年間または3年間の期間で、一定のスロット数（最小100スロット）をまとめて購入
- 割引の適用: 長期間の利用を確約する代わりに、オンデマンド課金や時間単位のコミットメントよりも大幅に安い単価でスロットを利用
- 柔軟な運用: 購入したスロットは「予約」として管理され、特定のプロジェクトや組織に割り当てて利用
- オートスケーリング: 予約したスロットを超えてクエリ実行にスロットが必要になった場合、自動的に追加のスロットが提供され、その分はオンデマンド課金となります。この柔軟性により、コストを抑えつつ、急なワークロードの増加にも対応可能
以下のようなイメージです。
常時多くのスロットを消費しているようなワークロードに対して、スロットをまとめて購入します。
ただし、上図は極端な例です。
オンデマンド課金で利用している状態から、いきなり上図にシフトするのはまれなケースだと思います。
BigQuery Editionsで従量課金とコミットメントを併用する
先述した通り、従量課金とコミットメントは併用することが可能です。
例えば、「BigQuery Editionsを従量課金で使用していたが、扱うデータ量/連携先が増え、ワークロードが増加した」場合を考えてみましょう。以下の図のようなイメージです。
設定したベースラインがもはや意味を成していないように見えますね。
上図のような際、ベースラインを引き上げるのももちろん手ですが、長期的に見てもこのような状態が続くのであれば、一部コミットメントを購入するといった合わせ技が可能です、
オンデマンド課金からEditionsへ移行する際のおすすめフロー
オンデマンド課金からEditionsへの移行にあたって、私が考えるおすすめステップは下記です。
Step 0: 現在の利用状況を把握してBigQuery Editionsを使用するか判断
まず、過去のクエリ履歴とコストを分析します。
INFORMATION_SCHEMA.JOBSビューを利用して、クエリのスキャンデータ量やスロット消費量、実行時間を計測- BigQueryの「料金」ページや「Cloud Billing」レポートで、過去のコスト推移をチェック
このデータから、日・週・月ごとの平均的なスロット使用量を割り出します。
割り出したデータから、「ワークロードの実行に偏りがあるか」「一定期間、まとまったスロット使用量が使用されていないか」などを確認し、BigQuery Editionsを使用するか判断します。
Step 1: BigQuery Editionsを「従量課金」で使用する
BigQuery Editionsを使用するとなった場合、まずは「従量課金」で使用されることをお勧めします。
前述したとおり、ベースラインと最大スロットの設定が必要になります。
中でも最大スロット数の見積もりには注意が必要です。
最大スロット以上の容量が要求されると、ワークロードのジョブがスロットの空き待ちとなってしまうためです。
パフォーマンス要件が厳しいワークロードの際は特に注意が必要です。
BigQuery Editionsの使用を開始することで、BigQueryの「容量管理」からスロットの使用状況などの情報を確認できるようになります。
確認方法については下記ドキュメントをご参照ください。
Step 2: コミットメントの購入を検討する
Step1で収集した情報をもとに、コミットメントの購入を検討します。
いきなり使用スロットをすべてコミットメントで購入するか、一部をコミットメントとして購入するか。の判断が必要になりますが、前述したとおり、いきなりすべてをコミットメントで購入するパターンは稀だと思います。
まとめ
今回のブログで解説したように、BigQuery Editionsに移行する際は、まずは現在のスロット利用状況を正確に把握し、そこから最適なコミットメントのレベルを見極めることが成功の鍵です。BigQuery Editionsの機能を最大限に活用し、コストを抑えながらビジネスの成長を加速させましょう。
BigQuery Editionsをあなたのワークロードにどう活かしていくか、ぜひ検討してみてください。