BigQueryの物理ストレージへの切り替えはコスト削減につながる一方で、time travelとfail-safeストレージのコストには注意が必要です。本記事では、これらの機能が請求額を膨らませてしまう仕組みと、time travelウィンドウの短縮やデータ削除前の論理ストレージへの切り替えといった回避策を紹介します。
BigQueryの論理ストレージから物理ストレージへ切り替えることで、ストレージコストを大幅に削減できるケースがあります。実際、私たちが支援してきた多くのお客様でその効果が確認されています。
しかし、BigQueryのtime travelとfail-safeのコストを加味すると、結果的に論理ストレージよりも高くついたり、想定外のストレージコストが発生したりすることもあります。
本記事で取り上げるのは、次の2点です。
- コストを押し上げるBigQueryのtime travelとfail-safeストレージの落とし穴
- その落とし穴を回避するための選択肢
BigQueryのtime travelとfail-safeの落とし穴
BigQueryのtime travel機能を使うと、一定期間内であれば、変更・削除されたデータに任意の時点までさかのぼってアクセスできます。time travelウィンドウは初期設定で7日間ですが、最短2日間まで短縮可能です。
BigQueryのfail-safe機能は、緊急時のデータ復旧用に、time travelウィンドウの_後_さらに7日間、削除データを保持します(少し前までは14日間でした)。time travelとは異なり、保持期間は変更できません。また、fail-safeのデータを復元するにはGoogle Supportにチケットを起票する必要があります。
物理ストレージを利用している場合、time travelとfail-safeのストレージはいずれもアクティブ物理ストレージの料金で課金されます。一方、論理ストレージではどちらも課金対象外です。
下のグラフは、次のような状況をシミュレーションしたものです。
- 長期物理ストレージの合計が200 GiBあり、そのうち50 GiBを削除
- time travelウィンドウは7日間で、その後
- fail-safe期間が7日間続く
先日開催したBigQueryライブQ&Aで紹介した、次の事例を見てみましょう。
あるお客様が、長期物理ストレージにあった大規模なテーブルを削除しました。削除されたテーブルは、復元に備えてtime travelに保管されます。削除と同時にテーブルデータはtime travelおよびfail-safeストレージ内でアクティブストレージに変換され、合計21日間(time travelで7日、当時14日間あったfail-safeで14日)、お客様は気づかないうちにアクティブストレージ料金を支払い続け、想定外に高額なストレージ請求が発生してしまいました。
選択肢1:BigQueryのtime travel設定を見直す
BigQueryのtime travelは初期設定で7日間ですが、最短2日間まで短縮できます。データの保護レベルを多少下げても問題ないと判断できる場合は、この設定を短くすることでtime travel内に保持されるデータのコストを抑えられます。
たとえば、BQからGCSなどへのバックアップ体制がしっかり整っているなら、time travelを2日間に短縮しても支障はないでしょう。お客様のなかには、自動アーカイブのポリシーやパイプラインを構築してデータを定期的にバックアップしているケースもあります。こうした場合、すでにBigQuery外でバックアップが取られているため、time travelを短く設定しても理にかなっています。
これまでの経験上、ほとんどのお客様はtime travelを丸7日間使い切っているわけではありません。仮に2日間まで短縮しても、その後ろにさらに7日間のfail-safeが控えているからです。データ履歴を7日間フルに残すことよりコスト削減を優先したいのであれば、time travelを2日間にしても大きな影響はないはずです。
もう一つの活用法として、大量のデータを削除する直前にtime travelを2日間まで一時的に縮め、time travel内のストレージ容量を抑えるという手もあります。必要であれば、後で元の値に戻すのを忘れないでください。
選択肢2:データ削除前にBigQueryの論理ストレージへ切り替える
もう一つの方法は、データを削除する_前に_データセットのストレージ課金モデルを論理ストレージに変更することです。論理ストレージモデルでは、time travelもfail-safeも課金対象にならないためです。
ただし、この変更は14日に1回しか行えないため、戻すにも14日間待つ必要があります。また、ストレージモデルの切り替えが反映されるまでには最大24時間かかります。
切り替え前には、必ずこちらのクエリを実行し、論理ストレージ14日分と、アクティブ物理ストレージ9日分(time travel最短2日+fail-safe 7日)のコストを比較してください。
以下はこのクエリの出力例です。「additional_costs_for_physical_storage」にはtime travelとfail-safe両方のストレージコストが含まれています。
dataset
logical_active_price
base_physical_price
logical_long_term_price
base_long_term_price
additional_costs_for_physical_storage
logical_storage_price
physical_storage_price
difference_in_price_if_physical_is_chosen
recommendation
warehouse
$ 0.57
$ 0.07
$ 0.00
$ 0.00
$ 62.27
$ 0.57
$ 62.34
$ -61.77
Keep dataset on logical storage
選択肢3:そもそもBigQueryの物理ストレージに切り替えない
データの追加と削除を頻繁に繰り返している環境では、time travelとfail-safeのデータ量がかなり大きくなりがちです。そもそも物理ストレージに切り替えること自体が得策ではないケースもあります。
論理ストレージモデルではtime travelとfail-safeのデータは課金対象外ですが、物理ストレージモデルでは課金対象になるためです。
そのため、この領域に大量のデータが残る運用では、論理ストレージで支払うコストを上回ってしまう可能性があります。物理ストレージへの切り替えを検討するときは、こうしたデータ量をしっかり確認することが大切です。
先ほど紹介したクエリは、プロジェクト(および単一リージョン)内の各データセットを走査し、コスト内訳と推奨事項を提示します。
BigQueryの物理ストレージへの切り替えが効果的なのは、次のようなシナリオです。
- データの大半がテキストや文字列(JSON、住所、ログなど)である場合。圧縮率が最も高くなるためです。
- 確立されたデータライフサイクル設計がある場合(例:日付でパーティション分割されたテーブルで、各パーティションがX日後に期限切れになるなど)。
- テーブルやパーティション内のデータが頻繁に書き換えられない場合(前述のとおり、頻繁な変更はtime travelとfail-safeのストレージ増につながります)。
まとめ
多くのケースで、BigQueryの論理ストレージから物理ストレージへの切り替えは確かにコスト削減につながりますが、その効果を帳消しにしかねない落とし穴があることも押さえておきましょう。