マルチプロダクトのデータ基盤設計〜データメッシュへのリアーキテクチャで見えた課題と伸びしろ〜

Slide 1

Slide 1 text

マルチプロダクトのデータ基盤設計〜データメッシュへのリアーキテクチャで見えた課題と伸びしろ〜 TECH PLAY Data Conference 2024 #2 ファインディ株式会社 CTO 室データソリューションチーム / データエンジニア開功昂(hiracky16)

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

3  自己紹介 Findy / データエンジニア開功昂 / Noriaki Hiraki / @hiracky16 ● 2023 年 11 月にファインディの CTO 室データソリューションチームにジョイン 🙌 ● データエンジニアとしてマルチプロダクトのデータ基盤を設計・開発を推進 ● サッカー⚽とかポッドキャスト 🎙が好きです

Slide 4

Slide 4 text

4  事業紹介エンジニア個人のキャリアや組織に関する領域を中心に複数のサービスを展開。 “挑戦するエンジニアのプラットフォーム”を掲げています。正社員エンジニアの採用 8 万人のエンジニアと700 社以上のテック企業をマッチング   フリーランスエンジニアの採用全国で働くリモートエンジニアとテック企業をマッチングエンジニア組織の見える化 GitHubやJiraを解析し、エンジニア組織の見える化と生産性向上をサポート開発ツールのレビューサイト   データ基盤も含め様々なツールの選定理由やレビューを掲載 

Slide 5

Slide 5 text

5  ● ファインディのデータ基盤と組織 ● データメッシュへの移行理由と背景 ● データメッシュへのリアーキテクチャ ○ 分散型のデータアーキテクチャ ○ データをプロダクトとして扱う ○ セルフサービスのデータプラットフォーム ○ フェデレーテッド・ガバナンス ● 学んだ教訓とベストプラクティス ● まとめアジェンダ

Slide 6

Slide 6 text

ファインディのデータ基盤と組織

Slide 7

Slide 7 text

7  ファインディのデータ基盤と組織 ● データ基盤チームは 2023 年 7 月に発足 ○ それまでは機械学習チームが BigQuery のお世話 ○ 利用用途が多岐にわたり整備が追いつかずデータエンジニアを採用 ● データ組織は横断型組織 ● データ基盤は事業部付のデータアナリストや機械学習エンジニアが利用 ● 複数事業部横断で 1 つの BigQuery にデータを蓄積

Slide 8

Slide 8 text

8  ファインディのデータ基盤

Slide 9

Slide 9 text

9  現行アーキテクチャの伸びしろ ● データの取得部分がブラックボックス ○ 後ほど GAS を経由して BigQuery へアクセスしていたことが判明 ● データソースの変更に対する影響範囲が見積もれない ○ データリネージが追えない ● 権限管理ができていない ● クエリの正確性が担保できていない ● 検証環境がないため新規開発やアップデートが困難

Slide 10

Slide 10 text

データメッシュへの移行理由と背景

Slide 11

Slide 11 text

11  データメッシュとは？ ● ドメインごとに分散型のデータウェアハウスのアーキテクチャ ● 従来の中央集権型と違い以下のようなメリットがある ○ サイロ化されたデータウェアハウスの構築 ○ 変更に対する柔軟性 ○ コストの透明性 ○ きめ細かい権限管理

Slide 12

Slide 12 text

12  ● 採用理由 ○ 事業やチームごとにアクセス権を管理できる設計 ○ データ蓄積や利活用の幅をより柔軟に広げられる ○ 事業ごとにデータの品質を高める活動に集中できる ● 採用前の心配事 ○ 事業部間の連携が遅くなりそう ■ → 一旦できなくなるが別の方法で連携する ○ データエンジニアが複数人必要 ■ → 採用頑張る💪💪💪 データメッシュへの移行理由と背景

Slide 13

Slide 13 text

13  移行開始 1 年後のアーキテクチャ

Slide 14

Slide 14 text

データメッシュへのリアーキテクチャ

Slide 15

Slide 15 text

15  データメッシュに必要な 4 つの原則 ● 分散型のデータアーキテクチャ ○ 各ドメインチームがデータを所有・管理 ● データをプロダクトとして扱う ○ ユーザーのニーズに応える高品質なデータ提供 ● セルフサービスのデータプラットフォーム ○ 技術的な障壁を下げ、各チームが独立してデータ活用 ● フェデレーテッド・ガバナンス ○ 組織全体でのデータ標準とポリシーの策定・遵守

Slide 16

Slide 16 text

16  分散型のデータアーキテクチャ ● “分散型のデータアーキテクチャ” を設計 ● 弊社ではドメインを “事業” と捉え、Google Cloud のプロジェクト単位でデータ基盤を作っていく

Slide 17

Slide 17 text

17  各ドメインチームがデータを所有・管理 ● 事業ドメインに詳しいデータアナリストを募りデータオーナーとしてデータ品質向上の活動を促す ● 取り組みの一環として野良 SQL を dbt/Dataform 化するなどがある

Slide 18

Slide 18 text

18  責任分界点を定めて自立的した管理ができるようにする ● レイヤーを使って責任分界点を定める ● データチームはそれぞれのチームが自立してデータが見れるように支援 ○ チームトポロジーで言う、ストリームアラインドとイネーブリングチームの関係のイメージ

Slide 19

Slide 19 text

