BigQuery Autoscaling パブリックプレビュー徹底解説（DoiT版）

本記事で使用する用語の簡単な解説です。BigQueryに馴染みのある方にはほぼ既知の内容ですが、そうでない方は以下を踏まえたうえで読み進めてください。

• Job（ジョブ） クエリ実行、データのロード、データのコピーなど、BigQuery上で処理を行うアクションを指します。最も一般的なジョブはクエリで、両者はしばしば同じ意味で使われます。
• Slot（スロット） ジョブの処理を行うためにBigQueryで使われる基本的なコンピュート単位です。「ミニ仮想マシン」のようなもので、多数が連携して実際のジョブを処理するとイメージしてください。
• Reservation（予約） 任意の数（0件以上）のプロジェクトに割り当てるためのスロットを確保する仕組みです。
• Commitment（コミットメント） 通常1か月または1年といった一定期間にわたって固定数のスロットを確保する代わりに、より安価な料金で利用できる仕組みです。
• Admin Project（管理プロジェクト） BigQueryの予約とコミットメントの「管理者」として指定されるプロジェクトです。通常は1組織につき1つ（または少数）を設けて、組織内のBigQueryリソースを「シングルペイン・オブ・ガラス」で一元管理できるようにします。フラットレートおよびオートスケーリングのプロジェクトでは、組織全体の予約課金SKUがこのプロジェクトに紐付きます。
• Flex Slots 短期的にスロット数を増やしたいときに予約へ追加できるスロットです。秒単位で課金されますが、最低課金期間は60秒です。
• Idle Slot（アイドルスロット） 現在ジョブで利用されていないスロットです。
• Workloads（ワークロード） 1つのプロジェクト内で実行される一連のジョブの集まりを指します。
• Slot/Hour（スロット時間） BigQuery Autoscalingプロジェクトの基本的な課金指標です。1スロットを1時間ジョブで使った量を1単位として定義します。
• Autoscaling Slots 実行中のワークロードの必要に応じて、ベースライン値から最大値までスロット数を自動で増減させる新しい仕組みです。
• Baseline Slots（ベースラインスロット） BigQuery Autoscalingプロジェクトで「ホット」かつアクティブな状態に保たれる最低スロット数です。オートスケーリングが発生する前にまずこれが利用され、予約が有効である限り課金されます。

Googleは長らく待ち望まれていた機能をついにパブリックプレビューとして公開しました。それが、購入済みのキャパシティではスロットが不足する場面に対応する、BigQueryのスロットオートスケーリングです。

ざっくり言えば、特定の使用量しきい値に達したらFlex Slotsの予約を調整するCloud Functionなど、手動の介入を一切必要とせずに、ワークロードに応じてBigQueryがスロットを自動で増減させてくれるようになります。

BigQueryの課金モデルは10年以上前から存在しており、基本的には「スキャンしたデータ量に応じた課金」と「キャパシティに応じた課金」の組み合わせです。そのため、コンピュートキャパシティの自動スケーリングとは相性がよくありませんでした。これに対応するためGoogleは、新機能向けに「使った分だけ支払う」アプローチに基づく、より現代的な課金モデルを導入しました。

この機能はその名のとおり、スロットを自動でスケーリングするものです。つまり、ワークロードに追加のスロットが必要になると、BigQueryが予約内のスロット数を実行中のジョブに合わせて自動で増減させます。

これに合わせて、前述のとおり「slot/hour」という単位で課金される新しいモデルも導入されます。これは1スロットを1時間使用したときの料金を、秒単位で課金するものです。

* この変更はBigQueryのコンピュート／分析側の料金にのみ影響し、ストレージコストには影響しません。ストレージは今回の変更の対象外です。本記事を読み進める際にはこの点を念頭に置いてください。

