こんにちは、メディアサービス開発部サービス分析課の佐藤です。ブックウォーカー社で全社横断のデータ基盤を構築しています。
今年の3月末にBigQueryの新料金体系、BigQuery Editionsが発表されました。これに伴い来月の7月5日より従来の定額モデルが終了し、オンデマンド料金モデルも25％の値上げとなります。
これまでブックウォーカー社ではスキャンサイズのバーストを防ぐためにGoogle Cloud（GCP）の「割り当てと上限」を利用し、BigQueryにおいてプロジェクト全体のスキャンサイズとユーザーごとのスキャンサイズを制限していました。これはプロジェクト全体、あるいはユーザーが設定したスキャンサイズを上回るとそれ以上の処理を停止させるという制限です。
Webサービス開発に関わる分析業務ではGoogleAnalyticsのエクスポートログやWebサイトのアクセスログなどの大規模なログデータに対して数ヶ月～数年と長期間分の集計をすることもあります。スキャンサイズに対する従量課金から計算スロットに対する従量課金になることは歓迎すべき状況です。Editionsへ移行してもコスト的に問題がないのであれば「割り当てと上限」を緩和・撤廃し、より大規模な集計をすることが期待できます。 こういった背景のもと、積極的にEditions移行を検討することとなりました。
そして調査・検討の結果、ブックウォーカー社では6月の頭にオンデマンド料金モデルからEnterprise Editionsへ移行しました。 この記事はその移行に向けた取り組み内容を記したものです。まだ移行を検討中の方の助けになれば幸いです。
見積もりをして移行を検討する
発表から数日でEditionsに移行した場合の料金を試算するのに役立つ様々な記事が公開されました。こちらをありがたく参考にさせていただき、まずは公式でも推奨されているAutoscalingと最大予約サイズ数指定での利用を想定して3つのEditionそれぞれの事前見積もり行いました。（見積もりの参考にした記事は当記事末尾に記載しました）
INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT ビューを元に上図のようなグラフを描き、弊社の利用状況を確認しました。試算の結果、オンデマンドプランから移行した場合にStandardエディションでは確実に安くなり、Enterpriseエディションであれば現在と同程度という見積もりを得ました。オンデマンドモデルの25％値上げを考えると現在と同程度であればそれでも十分そうです。
両エディションを比較し、BI EngineやBigQuery Omniなど扱える機能に差があることからEnterpriseエディションへ移行することに決定しました。
データ基盤を構築してから1年が経ち、日々増加していった利用者とそれに伴うスキャンコストの増大からデータ基盤コストの大半はBigQueryのスキャン代金により占められていました。
今回のBigQuery Editionsへの移行の判断はプラン移行とその後の継続的な最適化によってBigQueryのコスト削減を期待しての意思決定でした。
タイムアウトを設定する
Editionsの料金モデルは消費したスロット時間の従量課金制です。コストの急増を防ぐため最大予約サイズ数指定を行うとはいえ、それだけでは完全な対策とは言えません。 図1のグラフにあるように、どうしても突発的な消費スロット時間のバーストは発生してしまいます。複雑な計算やJOINなどクエリの処理に必要となる計算リソースが多く、消費スロット時間が長いジョブは長時間ずっとRUNNING状態のまま残り続けることになってしまいます。 常にすべてのジョブが数分で終わる保証があればよいのですが、何かの間違いで1時間以上残り続けてしまっては困りものです。 アラートを鳴らして手動で対応してもよいですが、そもそも長時間かかるクエリは自動で停止させたいです。
そこでデフォルト構成で指定できるタイムアウトを設定します。 ジョブがキューに入った後の経過時間がdefault_query_job_timeout_ms での指定値を超えた場合、そのジョブはタイムアウトします。これで長時間実行しつづけるジョブを自動で停止させることができます。
タイムアウトの時間を決めるため INFORMATION_SCHEMA.JOBS を利用し、過去に実行されたクエリはどのくらい処理に時間がかかっていたかも調査しました。
図3のように1分単位になるよう切り上げた数値を元に頻度を集計し、ヒストグラムで確認すると大半のクエリは1分程度で終了していることが判明しました。図3以外にも様々な情報をもとに99％範囲を考慮して10分で切り上げるようタイムアウトの値を 600000 に指定しています。
ただし、この default_query_job_timeout_ms は実行時間だけではなくジョブキューでの待機時間も対象に含まれてしまいます。このため、ジョブ自体は短時間で終了するのにたまたまBigQueryで大量のジョブ処理されていたため待たされてタイムアウトになってしまうというケースも起こり得ます。この事態を回避するためにはBigQueryのジョブ処理量やキュー待機量を監視し、必要であれば何らかの対策を講じるべきでしょう。
BigQueryでの処理リソース飽和対策としては集中的に利用されるテーブルに対するクラスタリング・パーティショニング、BI Engineでのキャッシュ、クエリの最適化、等々の様々な手段があります。こうした最適化は様々な手段が用意され、公式ドキュメントにもベストプラクティスの記載があります。また、つい最近には自動的にクラスタリングやパーティショニングの推奨する機能が追加されました。 コスト削減はモニタリングをしつつ継続的に行っていくと良いでしょう。
実際に移行作業を行う
月次でコスト計算を行っている都合もあり、移行の日取りは月初営業日としました。移行に先立ち、事前にSlack等で社内各方面へアナウンスを行っておきます。
実際の移行作業はチームで画面共有をしつつBigQueryコンソールから行いました。BigQuery Reservation APIを有効にし、容量管理の画面から「予約を作成」から設定項目を埋めて保存します。
作成画面ではリージョン、エディション、slot上限、ベースライン（最低確保スロット数）などが指定でき、それら指定内容に基づいて画面右側に費用予測が表示されるようになっています。slot上限に対して25％、50％、75％の利用を1ヶ月続けた場合、これくらいになりそう、という試算が載っています。実際のBigQueryの利用実績とは関係ないので、事前見積もり済みの今回はあまり参考にしませんでした。
作成された予約は容量管理画面に現れますので、「割り当ての作成」からプロジェクトとジョブタイプを指定して割り当てていきます。
これでオンデマンド料金モデルからEnterpriseエディションへの移行が完了しました。実際に有効化されてる様子はBigQueryコンソールの下部、「個人履歴」または「プロジェクト履歴」で確認できます。移行作業後に実行された適当なジョブを選び、詳細を開いて「予約」の項目に先程の作成時に設定した予約の名前が表示されていれば大丈夫です。
移行後に発覚したうっかりミスですが、この時予約作成をしたリージョンが東京のみでUSリージョンにあるデータへのクエリがオンデマンド料金のままになっていました。 BigQueryの利用リージョンと予約作成リージョンはしっかり確認するようにしましょう。
監視ダッシュボードを用意する
当初はINFORMATION_SCHEMAを利用してLookerStudioでダッシュボードを作っていました。ですが、BigQueryの負荷状況をBigQuery自身に問い合わせるのが好ましくなかったため、ほぼ同じようなモニタリングダッシュボードをCloud Monitoringで作成しました。
それぞれのグラフは下記の指標から作成しています。
- ステータス別ジョブ数：
BigQuery Project > Job > Job count - クエリ実行時間：
BigQuery Project > Query > Query execution times - 消費スロット：
BigQuery Project > Slots > Slots used by project, reservation, and job type
Cloud MonitoringであればBigQueryへ負荷をかけることなく、ダッシュボードの自動更新もできます。移行後数日は直近の数時間を表示して監視しておきましょう。
またスロット消費アラートも設定してSlackへ通知されるように準備しておきます。最大予約サイズ指定から計算し、「5分間でこの程度のスロットが消費された場合アラートを鳴らす」という指定をしておけば最大値に張り付きっぱなしである状況を検知できるでしょう。
BI Engineを利用する
移行した後に上記のダッシュボードを利用して監視を行っていたところ、移行のすぐ翌日にはLookerStudioなどの利用が活発な日中にBigQueryの処理能力不足が原因でジョブキューが大量にPENDINGとして溜まってしまっていることがわかりました。
slot上限を緩和することを検討しましたが、原因となるジョブのほとんどがLookerStudioというダッシュボード起因であることからBI Engineの利用を検討しました。BI EngineとはダッシュボードなどのBI向けに用意されたBigQueryのキャッシュ機能です。BIを通じて特定のクエリ、特定のテーブルが頻繁に利用される場合にデータをキャッシュへ保存することで高速化が見込めます。キャッシュ容量を1GiB単位で予約することができ、東京リージョンでは1GiBあたり月々$36.4の料金がかかります。
料金 | BigQuery: クラウド データ ウェアハウス | Google Cloud
とりあえず手始めに2GiBから開始して様子をみます。こちらもCloud Monitoringを使って監視をしていきます。
それぞれのグラフは下記の指標から作成しています。
- 確保サイズ・使用サイズ：
BigQuery Project > Reservation > Reservation total bytesとReservation used bytes - テーブル別使用サイズ：
BigQuery Project > Reservation > Reservation used bytes table
ダッシュボードでモニタリングしている限り、やはり日中はBI Engineの容量をかなり消費する状態になっていました。一方で実行・待機ジョブの数（ステータスがRUNNNINGとPENDINGなジョブの数）をみるとBI Engineを有効化した日からPENDINGが大分減り、RUNNING数が増えました。待ち状態のジョブが減り、1分間に実行できるジョブの数が増えたことがわかります。
移行後の監視と対応
BI Engineは導入しましたが、それでもLooker Studioからの大量のジョブがなだれ込むタイミングでPENDINGジョブが増加する状況が続きました。ダッシュボードへのアクセス待ち時間が許容できない状態となったため、結局slot上限の引き上げを実施しました。そもそもslot上限はバーストを防ぐためのもので、最初から設定値が厳し目にしすぎていたという反省もあります。
当初の想定では大半のクエリは1分以内に終了し、消費スロット時間も大したものではないという予定でした。しかし実際に移行をしてみるとそれなりに消費スロット時間があったようで、移行後の監視と対応に1週間程度はかかりきりとなってしまいました。
移行から2週間ほど経った現状のコストをCloud Billingレポートから確認してみたところ、時期によって利用量の差があるものの大体移行前と同じ程度のコスト感で利用できているようです。来月のオンデマンド料金25％値上げを考えれば事前にコスト削減できたと言えるでしょう。
なお移行後に1日だけ青い棒（＝オンデマンド料金）が伸びてる日はUSリージョンがオンデマンド料金になったまま「割当と上限」の緩和・撤廃をアナウンスした日です。またその日と翌日は諸事情によりデータ基盤チームが複数のログテーブルにまたがった大規模処理を数時間に渡って行ったため、その処理コスト分だけ赤い棒（＝BigQuery Editions料金）が伸びています。
まとめ
このような流れでブックウォーカー社ではBigQueryの利用プランのEditions移行を行いました。 事前準備だけでなく、移行当日やその後の対応も色々と手間がかかりましたが移行自体は実施してみてよかったと考えています。それはクエリのスキャンサイズに比べ、計算リソースはエンジニアリングで対処しがいのある対象だと感じているためです。BigQueryのみならず、データ基盤全体の最適化をこれからどうにかしてやろうと計画を練っています。
この記事が7月5日を目前にどうやって移行をしようか検討しているBigQuery利用者の役に立てればと思います。
参考記事
移行に当たって公式ドキュメントはもちろん、下記の記事も参考にさせていただきました。ありがとうございます。
