hacomonoデータ基盤の進化

ウェルネス向けSaaSにおける1,000万人規模のイベントデータ基盤の現実と理想。

Transcript

1. hacomono データ基盤の進化 ウェルネス向けSaaS における1,000 万人規模の イベントデータ基盤の現実と理想 1
2. 自己紹介 矢嶋 裕介 VP of Platform Engineering 3 人の子供を抱える2 シーター乗り 2
6. hacomono データ基盤の歴史 6
7. hacomono データ基盤の歴史 Ver 0.1: BigQuery 基盤の誕生 Ver 1.0: 新BigQuery 基盤 Ver 2.0: 次世代アーキテクチャ 7
8. BigQuery 基盤の誕生 8
9. プロダクトエンジニアがノリと勢いで作成 9
10. BigQuery 基盤のアーキテクチャ Google Cloud AWS tenant1 AWS tenant2 定期実⾏ データ抽出 定期実⾏ データ抽出 データ転送 データ転送 RDS MySQ cron Rake Task RDS MySQ cron Rake Task BigQuery 10
11. Google Cloud AWS tenant1 AWS tenant2 定期実⾏ データ抽出 定期実⾏ データ抽出 データ転送 データ転送 RDS MySQ cron Rake Task RDS MySQ cron Rake Task BigQuery BigQuery 基盤のアーキテクチャ アプリケーション上で動くバッチプログラム cron による日次でのバッチ実行 Rake Task でデータ抽出 各テナントから直接BigQuery へデータ転送 11
12. BigQuery データ基盤 カスタマーサクセス プロダクトマネージャー プロダクトエンジニア いろんなところで使われだした カスタマーサクセス 顧客データの分析とレポート プロダクトマネージャー プロダクト機能の利用分析 プロダクトエンジニア プロダクトの障害調査 12
13. 順調にテナントが増えていった 2020 2021 2022 1000 900 800 700 600 500 400 300 200 100 13
14. そうすると・・・ 14
15. スケーラビリティの限界 1. 転送時間の肥大化 大きなテナントでは5 時間以上かかる 2. API レート制限の問題 テナント数増加に伴いテーブル数も増大しRate Limit に抵触 3. モニタリング不能 数千箇所で分散実行されるRake Task 4. データ品質の低下 Rate Limit 抵触やリソース不足によりバッチエラーが発生しデータが欠落 5. 業務への影響 データ品質の低下により各所の業務に影響が出始めた 15
16. 片手間での維持は限界、なんとかせねば 16
17. データエンジニアリングチームが誕生 （2023 年） 17
18. 新BigQuery 基盤 18
19. 新BigQuery 基盤のアーキテクチャ Google Cloud AWS DataLake Services Account B Account A Start rds:StartExportTask rds:StartExportTask Export to Export to Athena UNLOAD データ転送 RDS MySQ Aurora Cluster EventBridge Daily Schedule S3 Bucket Glue Catalog Step Functions BigQuery 19
20. Step Functions 20
21. 新BigQuery 基盤のアーキテクチャ 日次バッチ処理 ... Snapshot Export を実行 データ統合 ... 複数のAWS アカウントから1 箇所のS3 Bucket へ統合 PII 対応 ... 個人情報を排除してBigQuery へ転送 規模 ... 3,000 以上の論理データベース データ保持期間 ... 7 日間分のスナップショットを保持 セキュリティ ... S3 Bucket Policy を活用したクロスアカウントアクセスの実現 21
22. うまくいった... かに見えたが 22
23. 運用負荷 パイプラインの運用・監視が必要なため、データエンジニアの負担が増大。 日々のモニタリングとトラブルシューティングに時間を取られるように。 23
24. リカバリー時間の肥大化 失敗時の再実行に時間がかかる。 特に大規模なテナントでは復旧に半日以上かかることもある。 24
25. 実行頻度の制約 Aurora Cluster Snapshot Export の同時実行数に関するクオータが厳しく、実行速度を 上げられない。 鮮度の高いデータを取得することが困難。 25
26. スキーマ設計の問題 アプリケーションで付与したスキーマ名が悪く、フィルタ機能が利用できない。 Export 対象を絞り込むことができず、実行速度の改善が困難。 26
27. メタデータの欠如 アプリケーション開発時に各カラムのメタ情報を付与していないため、データの内容 を誰も把握していない状況。 収集したデータに何が含まれているのか不明で、活用が進まない。 27
28. 肥大化する要求 ️ リアルタイム分析 ️ プロダクト機能からのデータ利用 ️ 新規パイプラインの迅速な追加 ️ 利用規約との整合性 ️ 各国法律への準拠 ️ 高レベルの監査要件 ️ コストパフォーマンス ️ AI からの利活用 28
29. そもそも「新」とか「New 」とかつくアーキテクチャは必ず負債になる 29
30. 次世代基盤に求められるもの マルチプロダクト構想に耐えるアーキテクチャ AI を含むプロダクトからの利活用 データガバナンスの実現 「新」とか「New 」とか名前につけない 30
31. 突然ですが、 「FitFits はじめます」 31
32. FitFits とは hacomono が初めて提供するtoC プロダクト サブスク x 選び放題 詳しくはWEB で https://fitfits.hacomono.jp/ 32
33. toC プロダクトがSaaS ビジネスに加わるメリット 予算の拡大 ... エンドユーザーの行動分析が容易になる 分析結果の再利用 ... 分析結果をSaaS ビジネスでも利用できる 分析モデルの提供 ... 契約されている事業者様に有用な分析モデルを提供できる 33
34. データエンジニアリングに追い風が吹いてきた 34
35. Ver 2.0 の要件 すべてのデータをカタログ化（メタデータを管理） データメッシュを前提とした高いコストパフォーマンス アジリティの高いパイプライン構築 35
36. データカタログ 目的 hacomono が預かっているデータの目録化 データマート構築の基礎データ コストパフォーマンスの高いパイプライン構築 アプローチ カタログ化後、優先度に従ってパイプライン構築 データメッシュ化を前提としたメタデータ管理 36
37. データメッシュ プロダクトに近い場所での集計処理 レビューコメントなどをLLM によって事前分析 必要な時だけPull する仕組み 不要な転送を削減 37
38. データパイプライン アジリティ高くパイプラインを構築できるプラットフォームの実現 複数のPaaS 型データ基盤を検討 38
39. Ver 2.0 全体像 1. バッチ転送システム（Ver 1.0 改善版） 2. メタデータ管理サービス 3. データパイプラインプラットフォーム 39
40. 現在進行形で進めています 40
41. Ver 2.0 で実現する未来 41
42. プロダクト x データ データガバナンスの実現による安全性の担保 プラットフォームサービスと密接に関わったデータ基盤 hacomono Insight などのプロダクト機能の提供基盤 42
43. AI x データ AWS Bedrock を中心としたAI 基盤からのデータ利用 hacomono Insight へのAI 機能追加 レコメンドエンジンの実現 日本のウェルネスの可視化 43
44. Ver 0.1 2020~2022 Ver 1.0 2023~2025 Ver 2.0 2026~ まとめ Ver 0.1 ノリと勢いだけでは限界を迎えた Ver 1.0 プロダクト利用に向けて課題が見えてきた Ver 2.0 toC/toB ハイブリッドアーキテクチャへの 挑戦 44
45. We're Hiring! 世界のウェルネスを支えるデータ基盤を一緒に作りませんか？ https://www.hacomono.co.jp/recruit/engineer/ 45