BASE株式会社のBigQuery導入事例
BASE株式会社 / Shota Imazeki
メンバー / データエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
オンデマンド | 101名〜300名 | 2020年11月 | B to B B to C |
| 利用プラン | オンデマンド |
|---|---|
| ツールの利用規模 | 101名〜300名 |
| ツールの利用開始時期 | 2020年11月 |
| 事業形態 | B to B B to C |
アーキテクチャ

アーキテクチャの意図・工夫
抽出・加工基盤
本番環境のDBからは、レプリケーションされた分析用DBを経由してデータを取得しています。Embulkが分析用DBからデータを抽出し、BigQueryにロードしています。
AirflowがこのEmbulkジョブを含む各処理(抽出、ロード、BigQuery上でのデータ整形、Slack通知など)のオーケストレーションを一元管理しています。Airflowにより、ジョブのスケジュール管理・依存関係制御・リトライ・通知が自動化され、安定したデータ更新を実現しています。
ウェブ行動ログは、Google AnalyticsのBigQuery Export機能を利用し、自動的にBigQueryへ連携されるようになっています。
アプリ行動ログは、アプリからのイベントログをPub/Sub経由で受け取り、Dataflowを用いてBigQueryにStreaming Insertしています。
活用基盤
BIツールにはLookerを利用しており、主にダッシュボードでの可視化や、分析者が直接クエリを実行しての探索的分析が行われています。
大規模集計処理(例:ウェブ・アプリ行動ログ、長期間の注文情報などを利用した集計)はBigQuery側で実行し、結果を本番環境のDBに返すケースもあります。
日次の売上レポートやトリガー通知などはAirflow経由でSlackに通知され、運用・監視の自動化にも活用されています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
BASEは、個人やスモールチームが簡単にネットショップを開設・運営できるECプラットフォームを提供しています。サービスの成長に伴い、BigQuery導入前に既に開設数は100万ショップを突破しており(現在は240万ショップ超)、注文や配送、商品などの日々のEC運営に関わる膨大なデータが本番環境のDBに蓄積されています。
これらのデータはプロダクト改善や事業の意思決定のための分析に必要不可欠なものであり、チーム内では本番環境のDBからレプリケーションした分析用DBに対してクエリを実行し、分析を行っていました。しかし、分析用DBにはトランザクション処理向けのものを使っており、ショップ数とトランザクションデータの増加に伴って分析基盤の限界が顕在化してきました。
- クエリ実行時間の増大
- 大量データに対する集計クエリが数十分〜数時間かかるケースもあり、業務のボトルネックになっていました。
- 同時実行の制約
- 一部の重い分析クエリがリソースを専有し、他のユーザーのクエリ実行が滞る問題が頻発していました。
このように、データ量と分析ニーズの急増に対して、既存の既存のトランザクション処理向けDBではスピードとスケーラビリティの両立が難しくなっていたことが、BigQuery導入を検討するきっかけとなりました。
どのような状態を目指していたか
これらの課題を解消するために、私たちが目指していたのは「誰もがストレスなくデータを扱える分析基盤」でした。具体的には次のような状態です。
- 大規模データでも高速にクエリを実行できること
- 数十億レコード規模のデータに対しても、数秒〜数十秒で結果を返せるようにしたい。
- 複数人が同時に分析できる環境
- アナリストやエンジニアが同時にクエリを実行しても、お互いに影響を受けない環境を実現したい。
- スケールやメンテナンスを意識しない運用
- 分析基盤のリソース管理やチューニングに時間を割かず、プロダクト開発やデータ活用に集中できる状態にしたい。
比較検討したサービス
- Redshift
比較した軸
Redshiftも候補として比較検討しましたが、クラスター運用やスケーリングの手間を最小化したいという観点から、最終的にBigQueryを採用しました。 BigQueryはサーバーレスでスケーラブルなアーキテクチャに加えて、ストレージとコンピュートの分離によるコスト効率、クエリ最適化の自動化という点で当時のBASEの検討フェーズにマッチしていました。
選定理由
決め手となったのは、従量課金とサーバーレスという仕組みから、スモールスタートしやすいことでした。当時、分析基盤を段階的に整備していくフェーズにあり、サーバーレスで使った分だけ課金されるBigQueryのモデルが私たちの運用方針にマッチしていました。またチーム内での利用経験があったこともポイントの一つでした。
導入の成果
改善したかった課題はどれくらい解決されたか
BigQueryの導入によって、これまで抱えていた課題は大きく解消されました。
- 以前は数十分かかっていたクエリが、BigQueryでは数秒〜数十秒で完了するようになり、分析スピードが大幅に向上しました。
- サーバーレス基盤の恩恵により、複数人が同時に分析クエリを実行しても処理が滞ることはなくなりました。
- 今までは実行が難しかったテラバイト(TB)級の大規模データに対するクエリも問題なく扱えるようになり、分析の幅が大きく広がりました。
どのような成果が得られたか
これまでDB負荷を気にして慎重にクエリを実行していた状況から、誰もが安心して分析できる環境へと変わりました。 従量課金であるため実行量に応じたコスト管理は行っていますが、分析者が自由に試行錯誤できる環境が整ったことで、データ活用のスピードと自由度が格段に向上しました。
導入に向けた社内への説明
上長・チームへの説明
トランザクション処理向けのDBでの分析クエリ実行に時間がかかり、業務効率が下がっているという課題は、すでにチーム内でも認識されていました。 そのうえで、BigQueryを導入することでクエリ性能が大幅に改善できる見込みがあること、そしてサーバーレスかつ従量課金でスモールスタートが可能なため、初期コストや運用負荷を抑えながら導入できることを中心に説明しました。
活用方法
各チームの分析担当者が以下のような形でBigQueryを利用しています。
- KPI監視(ダッシュボード、Slack通知)
- 売上や注文数、ユーザー行動などの主要指標をダッシュボードで可視化し、Slack通知を通じて異常検知や日次レポートを自動で共有しています。
- 施策の効果検証
- 新機能リリースやキャンペーン施策の前後でデータを比較し、数値的な変化やユーザー行動の傾向を検証しています。
- データ分析業務
- 各チームがプロダクトや事業課題に応じてデータを探索・抽出し、プロダクト改善や意思決定に活用しています。
よく使う機能
- 分析クエリの実行、Lookerからのデータ読み込み
- スプレッドシートのBigQuery連携
- IAMによるコスト管理設定(Query usage per day, Query usage per day per userなど)
- INFORMATION_SCHEMA(JOBS_BY_PROJECTなど)を用いた利用状況の監視
- Gemini in BigQuery
ツールの良い点
- 大規模データでも高速にクエリを実行できる
- サーバーレスかつ従量課金でスモールスタートがしやすい
- Google AnalyticsやスプレッドシートなどのGoogle関連のサービスとの親和性が高い
ツールの課題点
- コスト管理設定について、プロジェクト単位での割り当て設定は可能だがアカウント単位などでの設定が難しい
- IAMロール(プロジェクトレベル)とBigQuery固有の権限(データセット/テーブルレベル)を組み合わせる場面があり、 権限管理の運用が煩雑化しやすい。
- 本番環境のDBがGCP以外にある時にクラウドを跨いだデータ連携方法を考える必要がある。
ツールを検討されている方へ
上述の通り、BigQueryは従量課金かつサーバーレスな仕組みでスモールスタートがしやすいのが大きな特徴です。初期構築の負担が少なく、必要なタイミングでスケールできるため、分析基盤を段階的に整備したいチームにも適しています。まずは小規模なデータセットから試してみて、クエリの実行感やコスト感を掴むところから始めるのがおすすめです。実際に触れてみることで、運用イメージや自社の課題に合うかどうかが具体的に見えてくるはずです。
BASE株式会社 / Shota Imazeki
メンバー / データエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名
よく見られているレビュー
BASE株式会社 / Shota Imazeki
メンバー / データエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


