BigQuery editions の Autoscaling の自動設定・料金按分の仕組みを紹介します

はじめに

初めまして。横断クラウドアーキグループの勝俣です。私は普段 BigQuery の計算リソースである Slot と呼ばれるものを全社横断的に購入・管理する社内サービス「BQ ホーダイ」の運用を担当しています。今回は BQ ホーダイチームの提供機能として BigQuery editions の Autoscaling の自動設定・自動料金按分の仕組みを紹介します。

背景

当社では Google Cloud の BigQuery に事業データを保持・分析しています。その大規模なデータの分析には BigQuery 上での計算リソースである Slot を大量に必要とします。 Slot はオンデマンドとして使いたい時に使いたいだけ利用できるのが基本の設定ですが、事前に一定の量を購入して確保することもできます。事前に Slot を購入することにより確実に Slot を確保できる、Slot の料金を固定する事ができる、オンデマンドの Slots 上限値である 2000 を超えて利用することができるといったメリットがあります。

当社では事前購入した Slot を効率的に運用するために下記のような Slot の一括購入・管理の仕組みを、BQ ホーダイとして社内向けに提供しています。

Slot 管理に関して、今回のテーマで重要になる点は下記になります。

Slot は 1 つの管理プロジェクトで全て購入し、各 Reservation に割り当てしている
Slot の購入に関しては低価格でより多くの Slot を購入するため 1 年コミットでの購入のみ許可している(1年間は購入した Slot を解約出来ない)
各 Reservation の担当者に Slot を利用した分だけ後で BQ ホーダイチームから請求を行う

Autoscaling 実装の課題

BigQuery editions では 1 年コミットのほかにも Autoscaling と呼ばれる必要に応じて自動的に Slot を購入したり、削除したりしてくれる機能があります。 Autoscaling しても良い最大値を Max という値として事前に Reservation 毎に指定し、その値の間で 100 Slot 刻みで Slot が自動調整されます。リクルートで購入している Slot は全て Enterprise 利用なので Baseline Slot と Autoscaling の併用が可能で、結果として図のような挙動を Autoscaling は行います。

Autoscaling により購入した Slot は 1 年コミットの Slot よりも比較的単価が高いものの、購入した 1 年コミットの Slot を 1 日の半分程度の時間しか使っていないというような状況であれば年間 Slot ではなく Autoscaling を利用した方が価格を抑える事ができます。

ただし、BQ ホーダイチームとリクルート全体の運用上 Autoscaling を利用者にそのまま提供するのには少しだけ課題があります。

1 つ目に Slot(Autoscaling) の料金を各 Reservation の担当者に請求する必要があるということです。

1 年コミットの Slot であれば事前に利用額がわかるため請求を行うことは容易ですが Autoscaling の場合秒単位で購入する Slot が変動するため、その請求額は毎月変動する上に実際にどの Reservation がどれだけの Slot を購入したのかがわかりません。

2 つ目の課題として Autoscaling は「今はクエリ速度が多少遅くても良いのでスケールして欲しくない」という状況でも Autoscaling の上限まで Slot を購入してしまいます。

1 つの Reservation 内で「この時間帯は重要なバッチが動くので Autoscaling 上限まで Slot を購入してでも性能を担保したい」「この時間帯はバッチではなく、分析等をしている時間帯なので予想外の支出を抑えたい」という 2 つの時間帯があるケースが少なからずあるので、その辺りを時間帯によって自動で増減させる必要がありました。

Autoscaling 提供の仕組み

前述の様な課題を解決しつつ、Autoscaling にて効率的に Slot を購入するために Google Cloud 上でこちらの様な仕組みを BQ ホーダイチームで作って運用しています。

このアーキテクチャには大きく 2 つの機能があります。

1 つ目は Autoscaling の自動設定・自動設定削除機能です。事前に設定した 2 つの Cloud Scheduler が(例えば)重要なバッチの実行時間前と後に Cloud Functions を起動し、Autoscaling の設定を行ったり設定を戻したりします。 Autoscaling 設定の操作の前に Datastore へ設定状況を保存することによって設定のステート管理をしています。 Datastore でステート管理をすることによって Cloud Scheduler が多重起動してしまった場合に Autoscaling が多重に設定されてしまうことを防いでいます。(Datastore へステート情報を保存・削除できた Cloud Functions のみが Autoscaling の設定を実際に行える) また別途 Datastore のステート情報を監視するバッチも稼働させていて、Cloud Scheduler が何らかの理由で Cloud Functions を起動出来なかった場合にアラートが発生するようにしています。

2 つ目に Autoscaling の料金を自動的に算出して Slack に通知してくれる機能です。実際にどの Reservation がどれだけ Autoscaling によって Slot を購入したのかを知るために、月次で INFORMATION_SCHEMA から Autoscaling の変更ログを取得し、各 Reservation の月の Autoscaling 利用料金を自動的に算出してくれます。

INFORMATION_SCHEMA にはいつ、どの Reservation が、どのくらい Autoscaling により Slot を購入したのかが全てログとして残っているため、その情報と Autoscaling の単価を掛け合わせて算出しています。

以上の仕組みを作成し、社内に無事 Autoscaling による Slot の効率運用を実現させることができました。また、これらの定期実行設定は全て Terraform で管理していて利用者は新規利用や既存の設定変更の申請を GitHub 上にある Terraform リポジトリへの Pull Request という形で行うことができます。

文面等で直接やりとりをするのには一定の労力が必要だったり、少人数の BQ ホーダイチームが全ての申請を Terraform に反映していくのも工数が必要になってしまったりするため、この申請フローにする事でお互いにスムーズに行いたい設定が実現できます。