BigQuery Editions で料金とパフォーマンスを最適化する
はじめに
こんにちは、クラウドエース データソリューション部の坂田です。
みなさんの BigQuery ライフはいかがですか？
今回は、BigQuery Editions における料金とパフォーマンスの最適化についてお話しします。
説明すること
- BigQuery Editions を使い始めてしばらく経った際の料金とパフォーマンスの最適化方法
説明しないこと
- BigQuery Editions を使い始める際の最適な設定
- 他の料金体系「オンデマンド」での最適化
- スロットに関する設定以外の最適化
BigQuery Editions とは
BigQuery Editions とは、BigQuery で発生する「コンピューティング料金」の料金体系の 1 つです。
「クエリで使用したスロットの量・時間に応じて料金が発生する」という形となっており、単価の単位は「円 / スロット・時間」です。
スロットとは
スロットとは、クエリを実行するための仮想CPUのこと。
複数のスロットを使って分散処理が行われ、必要なスロット数は自動的に計算される。
クエリの規模が大きい場合、多くのスロットを使って分散処理することで高速な処理を実現する。
詳しくは以下ドキュメントを参照。
BigQuery Editions は以下のような特徴があります。
- 使用するスロットの量の下限と上限を設定でき、料金とパフォーマンスをコントロールしやすい
- 各エディション「Standard」「Enterprise」「Enterprise Plus」によって、料金・機能・制限が異なる
- コミットメント（確約利用割引）によって割引価格を適用することもできる
以下の記事でも詳しく解説しています。
なぜ最適化が必要なのか
BigQuery Editions では、主に以下の項目を設定します。
- スロットのベースライン：最低限確保するスロットの量
- スロットの最大予約量：使用するスロットの上限
- コミットメントの量：どのくらいの量のスロットを使用することを確約するか
上記はすべて 100 スロット単位で設定できます。
BigQuery Editions におけるコミットメントとは
一定量のスロットの長期間使用（1 年 or 3 年）を確約する代わりに割引価格で利用できる仕組み。
コミットメントのスロットは 100 単位で設定できる。
詳しくは以下ドキュメントを参照。
例えば、ベースラインを 200 スロット、最大予約量を 500 スロット、コミットメントの量を 0 スロットと設定したとします。
この場合、常時 200 スロットが確保されており、クエリを実行するために 200 以上のスロットが必要な場合は、200〜500 の範囲でスロットが自動スケーリングします。
そして、常時確保されている 200 スロット分は固定料金として料金が発生し、自動スケーリングで追加されたスロットは使用した分だけ料金が発生します。
もし、普段実行されているクエリが 200 スロット未満で実行できている場合、現状の設定はオーバースペックとなり、料金に無駄が生じていることになります。
一方で、常に上限の 500 スロットが確保されており、クエリを実行するのにスロットが足りていない場合、現状の設定はアンダースペックとなり、ベースラインや最大予約量を見直すことでパフォーマンスを改善させることができます。
このように、一度設定した BigQuery Editions の設定を見直すことで、料金を抑えたり、パフォーマンスを改善したりできる可能性があるのです。
最適化の方針
前提として、BigQuery Editions の最適化は 1 ヶ月程度の使用実績をもとに行います。
もし、使い始めたばかりの場合は、もう少し様子を見ましょう。
その上で、最適化は、「パフォーマンス要件を満たしつつ、料金を抑える」ことを目指します（当たり前ですが...）。
現状の設定でパフォーマンス要件を満たせていないのであれば、まずはパフォーマンスを改善させることを優先します。
確認ポイント
最適化を行うにあたって、以下のポイントを確認します。
① 実績を確認する
② スロット見積もりツールによる推奨値を確認する
ポイント① 実績を確認する
現状の設定に対して調整できる余地はあるかどうかを判断するには、現状の把握が必要です。
「スロットの料金で節約できる部分はないか」と「現状の設定で BigQuery のパフォーマンスに問題はないか」の 2 つの観点を確認します。
具体的には、以下のような項目を確認します。
- スロットの使用状況
- クエリで実際に使用されたスロットの量（スロットの需要量）
- BigQuery が確保したスロットの量（スロットの供給量）
- パフォーマンス
- クエリの実行時間
- どのユーザーやアプリケーションが、いつの時間帯にどのくらいクエリを実行し、どのくらいのスロットを使用しているか
- BigQuery のパフォーマンスが、BigQuery と依存関係のあるジョブに悪影響を及ぼしていないか
これらの情報は、
- BigQuery モニタリング
- クエリの実行詳細画面
- INFORMATION SCHEMA の RESERVATIONS_TIMELINE ビュー
- INFORMATION SCHEMA の JOBS ビュー
などから確認できます。
BigQuery Editions では、クエリで実際に使用されたスロットの量（需要量）ではなく、BigQuery によって確保されたスロットの量（供給量）に対して課金されます。
そして、スロットの需要に合わせて供給されるスロットが自動スケーリングされるため、需要に見合った供給なのか、といったスロットの需給バランスを確認します。
特に、自動スケーリングに影響を及ぼすような、スロット需要が特に大きかったクエリについて、スロットの使用状況を確認します。
例：スロットの供給量の確認
例えば、以下のクエリで、1 分ごとの、自動スケーリングによるスロットの供給量（ベースラインを除く）を確認できます。
SELECT
period_start,
autoscale.current_slots
FROM
`region-<REGION>`.INFORMATION_SCHEMA.RESERVATIONS_TIMELINE
ポイント② スロット見積もりツールによる推奨値を確認する
BigQuery Editions では、「スロット見積もりツール」と呼ばれる機能が用意されています。
※ 執筆時点ではプレビューの機能です。
スロット見積もりツール では、以下のことを確認できます。
- スロットの使用実績をもとにした最適な設定値
- 推奨値を適用した場合、パフォーマンスがどのように変化するか
BigQuery Editions の設定に更新に合わせたパフォーマンスの変化も確認できるため、ぜひ活用しましょう。
ただ、ここまで読むと、「スロット見積もりツールだけ確認すれば良いのでは？」と思われたかもしれませんが、推奨値が適切かどうかの判断も必要です。
そのため、スロット見積もりツールだけでなく、実際の状況も確認し、推奨値が適切かどうかも確認します。
スロット見積もりツールの確認方法
スロット見積もりツールは、Cloud Console の画面で、
BigQuery > 容量管理 > リージョンを選択 > スロット見積もりツール
から確認できます。
※ 上記は、一時的に作ったプロジェクトの画面のため、スロット見積もりツールの情報が表示されていませんが、1 ヶ月程度の運用実績があれば、スロットの使用状況や推奨設定などが表示されます。
最適化
確認した実績や推奨値をもとに、以下の設定を見直します。
ベースライン（下限）
ベースラインの値が、常時確保されるスロットの量を表すため、料金に大きく影響します。
主に、「スロットの使用状況（需要量、供給量）」を確認し、ベースラインを決定します。
例えば、スロットの需要量・供給量が多くの時間帯で一定量を超えている場合、その一定量の値をベースラインに設定します。
また、スロットの需要量がベースラインより小さく、ベースラインを超えるスケーリングがあまり行われていない場合、ベースラインを小さく設定します。
ベースラインの値を大きくすると、自動スケーリングの頻度が減るため、自動スケーリングによるタイムラグ（数秒）を抑えられ、（多少の）パフォーマンス改善を見込めます。
最大予約量（上限）
パフォーマンスに大きく影響する項目です。
主に、「スロットの使用状況（需要量、供給量）」「パフォーマンス（クエリの実行時間など）」を確認し、最大予約量を決定します。
値を大きくすると、より多くのスロットを用意することができるようになるため、実行時間が短くなり、パフォーマンス向上が見込めます。
また、値を小さくすると、パフォーマンスへの悪影響が出る可能性がありますが、スパイク的なスロットの増加を抑えられるため、料金の急激な増加を抑えることができます。
スロットの最大予約量とパフォーマンスの関係（あくまでイメージです）
コミットメント
ベースラインで確保されているスロットに対して、コミットメントを適用することで、スロットの固定的な料金を抑えることができます。
以下は東京リージョン、Enterprise プランの BigQuery Editions の料金です。
- 従量課金：$0.06 / スロット・時間
- 1 年コミットメント：$0.048 / スロット・時間
- 3 年コミットメント：$0.036 / スロット・時間
※ 料金表はこちら
自動スケーリングで確保されるスロットは、「従量課金」の料金が適用され、コミットメントの料金より高いのが分かります。
固定的に確保されているスロットに対しては、できる限りコミットメントの料金を適用した方がお得になります。
ただし、コミットメントは 1 年・3 年の契約期間が必要なため、BigQuery を長期的に利用することが前提となります。
最適化の例
最適化の例を 2 つ紹介します。
ケース①
現状の設定を以下とします。
- ベースライン：0 スロット
- 最大予約量：500 スロット
- コミットメント：0 スロット
そして、日々どのくらいのスロットの量が確保されているか（スロットの供給量）を確認したところ、以下のように、常に300 スロット以上は確保されていることが分かりました。
スロットの供給量の推移
そこで、ベースラインとコミットメントを 300 スロットに設定することで、固定的に確保されている 300 スロット分を割引料金で利用でき、全体の料金を抑えることができます。
また、上記のグラフでは、スロットの供給量が最大予約量の 500 に張り付いていたり、多くの時間で 500 に達していないという状況ではないようなので、最大予約量は 500 のままでも良さそうです。
もし、スロットの供給量が多くの時間で最大予約量に達しており、「スロットの競合」と呼ばれる、クエリの実行に必要なスロット量が不足している状況が確認されたり、明らかに最大予約量がオーバーな値であることが確認されれば、最大予約量を見直します。
スロットの競合が発生しているかどうかは、BigQuery モニタリングのジョブエクスプローラや、クエリの実行詳細画面から確認できます。
ケース②
現状の設定を以下とします。
- ベースライン：500 スロット
- 最大予約量：1000 スロット
- コミットメント：0 スロット
ケース①と同様、スロットの供給量を確認します。
スロットの供給量の推移
多くの時間では、ベースライン 500 を超える自動スケーリングが行われていないことが分かります。
次に、スロットの需要量（クエリで実際に使用したスロットの量）を確認します。
スロットの需要量の推移
多くの時間でスロットの需要量がベースライン 500 を下回っており、 0 の時間帯が多いことが分かります。
以上のことから、現状のベースラインは過剰な設定になっており、余分に料金が発生していると考えられるため、ベースラインを現状より小さい値に設定します。
今回は、スロットの需要量が 0 の時間帯も多いため、ベースラインを 0 に設定するのが一番安い可能性もあります。
また、最大予約量はケース②と同様、BigQuery のパフォーマンスから値が適切かを判断します。
上記のグラフを見る限り、最大予約量は現状のままでも問題なさそうです。
まとめ
今回は、簡単にですが、BigQuery Editions における料金とパフォーマンスの最適化の重要性とその方法についてお話ししました。
BigQuery の使い方は様々であるため、一概にこの最適化方法を適用できるわけではないとは思いますが、最適化の方針や確認ポイントについて、参考になれば幸いです。
また、BigQuery の最適化は、BigQuery Editions の設定の見直しだけでなく、クエリのリファクタリングや実行のタイミングの調整など、様々な方法があります。
このあたりはまた別の機会にお話しできればと思います。
参考文献
Google Cloud 公式ブログ
他社様の最適化事例
Discussion