これは、現在フラットレート課金を利用していて、予約量よりも多くのスロットが必要になるケースで非常に強力です。Flex Slotsでも追加のスロットを得る手段はありましたが、自動ではなく、追加のツール（多くの場合、Cloud Functionを定期実行して使用済みスロットメトリクスを監視し、必要に応じて予約にFlex Slotsを追加・削除する仕組み）が必要でした。実装例はこちらにあります（DoiTとは無関係です）。残念ながら、即座にスロットを追加したい場合は、追加のインフラを自前で構築・運用するしかありませんでした。

細部に入る前に1つ注意点として、この新しい課金モデルは1つの予約単位で適用でき、その予約には0件以上のプロジェクトを含められます。つまり予約とプロジェクトをまたいで、オンデマンド・フラットレート・オートスケーリングを自由に組み合わせ、最適な利用形態やコスト構成を作ることができます。

実運用では、ベースライン値が設定されたプロジェクトの場合、すべてのジョブはまずベースラインスロットを使い始め、それを使い切った時点でスケーリングを開始します。これらは予約内のプロジェクトで実行されるすべてのジョブで共有されるスロットプールであり、フラットレート予約と同じ仕組みです。使われなくなるとスケールダウンされて課金対象から外れる点が、削除するまで課金が続くFlex Slotsとの大きな違いです。

とはいえ、スケーリングには60秒のウィンドウがあり、その中でBigQueryがどのようにスケールさせるかを判断します。これにより、短時間で完了するクエリが最大スロット数まで一気に跳ね上がり、必要のない分まで過剰に課金されることを防いでいます。

クラウドの世界では非常によくある話ですが、答えは「ケースバイケース」です。これでは身も蓋もないので、この新しいオートスケーリングモデルが向いているシナリオをいくつか見ていきましょう。

たとえば、1日に数回しか実行されず、それぞれ短時間で終わるものの、実行時には大量のスロット（数千スロット規模）を使うワークロードがあるとします。Flex Slotsで対応することもできますが、こうしたジョブは1分以内に終わることも多く、Flex Slotsの最低課金期間である60秒分を実質的に過剰に支払うことになります。

また、大量のスロット（オンデマンドのスロット数を超える2,000スロット超）を使い、かつ読み取り中心でオンデマンド課金が割に合わないようなワークロードは、Autoscalingにうってつけの候補です。さらに、こうしたワークロードはユーザーの操作をきっかけに開始されることも多く、その都度Flex Slotsの予約を作って実行する余裕がないケースも少なくありません。

最後に、ワークロードの利用がスパイク状になる場合は、当社のBigQuery Autoscaling Slots計算ツールでスロット使用状況を現行構成と比較し、より適しているかどうかを確認してみてください。

新しいオートスケーリングモデルにおける予約は、フラットレート課金時代の予約とほぼ同じですが、いくつか新しい概念や相違点があります。

引き続き管理プロジェクト内で作成され、各予約の中には0件以上のプロジェクトが含まれ、それらにスロットが割り当てられます。

スケーリングという新たな概念が加わったことで、最小スケーリング値「Baseline Slots」と最大スケーリング値「最大予約サイズ（max slots）」が設定されるようになりました。

max slotsの値は、Baseline Slotsの値と、予約全体に設定されるオートスケーリング分のスロット数の合計として定義されます。

デフォルトでは、ジョブ（または複数ジョブ）が予約のオートスケーリング上限を超えた場合、同じ管理プロジェクト内の他の予約からスロットを借りられます。「予約の作成」画面には「Ignore idle slots（アイドルスロットを無視する）」というチェックボックスがあり、これをオンにするとこの機能を無効化できます。

料金体系は、これまでBigQueryで提供されてきた従来モデルとは大きく異なります。新しい料金モデルはslot/hourという考え方に基づいており、これは1スロットを1時間使ったときの料金を秒単位で課金するものです。

Autoscalingでは、スロットを使った時間に応じて課金されます。秒単位での課金ですが、計算をわかりやすくするために時間を基準としています。たとえば1スロットを900秒（1時間の1/4）使用した場合、課金は0.25 slot/hours。3,600秒（1時間）使用した場合は1.0 slot/hoursです。実際のジョブでは複数のスロットを同時に使うことが多いはずなので、これに使用スロット数を掛ければ、課金されるslot/hoursの量がわかります。

