既存SaaSにデータ分析基盤(DWH)を後付けする前に決めること

「今月の売上内訳を出してほしい」と頼まれるたびに、エンジニアが本番DBに直接SQLを書いて集計している——スタートアップやSMB向けSaaSでは、実はかなりよくある光景です。ダッシュボードと呼べるものはなく、Slackで依頼が来てSQLで返す、が分析の実態になっている。そのうち集計クエリが本番の負荷を上げ始め、「あの重いクエリのせいでアプリが固まった」という事故が起きて初めて、データ分析基盤(DWH)の話が持ち上がります。

この記事では、DWHを後付けする前に決めておくべきことと、「いきなり大掛かりにしない」ための段階の踏み方を整理します。着手前の基本的な確認観点は改善の最初の確認観点に、DB自体の負荷対策はDBボトルネックで遅いWebサービスの改善手順にまとめているので、あわせて参考にしてください。

なぜ「本番DBに直接クエリ」が問題なのか

症状は主に3つに分かれます。

• 本番アプリへの負荷波及: 集計クエリはOLTP(トランザクション処理)向けに設計されたスキーマ・インデックスと相性が悪く、大きなJOINや集計はテーブルロックや高いCPU負荷を招きます。月末の締め処理と経営会議向け集計が同時に走って本番が固まった、という事故は珍しくありません。
• 分析の属人化: SQLが書けるエンジニアだけがデータを見られる状態になり、PdMやセールスが「知りたいときにすぐ見られない」。依頼→待ち→回答のラグが意思決定を遅らせます。
• 横断分析ができない: プロダクトDBに加えて広告費(Google/Meta等)、CRM、決済(Stripe等)のデータを見比べたい場合、本番DBだけでは完結せず、結局手作業でスプレッドシートに転記することになります。

これらの症状が1つでも当てはまるなら着手を検討する価値はありますが、全部が同時に必要とは限らない点が重要です。次の章で判断軸を整理します。

決めること1: 何を分析したいのか(先に確定する)

DWH導入で最も多い失敗は、「とりあえずデータを全部溜めておけば後で何とかなる」という発想で着手し、結局誰も使わないダッシュボードだけが残ることです。着手前に次を言語化します。

• 誰が・どの頻度で・何を見て・何を判断するか。例:「経営陣が週次で、チャネル別のLTVとCACを見て広告予算配分を判断する」。この一文が言えないKPIは後回しにする
• 既存のBIツール(Looker Studio、Redash、Metabase等)で足りないのか、それともスプレッドシート集計の延長で十分なのか。DWHは「土台」であってゴールではなく、その上に載せるBI/可視化層とセットで初めて意味を持つ
• 分析対象が本当に本番DBのデータだけで完結するか。広告費・決済・CS問い合わせなど外部データソースとの結合が要るなら、そのソースごとに個別のETL/API連携が発生することを見積もりに織り込む

ここが曖昧なまま「BigQueryを入れましょう」という技術先行の話になると、後述する過剰投資に直結します。

決めること2: ETLかELTか、更新頻度はどれくらい必要か

ETL vs ELT

• ETL(Extract→Transform→Load): 抽出時にデータを整形してからDWHに入れる。変換ロジックが複雑になりがちで、変換基盤(Embulk、Fivetran、Airbyte等)の運用コストがかかる
• ELT(Extract→Load→Transform): 生データをまずDWHに入れ、DWH側(dbt等)で変換する。BigQuery/Snowflakeのような分析特化DBは大量データの変換処理が得意なため、近年はELTが主流

中小規模のSaaSであれば、まずはELTで「生データをそのままDWHにレプリケートし、必要な集計はDWH上のSQL(またはdbtのview)で組む」形が扱いやすく、変換ロジックの見直しもクエリを直すだけで済みます。

更新頻度は「意思決定のリズム」から逆算する

ここを技術的な最大値(リアルタイム)で考えるとコストが跳ね上がります。

• 週次の経営会議にしか使わないなら、日次バッチ更新で十分。夜間にDBのスナップショットを取ってDWHに反映すれば足りる
• 「今どれだけ売れているか」をリアルタイムで見たいダッシュボードが本当に必要か、それとも「昨日までの数字が朝見られれば十分」かを分けて考える。前者はCDC(Change Data Capture)や日中複数回のバッチが必要になり構成が一段複雑になり、コストも運用の手間も増える
• 実務上、リアルタイム性が本当に必要なケースは稀です。「なんとなくリアルタイムの方がかっこいい」ではなく、日次更新で意思決定が回るかをまず疑ってください

決めること3: 本番DBへの影響をどう避けるか

DWHへのデータ転送そのものが本番DBに新たな負荷源にならないよう、事前に経路を決めます。

