最初に、オンデマンドか容量課金かを確認
オンデマンドでは、クエリが処理するデータ量が費用の基準になります。容量ベースの課金では、スロットの計算容量を基準に考えます。ストレージなどの費用もあるため、BigQueryの請求合計をすべてクエリ費用として扱わないようにします。Google公式：費用の見積もりと管理
| 課金方式 | 最初に見るもの | 金額へのつながり |
|---|---|---|
| オンデマンド | 課金対象量、ジョブの頻度、無料枠や割引 | 課金対象量の差と実効単価から確認 |
| 容量ベース | エディション、予約・確約、稼働・自動スケールの設定と利用状況 | 処理の効率化後に、課金される容量や時間が変わるかを確認 |
単価や対象項目は契約・リージョン・エディションによって確認が必要です。この記事のために一律の円単価を当てはめることはしません。Google公式：BigQueryの料金
増えたのは、1回の処理量か、実行回数か
クラウドスリムでは、費用が増えたプロジェクトと時期を絞り、定期集計・BIからの参照・臨時の分析などの用途を確認します。似たクエリが何度も実行されている場合は、1回の最適化だけでなく、実行頻度や更新要件を見直す候補になります。
- どの処理か
- ジョブ、実行するサービス・担当、参照テーブル、更新先
- どのくらい使うか
- 実行回数、処理・課金対象量、実行時間、時間帯
- 何を守るか
- 更新期限、結果の一致、遅延到着データ、過去データの訂正
Googleのジョブ情報ビューでは、処理量や課金対象量などのメタデータを確認できます。アクセス権と対象リージョンを確かめて利用します。Google公式：ジョブ情報
LIMITを付けるだけで、料金が減るとは限らない
表示する行数を減らすことと、読み取るデータ量を減らすことは別です。非クラスタ化テーブルでは、LIMITを付けても読み取り量を減らせないと公式資料に説明されています。まず必要な列と期間を明確にし、実行前の見積もりを確認します。
オンデマンドでは、ドライランや処理バイト数の上限設定が確認に使えます。実行前の見積もりと、実際のジョブの課金対象量を区別して記録します。Google公式：クエリ費用の制御
パーティション分割したテーブルでは、条件が適切なら対象外のパーティションを読み取りから外せます。ただし、日付条件があれば必ず効くとは限りません。テーブルの分割方法と条件式を確かめます。Google公式：パーティションの絞り込み
定期集計は、全件更新が本当に必要かを調べる
毎晩、過去のすべてのデータを再集計しているなら、変化した期間だけを再計算する方法を検討できます。これはクラウドスリムで扱う改善案の一例です。実施できるかは、データの更新のされ方に依存します。
過去の訂正や遅れて到着するデータがあると、直近分だけでは集計結果を取りこぼすことがあります。「何日前まで更新されるか」「修正を検知できるか」を確かめ、新旧の集計結果が一致することを検証してから切り替えます。
削減見込み額と、確定した削減額を分ける
オンデマンドの試算では、改善後の課金対象量と実効単価を確認します。クエリ1回分だけでなく、月に何回動くか、無料枠や割引がどう適用されるかも揃えます。
容量ベースの課金では、処理量が減っただけの段階で、その割合を請求額に掛けません。予約や確約の条件、必要な容量、課金対象の時間が変わるかを確認して、費用に反映される範囲を説明します。
反映後も、データ量・ジョブ数・更新頻度の変化を確認します。クラウドスリムでは、原則として変更前後30日を比較し、今回の施策による削減額をお客様と合意します。
調査と実装に手が回らないときは
利用サービスと今の費用を入力すると、見直しの着眼点をメールで受け取れます。簡易診断にクラウドの閲覧権限やSQL本文は不要です。
詳細診断では、NDAとデータ利用範囲の合意後に、必要なジョブ情報・構成などを確認します。改善提案からPR、テスト・復旧手順、効果確認までを支援します。サービス全体の進め方を見る
この記事は費用を見直すための確認手順です。個別の構成・契約・性能要件によって、実施できる変更と効果は異なります。製品の仕様や価格は、本文中のGoogle公式資料で最新の内容をご確認ください。