BigQuery自動キャンセルで社内データ基盤のコスト最適化

1. はじめに

こんにちは。開発統括本部 データ基盤開発部の林 沛萱(リン ペイ シュェン)です。

私たち DMM グループでは社内向けにデータ分析を効率化するための基盤として「i3 データ基盤」を提供しています。「i3 データ基盤」という名称には、integration(統合)、insight(洞察)、intelligence(知見)の 3 つの意味が込められており、社内データを統合し、分析や意思決定に役立つ洞察を得ることを目的としています。

私たちデータ基盤開発部は、この i3 データ基盤を通じて、各事業部が保有するデータを BigQuery を中心に集約し、データ利用者が手軽に活用・分析できる環境を提供しています。

i3 データ基盤の概要

また、私たちは、この i3 データ基盤の利用状況を日々モニタリングし、快適で効率的なデータ分析環境の維持・改善に取り組んでいます。「データ利用のハードルをゼロにする」というビジョンのもと、誰もが安心してデータを活用できる仕組みづくりを進めています。

それでは、本題である「i3 データ基盤における BigQuery クエリ自動キャンセル機能」についてご紹介します。

2. 背景と目的

私たちが所属するデータ基盤開発部では、利用者が快適にデータ分析を行えるよう、BigQuery の利用動向を継続的に分析しています。その中で明らかになった課題が、想定外の高コストクエリが定期的に発生しているという点でした。

以前は、高コストクエリを検知した際に、該当ユーザーへ個別に連絡し、クエリの修正方法や今後の注意点を伝えるという運用をしていました。 しかし、この方法では人的リソースの負担が大きく、根本的な再発防止にはつながりませんでした。

過去の分析から、コストが異常に膨らんだケースの多くは、下記の原因であることが分かりました。

  • 参照テーブルの日付フィルタが不適切で、想定以上のデータ量をスキャンしてしまった
  • クエリ内の複雑な結合(JOIN)構文によって計算量が急増した
  • テストや一時的なアドホッククエリを誤って実行してしまった

特に、データ量の多いデータに対して日付の参照範囲を不適切に指定したクエリがスケジュール実行され続けるケースでは、継続的に大量のリソースを消費し、コストへの影響が非常に大きくなっていました。

このような背景から、リソース効率の向上と安定した利用環境の維持を目的として、コスト高騰につながるクエリを自動で検知・キャンセルする「BigQuery クエリ自動キャンセル機能」を開発しました。 今回は、その仕組みと運用の工夫についてご紹介します。

3. 機能概要

本機能は、i3 データ基盤における、データを分析しているデータ利用者が使用されている各 Google Cloud プロジェクトを対象に、3 分ごとに BigQuery 上の実行中クエリのジョブデータをスキャンします。 DAG 実行時点で、クエリのコストがおおよそ 30 ドルを超えている場合、そのクエリの実行を自動でキャンセルします。

以下の図では、本機能の概要で、Airflow DAG を中心にした自動キャンセル処理のフローを示しています。

本機能の概要

以下では、主な実装の要点を紹介します。

3.1 Airflow を中心にした実装

i3 データ基盤では、Airflow(Google Cloud Composer)を用いて、社内外のさまざまなデータを BigQuery 上に取り込んでいます。 もともと Airflow を活用したデータパイプラインの運用基盤が整備されていたため、本機能もその仕組みを活かして実装しました。

Airflow の採用により:

  • 既存の監視・通知基盤(Slack 連携など)との統合が容易
  • DAG のスケジュール管理による定期実行(3 分ごと)の実現
  • Cloud Run など新たな実行環境を立てる必要がなく、運用コストが発生しない

といった利点があります。

これにより、既存のワークフロー管理とシームレスに連携できるという点で、本機能は Airflow の DAG として実装されます。

3.2 キャンセル処理の流れ

以下の図は、本機能の全体的な処理の流れを表しています。
Airflow DAG がどのように BigQuery 上から実行しているクエリの情報を取得し、キャンセルや通知するかを俯瞰できます。

DAG のシーケンス図

大まかな処理の流れは以下の通りです。

  1. 3 分ごとに DAG が自動実行され、DAG は BigQuery 上で保存されている情報から、監視対象となる Google Cloud プロジェクトの一覧を取得します。

  2. 各プロジェクトに対して、並列処理でプロジェクトごとに BigQuery API を通じて実行中のクエリが消費したコストを取得します。

  3. 取得した実行中クエリのコストをチェックし、おおよそ 30 ドルを超えるクエリを高コストクエリとして判定します。

  4. 閾値を超えたクエリに対しては、BigQuery API に停止リクエストを送信し、クエリの実行をキャンセルします。

  5. キャンセルされたクエリ情報は Slack API 経由でリアルタイムに通知され、運用チーム全体およびクエリ実行者に共有します。

  6. プロジェクト内高コストクエリが存在しない場合は、ログ出力のみ行い、次の監視サイクルに移ります。

この一連の流れにより、コスト異常が発生しても即座に自動検知・対応が可能となり、 人手による監視や停止対応を行う必要がなくなりました。

3.3 キャンセル後の通知

キャンセルが発生すると、Slack 通知を通じてリアルタイムに関係者へ共有されます。 データ利用者が誤って重いクエリを実行してしまった場合も、通知をきっかけに自発的に報告するケースが増えています。 また、クエリの最適化に課題がある場合には、基盤運用チームへ相談できるフローを整備しています。

この仕組みにより、運用担当者と利用者の双方が即座に状況を把握でき、問題の早期発見と改善につながっています。

キャンセル後の通知

3.4 キャンセル除外対象

また、一時的に長時間クエリの実行が必要な場合には、申請によって実行許可を付与できる仕組みを設けています。免除ユーザー、免除期間の定義はすべて DAG の設定ファイルで一元管理されており、運用チームが柔軟かつ安全に制御できる設計になっています。

免除申請

4. 運用の成果

本機能の導入によって、高コストクエリの発生件数が大幅に減少しました。 導入前には 2 月に 34 件、3 月に 21 件の高コストクエリが発生していましたが、導入後は 7 月に 4 件、8 月に 14 件まで減少しています。 さらに、50 ドル以上の高額クエリは導入以降一度も発生しないようになりました。

また、従来は担当者が個別 DM で連絡していましたが、本機能の導入により、コスト閾値を超過したクエリは Slack 上で自動的に公開通知される仕組みに変更されました。

コスト閾値を超過したクエリの情報がチャンネル内で共有されることで、チーム全体に「無駄なコストを発生させない」という意識が自然と浸透しつつあります。

さらに、運用チームの手動監視負荷も大幅に軽減されました。 これまで人手で行っていたコスト確認やキャンセル判断の多くが自動化されたことで、より付加価値の高い改善業務にリソースを振り向けられるようになっています。

5. まとめ

「BigQuery クエリ自動キャンセル機能」は、BigQuery のコスト最適化を自動化し、運用負荷を大きく削減する仕組みです。 Airflow DAG による定期監視と Slack 通知の導入により、クエリの問題の早期検知と共有が可能になり、利用者のコスト意識も向上しています。

最後に、データ基盤開発部では、より良いデータ分析体験・データ活用体験を届けるために、ともに開発を推進してくれる心強い仲間を募集しています。
ご興味のある方は、ぜひ下記の募集ページをご覧ください!

dmm-corp.com