BigQuery のオンデマンド料金または定額料金のどちらを選択するか
Google Cloud Japan Team
※この投稿は米国時間 2020 年 5 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: これは BigQuery 費用の管理に関するシリーズの一部です。シリーズの他の投稿 Reservations の効果的な使い方、Flex Slots を使用して費用を節約する方法もご覧ください。
データをビジネスの意思決定プロセスに役立てるには、データを有効に活用できるようにデータ分析の使用方法を継続的に最適化する必要があります。ここでは、需要が増減、変化する中で BigQuery の使用をより効率的にする方法をいくつか紹介します。
データの分野の多くの物事と同様に、単純な状況には単純な解決方法で対処できます。状況が複雑なほど、解決方法は単純ではなくなりますが、はるかに強力なものになります。この投稿では、いくつかのシナリオを通じて、ビジネスの特定のニーズに合わせて BigQuery をデプロイする方法を示します。
まず、簡単に説明すると、BigQuery は Google Cloud のエンタープライズ向けフルマネージド データ ウェアハウスです。BigQuery では、ストレージとコンピューティングを分けているため、それぞれの費用も分かれています。この投稿では、コンピューティング費用のみを扱います。
まず、BigQuery でのコンピューティングの課金方法について説明しましょう。BigQuery サンドボックスは完全に無料で利用できます。純粋な従量課金制モデルを使用する場合は、データのクエリに使用するコンピューティングに対してのみ支払います。この従量課金制モデルはオンデマンド料金とも呼ばれ、クエリがスキャンしたバイト数に基づいて課金されます。定額モデルでは、BigQuery サービスの専用リソースに対して毎月固定額を支払います。スキャンできるデータ量に制限はありません。
それぞれについてもう少し詳しく説明しましょう。
BigQuery サンドボックス
BigQuery サンドボックスは、Google Cloud Billing を設定していなくても、Google アカウントをお持ちであれば誰でも使用できます。つまり、いくつかの制限はありますが、完全に無料で利用できます。
BigQuery のオンデマンド料金モデル
BigQuery のオンデマンド モデルでは、すべての Google Cloud プロジェクトが最大 2,000 スロットを取得し、空き容量がある場合は、この上限を超えてバーストすることができます。スロットは BigQuery の演算能力の単位であり、クエリの実行時に動的にスケジュールされます。前述したように、クエリは実行時にデータをスキャンします。オンデマンド課金モデルでは、スキャンしたバイト数に基づいて課金されます。
BigQuery の定額料金モデル
定額モデルでは、予約するスロット数を決定し、そのリソースに対して毎月固定料金を支払います。スロットを分単位で予約するか、月単位で予約するか、または年間契約するかを選択できます。このモデルでは、スキャンしたバイト数に基づいて課金されることはありません。これはクエリし放題プランのようなものと考えてください。
状況に最適なプランを選択する方法いくつかのシナリオを見て、選択時に考慮する点について説明しましょう。各シナリオは関連していて、環境が段階的に複雑化していきます。
1. BigQuery を使い始めたばかりです。これからどのくらいクエリを実行するかわかりませんが、費用は効率化する必要があります。
2. BigQuery を使い始めてしばらく経ちました。データは増加しています。ビジネスでデータへのアクセスをより多く求める中、ますます多くの人がデータ ウェアハウスを使用するようになりました。コストを抑えながらこれに対処したいと考えています。
3. データサイロを 1 つのソースに統合して分析ワークロードを実現することや、Spark や Python を使用した高度な分析をサポートすることを検討しています。これに加えて、アドホック分析からビジネス インテリジェンスまで、さまざまなワークロードが混在する複数の業務部門をサポートする必要があります。このワークロードの中には、厳しいサービスレベル目標を定めたものもあれば、ベストエフォート型のサービスレベルを許容できるものもあります。
これらの各シナリオに取り組む方法を紹介します。
1. BigQuery を使い始めたばかりです。
BigQuery のオンデマンド モデルは、費用対効果を求めている場合に最適であり、使用した分だけを支払います。費用の最適化のベスト プラクティスに従って、カスタムの費用管理を利用した場合、使用した分だけに課金されると同時に、予期しない使用量の急増を防ぐことができます。
BigQuery の費用とパフォーマンスの最適化の方法はほぼ同じであるため（スキャンするデータを制限）、すばらしいことに、消費するリソースを可能な限り抑えながら、パフォーマンスも改善できます。
クエリを実行していないときには、オンデマンド スロットは即座にゼロにスケーリングされます。ノードをシャットダウンするために、行われるかわからない非アクティブ時のタイムアウトを待つ必要はありません。BigQuery はクエリを完了するために必要な数のリソースのみをスケジュールし、クエリが完了すると直ちに解放します。
初期段階で行うべき最も重要なことの 1 つは、BigQueryの使用量のモニタリングを設定することです。過去 180 日間のジョブのメタデータが INFORMATION_SCHEMA テーブルに保存され、それに対してクエリの実行やレポートの作成を行うことができます。また、スロット使用率などを把握するために、Cloud Monitoring に保存された BigQuery 指標も活用する必要があります。
2. BigQuery を使い始めてしばらく経ちました。
BigQuery の利用が増えるにつれて、スキャンするデータ量が増え、それに応じて費用も増加してきました。オンデマンド モデルを使用している場合は、費用を削減する機会を探っているかもしれません。1 つの選択肢は、BigQuery Reservations を検討することです。
まず理解しておきたいのが、BigQuery Reservations とオンデマンド料金モデルは相互に排他的ではないということです。どちらか一方を使用することも、必要に応じて組み合わせることも、あるいは Flex Slots の短期割り当てを使用して予約を試すこともできます。
Flex Slots とはFlex Slots は、最低 60 秒という短い時間単位で、データ ウェアハウスを素早く拡大、縮小します。Flex Slots を利用すれば、急激な分析需要の増大にも迅速に対応し、年末商戦やアプリの発売などのビジネス イベントに備えることができます。また、Flex Slots は、専用予約を短期間テストするのに最適な方法であり、スロット コミットメントが長い方がワークロードに適しているかどうかを判断するのに役立ちます。多くの企業では、分析ニーズが季節、月、時間単位によっても変化するため、必要に応じて Flex Slots を予約して、スロットプールに容量を追加できます。
また、料金モデルを組み合わせて、ワークロードによって使い分けることも検討してください。BigQuery を利用するワークロードがいくつかあるとしましょう。データを取り込んで、それを ELT スタイルで変換し、レポート作成とアドホック クエリの両方の使用に対応します。
アドホック ワークロードは、そもそも予測が困難です。ユーザーのデータ探索を制限せずに費用を抑えたい場合は、定額モデルを使用してクエリし放題の環境を提供することをおすすめします。
アドホック ワークロードの陰に対して、レポート作成ワークロードは陽のようなものです。アドホック クエリでは負荷の予測は難しいですが、それに比べてレポート作成ワークロードははるかに予測しやすいものです。通常、アドホック ワークロードにはベストエフォート型リソースが割り当てられますが、レポート作成ワークロードには厳しい SLA が適用される傾向があります。SLA が適用されるワークロードの場合は、それらにリソースを割り当てて、他のワークロードが割り込まないようにすると便利です。ここで登場するのが、BigQuery の予約によるワークロード管理です。ベストエフォート ベースでスロットプールからスロットを使用するようにプロジェクトを構成し、高 SLA のワークロード用にはスロットを予約しておくことができます。高 SLA のワークロードが予約分を消費していない場合は、予約されたスロットを他のワークロードとシームレスに共有できます。また、厳しい SLA が適用されたワークロードを実行する場合、BigQuery は他のそれほど重要ではないワークロードと共有されていたスロットを自動的にスムーズにプリエンプトします。
最終的には、毎日変換するデータの量をかなり予測できるようになるでしょう。つまり、ELT ジョブが毎日同じ量のデータを処理することがわかります。処理するバイト数は予測可能であるため、このワークロードはオンデマンド料金に適していると言えます。そのため、プロジェクトの ELT ワークロードは予約に割り当てず、オンデマンド リソースを使用して実行するとよいでしょう。スキャンしたバイト分だけ支払うだけでなく、状況に応じて、プロジェクトごとに割り当てられた通常の 2,000 スロットを超えてバーストすることもできます。
3. データサイロなどを統合しています。
つまり、複数のデータサイロから統合しているため、大量のワークロードがあります。上記の 2 番目のシナリオで説明した種類のワークロードに加えて、Spark や Jupyter を使用してデータレイクからデータを利用しているパワーユーザーやデータ サイエンティストがいます。彼らは BigQuery で引き続き同じことを行いたいと考えています。また、BigQuery ML を使用して ML モデルからバッチ推論を作成して取得する予定です。
上記のように料金モデルを組み合わせて使用することもできますが、定額料金にはBigQuery ML のすべての使用量と1 か月あたり 300 TB の Storage API の使用量も含まれています。そのため、Python（Jupyter、Pandas など）や Spark が使用されるデータ サイエンスや高度な分析では、スロット予約が割り当てられている Google Cloud プロジェクトでこれらのワークロードを実行することで、コストを節約できる場合があります。
すべてを組み合わせる
3 番目のシナリオのような状況にインフラストラクチャが成熟するまでは、費用対効果の目標を達成するために、以下の複数の料金体系を組み合わせて使用するとよいでしょう。
BigQuery Reservations: 費用を予測可能にし、SLA が適用されるワークロードに対して容量を保証します。
BigQuery Flex Slots: 追加の容量を必要とする周期的なワークロードや、短時間で大量のデータを処理する必要があるワークロードに使用します。このような場合、予約したスロットを使用して短時間で実行する方が低コストになります。
オンデマンド: 処理されるデータの量が予測可能なワークロードに使用します。バイト単位でスキャンされる課金モデルでは、コンピューティングの消費量として、スキャンしたデータの量によって使用分を正確に支払うという点で有利です。
予約または予約を無効にしたプロジェクトに合わせてワークロードを Google Cloud プロジェクトに配置できるのであれば、ワークロードごとに適切なリソースを選択できます詳細については BigQuery の料金モデルをご覧ください。
- By Vince Gonzalez, Specialist Customer Engineer, Data Analytics
