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

Transcript

1. マルチプロダクトのデータ基盤設計 〜データメッシュへのリアーキテクチャで見えた課題と伸びしろ〜 TECH PLAY Data Conference 2024 #2 ファインディ株式会社 CTO 室データソリューションチーム / データエンジニア 開 功昂(hiracky16)
2. 自己紹介
3. 3
 自己紹介 Findy / データエンジニア 開 功昂 / Noriaki Hiraki / @hiracky16 • 2023 年 11 月にファインディの CTO 室データソ リューションチームにジョイン 🙌 • データエンジニアとしてマルチプロダクトのデータ基 盤を設計・開発を推進 • サッカー⚽とかポッドキャスト 🎙が好きです
4. 4
 事業紹介 エンジニア個人のキャリアや組織に関する領域を中心に複数のサービスを展開。 “挑戦するエンジニアのプラットフォーム”を掲げています。 正社員エンジニアの採用 8 万 人 のエンジニアと700 社 以 上 の テック企業をマッチング 
 フリーランスエンジニアの採用 全 国で働くリモートエンジニアとテッ ク企業をマッチング エンジニア組織の見える化 GitHubやJiraを解 析し、エンジニア組 織 の見える化と生産性向上をサポート 開発ツールのレビューサイト 
 データ基盤も含め様々なツールの選定理 由やレビューを掲載

5. 5
 • ファインディのデータ基盤と組織 • データメッシュへの移行理由と背景 • データメッシュへのリアーキテクチャ ◦ 分散型のデータアーキテクチャ ◦ データをプロダクトとして扱う ◦ セルフサービスのデータプラットフォーム ◦ フェデレーテッド・ガバナンス • 学んだ教訓とベストプラクティス • まとめ アジェンダ
6. ファインディの データ基盤と組織
7. 7
 ファインディのデータ基盤と組織 • データ基盤チームは 2023 年 7 月に発足 ◦ それまでは機械学習チームが BigQuery のお世話 ◦ 利用用途が多岐にわたり整備が追いつかずデータエンジニアを採用 • データ組織は横断型組織 • データ基盤は事業部付のデータアナリストや機械学習エンジニアが利用 • 複数事業部横断で 1 つの BigQuery にデータを蓄積
8. 8
 ファインディのデータ基盤
9. 9
 現行アーキテクチャの伸びしろ • データの取得部分がブラックボックス ◦ 後ほど GAS を経由して BigQuery へアクセスしていたことが判明 • データソースの変更に対する影響範囲が見積もれない ◦ データリネージが追えない • 権限管理ができていない • クエリの正確性が担保できていない • 検証環境がないため新規開発やアップデートが困難
10. データメッシュへの 移行理由と背景
11. 11
 データメッシュとは？ • ドメインごとに分散型のデータウェアハウスのアーキテクチャ • 従来の中央集権型と違い以下のようなメリットがある ◦ サイロ化されたデータウェアハウスの構築 ◦ 変更に対する柔軟性 ◦ コストの透明性 ◦ きめ細かい権限管理
12. 12
 • 採用理由 ◦ 事業やチームごとにアクセス権を管理できる設計 ◦ データ蓄積や利活用の幅をより柔軟に広げられる ◦ 事業ごとにデータの品質を高める活動に集中できる • 採用前の心配事 ◦ 事業部間の連携が遅くなりそう ▪ → 一旦できなくなるが別の方法で連携する ◦ データエンジニアが複数人必要 ▪ → 採用頑張る💪💪💪 データメッシュへの移行理由と背景
13. 13
 移行開始 1 年後のアーキテクチャ
14. データメッシュへの リアーキテクチャ
15. 15
 データメッシュに必要な 4 つの原則 • 分散型のデータアーキテクチャ ◦ 各ドメインチームがデータを所有・管理 • データをプロダクトとして扱う ◦ ユーザーのニーズに応える高品質なデータ提供 • セルフサービスのデータプラットフォーム ◦ 技術的な障壁を下げ、各チームが独立してデータ活用 • フェデレーテッド・ガバナンス ◦ 組織全体でのデータ標準とポリシーの策定・遵守
16. 16
 分散型のデータアーキテクチャ • “分散型のデータアーキテクチャ” を設計 • 弊社ではドメインを “事業” と捉え、Google Cloud のプロジェクト単位 でデータ基盤を作っていく
17. 17
 各ドメインチームがデータを所有・管理 • 事業ドメインに詳しいデータアナリストを募りデータオーナーとしてデー タ品質向上の活動を促す • 取り組みの一環として野良 SQL を dbt/Dataform 化するなどがある
18. 18
 責任分界点を定めて自立的した管理ができるようにする • レイヤーを使って責任分界点を定める • データチームはそれぞれのチームが自立してデータが見れるように支援 ◦ チームトポロジーで言う、ストリームアラインドとイネーブリングチーム の関係のイメージ
