Contents
2024 年の料金体系全体像
| 項目 | 課金方式 | 代表的な単価 (USD) | 主な利用シーン |
|---|---|---|---|
| オンデマンド クエリ | 従量課金（スキャン量） | 5 USD / TB（クエリ実行時） | 突発的・テスト・予測が困難なワークロード |
| スロット予約 (Reservation) | 定額課金（予約スロット数） | 0.04 USD / スロット‑hour （≈ 29 USD / スロット‑month） ※最小単位は 100 スロット |
安定した月間クエリ量が見込める長期プロジェクト |
| BI Engine | メモリ課金（GB‑hour） | 0.20 USD / GB‑hour （≈ 144 USD / GB‑month） | ダッシュボードやレポートでミリ秒応答が必要なケース |
| Long‑Term Storage | ストレージ割引（使用量ベース） | 0.01 USD / GB‑month（90 日以上のデータに自動適用） | アーカイブ・履歴データの長期保存 |
| Committed Use Discount (CUD) | 予約利用による割引 | 1 年プラン：30 % 割引、 3 年プラン：45 % 割引（スロット・BI Engine に適用） |
将来も同規模のリソースを使い続けることが確実な場合 |
ポイント
オンデマンドは「従量」＋「スキャン量」にだけ課金され、ストレージ費用は別途計上されます。
スロット予約は CPU・メモリを事前に確保できるため、利用率が 70 % 以上になるワークロードでコスト効率が高まります。
* BI Engine は「メモリ使用量」に対して課金され、データ自体のスキャンは発生しません（キャッシュから直接取得）。
クエリ実行コストを抑える基本テクニック
1. パーティションとクラスタリングの活用
- 効果：不要データのスキャンを大幅に削減。
- 実装例
|
1 2 3 4 |
CREATE OR REPLACE TABLE `proj.dataset.sales` PARTITION BY DATE(order_timestamp) -- 日付でパーティション化 CLUSTER BY customer_id, product_id; -- 高頻度でフィルタリングする列をクラスタキーに |
| 前提 | スキャン量 (GB) | 削減率 |
|---|---|---|
| 非パーティショニングテーブル（500 GB） | 500 | – |
| パーティション＋クラスタリング適用後 | 95 | 81 % |
2. 必要な列だけを取得する
SELECT *は全列スキャンの元になるため、必ず使用カラムを明示。
|
1 2 3 4 5 |
-- 推奨 SELECT order_id, customer_id, total_amount FROM `proj.dataset.sales` WHERE order_date = '2024-03-01'; |
目安：平均 30 % のスキャン削減が期待でき、5 USD/TB の単価で計算すると 0.15 USD/クエリ のコストダウンになるケースも。
3. APPROX 系関数の活用
- 正確性が ±0.5 % 程度許容できる集計は
APPROX_COUNT_DISTINCT、APPROX_QUANTILESなどを使用。
|
1 2 3 |
SELECT APPROX_COUNT_DISTINCT(user_id) AS uniq_users FROM `proj.dataset.events`; |
- 効果：同一データセットで実行時間が約 50 % 短縮され、CPU 使用量も削減。
4. テーブルサンプルとプレビューで開発コストを抑える
TABLESAMPLE SYSTEM (X PERCENT)で部分スキャン。
|
1 2 3 4 |
SELECT * FROM `proj.dataset.sales` TABLESAMPLE SYSTEM (5 PERCENT) WHERE order_date = '2024-03-01'; |
- 効果：フルテーブル 200 GB のうち 10 GB だけスキャンし、0.05 USD 未満に抑えられます。
5. データ型の最適化（根拠付き）
INT64は整数演算が高速であり、NUMERICやSTRINGに比べてストレージサイズも小さくなることが多いです。- ベストプラクティス：数値データは可能な限り
INT64（またはFLOAT64）に統一し、NUMERICは高精度が必須の金額計算等に限定。
スロット予約とハイブリッド運用の設計例
1. ハイブリッド構成の考え方
| 条件 | 推奨構成 |
|---|---|
| 月間平均クエリ量が 10 TB 以上 （スキャン単価が高くなる） |
スロット予約 × 200‑300 スロット + ピーク時オンデマンド追加 |
| 利用率が 60 % 未満 | オンデマンド主体で、必要に応じてスロットを段階的に増やす |
2. シミュレーション例（2024 年想定）
- 前提：月間平均スキャン量 12 TB、ピーク時は 1.5 倍の負荷が 7 日続く
- 設計
- 予約スロット：250 スロット → 250 × 29 USD = 7,250 USD / 月
- オンデマンド追加：ピーク時に 100 スロットを 8 時間/日、7 日使用 → (0.04 USD × 100 × 8 × 7) = 224 USD
| シナリオ | 合計月額コスト (USD) | 割合 |
|---|---|---|
| フル予約（350 スロット） | 10,150 | – |
| ハイブリッド（250 + オンデマンド） | 7,474 | 26 % 削減 |
3. 自動拡張の実装手順
- モニタリングメトリクス取得
-
bigquery.googleapis.com/reservation/slot_utilizationを Cloud Monitoring に追加。 -
Cloud Scheduler + Cloud Functions
python
# 例: 利用率が 80% 超えたらオンデマンドスロットを 50 増やす
import google.cloud.bigquery_reservation_v1 as reservation
def scale_up(event, context):
client = reservation.ReservationServiceClient()
name = "projects/PROJECT_ID/locations/us/reservations/my-reservation"
usage = client.get_slot_pool(name=name).slot_capacity_utilization
if usage > 0.80:
# ここでオンデマンドスロットを購入する API 呼び出し（ベータ機能）を実装
pass
3. **コスト可視化**
* Billing Export を BigQuery にエクスポートし、,ondemand_cost を集計。
BI Engine と長期保存 (Long‑Term Storage) の活用シナリオ
1. BI Engine の料金感覚
- 課金モデル：GB‑hour（0.20 USD/GB‑hour）
- 実務上の利用例
- ダッシュボードで 10 GB のデータをキャッシュ → 月間使用時間が 8 時間と仮定すると、
10 × 8 × 0.20 = 16 USD。
注意：BI Engine は「メモリ確保」に対して課金されるため、実際に利用しないデータはキャッシュから外すか、サイズを縮小してください。
2. Long‑Term Storage のコストメリット
- データが 90 日以上 保存されていると自動的に 0.01 USD/GB‑month に割引（標準ストレージは 0.02 USD/GB‑month）。
| データ種別 | ストレージ費用 (USD/GB‑month) | 推奨保存期間 |
|---|---|---|
| 標準ストレージ | 0.020 | 最近 90 日以内 |
| Long‑Term Storage | 0.010 | 90 日以上の履歴データ |
| BI Engine メモリ | 0.200 (GB‑hour) | 高頻度アクセスが必要な分析 |
3. 実装フロー
- テーブル分割
sql
-- 最近 90 日は標準ストレージに残す（BI Engine 有効化）
CREATE OR REPLACE TABLE
PARTITION BY DATE(order_timestamp)
OPTIONS (expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 90 DAY));
-- 90 日以降のデータは別テーブルへコピー
CREATE OR REPLACE TABLE proj.dataset.historical_sales AS
SELECT * FROM proj.dataset.sales
WHERE order_timestamp < DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY);
2. **Long‑Term Storage に自動移行**
* テーブルの
- BI Engine の有効化手順
- GCP コンソール → BigQuery → リソース > BI Engine
- 「BI Engine を有効にする」ボタンをクリックし、対象データセット・テーブルを選択。
4. コストシミュレーション（月間 5 TB データ例）
| 項目 | サイズ (GB) | 単価 (USD/GB‑month) | 月額 |
|---|---|---|---|
| 標準ストレージ（最新 90 日） | 3,000 | 0.020 | 60 USD |
| Long‑Term Storage（90+日） | 2,000 | 0.010 | 20 USD |
| BI Engine メモリ（平均 120 GB、8 時間/日） | 120 × (8/24) ≈ 40 GB‑hour | 0.20 / GB‑hour | 192 USD |
| 合計 | — | — | 272 USD |
結果：Long‑Term Storage に移行するだけで標準ストレージ費用が 33 % 削減できます。BI Engine は必要容量を最小化すれば、実際のコストは数百ドル程度に抑えられます。
AI driven Cost Recommender の有効化と活用法
1. 有効化手順（コンソール）
| 手順 | 操作内容 |
|---|---|
| ① | ナビゲーションメニュー → Cost Management → Recommender |
| ② | 「BigQuery Cost Optimization」を探し、有効化 をクリック |
| ③ | 推奨アクションの通知先（メール / Pub/Sub）を設定 |
2. 主な推奨内容と実装例
| 推奨項目 | 内容 | 実装サンプル |
|---|---|---|
| 未使用スロット削減 | 利用率が 30 % 以下で 7 日以上続く場合、予約スロット数を減らす提案。 | python<br>client.update_reservation(name=..., capacity=new_capacity) |
| クエリ最適化 | SELECT * や非推奨関数が検出されたら列指定・APPROX 系への置換を通知。 |
Slack Webhook にメッセージ送信例 |
| Long‑Term Storage への自動移行 | 90 日以上のテーブルに対し、長期保存割引適用を推奨。 | ALTER TABLE … SET OPTIONS (expiration_timestamp=…) |
3. 推奨アクションの評価指標
| 指標 | 計算式 | 例（月間） |
|---|---|---|
| スロット削減効果 | 削減スロット × 0.04 USD/時 × 730 時間 | 50 スロット × 0.04 × 730 ≈ 1,460 USD |
| クエリ最適化効果 | (削減スキャン量 TB) × 5 USD/TB | 2 TB 削減 → 10 USD |
モニタリング・アラート・予算管理のベストプラクティス
1. Cost Dashboard の構築（Data Studio / Looker）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
-- 月別コスト集計ビュー CREATE OR REPLACE VIEW `project.cost_summary` AS SELECT EXTRACT(MONTH FROM usage_start_time) AS month, SUM(CASE WHEN sku_id LIKE 'bigqueryreservation%' THEN cost ELSE 0 END) AS slot_cost, SUM(CASE WHEN sku_id = 'bigqueryondemand' THEN cost ELSE 0 END) AS ondemand_cost, SUM(CASE WHEN sku_id = 'bigquerystorage' AND usage_start_time >= TIMESTAMP_SUB(usage_end_time, INTERVAL 90 DAY) THEN cost * 0.5 ELSE cost END) AS storage_cost, -- 長期保存割引を概算 SUM(cost) AS total_cost FROM `billing_dataset.billing_export_*` WHERE service.id = '6F81-5844-456A' -- BigQuery のサービス ID（公式ドキュメント参照） GROUP BY month; |
- 可視化項目
- 月次総コスト、スロット vs. オンデマンド比率、Long‑Term Storage 割引効果、Recommender の適用数。
2. Budgets & Alerts（予算設定）
| 項目 | 設定例 |
|---|---|
| 月次予算 | 10,000 USD |
| 通知レベル | 80 % → メール、100 % → Slack + PagerDuty |
| 対象サービス | BigQuery（オンデマンド・スロット・BI Engine） |
3. スロット利用率の自動監視
|
1 2 3 4 5 6 7 8 9 10 11 |
# Cloud Monitoring アラートポリシー (YAML) displayName: "BigQuery Slot Utilization > 85%" conditions: - conditionThreshold: filter: metric.type="bigquery.googleapis.com/reservation/slot_utilization" comparison: COMPARISON_GT thresholdValue: 0.85 duration: 300s notificationChannels: - projects/PROJECT_ID/notificationChannels/CHANNEL_ID |
- アクション：閾値超過時に Cloud Functions がオンデマンドスロットを追加するスクリプトを起動。
実践事例（匿名企業）と学べるポイント
| 企業規模 | 背景 | 採用した施策 | コスト削減率 |
|---|---|---|---|
| A社 (SaaS) | 月間データ処理量 12 TB、オンデマンド主体で変動が激しい。 | パーティション＋クラスタリング導入、BI Engine 50 GB のキャッシュ化、Recommender による未使用スロット削減。 | 28 %（月額 6,800 USD → 4,900 USD） |
| B社 (金融) | 年間レポート作成でピーク時に 400 スロットが必要。 | ハイブリッド構成（250 スロット予約 + ピーク時オンデマンド追加）、自動拡張スクリプト実装、Long‑Term Storage へ履歴ログ移行。 | 23 %（年額 150,000 USD → 115,500 USD） |
| C社 (広告テック) | 高頻度ダッシュボードでレイテンシが課題。 | BI Engine 120 GB 常駐、クエリを APPROX 系に置換、パーティション化でスキャン量削減。 | 31 %（月額 9,200 USD → 6,300 USD） |
学べるポイント
- ハイブリッド運用は必須：予約スロットだけでは過剰投資、オンデマンドだけだと変動費が膨らむ。
- Recommender の活用で「見えない」無駄を自動検出。手作業でのモニタリングコストが削減できる。
- Long‑Term Storage の自動適用は、データ保持ポリシーが明確な組織で即効性が高い。
まとめ
| 項目 | 実施すべきこと |
|---|---|
| 料金把握 | オンデマンド (5 USD/TB) とスロット予約 (0.04 USD/slot‑hour) を基準に、CUD でさらに割引を検討。 |
| クエリ最適化 | パーティション・クラスタリング、列指定、APPROX 関数、テーブルサンプルを標準化。 |
| スロット運用 | 70 % 以上の利用率が見込める場合は予約スロット、残りはオンデマンドでハイブリッド化。自動拡張スクリプトを導入。 |
| BI Engine & Long‑Term Storage | 高頻度アクセス分は BI Engine にキャッシュし、90 日超過データは Long‑Term Storage へ自動移行。 |
| Cost Recommender | 有効化 → 推奨アクションを定期的にレビュー・実装。 |
| モニタリング & 予算管理 | Billing Export → BigQuery ダッシュボード、Monitoring アラート、Budgets を設定し、月次レビューで改善サイクルを回す。 |
最終的なゴールは「必要なデータ分析を行いながら、無駄なコストは 20 % 以上削減する」ことです。上記のフレームワークと具体的手順を組織に落とし込み、継続的に改善していくことで実現できます。
本稿は執筆時点（2024 年 2 月）で入手可能な公式情報を元に作成しています。最新の料金や機能変更があれば、必ず GCP コンソールまたは公式ドキュメントをご確認ください。