BigQuery コンピューティング分析費用の最適化
Google Cloud Japan Team
※この投稿は米国時間 2024 年 1 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。
BigQuery は、効率的な SQL クエリ機能で知られる、強力でスケーラブルなペタバイト規模のデータ ウェアハウスであり、世界中の組織で広く採用されています。
BigQuery は優れたパフォーマンスを提供しますが、お客様にとって費用の最適化は依然として重要な課題です。Google Cloud と Deloitte は共に、BigQuery の費用を最適化するためにお客様を支援した豊富な経験を有しています。以前のブログ投稿では、BigQuery 導入時に物理ストレージの費用を削減して最適化する方法を説明しました。このブログ投稿では、オンデマンド料金モデル（$/TB）ではなく、新しく導入された BigQuery エディションを利用して BigQuery のコンピューティング費用を最適化することに焦点を合わせます。
自動スケーリングを利用できる BigQuery エディション スロットは、費用を最適化する方法として魅力的な選択肢です。
設計上の課題
BigQuery オンデマンド料金モデルは、そのシンプルさとクエリごとの課金という特長から、多くの組織のワークロードに採用されています。しかし、クエリ分析にかかるコンピューティング費用は膨大になる可能性があります。一部のお客様にとっては、コンピューティング分析に関連する費用を最小限に抑えることが大きな課題となっています。
Deloitte は、以下のような課題に取り組む顧客を支援しました。
- BigQuery エディションとオンデマンドの費用を比較する概念実証の実施
- BigQuery エディション スロットをどこで管理するか
- どのようにして別の部門にチャージバックするか
- どのような基準を使用してプロジェクトを予約にグループ分けするか
- 無駄を削減するために、どのようにしてアイドル スロットを他の予約と共有するか
- ROI を最大化するために、いくつのスロットをコミットするか
以下に、Google Cloud で BigQuery を使用して費用を最適化する際に、上記の課題に対処する方法を詳しくご紹介します。
おすすめの方法
まず、BigQuery エディションに馴染みがない方は、BigQuery エディションの概要とスロットの自動スケーリングの概要をお読みになることをおすすめします。
オンデマンドと BigQuery エディションの比較
次に、オンデマンドと BigQuery エディションの主な違いを確認していきましょう。オンデマンド料金モデルでは、各プロジェクトの分析用に最大 2,000 スロットまでスケールアップできます。料金は、使用したスロットの容量とは関係なく、スキャンしたバイト数に単価を乗算した値に基づきます。
一方、BigQuery エディションはスロット時間に基づいて課金されます。BigQuery エディションは自動スケーリングが可能なため、定義した最大スロット数までスケールアップでき、コンピューティング分析ジョブが終了したらゼロまでスケールダウンできます。スケールダウンには 1 分ほどかかることに注意してください。
オンデマンドで利用可能なプロジェクトごとに 2,000 を超えるスロットを必要とするワークロードがある場合は、より高い容量要件の BigQuery エディションを使用する必要があります。さらに、Enterprise エディションや Enterprise Plus エディションを使用している場合は、「コールド スタート」の影響を受けやすいワークロードにベースライン スロットを割り当てることで、安定したパフォーマンスを確保できます。また、1 年または 3 年のスロット コミットメント オプションを利用することで、それぞれの単価を 20% または 40% 引き下げることができます。注: ベースライン スロットとコミット済みスロットは、ジョブ アクティビティに関係なく、24 時間 365 日課金されます。
スロット管理プロジェクトの設定
予約を作成する前に、スロットのコミットメントと予約の管理専用の BigQuery 管理プロジェクトを組織内に設定することが不可欠です。このプロジェクト内では、他のワークロードを実行しないようにしてください。そうすることで、すべてのスロット料金がこのプロジェクトに集約され、管理を効率化できます。
アイドル状態のスロットや未割り当てのスロットが同じ管理プロジェクト内の予約でのみ共有されるという点で、すべての予約を単一の BigQuery 管理プロジェクトで管理することには価値があります。この方法はベスト プラクティスと考えられており、効率的なスロット使用率を実現できます。
BigQuery エディションとオンデマンドとの費用比較
ワークロードに対して、BigQuery エディション スロットがオンデマンドよりも費用対効果が高いかどうかを判断するには、オンデマンド クエリの消費量が多いプロジェクトを選択して概念実証を実施し、BigQuery エディション スロット モデルを試します。まず、BigQuery 管理プロジェクト内に予約を作成し、プロジェクトを割り当てます。最大予約サイズとして、現在のオンデマンド容量に相当する 2,000 スロットから始めます。
その後、BigQuery の管理グラフを使用してスロットの費用を決定できます。さらに、JOBS 情報スキーマを使用してクエリを実行することで、プロジェクト内でスキャンされたバイト数を確認でき、「オンデマンド」料金モデルでの費用を計算できます。
次の図は、Enterprise エディションを使用した BigQuery スロットの予約です。コミットメントなしで、最大スロット数は 2,000、ベースライン スロットは 0 です。概念実証を実施するために、この予約にはプロジェクトが 1 つだけ割り当てられています。
図 1: ベースライン スロットと自動スケーリング スロットがある予約。
これまでの経験から、このようなケースにスロットを活用することには大きなメリットがあることがわかっています。ただし、スロットベース モデルとオンデマンド モデルそれぞれが特定のクエリ要件に応じた価値を提供するため、お客様独自の評価を行う必要があります。ほとんどのジョブやクエリが数秒以内に完了し、データスキャンが制限されているような、トラフィック量が少なく管理が簡単なプロジェクトの場合は、オンデマンド モデルの方が適している可能性があります。
図 2 と図 3 は、BigQuery エディション スロットの費用モデルとオンデマンド モデルを使用した場合の比較を示しています。
図 2: BigQuery エディション スロットの費用。
図 2 では、BigQuery エディション スロットの費用が 1,641 ドルであることがわかります。
図 3: BigQuery をオンデマンドで使用した場合の費用。
図 3 では、同じ期間で BigQuery をオンデマンドで使用した場合の費用が 4,952 ドルであることがわかります。
図 4 は、最初の自動スケーリングのスロットサイズが大きすぎたことを示しています。図 7 では、費用の最適化のためにスロットサイズをリセットできるように、スロット見積もりツールによって推奨されるスロットサイズが示されています。
図 4: スロットの最大数が大きすぎる自動スケーリング。
予約とチャージバックの管理
BigQuery エディションのスロットモデルでは、すべてのスロット費用は中央の BigQuery 管理プロジェクトに記録されます。請求や会計の目的で消費されたリソースに対して別の部門やチームに請求する必要がある場合、別の部門へのチャージバックは重要な考慮事項になります。
今後提供される BigQuery スロット割り当て請求レポートには、割り当てられたクエリ プロジェクトごとに、各予約の費用を示す行が含まれます。チャージバックを容易にするため、コストセンターに基づいてプロジェクトをグループ化し、簡単に割り当てられるようにすることをおすすめします。この新機能が利用可能になるまでは、BigQuery 情報スキーマに基づいたクエリを実行することで、各プロジェクトのスロット時間の使用量を判断でき、チャージバックのために利用できます。
プロジェクトのグループ化
スロットの使用量を最適化するために、ビジネス インテリジェンス（BI）、標準的な抽出、変換、読み込み（ETL）、データ サイエンス プロジェクトなど、さまざまなワークロード タイプに基づいてプロジェクトをグループ化することを検討してください。各予約は、グループ内で共有される固有の特性を持つことができ、ベースライン要件と最大スロット要件を定義できます。コストセンターごとにプロジェクトをグループ化するアプローチでは、各コストセンターは異なる部門（BI、ETL、データ サイエンスなど）に属することになり、効率的にチャージバックすることができます。
アイドル スロットの活用
アイドル スロットを共有することで、無駄を省くことができます。デフォルトでは、予約で実行されるクエリは、同じ管理プロジェクト内の他の予約のベースライン アイドル スロットを自動的に使用します。自動スケーリング スロットは不要になると削除されるため、アイドル容量とはみなされません。アイドル容量は、クエリの優先度に関係なく、必要に応じて元の予約にプリエンプティブルに戻ります。このようにアイドル スロットを自動的かつリアルタイムに共有することで、最適な利用率を確保できます。
スロットの自動スケーリングの概要に記載された以下の図は、アイドル スロットの共有による予約を示しています。
図 5: ベースライン、自動スケーリング スロット、アイドル スロットの共有による予約。
予約では、次の優先度でスロットを使用および追加します。
- ベースライン スロット
- アイドル スロットの共有（有効になっている場合）
- 自動スケーリング スロット
ETL 予約の場合、使用可能なスロットの最大数は、ETL ベースライン スロット（700）、ダッシュボード ベースライン スロット（すべてのスロットがアイドル状態の場合、300）、自動スケーリング スロットの最大数（600）の合計です。したがって、この例の ETL 予約では、最大 1,600 スロットを利用できます。
適切なコミットメント レベルの決定
1 年または 3 年のプランを契約すると、従量課金制スロット（PAYG）で 20% または 40% の割引を受けることができます。ただし、ワークロードが主にスケジュールされたジョブで構成されており、常に稼働しているわけではない場合、スロットがアイドル状態にも関わらず 24 時間 365 日の料金を支払うことになる可能性があります。最適な予約設定を見つけるには、スロット見積もりツールを使用して使用パターンを分析し、詳細な情報を得ることです。このツールは、お客様の使用状況に基づいて最適なコミットメント レベルを提案するもので、100 スロットを 1 単位としてシミュレーションを行い、お客様のコミットメント レベルに最適な ROI を特定します。以下のスクリーンショットはこのツールの例です。
図 6: 最適な費用設定に役立つスロット見積もりツール。
現在、Google Cloud コンソールでは、組織レベルの BigQuery エディションに関する推奨事項もダッシュボードに表示され、システム全体を包括的に把握できるようになっています。
図 7: BigQuery エディションの Recommender ダッシュボード
また、3 年間の確約利用割引を利用してスロットの使用量を最適化することで、さらに費用を削減できます。
構築しましょう
BigQuery エディションを使用してオンデマンド（$/TB）からスロットに移行することは、分析費用を削減する大きなチャンスとなります。概念実証の実施と BigQuery エディションのスロットモデルへの移行に関する詳細なガイダンスに沿って進めることで、費用最適化の取り組みの成果を最大化できます。BigQuery の活用により、費用の最適化までの道のりが生産的なものになり、成功裏に終えられることを祈っています。サポートが必要な場合は、こちらからいつでもお問い合わせください。
-エンタープライズ GSI、シニア パートナー エンジニア Schneider Larbi
-Deloitte、シニア マネージャー兼チーフ アーキテクト Jonathan Zhuo 氏
