BigQueryスロット利用量の見積り

  • f
  • t
  • p
  • h
  • l
accountant-1238598_900

この記事は GiXo アドベントカレンダー の 12 日目の記事です。
昨日は、「プログラミング歴40年のおじさんが初めて本格的なPythonプログラム」を書いてみた でした。

本稿ではBigQueryにおいて計算リソースの単位として表現されるスロットについて、どのように利用量の確認・見積りを行うかについてお話をしたいと思います。スロットの見積り、難しいですよね。私は大層混乱しました。まだ混乱しているかもしれません。そんな難しいスロット利用量の確認・見積りについて少しでも役に立てばという思いで筆を執っている次第です。あるいは、どうせまた忘れてしまう未来の自分のためかもしれません。では始めます、よろしくお願いします。

定額料金で利用する際に特に気になるよね

BigQueryを定額料金で利用する際にはスロットを100単位で任意の量だけ購入し、その購入量に応じて金額が決まります(最小100)。なので必要以上にスロットを確保してたくさんお金を払うことを避けるために「スロットをどれくらい利用するワークロードなのか」を見積り、それをもとに購入するスロット数を決定していくことになります。

INFORMATION_SCHEMAでスロット利用量を確認する

スロット利用量を見積もるにあたって「こんな処理の時はこんくらいかかる」みたいな基礎値というか足がかりになる数値が必要になると思います。そんなときに情報を得るために登場するのがINFORMATION_SCHEMAテーブルさんです。

BigQueryにはユーザーが明示的に作成しなくとも、INFORMATION_SCHEMAというテーブルが存在しています。ここにはいろんな情報が保持されていまして、消費されたスロットの情報も取得できます。テーブルの1行は各処理(クエリ等)を表します。

私はINFORMATION_SCHEMAテーブルからのスロット利用量にまつわる情報取得についてGoogle社のこの記事を読んで理解が深まりました。Googleさんいつも分かりやすい解説をありがとうございます。

total_slot_msというカラムに「ジョブの全期間のスロット(ミリ秒)」が保持されています。(ミリ秒)というのが、見積りを行っていくうえでの鍵となります。定額料金では100スロットとか1000スロットとかの単位で契約するわけですが、このとき確保している計算リソースはスロット数×時間の面積です。一日中どの瞬間でも○○スロットまで使える状態だよ、ということですね。この確保された計算リソースを100%余すことなく使い切るというのは○○スロットを24時間隙間なく利用し続けるということです。

先ほど「テーブルの1行は各処理(クエリ等)を表します。」と書きました。つまり、total_slot_msカラムに入っている値は処理実行中における、ミリ秒ごとの利用スロットの合計です。処理実行中は常に一定のスロットを消費し続けているわけではなく、10スロットしか使ってない時間があれば200スロット使っている時間もあり得ます。この合計で、total_slot_msが例えば1000になったりします。1000スロットを瞬間的に利用してはい終わり、というものはあんまりないかなと思いますので、合計で1000スロットを利用する処理のために1000スロットを予約しておく必要はないと考えられます。

参考:7日間の平均スロット利用率計算の例

また、スロットの上限を超えるようなリクエストが発生した場合、何が起きるかというと処理待ちが発生します
処理がエラー終了するわけではないので、上限値を絶対に割らないようにスロットを確保しておかないといけない、というわけでは決してありません。

平均スロット利用量で考える

としたときに、じゃあいくらのスロットにすんねんという悩みが生まれてしまいますが、クエリの平均利用スロットで考えてみてはいかがでしょうか。例えばこのようなSQLで情報を取得します。このSQLでは、ジョブIDつまり実行された処理ごとの平均スロット利用量を算出しています。再掲ですが、こちらのGoogle社のブログも参考にさせて頂いてます。

実際にBigQueryが利用される際、常に処理が一つだけ動いているということはなく、同じ瞬間にいろんな処理が複数実行されているかと思います。BIツールからどんどんリクエストが飛んでくるということを想定すると尚更ですね。この複数実行されている処理それぞれで利用されているスロットの積み上げが、瞬間的に、定額料金で確保しているスロットに達していなければ待ちが発生することなく処理が実行されて行きます。

計算出来た平均スロットをもとに、同時に実行されるであろう処理数を想定してスロットを見積もります。平均100スロットのSQLは同時に1本、50スロットのSQLは同時に5本、10スロットのSQLが10本実行されると想定すると、100+250+100で450なので、500スロットを確保しておこうといった具合です。

とはいえなかなかどれくらいのワークロードになるか規模が読めないということもあるかと思いますが、そんな場合はオンデマンド料金も組み合わせて利用をはじめ、まずは様子をみつつある程度実測値で傾向を捉えたうえで見積りを精緻化させていくことも出来ます。ごく短時間から定額料金でスロットを確保できるFlex Slotsというものもあり、ワークロードに対して柔軟にスロット購入できるのは喜ばしいですね。

スロット利用量見積り機能があるらしい

本稿執筆時点ではプレビューですが、BigQueryにはこんな機能もあるみたいです。使ったことないので、ただ情報を放り投げる無責任ムーブです、ありがとうございます。使ってみてこんなだったよって教えてくれると嬉しいです。

いかがでしたでしょうか。ご参考になれば幸いです。
明日は「React 18を受けて現状の SPA ルーティング設計を見直した」を公開予定です。


Yuki Yanagi
Data-Informed 事業本部 / Technology Div. 所属
ダイエットのために毎日焼き鮭ばっかり食べています。

  • f
  • t
  • p
  • h
  • l