Photo by Rob Wicks on Unsplash
はじめに
BigQuery editionsの登場により、新しい料金モデルや既存モデルへの大幅な変更がユーザーに提示されました。
DoiTでは、多くのお客様とともに、適切に設計されたシステムの構築、クラウドサービスの効率的な活用、そしてコスト最適化に取り組んでいます。今回のBigQueryの変更を受け、コンピューティングコストを抑えるため「オンデマンド」から新しい料金モデルである「Standard Edition」への移行を検討するお客様からのご相談が増えています。
本記事では、移行にコストメリットがあるかを判断する手順、そして実際の移行と監視の進め方を解説します。
記事内で参照するSQLコードを実行するには、以下のINFORMATION_SCHEMA views: JOBS_BY_PROJECT, JOBS_TIMELINE_BY_PROJECT, RESERVATION_CHANGES_BY_PROJECTへのアクセス権が必要です。
テーブルアクセスに必要な権限：roles/bigquery.resourceViewer（プロジェクトレベル）
Standard Editionリザベーションの要点
Standard Editionはコンピュート（スロット時間）ベースの提供形態ですが、他のコンピュートベースの料金オプションと違い、組織単位ではなくプロジェクト単位（オンデマンドと同じ）である点が大きな特徴です。
最大のメリットは、低コストかつコミットメント不要でオートスケーリングを利用できることです：「BigQueryはワークロードの増減に合わせてスロットを動的に調整します」（スロットのオートスケーリングの概要）
オンデマンドとStandard Editionの主な違いは次のとおりです。
1. 課金単位：オンデマンドはスキャンしたデータ量に応じて課金されるのに対し、Standard Editionはスロット/時間モデルを採用しています。
2. スロットの可用性：オンデマンドではスロットは「ホット」な状態で即座に利用できますが、Standard EditionではAutoScalerがクエリジョブに必要なスロット容量を見極めてから割り当てるため（約10秒の遅延）、クエリのレイテンシに影響します。
3. 利用可能な最大スロット数：オンデマンドは2,000スロット、Standard Editionは1,600スロットです。
\[1\] Standard Editionの機能と制限のチェックリスト
最初のステップは、自分のプロジェクトがStandard Editionと適合するかを確認することです。下記の機能一覧をしっかり確認し、できることと制限を正しく把握してください。
詳細な比較は次のページを参照してください：BigQuery editions features。
\[2\] ワークロード使用状況の分析
機能と制限を確認したら、次はプロジェクトがI/O中心かCPU中心（スロット）かをもとにコストを見積もります。INFORMATION_SCHEMA.JOBSビューでは、total_bytes_billed（I/O）とtotal_slot_ms（CPU）からこのデータを取得できます。
目的は、スキャンデータ量に基づくコストと、スロット使用量に基づく概算コストを比較することです。I/Oベースのコストは全クエリコストの合計なので比較的シンプルに算出できます。一方、スロットベースのコスト見積もりはオートスケーラーの動作（100スロット単位のバケットサイズ、最低1分間のダウンスケーリング遅延）を考慮していないため、やや低めに出ます。この差を埋めるため、スロットベースの見積もりに1.5倍の係数を掛けます。
下表は月間コストとスロットコストのオンデマンドに対する比率を比較したもので、オンデマンドからStandard Editionへ移行した際に予想されるコスト変化を示します。
比率が100未満ならコスト削減の可能性、100超ならコスト増加の可能性を意味します。
例：
顧客の月額コスト — オンデマンドの方が高い
顧客の月額コスト — オンデマンドの方が安い
上表を生成するコード：BigQuery OnDemand vs. SE.sql
Standard Editionはオンデマンドに比べて機能が少ない点を踏まえると、比率が概ね75%を超える場合はオンデマンドを継続するのがおすすめです。期待できる削減幅がわずかなうえ、一部機能を犠牲にすることになるためです。
\[3\] 最大スロットの設定
Standard Editionで必要な設定は1つだけ、AutoScalingの上限となる最大スロット数です。
適切な値はどう決めればよいのでしょうか。
残念ながら万能の答えはありません。ワークロードのパターンや、コストとパフォーマンスのバランスをどう取りたいかに応じて、初期設定後に調整が必要になるはずです。
初期値を決める方法のひとつとして、次の計算式が使えます。
選択した期間のうちスロット使用量が100（基本構成）を超えた時間帯について90パーセンタイル値を求め、100の倍数に切り上げます。
選択期間内のP90時間に基づく最大設定値
初期最大設定値を求めるためのコード例：BQ SE max configuration.sql
リザベーションの作成
リザベーション作成の手順は次のページに詳しくまとまっています：Get started with reservations。
Standard Editionを選択し、「max Slots」を設定したうえで、適切なリージョンまたはマルチリージョンを選んでください。これらが正しく設定されていないと、リザベーションは正常に機能しません。
\[4\] パフォーマンスとコストのモニタリング・評価
パフォーマンスへの影響
アプリケーションのパフォーマンスを把握するため、移行前にジョブの処理時間やアドホッククエリの応答時間といった指標を取得し、移行後の結果と比較します。BigQueryユーザーに変更内容を事前に周知し、フィードバックを集めておくのもおすすめです。
システム視点でのパフォーマンス評価には、次のセクションで紹介する管理リソースグラフが活用できます。
コストメリット
コスト効果を評価するには、日次の請求ダッシュボードで支出を確認します。請求セクションでAnalysisとStandard EditionのSKUを選択してください。
下表は1時間単位で総スロット割り当て数と推定コストを集計したものです。これを使うと、オートスケーラーの挙動に基づく実コストを概算できます。
コード例：Standard Edition cost estimation.sql
1時間あたりの推定コスト分布
\[5\] チューニング
Standard Editionのチューニングは、最大スロット数の設定値を増減することで、パフォーマンスを高めたり（スロット数を増やす）、コストを抑えたり（スロット数を減らす）する作業です。目指すのは、リソースが過少利用にも過剰割り当てにもならない、バランスの取れたシステムです。
ワークロードの効率をモニタリングすると、システムがバランスの取れた状態か、活用しきれていないか、過剰にプロビジョニングされているかを判断できます。これは管理リソースグラフを確認するか、INFORMATION_SCHMEA viewsを直接クエリすることで行えます。
管理リソースグラフ：
BigQuery管理者は、組織全体のスロット使用状況とBigQueryジョブのパフォーマンスを継続的にモニタリングできます。これらのグラフはBigQueryサイドバーの「Monitoring」セクションにあり、さまざまな観点のビューが用意されています。詳しくはadministrative resource chartsのガイドを参照してください。
- スロット使用状況の分析：P90またはP99メトリクスを使い、スロットの使用量と割り当て量（「ベースライン+オートスケールスロット」を含む）の関係や、スケールアップ／ダウンに要する時間を確認します。
スロット使用状況
上のグラフは、リザベーションの変更情報を含むRESERVATION_CHANGES_BY_PROJECT``viewのデータを使用しています。
下表はスロット割り当てと、次の変更（スケールアップまたはダウン）が発生するまでの時間を表示します。'allocated_slots'は特定の時点で割り当てられたスロット数（次の'UPDATE'が発生するまで）を、'Estimated total slots'は期間全体での総割り当て量を表します。
コード例：Monitor BQ edition autoscaling.sql
実際のスロット割り当てと継続時間
- ジョブの同時実行状況：システムのボトルネックを把握するには、「pending jobs」メトリクスを確認します。
保留中のジョブ
- ジョブのパフォーマンス：90パーセンタイル（P90）指標を活用し、レイテンシの高いジョブをモニタリングします。
ジョブのレイテンシ
まとめと推奨事項
バーストやスパイクが発生するケースでは、本記事のアプローチよりも適した方法があり、より踏み込んだ分析が必要になることもあります。とはいえ、ここで紹介したツールは分析全体を通じて有用な示唆を与えてくれるはずです。
移行の判断は、対象プロジェクトでのユーザーの利用形態、つまりI/O中心（「オンデマンド」が割高になる）かCPU中心（「Standard Edition」のコストが高くなる）かに大きく左右されます。
GoogleはStandard Editionを主に研究開発プロジェクト向けとして推奨しており、「たとえばStandard Editionは、アドホック、開発、テストワークロードに最適です」と述べています。
「本番ワークロード」の捉え方はお客様によって異なるため、ETL/ELTの本番ワークロードでもStandard Editionの利用を検討するお客様もいます。エディションの制限（特に99.9%のSLA）を満たし、負荷が時間的に安定しており、エンドユーザーがクエリのレイテンシを気にしないのであれば、これも十分許容できる選択です。
ここまでで全体の流れをつかんでいただけたはずです。ぜひ実際に試して、結果をお聞かせください。