料金算出に必要な残りのピースは、slot/hourあたりの単価です。パブリックプレビューでは1 slot/hourあたり0.06米ドルに設定されています。プレビュー機能であるため、変更される可能性がある点にご注意ください。

したがって、ジョブのコストを算出する全体の式は次のとおりです。

Price = 0.06 * (<使用スロット数> * (<使用秒数>/3600))

少し読みづらいですが、要は使用スロット数に使用時間（使用秒数 / 3,600秒）を掛けているだけです。見た目ほど難しくはありません。

とはいえ手計算は面倒なので、料金の試算と比較を簡単にできる計算ツールを作成しました。読み取り専用なので、まずご自身のWorkspace環境にコピーしてからお使いください。

これはGoogleの新機能であるため、対応する新しい料金SKUも用意されています。これによりDoiTコンソール（旧Cloud Management PlatformまたはCMP）で支出を追跡できます。

slot/hourのコストは、次のような名前のSKUで計上されます。

BigQuery Autoscale Preview for US (multi-region)

このSKUのIDはB8BE-01DC-0ECFです。

年間コミット（後述）は、次のような名前のSKUで計上されます。

BigQuery Autoscale Preview 1 Year for US (multi-region)

このIDはC0F6–38AB-6629です。

SKU名のリージョンまたはマルチリージョンの部分は対象によって異なりますが、フォーマットはすべてのリージョンで共通です。

フラットレート料金と同様、Autoscalingにもコミットメント機能があります。100スロット単位で一定数のスロットを所定の期間利用することをコミットする代わりに、より安価な単価で利用できます。仕組みはフラットレートのコミットメントと同じですが、Autoscalingでは年間コミットのみが対象です。フラットレートのコミットメントと同じく、リージョン単位またはマルチリージョン単位で適用され、購入したリージョン／マルチリージョンで利用しなければ割引のメリットは得られません。

*コミットメントを行うと、フラットレートのコミットメントと同様にコミット値の全額が請求される点にご注意ください。課金上の扱いはフラットレートのコミットメントとまったく同じです。

年間コミットメントの料金は1 slot/hourあたり0.05米ドルで、100スロット単位で購入できます。100スロットあたり月額およそ3,504米ドルとなり、コミットなしで100スロットを1か月フル稼働させた場合（月730時間と仮定）の月額およそ4,380米ドルと比べてお得です。

フラットレート課金からAutoscalingに切り替える最も簡単な方法は、予約の設定をフラットレートからAutoscalingに変更するだけです。Googleは予約の入れ替えを簡単にしており、削除や再作成は不要です。

オンデマンドからAutoscaling（あるいはフラットレート）への切り替えは、もう少し手順が必要です。切り替え前にGoogleの公式ドキュメント（こちら）を一読し、予約作成の手順に沿って進めつつ、メニューでフラットレートではなくAutoscalingを選択することを強くおすすめします。

最後にこの疑問が出るのは、多くのBigQueryユーザーが自分の使用量を把握していないからではないでしょうか。ご安心ください、こちらでフォローします。

以前、私が執筆したBigQueryコスト最適化の連載記事では、これに役立つ複数のクエリをまとめたGitHubリポジトリを公開しています。リポジトリ内のクエリを実行する際は、スキャンするデータ量にご注意ください。社内データセットには、2 TBを超えるスキャンになるものもあります。

このトピックは非常に幅広く、本記事の範囲を大きく超えるためすべてには触れませんが、まずは以下のクエリの実行をおすすめします。

• Slots by Minute 指定した期間の時系列を作成し、各分間に使用されたスロット数を表示します。
• Top Complex Queries 指定期間内で最も複雑な（ここでは使用スロットが最も多いと定義）クエリを返します。
• Job Information ジョブIDに関するスロット情報を含む統計情報を返します。あるジョブにパフォーマンス問題が発生していて、より高速に実行するために追加スロットが必要かどうかを確認したい場面で非常に役立ちます。