• リードレプリカ経由で読む: 本番のプライマリDBに直接ETL/ELTジョブを向けず、リードレプリカ(読み取り専用の複製)から抽出する。多くのマネージドDB(RDS、Cloud SQL等)は数クリックでリードレプリカを追加できる
• 抽出のタイミングを分散させる: 深夜帯などアプリの負荷が低い時間帯にバッチを寄せる。日中に重い抽出クエリが走ると、結局「DWHのための負荷」が新たな障害要因になる
• 抽出クエリ自体の設計: 差分抽出(前回実行時刻以降の更新分のみ)にすることで、毎回全件スキャンする全量抽出より本番への負荷を大きく減らせる。テーブルにupdated_atのようなタイムスタンプカラムがない場合はここでスキーマ変更が必要になることもあり、事前の設計調査で発覚させておきたいポイントです

決めること4: コストをどう見積もるか

DWH自体のクエリ課金・ストレージ課金に加え、見落とされがちなコストがあります。

• BigQueryはクエリのスキャン量課金。パーティション分割やクラスタリングをせずに全期間スキャンするクエリを日次で回すと、想定より高額な請求になることがあります。設計段階で日付パーティションを切ることはほぼ必須です
• ETL/ELTツールのSaaS利用料(Fivetran等)は転送データ量やコネクタ数に応じて課金され、テーブル数が多いプロダクトでは想定より早く跳ね上がることがあります。テーブル数を絞る、または自前のバッチスクリプトで代替するかを比較検討する価値があります
• 運用の人的コスト: DWH・ETL・BIツールという3層の構成を維持するには、誰かが継続的に見る必要があります。専任の分析担当がいない組織で複雑な構成を組むと、数ヶ月後に「誰も触れない」状態になりがちです

小規模なSaaSであれば、月額のDWH+ETLコストは数千円〜数万円で収まることが多いですが、テーブル数やクエリ頻度が増えると数十万円規模になることもあります。「見たいものが週次バッチで足りるか」を先に決めておくことが最大のコスト最適化です。

いきなり大掛かりにしない: 段階を踏む

DWH導入は「全社データ基盤」という壮大な絵から入りがちですが、まず小さく始めて価値を確認してから拡張することを強く勧めます。

1. ステップ0: リードレプリカ + 直接SQL。DWHを入れる前に、まず集計クエリの向き先をリードレプリカに変えるだけで、本番負荷の問題は解決します。分析の属人化は残りますが、コストはほぼゼロで即日対応できます
2. ステップ1: シンプルな集計テーブル/マテリアライズドビュー。「よく聞かれる数字」を日次バッチでサマリーテーブルに集計し、それをBIツールや社内ダッシュボードから見られるようにする。既存のDB(PostgreSQL等)の中で完結させられるため、新しいインフラを増やさずに解決できるケースは意外と多い
3. ステップ2: 本格的なDWH導入。分析対象が複数のデータソースにまたがる、SQLを書けない人が自分でダッシュボードを組みたい、履歴データを長期保持して時系列分析したい——といったニーズが明確になった段階で、BigQuery/Redshift/SnowflakeとBIツールの組み合わせを検討する

多くの相談では、ステップ0または1で当面の課題は解決します。ステップ2まで一気に飛ぶのは、複数の分析ニーズが具体的に言語化できていて、かつ継続的に運用できる体制(専任担当か、外部の運用委託)がある場合に限るべきです。

外注する場合の進め方

外部に依頼する場合、いきなり実装フェーズから頼むと前述の「技術先行」に陥りがちです。

• 最初のフェーズは現状の分析ニーズのヒアリングと診断に絞る。誰が何を見たいか、既存DBのスキーマと負荷状況、更新頻度の要件を洗い出し、ステップ0〜2のどこから着手すべきかを判断材料として提示してもらう
• 実装フェーズに入る前に、ステップごとの見積もりと撤退可能性を確認する。ステップ1で十分だった場合にステップ2への追加投資をしない、という選択肢を外注先が提示してくれるかは、その会社が過剰投資を避ける姿勢を持っているかの指標になります。既存プロダクト改善・モダナイゼーション支援では、まさにこの診断フェーズから対応しています
• データベース技術の選定・チューニングは分析基盤に限らず本番側の設計とも直結するため、DWH単体でなく本番DBの構成もあわせて見てもらうと手戻りが少ない
• 運用開始後、誰が異常検知(ETLジョブの失敗、コスト急増)に気づく体制かを事前に決めておく。作って終わりではなく、数ヶ月〜半年単位で「本当に使われているか」を見直すタイミングを最初から握っておくと、無駄な運用コストの放置を防げます

まとめ

• 本番DBへの直接クエリは負荷と属人化の温床になるが、DWHは「土台」に過ぎず、分析目的・更新頻度・本番への影響回避・コストを先に決めないと過剰投資になる
• 更新頻度は意思決定のリズムから逆算し、多くの場合は日次バッチで十分。リアルタイム性は本当に必要かを疑う
• いきなり本格的なDWHに飛ばず、リードレプリカ経由の直接SQL→サマリーテーブル→DWH本格導入の順で、必要になった分だけ段階的に投資する

torcheeesでは、既存プロダクトのデータ分析基盤の現状診断から、必要最小限の構成での実装支援まで対応しています。診断でまず現状のボトルネックと投資すべき範囲を整理し、改善支援で実装まで伴走することも可能です。「本番DBが重い」「分析が属人化している」と感じたら、まずはお問い合わせからご相談ください。