概要 - BigQueryの料金体系について
BigQueryのクエリは、初期状態では「オンデマンド」状態での実行となっている。大まかな特徴は以下の通り。
- 実際に実行したクエリに応じて課金が発生する
- 原則的な上限スロット数(2000)を条件付きでバーストすることができる
- 実行リージョン全体でのスロット数にゆとりがある場合に適用される
- 逆にリージョンのスロットの状況によっては2000未満しか使えないことがある
低コストでBigQueryの恩恵を受けられる料金体系だが、スロットの確保も都度行われるという点に注意が必要。複雑度が著しく高い集計が集中している場合、クエリ実行時にあまりスロットが確保できなくなるためだ。平時こういった事象が頻発することはないが、人気のあるリージョンや、Googleで元々確保しているリソースが少ないリージョン(例えば、USやEUと比べてAsia-Northeastは後者にあたるらしい)で需要の高まる時期にはスロットの枯渇が起こるということも考えられる。
今回検討したこと - Flex Slotsの活用
上記のスロット枯渇は、BigQuery Reservations(https://cloud.google.com/bigquery/docs/reservations-intro?hl=ja)の適用で解決できる。あらかじめスロットを確保することで、リージョン全体のスロット枯渇の影響を受けなくなる。
しかし、現在想定している環境は以下のとおりである。
- 定期処理をオンデマンドのまま実行している環境
- 安定させたいのは1日の中で特定時間帯(朝方)のクエリのみ
この条件でいきなり年間コミットメント・月間コミットメントといった定額課金に移行するのは若干金銭面のハードルが高い。スロットの枯渇は毎月・毎四半期確定で起こるというものではない。スロット枯渇に対応するコストを定額課金によるコストが著しく上回るのは避けたい。
そこで今回は、基本はオンデマンドのまま、リスクの高い時期のみFlex Slotsを必要数購入してそちらで実行する方法をとることにした。需要が上がるタイミングに合わせてFlex Slotsを活用することについては以下で言及されている。今回は、基底部分に定額制のコミットメントを置かず、Flex Slotsのみを単独で使用する。
https://cloud.google.com/blog/ja/products/data-analytics/introducing-bigquery-flex-slots
やり方
以下を参考に、重要な日次処理の実行前にスロット購入～割り当ての処理を、終了後に割り当て削除～スロット購入取りやめの処理を入れる。
https://cloud.google.com/bigquery/docs/reservations-tasks?hl=ja#bq
注意点
いきなり使用頻度の高いプロジェクトに適用しない
理由として、以下の2点がある。
- 割り当てはプロジェクト単位のため、同じプロジェクトで定期実行の処理以外にユーザがクエリを叩けば、そこにも購入したスロットが割かれる →BigQuery Reservations適用状態では購入スロット数以上のバーストは発生しないため、逆に枯渇リスクが高くなってしまう
- 購入スロットの割り当て/割り当て解除を行った際、反映されるまでに5分前後のラグが発生する
→特に、割り当て解除～スロット購入取りやめを行った場合、この5分間はクエリ実行に失敗するようになる
- オンデマンドに切り替わる前かつ使えるスロットがない状態によるエラーのため、年間コミットメント+Flex Slotsの構成でFlex Slotsだけを取りやめた場合は問題ないと考えられる(要検証)
2点目については今後改善される可能性があるが、基本的にはこの仕組みを適用したい処理のみ別プロジェクトに切り出すのが安全である。
疑問点
スロットの割り当て/解除の遅延について調べてみたものの、同じような事例を見かけなかった。これについては見落としや更新が無いかまた時間をおいて確認したい。