19. 19
 データメッシュに必要な 4 つの原則 • 分散型のデータアーキテクチャ ◦ 各ドメインチームがデータを所有・管理 • データをプロダクトとして扱う ◦ ユーザーのニーズに応える高品質なデータ提供 • セルフサービスのデータプラットフォーム ◦ 技術的な障壁を下げ、各チームが独立してデータ活用 • フェデレーテッド・ガバナンス ◦ 組織全体でのデータ標準とポリシーの策定・遵守
20. 20
 データ品質に対する取り組み • データソース側に対する取り組み ◦ テストはカバレッジが高めに設定 • SQL の品質担保 ◦ コーディング規約を作成 ◦ 一部 sqlfluff を導入して機械的に検知 • 事業サイドとモデリングの勉強会
21. 21
 他事業部へデータをプロダクトとして提供 • 共通で使えるカレンダーなどの社内マスタを整備 • Analytics Hub を使って Google Cloud 組織内で共有 ◦ カタログや公開したデータの使用回数が見れる
22. 22
 データメッシュに必要な 4 つの原則 • 分散型のデータアーキテクチャ ◦ 各ドメインチームがデータを所有・管理 • データをプロダクトとして扱う ◦ ユーザーのニーズに応える高品質なデータ提供 • セルフサービスのデータプラットフォーム ◦ 技術的な障壁を下げ、各チームが独立してデータ活用 • フェデレーテッド・ガバナンス ◦ 組織全体でのデータ標準とポリシーの策定・遵守
23. 23
 セルフサービスのデータプラットフォーム • BigQuery の UI を通してデータを見てもらう or Looker Studio やスプ レッドシートへ繋いで見る ◦ 定期的に見るものに関しては dbt or Dataform 化 • 各事業部でデータ基盤に必要なツールを導入 ◦ 組織事に微妙に事情が違うため ◦ データチーム側のキャッチアップが一定難しくなっている
24. 24
 データメッシュに必要な 4 つの原則 • 分散型のデータアーキテクチャ ◦ 各ドメインチームがデータを所有・管理 • データをプロダクトとして扱う ◦ ユーザーのニーズに応える高品質なデータ提供 • セルフサービスのデータプラットフォーム ◦ 技術的な障壁を下げ、各チームが独立してデータ活用 • フェデレーテッド・ガバナンス ◦ 組織全体でのデータ標準とポリシーの策定・遵守
25. 25
 フェデレーテッド・ガバナンス • IAM 管理や個人情報保護を組織で施行するためルールや運用を共通化 • PII に関しては制限と活用のバランスを見極めながら扱う範囲を議論 ◦ BigQuery Policy Tag と Cloud DLP を使って個人情報のマスキング を強化（テックブログ にて紹介）
26. 学んだ教訓と ベストプラクティス
27. 27
 コミュニケーションもリアーキテクトが必要 • 事業部サイドのアナリストやデータ活用者を巻き込むことが重要 ◦ データ利活用者がチームトポロジーのストリームアラインドチーム ◦ データエンジニアはイネーブリングチーム
28. 28
 成果を出しながらリアーキテクチャを進める • 成果を小出しに進めなければリアーキも持続可能ではない • データエンジニアがストリームアラインドとイネーブリングの間を行き来 する • 例えば Mart 作成や機械学習プロジェクトに関わる
29. 29
 Don’t Repeat Yourself • 事業ドメインが違うが技術選定やアーキテクチャは似ている • リソースに余裕があればプラットフォームチームがあるとよい ◦ インフラ構成は Terraform Private Module で共通化 ◦ データは Analytics Hub で組織全体に展開
30. 30
 “セルフサービス” をレベルアップし続ける • 「セルフサービス = BigQuery で SQL を実行する」の危険性 ◦ SQL にハードルがある人がいて利活用が広まらない ◦ SQL が書ける人が増えると一貫性の欠如 • 組織ごとやドメインによってセルフサービスの意味合いが違う ◦ ハードルを下げつつ、高品質で一貫性のあるサービスを模索し続ける
31. • データメッシュはデータエンジニアが必要 • 社内のメディアを使ってアウトプットし続ける • ファインディのイベント ◦ 時々データ系のイベントで公募もやっているのでぜひ！ • Findy Tools（ツールのレビューサイトで dbt や TROCCO などを掲載） ◦ （審査あり）誰でもレビュー投稿できます！ 31
 データエンジニアの採用に注力
32. まとめ
33. 33
 • データメッシュの 4 原則は抑えつつ設計は進めましょう ◦ データインフラだけでなく組織のアーキテクチャも変える • DRY に進めるために共通化が大切 • データプラットフォームのセルフサービス化は一長一短あるのでその時の 最適を求める • 採用したアーキテクチャによってはデータエンジニアの採用を頑張る必要 がある • データチームのアウトプット場として、ファインディのイベントや Tools へのレビュー寄稿はおすすめ まとめ
34. 複数プロダクト横断データ基盤を設計・開発しています！ 興味ある方はご応募、カジュアル面談お待ちしています→ データエンジニア 絶賛募集中です！！
35. ご清聴 ありがとうございました🙏