BigQuery のコスト最適化活動の全社展開用基盤を整えた話 [DeNA インフラ SRE]

はじめに

こんにちは。 IT 基盤部パブリッククラウドチームの中村です。

GCP の BigQuery は便利なサービスですが、使い方を誤ると簡単に高額請求されてしまうことがあるサービスでもあります。

この記事では、そんな BigQuery のガバナンスが効いた状態を維持する活動である BQ ドクターという取り組みを全社展開するための基盤を整備した話をご紹介します。

BQ ドクターとは

BQ ドクターは、下図のフローで継続的にデータのガバナンスを維持するための取り組みの総称で、以前からデータ本部で実施していました。

これまでの BQ ドクターについては、こちらをご覧ください。

BQ ドクターでは、具体的には以下のような活動をしていました。

テーブルの保存期間を設ける
定期的な中間集計やデータマートの整理
定期実行される SQL の改善

しかし、従来の BQ ドクターの取り組みには以下のような課題があり、その課題を解決するためデータ本部と IT 基盤部共同で BQ ドクターを拡張した取り組みを実施することになりました。

今回の取り組みでは、主に以下の課題の解決を目指しました。

データ本部管轄外の BQ はガバナンスが各プロジェクト依存になっている
- 権限管理のためにデータ本部が関われるプロジェクトは絞られていた
コスト監視や事故を防止する仕組みが確立されていない

この課題を解決するために、以下の対策を行いました。

データ本部管轄外も BQ ドクターの活動を行えるように全社的にデータを収集して BQ ドクター推進メンバー側で管理できる基盤を作る
コスト監視や BQ の課金上限を設定し事故を防ぐ

以降は、上記の対策の中で IT 基盤部が主に担当した対策についてご紹介します。

具体的なアクション

先述の対策の内、 IT 基盤部では以下の2つの対策をメインで実施しました。

データ本部管轄外も BQ ドクターの活動を行えるように全社的にデータを収集して BQ ドクター推進メンバー側で管理できる状態を作る
コスト監視や BQ の課金上限を設定し BQ 破産を防ぐ

データ本部担当箇所は一部省略されていますが、以下が今回作成したシステムの全体図です。

IT 基盤部は上図の文字と矢印が赤い部分を担当しました。

全社的な BQ のデータの収集と事故防止のために IT 基盤部で実施した対策の具体的な内容をご紹介します。

Cloud Logging を使って BQ のログを収集

データ本部管轄外の BQ に対しても BQ ドクターの活動を展開するためには、全社的に BQ の利用状況を知ることのできるデータを集める必要があります。

今回は Cloud Logging の Cloud Audit Logs と集約シンクを利用して、対象となるプロジェクトの BQ のクエリに関する監査ログを BQ ドクターのプロジェクトに集めました。

データの収集に Cloud Audit Logs と集約シンクを採用した理由は以下の通りです。

導入コストとメンテナンスコストが低い
BQ のメタデータよりも詳細に網羅されたデータを取得できる

Cloud Audit Logs は、「いつ誰がどこで何をしたか」という情報を持つ監査ログを保存できる仕組みです。各プロジェクトで BQ のクエリを実行すると、各プロジェクトのログバケットに監査ログが保存されます。このログには、実行したクエリや実行した結果どれくらいのデータを使用したか等の情報が含まれており、 BQ の利用状況を知ることができます。

しかし、先述の通り監査ログは各プロジェクトのログバケットに保存されるため、全社的に利用状況を知るためにはこのログを一箇所に集める必要があります。

そこで、 Cloud Logging の集約シンクという機能を利用することにしました。集約シンクを組織またはフォルダに設定することで、それらに属するプロジェクトのログを別の宛先にルーティングすることができます。

DeNA で利用している GCP のプロジェクトは基本的に DeNA の組織に所属しています。集約シンクは組織に設定することができるので、今回のようなケースでは組織に集約シンクを設定すると良いです。

しかし、組織に集約シンクを設定すると機密性が高くログを収集したくないプロジェクトも集約の対象になってしまいます。フィルタを設定することで除外することはできるのですが、この方法で除外するとフィルタの管理が必要になってしまいます。

フィルタを管理するのは大変なので、今回は Resource Manager のフォルダ機能を利用しました。具体的には、ログを収集しても良いプロジェクトとそうではないプロジェクトをフォルダで仕分けすることで、集約シンクのターゲットプロジェクトを設定することにしました。

以上の方法で集約シンクを設定したことで、効率的に約300プロジェクトの監査ログを収集することができました。

BQ クエリによる課金額の上限を設定

BQ ではクエリを実行した際のデータ使用量でも課金が発生します。このデータ使用量が大きくなるとそれだけ課金されてしまうため、一定の使用量を超えた場合にクエリを実行できなくするための Quota (割り当て)を設定することができます。

しかし、 BQ のクエリのデータ使用量を制限するための Quota のデフォルト値は無制限に設定されています。 Quota を適切な値に設定し直しているプロジェクト以外では、誤って大量のデータを扱うクエリを実行してしまったり、連続で大量にクエリを実行してしまう可能性があるということになります。

この状態では、事故が発生した際に被害が大きくなる危険性があるので、これから作成される新規プロジェクトと既存の全プロジェクトに Quota を設定することにしました。具体的には以下のような値に設定しました。

割り当て	設定値
Query usage per day	無制限 → 100TiB

データ使用量の上限を 100TiB に設定することで、もし事故が発生してもプロジェクト当たり約 $550 の被害で抑えることができます。(米国(マルチリージョン)の場合)

既存のプロジェクトに Quota を設定すると先述しましたが、 DeNA 組織下には既に大量のプロジェクトが存在しているので、一つ一つ設定することは困難です。

そこで、今回は以下のフローで Quota を設定しました。

クラウドアカウント台帳から GCP の全プロジェクトのプロジェクト ID を取得

gcloud cli を使って取得したプロジェクトの内、 Quota が無制限になっているプロジェクトを絞り込み

# Quota を取得
gcloud alpha services quota list \
  --service='bigquery.googleapis.com' \
  --consumer=projects/<PROJECT_ID> \
  --format json \
| jq '.[].consumerQuotaLimits[] | select( .metric == "bigquery.googleapis.com/quota/query/usage")'

絞り込んだプロジェクトに対して、 gcloud cli で Quota を設定

# Quota を設定
gcloud alpha services quota update \
  --service='bigquery.googleapis.com' \
  --consumer=projects/<PROJECT_ID> \
  --metric=bigquery.googleapis.com/quota/query/usage \
  --unit=1/d/{project} --value=<VALUE>

gcloud alpha services quota の詳細については、公式ドキュメントをご参照ください。

以上の方法で設定したことで、約700個の既存プロジェクトに Quota を設定することができました。