株式会社イノベーションのデータ基盤アーキテクチャ

1. はじめに

この記事では、私たち株式会社イノベーションが構築・運用しているデータ基盤のアーキテクチャについて、設計の背景や意図、そして実際の運用で工夫している点をご紹介します。

2. アーキテクチャ設計の背景

• 複数のプロダクトを展開しており、事業横断でのデータ活用が必要
• 「属人化せずに、安定した運用ができる基盤」を目指す必要がある
• Salesforceや広告媒体、プロダクトDBなど多様なソースからのデータ連携の必要がある
• 分析だけでなく、プロダクト改善や営業施策にもつながる「信頼できる一元データ」の整備が急務

3. アーキテクチャ全体像と目的

この構成は、以下のような目的を持って設計されています。

3.1 Big Queryを採用した理由

スケーラブルでサーバーレス、クエリ性能も高いため、データ基盤の中心にBigQueryを選定しました。

• bq load を使用した理由
  • CSV/スプレッドシートなど、多様なデータソースからの軽量なロードに適している
• 3層構造を採用した理由
  • データレイク(stg)、データウェアハウス(dwh)、データマート(dm)のレイヤー分けにより、変換ロジックの内容の分離や再利用性、デバッグ性を高められる
  • データレイクの導入により、元データの保持が可能になり、過去データとの比較や変化の分析が容易
• Dataform 採用の理由
  • SQL 基本でロジックを管理しつつ Git 管理により変更履歴の追跡、コードレビューが可能
  • レイヤー決めや命名ルールを通じた協業により属人化を防ぐ
  • 自動リネージ生成により、データの統合管理も効率化

3.2 Composer を使用している理由

• Airflow 基盤であり、スケジュール管理や再起動性が確保できる
• フルマネージドなため、インフラやパッチ管理などの負担が少ない
• GCS, BigQuery, Dataform などとの連携性が高い

3.3 GCP関連のIaC化

• Terraform を利用して、利用するアカウントやサービスの安定配置を行っている
• GCPに対する設定を可視化し、レビューの策定が可能

3.4 データ連携の標準化と非エンジニア化

• Autoro や Composer (Airflow) を使用して、全てのデータ連携を実行
• Google Drive や スプレッドシート などの非実装的な連携元についても、定型化フローを立てて定期実行を可能に

4. 実際に運用してみての気づき・工夫

日々の運用を通じて見えてきた改善点や、継続的に工夫しているポイントを以下にまとめます。

• テーブルのスキーマ変更への対応

  • schema drift (小さなカラム追加/削除)を見逃さないよう、schema check をロジック化

• データカタログの作成

  • IF定義書を可視化することで、内部データの利用効率化
  • アナリストが必要なスキーマを自動で引ける環境を構築

• コスト監視の実施

  利用実態の可視化を目的に、事業部単位でのモニタリングを実施

  • プロジェクトやラベル単位でのコスト集計を行い、部門ごとの利用量を定期レビュー

• Autoro 活用による、人を含んだ自動化

  • すべてを完全自動化できない場合に、人が関与するステップを少なくして定型化

• Airflow 前処理の工夫

  • スプレッドシート連携におけるエンコード変換/フォーマット乱れを補正

• 命名親和性やレイヤー分けの統一

  • Dataform での命名親和性やレイヤー分けをチーム内で統一することで、開発の属人化を防止

5. 今後の展望

今後さらにデータ基盤を活用しやすくするために、以下のような強化施策を検討しています。

• ML・分析基盤の強化
• よりリアルタイム性の高いデータ連携の仕組みを検討（Cloud Run Jobs など）
• データカタログやリネージの可視化など、「使いやすい基盤」の方向へ強化
• プロダクトや営業チームとの共創による、さらなるデータ活用の文化づくり

6. おわりに

私たちのデータ基盤はまだ成長途中ですが、「使われること」を第一に考えた設計と運用を意識しています。
この記事が、これからデータ基盤を構築される方や、運用中のチームの参考になれば幸いです。