BigQueryの課金モデルを見直してコスト削減した

GA4 のイベントデータを BigQuery にエクスポートして分析しています。
1日あたりのデータは数GB程度なんですが、毎日蓄積されつづけるのでコストが気になりますね。

なので課金モデルを見直してコスト削減してみました。

3行まとめ

課金モデルを「論理課金(デフォルト)」→「物理課金」に変更
ストレージコストは約20%に圧縮
UPDATE が多いデータセットでは逆に高になることもある

BigQuery の課金モデル

BiqQuery ではストレージとクエリ実行に課金されます。

そのうちストレージ課金は、

Logical (論理課金)
Physical (物理課金)

からデータセットごとに選択可能です。

Logical / 論理課金

無圧縮データサイズ基準で課金されます。
実際には圧縮保存されているんだけど「もし圧縮していなかったら」のサイズで計算されます。

Physical / 物理課金

圧縮後データサイズ基準で課金されます。

データ圧縮されるので基準となるデータサイズは小さくなります。
ただし単価は論理課金の約2倍で、タイムトラベル分も課金対象です。

課金モデルごとのコスト計算の違い

課金モデルによってコストの計算式が微妙に違ってきます。

タイムトラベルデータへの課金の有無

タイムトラベル機能を使うと過去時点に遡ってクエリを実行できます。
タイムトラベルはデフォルトで有効で。そのために追加のデータを保持していると云うことです。

論理課金ではこのデータは無料。
一方、物理課金では課金対象になります。

物理課金では基準となるデータサイズが圧縮される一方で、タイムトラベルデータが料金に含まれる

UPDATE が多いデータセットほどタイムトラベルデータが大きくなり。伴って物理課金が不利になります。

単価の違い

課金モデルによって 1GiB×1ヶ月あたりの単価が異なります。
物理課金の単価は論理課金の約2倍です。

価格はリージョンによっても異なります。詳しくは公式ドキュメント (https://cloud.google.com/bigquery/pricing?hl=ja#storage-pricing) を参照。

データ圧縮でデータサイズが小さくなっても、単価が高いことによって元のコストを追い越してしまうことも。

圧縮率が50%未満なら物理課金が有利。50%を超えるなら論理課金のほうが有利です。

ストレージ情報を見ながらコストを試算する

圧縮率の試算

Google Cloud コンソールの BigQuery スタジオでは各テーブルのストレージ情報を見られます。

例えばこのようなテーブルの場合、

論理課金の対象: {アクティブな論理バイト数} + {長期の論理バイト数}
- 1.5GB + 2.4GB → 3.9GB
物理課金の対象: {アクティブな物理バイト数} + {長期の物理バイト数} + {タイムトラベルの物理バイト数}
- 160MBGB + 300MB + 60MB → 520MB
圧縮率: {物理サイズ} / {論理サイズ}
- → 520MB / 3.9GB → 13.3%

データサイズが 13.3% まで圧縮されるので、割高な単価でもおつりがきそうです。

もう一つ別の例を見てみましょう。

論理課金の対象: {アクティブな論理バイト数} + {長期の論理バイト数}
- 5.2GB + 0GB → 5.2GB
物理課金の対象: {アクティブな物理バイト数} + {長期の物理バイト数} + {タイムトラベルの物理バイト数}
- 0.5GB + 0GB + 2.8GB → 3.3GB
圧縮率: {物理サイズ} / {論理サイズ}
- 3.3GB / 5.2GB → 63.5%

タイムトラベルデータ大きいために課金対象の圧縮率は63.5%にとどまります。
このようなテーブルでは単価の安い論理課金のまま置いておくのがお得。

ストレージ情報と料金表の項目の対応

料金表の見方を解説。

それぞれの項目が下記のように対応しています。

ストレージ情報の項目	料金表の項目
アクティブな論理バイト数	アクティブな論理ストレージ
長期の論理バイト数	長期の論理ストレージ
アクティブな物理バイト数	アクティブな物理ストレージ
長期の物理バイト数	長期的な物理ストレージ
タイムトラベルの物理バイト数	アクティブな物理ストレージ

アクティブ/長期の閾値は90日です。
過去90日以内に変更されたテーブル or パーティションはアクティブなバイト数として計上されます。90日以上変更されていなければ長期バイト数です。

課金モデル変更の方法

実際に課金モデルを変更する方法について。BigQuery スタジオの「データセットの詳細 > 詳細を編集」から設定できます。

ちなみにデフォルトの STORAGE_BILLING_MODEL_UNSPECIFIED だと LOGICAL (論理課金) と同等の設定です。

実際のプロジェクトではどうだったか

私が管理しているプロジェクトで、容量の大きなデータセットで見積ると。

データセット	更新傾向	コスト削減見積り
A	INSERTのみ	-89%
B	INSERTのみ	-60%
C	UPDATEあり	+673%

データセットA, B は物理課金に変更。データセットC は論理課金のまま据え置きとしました。

結果は最初にもお見せした通り。

ストレージコストは約20%ほどに削減されました。
全体としては約50%ほどに削減です。

まとめ

設定変更だけでコスト最適化できて良いですね。

私からは以上です。

無駄と文化

実用的ブログ