新しい料金モデルで BigQuery の物理ストレージの費用を削減

はじめに

※この投稿は米国時間 2023 年 9 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

BigQuery は、効率的な構造化照会言語（SQL）機能で知られる、スケーラブルなペタバイト規模のデータ ウェアハウスです。BigQuery は優れたパフォーマンスを提供しますが、クラウドベースのサービスにとって、費用の最適化は依然として重要な側面です。

このブログ投稿では、論理バイト ストレージ課金（Logical Bytes Storage Billing、LBSB）ではなく、新しく導入された物理バイト ストレージ課金（Physical Bytes Storage Billing、PBSB）を利用して BigQuery のストレージ費用を削減することに焦点を合わせます。PBSB は、2023 年 7 月 5 日から一般提供されています。Google は、ストレージ費用を最適化するためにこの機能を積極的に検討している組織と連携しています。

このブログ投稿では、お客様の支援について Google Cloud が Deloitte と積み重ねてきた広範な経験に基づいて、有用なインサイトと推奨事項を紹介し、BigQuery の実装をサポートするストレージを設計する際にお客様が PBSB モデルにスムーズに移行できるよう支援します。

設計上の課題

昨今のビジネス環境では、大規模な組織はペタバイト単位で測定されることも多い大量のデータを BigQuery データ ウェアハウスに蓄積しています。こうしたデータは、詳細なビジネス分析を実行し、貴重なインサイトを抽出するうえで非常に重要です。ただし、関連するストレージ費用が膨大になる可能性があり、中には年間数百万ドルを超える場合もあります。その結果、これらのストレージ費用を最小限に抑えることが、多くのお客様にとって課題となっています。

ソリューション

BigQuery でデータセットを作成する場合、ストレージ課金のデフォルトの消費単位は論理バイトです。しかし、物理バイト ストレージ課金が導入されたことで、お客様は物理バイトによる課金モデルを選択できるようになりました。この課金モデルを選択すると、お客様はデータのアクセス性やクエリのパフォーマンスを損なうことなく、物理バイトの圧縮機能によってもたらされる費用削減の利点を活用できます。

BigQuery データ ウェアハウスのストレージ費用が高額であるという課題に対処するために、Google は、新しく導入された物理バイト ストレージ課金オプションを活用するための 2 段階のアプローチを用意しています。

1 段階目のアプローチ: PBSB と LBSB を比較した BigQuery の費用便益評価を実施します。Google は、こちらのクエリを使用してデータセット レベルでの価格差を計算する方法例を提供しています。

上の例のクエリを実行すると、以下の表に示されている内容が出力されます。

この例では、1 番目のデータセットが、16～25 の範囲のアクティブかつ長期的な優れた圧縮率を示しています。その結果、ストレージ費用が 8 分の 1 に減り、月額で 70,058 ドルから 8,558 ドルに大幅に削減されています。

その一方で、このテストの 4 番目のデータセットでは、約 11 TB、すなわちタイムトラベル用のアクティブな物理ストレージ データのうち 96% が使用されています。これは PBSB には適していません。

評価中、10 MB の制限により CSV ファイルのダウンロードが妨げられる可能性がある「_session」行と「_scripts」行の存在を確認しました。「_session」オブジェクトは BigQuery セッションで生成された一時テーブルに対応しており、「_scripts」オブジェクトはストアド プロシージャまたは複数ステートメント クエリの一部として生成される中間オブジェクトに関係しています。こうしたオブジェクトは論理バイトに基づいて課金され、デベロッパー側で物理バイトに変換することはできません。この点に対処するには、次の句を使用してクエリを修正し、上述のオブジェクトを無視します。

where total_logical_bytes > 0 AND total_physical_bytes > 0 AND table_schema not like '_scripts%' AND table_schema not like '_session%'. [2, 7, 8]

2 段階目のアプローチ: 適合するデータセットの物理ストレージ課金に切り替えます。お客様は、自社の定額コミットメントがすべてアクティブでなくなるまで、物理ストレージ課金の対象にデータセットを登録できないことを覚えておく必要があります。

