はじめに
初めまして。プラットフォーム開発部にてデータ基盤を整備しているkashiraと申します。
BigQueryの大規模な料金改定が来ましたね。 cloud.google.com
ピクシブでは、ストレージ料金に大きな課題を感じていたので、Preview版の時点からデータセットのストレージ請求モデルを非圧縮から圧縮に切り替えています（安くなるデータセットのみ）。
この記事では、このデータセットのストレージ請求モデルの切り替えがどれくらい効果があったのか、そして切り替え作業で地味に苦労したことについて話したいと思います。
請求モデルの切り替え手順や、詳しい説明は公式ドキュメントをご参照ください。 cloud.google.com
TL;DR
ピクシブの場合はデータセットのストレージ請求モデルを切り替えるだけで、既存料金の40%程度の料金に抑えることが出来ました。
金額に換算すると年間7000万円相当の料金を削減することが出来ます。
ピクシブのストレージについて
ピクシブでは非圧縮のデータ量(TOTAL_LOGICAL_BYTES)が6.5 PiB あります！
- ACTIVE_LOGICAL_BYTES = 1PiB
- LONG_TERM_LOGICAL_BYTES = 5.5PiB
GA(Google Analytics), FA(Google Analytics for Firebase)のデータがストレージのほぼ全てを占めています。
| TOTAL_LOGICAL_BYTES (PiB) | |
|---|---|
| GA, FAの加工済みデータ | 3.02 |
| GA, FAの生データ | 1.98 |
| 自前のログデータ | 0.68 |
| その他構造化データ | 0.84 |
切り替え作業について
Preview状態で動作に不安があったのと、一度切り替えると戻せない仕様のためバックアップを取って作業しました。(2023/02/01 時点)
※ データセットのストレージ請求モデルは性能に影響を与える変更では無いので念の為です。ピクシブでも切り替え後に性能の変化はなかったので、合意が取れれば何もせずに切り替えて良いと思います。
このバックアップ作業が大変でした。
作業内容としては CREATE TABLE COPY をスクリプトを使って流すだけなのですが、バックアップするテーブルが16万件程度あったので、BigQueryのCOPYジョブ数の割り当て制限に引っかかることが想定されました。(2023/04/10時点ではCOPYジョブ数の上限は1日にプロジェクトあたり10万件)
そのためBigQueryの割り当て制限を超えないように、複数プロジェクトを使って作業を進めていきました。
また最初は16万件を2並列で処理しようとしていたのですが、作業時間の見込みが25時間を超えそうだったので10並列でスクリプトを流すように手順を変更しました。
これにより約10時間程度で作業が終わりました。
他に詰まった点としては以下のようなものがありました。
- カラムのアクセス制限はBigQueryの権限とは別なので、事前にポリシータグの読み取り権限を貰う必要がある
- パーティションの上限を超えたテーブルが存在していたので、
CREATE TABLE COPYのジョブが失敗した
色々なエラーや制限を回避しながら、問題を起こさずにバックアップ、請求モデルの切り替え、バックアップの削除が出来たのは個人的に良かったです。
また100TiB以上あるテーブルのコピーが2-3分で終わったのでBigQuery凄いなと感じました。
おわりに
ストレージ料金の改定でBigQueryをもっと安く使えるようになります 🎉
簡単に設定できるので、ぜひGAになった際には試してみてください。
また大規模なデータに興味がある方はピクシブの採用ページも見てみてください。
https://hrmos.co/pages/pixiv/jobs/005