19  データメッシュに必要な 4 つの原則 ● 分散型のデータアーキテクチャ ○ 各ドメインチームがデータを所有・管理 ● データをプロダクトとして扱う ○ ユーザーのニーズに応える高品質なデータ提供 ● セルフサービスのデータプラットフォーム ○ 技術的な障壁を下げ、各チームが独立してデータ活用 ● フェデレーテッド・ガバナンス ○ 組織全体でのデータ標準とポリシーの策定・遵守

Slide 20

Slide 20 text

20  データ品質に対する取り組み ● データソース側に対する取り組み ○ テストはカバレッジが高めに設定 ● SQL の品質担保 ○ コーディング規約を作成 ○ 一部 sqlﬂuﬀ を導入して機械的に検知 ● 事業サイドとモデリングの勉強会

Slide 21

Slide 21 text

21  他事業部へデータをプロダクトとして提供 ● 共通で使えるカレンダーなどの社内マスタを整備 ● Analytics Hub を使って Google Cloud 組織内で共有 ○ カタログや公開したデータの使用回数が見れる

Slide 22

Slide 22 text

22  データメッシュに必要な 4 つの原則 ● 分散型のデータアーキテクチャ ○ 各ドメインチームがデータを所有・管理 ● データをプロダクトとして扱う ○ ユーザーのニーズに応える高品質なデータ提供 ● セルフサービスのデータプラットフォーム ○ 技術的な障壁を下げ、各チームが独立してデータ活用 ● フェデレーテッド・ガバナンス ○ 組織全体でのデータ標準とポリシーの策定・遵守

Slide 23

Slide 23 text

23  セルフサービスのデータプラットフォーム ● BigQuery の UI を通してデータを見てもらう or Looker Studio やスプレッドシートへ繋いで見る ○ 定期的に見るものに関しては dbt or Dataform 化 ● 各事業部でデータ基盤に必要なツールを導入 ○ 組織事に微妙に事情が違うため ○ データチーム側のキャッチアップが一定難しくなっている

Slide 24

Slide 24 text

24  データメッシュに必要な 4 つの原則 ● 分散型のデータアーキテクチャ ○ 各ドメインチームがデータを所有・管理 ● データをプロダクトとして扱う ○ ユーザーのニーズに応える高品質なデータ提供 ● セルフサービスのデータプラットフォーム ○ 技術的な障壁を下げ、各チームが独立してデータ活用 ● フェデレーテッド・ガバナンス ○ 組織全体でのデータ標準とポリシーの策定・遵守

Slide 25

Slide 25 text

25  フェデレーテッド・ガバナンス ● IAM 管理や個人情報保護を組織で施行するためルールや運用を共通化 ● PII に関しては制限と活用のバランスを見極めながら扱う範囲を議論 ○ BigQuery Policy Tag と Cloud DLP を使って個人情報のマスキングを強化（テックブログにて紹介）

Slide 26

Slide 26 text

学んだ教訓とベストプラクティス

Slide 27

Slide 27 text

27  コミュニケーションもリアーキテクトが必要 ● 事業部サイドのアナリストやデータ活用者を巻き込むことが重要 ○ データ利活用者がチームトポロジーのストリームアラインドチーム ○ データエンジニアはイネーブリングチーム

Slide 28

Slide 28 text

28  成果を出しながらリアーキテクチャを進める ● 成果を小出しに進めなければリアーキも持続可能ではない ● データエンジニアがストリームアラインドとイネーブリングの間を行き来する ● 例えば Mart 作成や機械学習プロジェクトに関わる

Slide 29

Slide 29 text

29  Don’t Repeat Yourself ● 事業ドメインが違うが技術選定やアーキテクチャは似ている ● リソースに余裕があればプラットフォームチームがあるとよい ○ インフラ構成は Terraform Private Module で共通化 ○ データは Analytics Hub で組織全体に展開

Slide 30

Slide 30 text

30  “セルフサービス” をレベルアップし続ける ● 「セルフサービス = BigQuery で SQL を実行する」の危険性 ○ SQL にハードルがある人がいて利活用が広まらない ○ SQL が書ける人が増えると一貫性の欠如 ● 組織ごとやドメインによってセルフサービスの意味合いが違う ○ ハードルを下げつつ、高品質で一貫性のあるサービスを模索し続ける

Slide 31

Slide 31 text

● データメッシュはデータエンジニアが必要 ● 社内のメディアを使ってアウトプットし続ける ● ファインディのイベント ○ 時々データ系のイベントで公募もやっているのでぜひ！ ● Findy Tools（ツールのレビューサイトで dbt や TROCCO などを掲載） ○ （審査あり）誰でもレビュー投稿できます！ 31  データエンジニアの採用に注力

Slide 32

Slide 32 text

まとめ

Slide 33

Slide 33 text

33  ● データメッシュの 4 原則は抑えつつ設計は進めましょう ○ データインフラだけでなく組織のアーキテクチャも変える ● DRY に進めるために共通化が大切 ● データプラットフォームのセルフサービス化は一長一短あるのでその時の最適を求める ● 採用したアーキテクチャによってはデータエンジニアの採用を頑張る必要がある ● データチームのアウトプット場として、ファインディのイベントや Tools へのレビュー寄稿はおすすめまとめ

Slide 34

Slide 34 text

複数プロダクト横断データ基盤を設計・開発しています！興味ある方はご応募、カジュアル面談お待ちしています→ データエンジニア絶賛募集中です！！

Slide 35

Slide 35 text

ご清聴ありがとうございました🙏