データ基盤の負債解消のためのリプレイス

https://livesense.connpass.com/event/333967/

Transcript

1. データ基盤の負債解消のためのリプレイス 2024.11.28 技術部データプラットフォームグループ 富⼠⾕康
2. • 株式会社リブセンス 技術部データプラットフォームグループ グループリーダー • 2018年⼊社 • 以来、推薦システムの改善、 データ基盤の開発、 マネジメントなどに取り組む 富⼠⾕ 康 (Fujitani Ko)
3. • ⼈材系を中⼼に複数のプロダクト • プロダクトは各事業部、データ基盤は横断部署で運⽤ リブセンスのプロダクトとデータ基盤
4. データ基盤、⼤きく分けて2つ プロダクト Redshift プロダクト 外部データ Livesense Analytics: データ分析（収集、蓄積） Livesense Brain: データ活用（推薦、機械学習） 22年〜大規模に刷新（中）
5. 22年末のLivesense Analytics ※ざっくり Beanstalk ソース Search Console Livesense Brain プロダクト 利⽤先 API Gateway SQS lambda Firehose EMR EC2 EventBridge Scheduler バックエンド オンプレ native app DB
6. • 同じようなことやるのに技術いろいろ 課題 処理 ⾔語 Beanstalk lambda EMR ワークフロー EventBridge Scheduler EC2 構成管理 Terraform CDK
7. • 同じ部署で別のクラウド ◦ 理由あったが⼤変 課題 Livesense Analytics Livesense Brain
8. • 開発体験が良くない ◦ ⼤きな変更‧モダン化も⼤変 ◦ リリース⼿順も様々 ◦ EOL対応も後⼿ 今までのデータ基盤
9. • データ‧事業の課題に集中できる環境 理想
10. • Google Analytics 4への移⾏ • BigQueryとSQLでの加⼯ • 技術スタック統⼀ ◦ GKE/Cloud Run/Argo Workflows/Python/FastAPI • 詳細は リブセンスの「10年物」のデータ基盤を作り変えている話 にも記載 リプレイスの主な取り組み
11. • There should be one-- and preferably only one --obvious way to do it. ◦ 何かをするのに、1つ‒‒理想的には1つだけの‒‒明確な⽅法があるべきだ (参考) • リプレイスで標準的な⽅法を構築 余談: Zen of Python
12. 25年初のLivesense Analytics ※予定 Livesense Brain プロダクト Cloud Run PubSub GKE CloudBuild CloudDeploy Cronitor CloudMonitoring Search Console Terraform バックエンド native app DB ※検証中 ※検証中
13. • ⼤きな改善に取り組みやすくなりつつある • SaaSのBigQuery連携も選択肢に ◦ GA4, fastly, Search Console ◦ データ追加の負担減‧よりリッチな情報 • 解きたい課題に集中できつつある リプレイスの結果
14. • Redash ◦ 利⽤者多‧クエリ多 ◦ データマート層を⼗分に拡充できてない ▪ やや複雑なクエリ - 利⽤者に負担 ▪ テーブル定義変更も容易でない • Redshift ◦ プロダクトはAWS。利点もあるが… ◦ BQ や Snowflakeのほうが機能充実 ◦ BQでデータソースからマートまで⼀貫したデータ⽣成したい まだ課題
15. 展望: 少し未来 Livesense Analytics Livesense Brain プロダクト Cloud Run PubSub Search Console GKE CloudBuild CloudDeploy Cronitor CloudMonitoring Terraform バックエンド native app DB
16. • アナリティクスエンジニアリングの強化（採⽤） • データを使った業務の改善 ◦ クエリ‧分析の質向上、脱スプレッドシート ◦ データソース改善 • BigQuery移⾏へ ◦ Redshiftのインスタンス変更（dc2->ra3）‧Redshift Spectrumやめる ◦ 各種準備‧実装 • 効果的な推薦‧検索‧機械学習モデルの実装 ◦ MLOps、使いやすいML/AI基盤 今後