デリッシュキッチンのBigQuery導入事例
株式会社エブリー / Hayato Tsukada
テックリード / バックエンドエンジニア
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
スタンダードプラン | FirebaseおよびGA4のエクスポート先 | 11名〜50名 | 2018年7月 | B to B B to C |
| 利用プラン | スタンダードプラン |
|---|---|
| 利用機能 | FirebaseおよびGA4のエクスポート先 |
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2018年7月 |
| 事業形態 | B to B B to C |
アーキテクチャ

アーキテクチャの意図・工夫
メインのデータ基盤としてはDatabricksを採用していますが、Google Cloud経由で取得するログデータの蓄積先としてBigQueryを利用しています。Firebase連携で自動的にBigQueryへデータがエクスポートされる仕組みを活かし、追加の転送基盤を構築することなくシンプルな構成を維持しています。
ポイントとしては、メインのデータ基盤(Databricks/AWS)とGoogle Cloudのマネージドサービスを目的に応じて使い分けている点です。BigQueryにはFirebase経由のログデータ蓄積と分析を担わせることで、それぞれのプラットフォームの強みを活かしたハイブリッドな構成としています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
Google Analytics for Firebaseで収集したアプリのユーザー行動データを、ファーストパーティデータと組み合わせてより柔軟かつ詳細に分析したいというニーズがありました。Firebase単体の分析機能では対応しきれない、カスタムクエリによる深掘り分析やデータの長期保存が求められていました。
どのような状態を目指していたか
BigQuery導入にあたり、以下のような状態を実現することをゴールとして設定していました。
- ファーストパーティデータとの統合分析が自由にできる状態: Firebase単体の分析機能に閉じず、自社の会員データや行動データとユーザー行動ログを掛け合わせ、SQLベースで自由に深掘り分析ができる環境
- データ連携に運用工数がかからない状態: ログデータの収集・蓄積において追加のETLパイプラインの構築・保守を必要とせず、データエンジニアが分析基盤の改善やコスト最適化に注力できる体制
- メインデータ基盤との役割分担が明確な状態: Databricks(AWS)とBigQuery(Google Cloud)の用途・データの所在が整理され、チーム内で迷いなくデータにアクセスできるルールが確立されている状態
- コストが予測・コントロール可能な状態: データ量の増加に対してストレージ・クエリコストの可視化と最適化の仕組みがあり、スケーラブルに運用できる状態
比較した軸
BigQueryの導入に関しては、Google Analytics for Firebaseとのネイティブ連携が決め手でした。FirebaseのデータエクスポートはBigQueryと直接統合されており、追加のETLパイプラインを構築する必要がありません。Firebase連携というユースケースにおいてはBigQueryが唯一のネイティブ連携先であり、他のDWHサービスと比較するまでもなく、最適なサービスとしてBigQueryを選定しました。
選定理由
- Firebaseとのシームレスな連携: 設定のみでデータエクスポートが完了し、運用負荷が極めて低い
- サーバーレスアーキテクチャ: インフラ管理が不要で、データエンジニアが分析基盤の構築・最適化に集中できる
- SQLベースの分析: 標準SQLで柔軟なクエリが記述でき、チーム内での知見共有がしやすい
- Google Cloudエコシステムとの親和性: Looker Studioなどの可視化ツールとの連携が容易
導入の成果
改善したかった課題はどれくらい解決されたか
BigQuery導入により、Firebase経由のユーザー行動データをSQLで自由に分析できる環境が整いました。
どのような成果が得られたか
特に大きな成果として、ストレージコストの最適化が挙げられます。データ量の増加に伴いストレージコストが課題となっていましたが、INFORMATION_SCHEMA.TABLE_STORAGE_BY_PROJECTを活用した詳細な分析を行い、論理バイトストレージから物理バイトストレージ課金への切り替えを実施しました。BigQueryの圧縮率が高いため、物理バイト課金の単価増を圧縮率が上回り、結果として大幅なコスト削減を達成しています。
このように、導入後も継続的にコスト最適化に取り組むことで、データ量が増加してもコストを適切にコントロールできる体制を構築しています。
導入時の苦労・悩み
メインのデータ基盤(Databricks/AWS)とBigQuery(Google Cloud)を併用する構成のため、データの所在や用途のすみ分けを明確にする必要がありました。
また、BigQueryのストレージコストについては、データ量が増えるにつれて課題として顕在化しました。課金モデル(論理バイト vs 物理バイト)の違いを正しく理解し、自社データの圧縮率を実測したうえで最適な選択をするためには、INFORMATION_SCHEMAを活用した詳細な調査が必要でした。
導入に向けた社内への説明
上長・チームへの説明
Google Analytics for Firebaseのデータ連携先としてBigQueryを利用する構成は、Googleが公式に提供している連携パスであり、技術的な妥当性の説明はスムーズでした。既存のデータ基盤(Databricks)との役割分担を明確にしたうえで、各チームに共通したフローとして整備することができました。
活用方法
それぞれの事業KPIを見るためにダッシュボードを作成し、その参照先として各種イベントデータを活用しています。
よく使う機能
- INFORMATION_SCHEMA: テーブルのストレージ使用量やコスト分析に活用。プロジェクト全体のデータ量・コストの可視化に不可欠
- 標準SQL: Firebase経由のユーザー行動データに対する集計・分析クエリの実行
- 物理バイトストレージ課金: 高い圧縮率を活かしたコスト最適化
- Firebase連携エクスポート: Google Analytics for Firebaseからの自動データ連携
ツールの良い点
- Firebaseとの連携が非常に簡単: 設定だけでデータが自動連携され、ETLパイプラインの構築・保守が不要
- コスト最適化の選択肢が豊富: 物理バイト課金への切り替えやパーティショニングなど、データ特性に合わせた最適化手段が用意されている
- INFORMATION_SCHEMAによるセルフサービス分析: コストやデータ量を自分たちで可視化・分析できるため、課題の早期発見と対応が可能
- サーバーレスで運用負荷が低い: インフラの管理が不要で、少人数のチームでも無理なく運用できる
ツールの課題点
- ストレージコストの管理に注意が必要: データ量が増加するとコストも増えるため、定期的な棚卸しと課金モデルの見直しが重要。デフォルトの論理バイト課金のままだと、圧縮効率を活かせずコストが割高になるケースがある
- 複数クラウド環境での管理: メインの基盤が別プラットフォーム(AWS/Databricks)にある場合、データの所在やアクセス権限の管理が複雑になりがち
- クエリコストの予測が難しい場合がある: オンデマンド課金ではクエリのスキャン量によってコストが変動するため、大規模なアドホッククエリ実行時にはコストの意識が必要
株式会社エブリー / Hayato Tsukada
テックリード / バックエンドエンジニア
よく見られているレビュー
株式会社エブリー / Hayato Tsukada
テックリード / バックエンドエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


