はじめに
アソビューAdvent Calendar 2025の12日目（表面）です。
こんにちは。アソビューでデータエンジニアをしている山野です。
アソビューのデータ基盤ではこれまでBigQueryとSnowflakeの2つのDWHを利用してきましたが、
今秋よりデータ基盤をBigQueryに一本化しました。
今回はこの一本化をする上で起きた課題やどのようなステップで一本化を進めたのか共有したいと思います。
前提・背景
アソビューのデータ基盤のこれまでの変遷、そしてハイブリッド構成から一本化を決めた経緯などについては
以下のブログで書かせて頂きましたので、ご一読いただけますと幸いです。
このDWH一本化検証の結果、アソビューではBigQueryに一本化することとなりましたが、
実際に一本化をするにあたり以下の課題が存在しました。
1. データ基盤が利用するGoogle Cloudプロジェクトの役割や定義が不明確 2. 各プロジェクトやBigQueryの利用に対する権限が整理されていない 3. BigQueryのコスト管理の最適化ができていないため、一本化前よりDWHの利用コストがかかる可能性が高い
課題1. データ基盤が利用するGoogle Cloudプロジェクトの役割や定義が不明確
一本化前のデータ基盤関連のプロジェクトは以下3つのプロジェクトに分かれていました。
ですが実際はデータ変換処理以外のバッチやエンジニアによる開発・テスト作業で「データマート」用プロジェクトを利用していたり、 データサイエンティストが「BIツール」用プロジェクトを利用しているなど、 本来のプロジェクトの役割と実態が乖離している状態でした。
この状態で一本化を進めると、Snowflakeからの移管対象がどのプロジェクトを利用すれば良いか判断が難しくなります。
また仮にどれか適当なプロジェクトに接続させた場合、これまでBigQueryで稼働していた既存処理とSnowflakeから移管した処理が限られたリソースを取り合うことになります。
これにより、安定稼働している既存処理のパフォーマンスや安定性が低下し、業務影響を及ぼす懸念がありました。
課題2. 各プロジェクトやBigQueryの利用に対する権限が整理されていない
アソビューのデータ基盤は構築されてからまだ新しく発展途上の部分もあり、
例えばエンジニアがレイクやデータマートのデータを自由に操作できるなど過剰に権限が付与されており、データ管理の安全性に問題がありました。
またSnowflake側で管理していた一部データは特定社員のみ参照できる権限をかけていたものがあり、BigQuery移管にあたりこちらについても権限の整理が必要でした。
課題3. BigQueryのコスト管理の最適化ができていないため、一本化前よりDWHの利用コストがかかる可能性が高い
一本化前の弊社のBigQueryはデフォルトのオンデマンド課金モデルで契約・利用していました。
オンデマンド課金モデルの場合、データスキャン量ベースで利用コストが決まるため、データスキャン量を抑えたクエリの実装・実行が重要です。
一方でSnowflakeに接続していたBIツールやデータサイエンティストが実行するクエリは、SQLの理解度や利用用途の関係からデータスキャン量について考慮されていないものが多くありました。
弊社が元々Snowflakeを併用していたのは、 BigQueryのオンデマンド課金よりも、ウェアハウス（コンピュートリソース）の稼働時間でコストが決まるSnowflakeの方が、こうしたクエリの実行コスト効率が良かったためです。
よってこのSQLがSnowflakeからBigQueryにそのまま移管されると、多大なコストが発生する懸念がありました。
これらの課題の解決のため、以下のステップでDWH一本化を進めました。
一本化へ向けたステップ
ステップ1. ワークロード整理とプロジェクト再設計
まずプロジェクト構成を整理しなければ、権限設定やコストの最適化の設計もできません。
よって現行のデータ基盤に関連するプロジェクトが管理するデータや役割・ワークロードの整理を行い、
またDWHを一本化する上でアソビューで想定されるワークロードを洗い出しました。
この結果からプロジェクトを以下の構成に変更することと決めました。
最後のデータ基盤プロジェクト管理については後述します。
ステップ2. 各プロジェクトに対する権限の再設計
ステップ1で洗い出したワークロードと再設計したプロジェクトの内容から各ユーザー(ロール)のプロジェクト毎の権限を設計しました。
ポイントはレイク・データマートのプロジェクトに対して、管理権限保持者以外のユーザー(ロール)による更新操作をできなくしたこと。
またリソースの取り合いを避けるため、データエンジニアはBIプロジェクトから、
データアナリスト・サイエンティストはデータ分析 / 機械学習プロジェクトからのみBigQueryの実行できるように限定しました。
ステップ3. BigQuery Editions適用設計
課題3の解決策として実装クエリの修正も必要ではありますが、エンジニア以外のメンバーにパフォーマンスを意識したSQL実装をお願いするのは難しい面があります。
よって対応として、デフォルトのオンデマンド課金モデルから、コンピュートリソース使用量ベースの課金モデルであるBigQuery Editionsへの変更を決めました。
BigQuery EditionsはGoogleのドキュメントをはじめ、多くの記事で紹介されていますのでここで詳細な説明は割愛します。
BigQuery Editionsの特徴の一つとしてコンピューティングリソース(スロット)を事前に確保・管理するための予約という概念があります。 予約は各プロジェクト毎に作成と割り当てをすることもできますが弊社ではデータ基盤管理プロジェクトで予約の一元管理を行う方式を採用しました。
この構成はGoogleのドキュメントでも推奨されています。
また弊社のワークロードのうち、データ転送(レイク作成)やデータ変換(データマート作成)のように元々BigQueryで実行されていたものは過去実績から予約スロット数をある程度判断できますが、 一方でSnowflakeから移管するものについては予約するスロット数を判断することは難しいです。 よってプロジェクトに対する予約の割り当てを以下の方針に決めました。
具体的にはデータマート以外のプロジェクトについてはその上位のフォルダに対して予約スロットを割り当て、スロットを共有する形としました。
加えてもう一点、BigQuery Editionsにはベースライン・コミットメントの概念が存在しますが、
こちらについてはBigQueryに一本化後、ある程度運用を行い、その結果から設定を検討する想定のため、いずれのプロジェクトにも設定はしていません。
以下の図がその予約割り当て設定のイメージです。
以上のステップを行い、最終的にBigQueryの一本化運用を開始することができました。
BigQuery一本化運用開始後に起きた課題と今後の対応
BigQuery Editions適用によってプロジェクト単位のBigQueryのコストが見れなくなった
オンデマンド課金モデルの場合、プロジェクト単位にBigQueryの利用コストをGoogle Cloudの請求コンソールから参照することができました。
今回のBigQuery Editions適用で管理用プロジェクトで一元管理する形にしたことにより、利用コストが全て管理プロジェクトに計上される形になってしまいました。
運用する上でプロジェクト毎の利用コストがモニタリングできないと、各プロジェクトの割り当てるスロット数の調整やベースライン・コミットメントの必要可否が判断できません。
今後の対応として各プロジェクトのBigQueryのジョブ履歴の情報をもとにコストの集計・モニタリングする仕組みの開発を予定しています。一部のプロジェクトでEditions適用前よりもコストが増加
運用開始後、利用コストが以前のオンデマンド課金モデルよりもコストがかかっていることが分かりました。
原因として、データ変換のクエリがその複雑さからスロット利用量が高く、これによりオンデマンド課金モデルの時より利用コストが高くついてしまったことが原因でした。
こちらについては暫定の対応としてデータマートプロジェクトのみオンデマンド課金モデルに戻すことで解消しました。 今後については現行のデータ変換クエリやデータマートの構成を見直し、データ変換にかかるスロットの利用量の改善を行う予定です。
最後に
アソビュー株式会社では新しいメンバーを随時募集していますので、ご興味がある方はお気軽にカジュアル面談にご応募ください。