データセットの課金モデルを更新する最も簡単な方法は、BigQuery (bq) update コマンドを使用し、storage_billing_model フラグを PHYSICAL に設定することです。

例: bq update -d --storage_billing_model=PHYSICAL PROJECT_ID:DATASET_ID

データセットの課金モデルを変更した後、変更が有効になるまで 24 時間かかります。ストレージ費用を最適化する際に考慮すべきもう 1 つの要素は、タイムトラベルです。

タイムトラベルを使用すると、更新または削除されたデータのクエリ、削除されたテーブルの復元、または期限切れのテーブルの復元が可能になります。デフォルトのタイムトラベル ウィンドウは過去 7 日間を対象としており、bq コマンドライン ツールを使用して構成することで、ストレージ費用とデータ保持のニーズとのバランスを取ることができます。次に例を示します。

bq update --dataset=true --max_time_travel_hours=48 PROJECT_ID:DATASET_NAME

このコマンドでは、指定されたデータセットのタイムトラベル ウィンドウを 48 時間（2 日）に設定しています。

「--max_time_travel_hours の値は、48（2 日）～168（7 日）の範囲の 24 の倍数（48、72、96、120、144、168）にする必要があります。」[5]

考慮事項

物理ストレージ課金モデルに切り替える場合、いくつかの考慮事項があります。次の表に料金を示します。

上の表の料金リストに基づいて、お客様は次の点を考慮する必要があります。

• BigQuery ストレージ料金に基づくと、物理ストレージ課金の単価は論理ストレージ課金の単価の 2 倍になります。
• 圧縮率が 2 未満の場合、お客様は自社のデータセットについて PBSB の恩恵を受けられません。
• LBSB では、タイムトラベル ストレージに使用されたバイト数に課金は生じませんが、PBSB ではそのバイト数に課金が生じます。フェールセーフを使用する場合も同様です。
• 評価を正確なものにするには、BigQuery ワークロードが安定した状態に達し、予測可能なパターンを確立した後に、タイムトラベル ストレージ使用率の評価を実施することが推奨されます。タイムトラベル ストレージに使用されるバイト数は時間の経過とともに変化する可能性があるため、これは重要なことです。
• お客様は、ストレージ費用を考慮しながら、特定のデータ保持要件に沿ってタイムトラベル ウィンドウを柔軟に構成できます。たとえば、お客様はタイムトラベル ウィンドウをカスタマイズして、デフォルトの 7 日間から 2 日間などの短い期間に調整できます。
• 7 日間のフェールセーフ期間が適用され、その間はタイムトラベルの設定を変更できません。ただし、この期間が終了すると、お客様はご都合に応じて追加のタイムトラベル日数を柔軟に構成できるようになります。この構成可能な範囲は 2～7 日間に及ぶため、お客様は 9～14 日間にわたる効果的なタイムトラベル ウィンドウを確立できます。構成しなかった場合、タイムトラベル ウィンドウはデフォルトの 14 日間に設定されたままになります。
• 物理バイト ストレージの課金への切り替えは一方向の操作です。一度変更すると、お客様は論理バイト ストレージ課金に戻すことはできなくなります。

構築を始める

BigQuery の物理バイト ストレージ課金（PBSB）を採用すれば、BigQuery のストレージ費用を削減する大きな機会が得られます。費用対効果の高いこの課金モデルを評価し、これに移行するプロセスは簡便なものであるため、お客様はメリットを最大限に活用できます。Google は、評価の実施と PBSB モデルへのシームレスな移行に関する包括的なガイダンスを提供しています。今後のブログ投稿では、新しく導入された BigQuery エディションを活用して、コンピューティングの観点から BigQuery 分析費用をさらに最適化する方法について掘り下げていきます。費用の最適化までの道のりが生産的ものになり、成功裏に終えられることを祈っています。クラウドへの移行に関するサポートについては、こちらからいつでもお問い合わせください。

^{この記事の執筆にご協力くださった Dylan Myers（Google）、Enlai Wang 氏（Deloitte）に心より感謝いたします。}

ー エンタープライズ GSI、シニア パートナー エンジニア Schneider Larbi

ー Deloitte、シニア マネージャー兼チーフ アーキテクト Jonathan Zhuo 氏