リクルート流データ基盤塾～鶴谷と学ぶ～

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© Recruit Co., Ltd. All Rights Reserved 自己紹介株式会社リクルート　データ推進室データエンジニアリング部　部長所属 2005/04 証券系SIer入社 2015/05 キャリア採用入社(リクルートID分析基盤担当) 2018/04 リクルートIDデータ基盤担当GM 2020/04 住まいデータ基盤担当GM 2022/04 旅行・飲食・美容・SaaSデータ基盤担当GM データエンジニアリング部部長 2022/09 検索基盤担当GM 経歴 4 鶴谷　誠文 Masafumi Tsurutani

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© Recruit Co., Ltd. All Rights Reserved リクルートのビジネスモデルについて 6 ● リクルートにはユーザーとクライアントという2つのお客様が存在 ● 「企業と人（B to C）」「企業と企業（B to B）」「人と人（C to C）」の間に立ち、双方にとって最適なマッチングを図る「場」を提供ユーザーとクライアントを新しい接点で結び、「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」の場を創造するリクルートマッチングプラットフォームクライアントとユーザーを結びつける対価としてクライアントからフィーを受領ユーザークライアント

Slide 7

Slide 7 text

© Recruit Co., Ltd. All Rights Reserved データ推進室について 7 z 職種・機能単位プロダクト単位アジリティテクノロジー部データソリューションユニットデータテクノロジーユニット HR 結婚旅行自動車学習飲食美容住宅 SaaS 横断データプロダクトマネジメント1部データプロダクトマネジメント2部データプロダクトマネジメント3部データサイエンス・機械学習エンジニアリング部データエンジニアリング部データマネジメント部採用・育成による専門性強化に責任を持つプロダクト戦略の実現のための活動に責任を持つより高度な専門性を基に領域・横断の重要案件の支援を行うデータテクノロジーラボ部室直下アドバンスドテクノロジーラボ部イノベーティブテクノロジー研究戦略部各事業領域のデータ戦略立案・推進を行う領域特化ユニットと領域横断で支援を行う専門職種のユニットが交差するマトリクス型組織

Slide 8

Slide 8 text

© Recruit Co., Ltd. All Rights Reserved 登壇者紹介 8 DTU DPM1部 DPM2部 DTL部 Megago n ATL部事業横断の機能に責任を持つ販促1 DSU (住まい) 販促2 DSU (結婚旅行自動車) 販促3 DSU (飲食美容) 販促4 DSU (まなび) SaaS DSU HR DSU 各事業領域戦略の実現のための活動に責任を持つ芳賀宣仁（はがのぶひと）阿部誠也（あべまさや）川合真大（かわいまさひろ）

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© Recruit Co., Ltd. All Rights Reserved リクルートのデータ基盤の特徴 ● 事業領域単位でデータ基盤を構築することで事業の要件・スピード感に柔軟に対応 ● 一方で領域横断で利用できるプロダクト・プラットフォームを整備して適材適所で導入することでシステムの垂直立ち上げを実現するとともに車輪の再発明を防ぐ 10 環境面販促1 DSU (住まい) 販促2 DSU (結婚旅行自動車) 販促3 DSU (飲食美容) 販促4 DSU (まなび) SaaS DSU HR DSU DTU ワークフロー実行基盤ターゲティングリスト抽出基盤・・・各事業領域で利用する・しないを選択

Slide 11

Slide 11 text

© Recruit Co., Ltd. All Rights Reserved リクルートのデータ基盤の特徴（続き） ● パブリッククラウド（Google Cloud、AWS）を適材適所で使い分ける ● データウェアハウスやパイプラインだけでなく、レコメンド基盤や検索基盤、BIツール、RAGシステムなどの開発も行う 11 技術面＜データ基盤の構成例＞専用線  Webサービス、事業システムのDB ETL処理 BigQuery BIツール RAGシステム Webサービスのフロントレコメンド基盤検索基盤ストリーミングパイプライン基盤カスタマー社内利用者（ワークフロー実行基盤）（ターゲティングリスト抽出基盤）

Slide 12

Slide 12 text

© Recruit Co., Ltd. All Rights Reserved ● ノウハウやナレッジ流通のためのデータ室ALLの共有会 ex.)AlloyDB検索基盤技術検証、Databricksモデルサービング技術検証 ● 品質担保のためのSP（シニアプロフェッショナル）・GM陣によるレビュー会 ex.)オンライン推論リファクタリングのアーキテクチャレビュー ● 社内標準Githubでのソース共有やコンフルでの設計情報共有リクルートのデータ基盤の進化の秘訣 12 仕組み面参考）AlloyDBの技術検証資料参考）オンライン推論リファクタリングの設計資料参考）社内認証基盤連携の開発事例

Slide 13

Slide 13 text

© Recruit Co., Ltd. All Rights Reserved 住まい領域でカオスエンジニアリングベースの障害訓練実施コンフルで実際に使った障害訓練の資料や振り返りを共有ノウハウ活用して他の領域でも障害訓練を実施リクルートのデータ基盤の進化の秘訣（続き） 13 ● 各グループがボトムアップでPoCや技術検証に取り組む ● 他組織の成功／失敗事例を活用することで基盤の高度化や技術的負債解消を推進 ● timesや勉強会などでのメンバー間での繋がりによる情報共有文化面 URL:https://speakerdeck.com/recruitengineers/developerssummit ＜具体例＞

Slide 14

Slide 14 text

© Recruit Co., Ltd. All Rights Reserved リクルートのデータエンジニアの育成の仕組み 14 ● マネージメントトラックとスペシャリストトラックのキャリアパスの整備 ● 室横断での中途採用オンボーディングやキックオフにより事業領域内の繋がりだけでなく、領域を跨いだ繋がりを創出 ● 室横断での人材育成を起点とした案件アサイン人事面 ● クラウド環境勉強制度（AWS、Google Cloud）を使った専用環境でのクラウド技術自己研鑽 ● Github Copilot Businessの利用環境を整備 ● 各領域でテックリードによるアーキテクチャレビューの実施環境面

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© Recruit Co., Ltd. All Rights Reserved 不動産マッチングプラットフォーム SUUMOとは 17 家を探しているユーザ不動産事業クライアントユーザとクライアント双方にとって最適なマッチングを生み出す「場」を提供進学に伴って一人暮らしを始めたい家族が増えたのでマンションか戸建てを買いたい実家をリフォームしたい賃貸仲介会社マンションデベロッパー売買仲介事業者ハウスメーカー工務店リフォーム事業者

Slide 18

Slide 18 text

© Recruit Co., Ltd. All Rights Reserved 不動産マッチングプラットフォーム SUUMOとは 18 家を探しているユーザ不動産事業クライアントユーザとクライアント双方にとって最適なマッチングを生み出す「場」を提供進学に伴って一人暮らしを始めたい家族が増えたのでマンションか戸建てを買いたい実家をリフォームしたい賃貸仲介会社マンションデベロッパー売買仲介事業者ハウスメーカー工務店リフォーム事業者本日のプロダクトはこっちの話！

Slide 19

Slide 19 text

© Recruit Co., Ltd. All Rights Reserved SUUMO営業のお仕事不動産会社の事業成長に伴走する SUUMOというメディア媒体の広告営業を前提としつつ、クライアントの事業成長に伴走する仕事不動産の仕入れに関するアドバイスなどの深い介在含めクライアントの成長を支援する中で、SUUMOというメディアも手段の一つとして提案している。不動産会社を顧客としたtoB営業 19 キャリア採用サイトにも詳細載っているのでご興味あれば

Slide 20

Slide 20 text

© Recruit Co., Ltd. All Rights Reserved SUUMO営業の課題とその打ち手(KR※.1 Davis) 一番重要なコア業務であるクライアントの業績拡大に向けた伴走に最大限時間を割きたいがそのために必要な定型分析や提案資料の作成がネックに課題：深い介在を志向する中で時間が足りない社内での分析業務やクライアントとの商談の場の利用に耐えうる内製の分析Webアプリケーション Davisを作成打ち手:分析〜可視化〜資料作成までできる分析プロダクトを作る 20 ※.1 KR = 戸建・流通

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© Recruit Co., Ltd. All Rights Reserved 住まい領域においてはWF型の開発が一般的 22 住まい領域においてはウォーターフォール型(WF型)の開発が一般的であったしかし、Davis開発においては不確実性の高い要求が多く、企画として実際に効果があるかどうかを事前に見積もることが難しい。一方でWF型の開発では検証完了までのリードタイムがかかりすぎてしまい、事業の期待に添うことができない企画検討要件定義開発テスト（単体・内結・総合）受け入れ（営業FB）リリース一般的な住まい領域の開発フロー

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© Recruit Co., Ltd. All Rights Reserved 開発手戻りをなくすための仕組み作り 24 企画検討要件定義プロト開発営業FB＆企画プロト開発営業FB＆企画開発＆テストリリースプロトタイプが完成した時点で、開発環境にデプロイし、営業の受け入れ確認を開発工程の早い段階から行い、開発の手戻りを無くした上で、短い期間でリリース企画検討要件定義開発テスト（単体・内結・総合）受け入れ（営業FB）リリース KRDavisの開発フロー一般的な住まい領域の開発フロー

Slide 25

Slide 25 text

© Recruit Co., Ltd. All Rights Reserved まとめ ● SUUMOメディアにおける対クライアント向けデータ活用 ○ 社内での分析業務やクライアントとの商談の場で活用する分析Webアプリケーション ○ 業務の型化からツール要件まで営業と一緒になって検討 ● データエンジニア（DE）の進化/成長 ○ サービスを安く・早く提供するための、データ基盤の開発 ○ 住まい領域においてはWF型の開発スタイルが主流だったが、それでは事業要求に応え切れない ○ データインフラ構築、CICD整備（各種自動化）、ディレクションなどを実施 ○ 事業に近い場所でエンジニアとして仕事をするため、エンジニアの速度がそのまま事業成長の速度になるとは言うものの... まだまだ開発速度は理想とはほど遠い。またLLMといった新規技術を用いた開発案件も求められるようになってきている。そのため日々の失敗を糧にしてエンジニアとしての成長が求められる状態です 25

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© Recruit Co., Ltd. All Rights Reserved 自己紹介阿部誠也 Masaya Abe データ推進室データテクノロジーユニットデータプロダクトマネジメント1部データプロダクトエンジニアリング1グループグループマネージャー 2019年にリクルートに新卒入社。リクルートの複数の事業領域で活用されている横断データマート・データプロダクトの開発・推進を担当。現在は横断データプロダクトを担当するデータプロダクトエンジニアリング1グループのマネージャーを務めている。 28

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© Recruit Co., Ltd. All Rights Reserved 発生した出来事 35 新規のセグメント項目開発の中で、同じ項目のデータ定義が異なることが発覚。危うく利用者影響につながるところに。発生した要因の1つは、過去経緯を含むデータの多重変換構造。集計データ BigQuery 各領域データ BigQuery JSON GCS DB backend frontend ※ 過去 Oracle Exadata を利用 Elasticsearch

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© Recruit Co., Ltd. All Rights Reserved 妥当性テストなどによる品質担保 37 単体テストに加え、以下のようなテストを拡充しデータの妥当性を担保。 ● 各領域の元データと、Sugarの画面上で提供している値を項目単位で比較検証 (妥当性テスト) ● E2Eテストと手動テストの組み合わせ集計データ BigQuery 各領域データ BigQuery JSON GCS DB backend frontend テストSQL テスト条件比較検証妥当性テスト Elasticsearch

Slide 38

Slide 38 text

© Recruit Co., Ltd. All Rights Reserved データ変換構造のリアーキテクチャ 38 Elasticsearchを経由せず、直接DBとしてBigQueryを利用する構造に。 ● クエリビルダ等バックエンドの改修 ● 集計データマートのカラム構造の最適化 ● パフォーマンステスト ● 変更前後の変換結果の比較検証テスト集計データ BigQuery 各領域データ BigQuery JSON GCS DB backend frontend 直接BigQueryを参照 Elasticsearch

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© Recruit Co., Ltd. All Rights Reserved 引用リスト 41 1. https://icooon-mono.com/15835-%e4%ba%ba%e7%89%a9%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3/ 2. https://icooon-mono.com/15681-%e5%88%86%e6%9e%90%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3/ 3. https://icooon-mono.com/11048-%e3%83%8e%e3%83%bc%e3%83%88%e3%83%91%e3%82%bd%e3%82%b3%e3%83%b3 %e3%81%ae%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3%e7%b4%a0%e6%9d%903/ 4. https://icooon-mono.com/10991-pc%e3%83%87%e3%82%a3%e3%82%b9%e3%83%97%e3%83%ac%e3%82%a4%e3%81% ae%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b3%e7%b4%a0%e6%9d%90-2/ 5. https://icooon-mono.com/12533-%e3%83%a1%e3%83%bc%e3%83%ab%e3%81%ae%e7%84%a1%e6%96%99%e3%82%a2 %e3%82%a4%e3%82%b3%e3%83%b3%e3%81%9d%e3%81%ae8/ 6. https://icooon-mono.com/12851-%e5%8f%8b%e9%81%94%e3%82%a2%e3%82%a4%e3%82%b3%e3%83%b32/ 7. https://docs.google.com/presentation/d/1fD1AwQo4E9Un6012zyPEb7NvUAGlzF6L-vo5DbUe4NQ/edit#slide=id.g5f77ca97a2_9 1_0 8. https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Elasticsearch_logo.svg

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© Recruit Co., Ltd. All Rights Reserved CDCデータパイプライン導入背景 As Is ● サービスのデータベースのデータは日次 ETLにより1日1回しか更新できない ● 瞬時に反映される必要はないにしても、1 日待たないと使えないデータが多数存在しており、それが制約となっている To Be ● サービスのデータベースに対する更新を随時かつ低遅延 (5-10min) で取得する ● 上記を都度の開発が不要な状態で実現する「データ鮮度による手段の制約を可能な限りなくしていきたい」

Slide 47

Slide 47 text

© Recruit Co., Ltd. All Rights Reserved 当時の状況 47 ● ちょうど近いタイミングに複数のサービスが新しく AWS 上で稼働する予定があり、データ基盤への ETL をどうするかという検討テーマが挙がっていた ● サービス本体の構成が似通っているので、標準的な方法を確立できると、仕組みを横展開することができ、一石 N 鳥な状況だった ● 実現したい要件を考えると、CDC (Change Data Capture) を採用することの妥当性がありそうだった

Slide 48

Slide 48 text

© Recruit Co., Ltd. All Rights Reserved CDCデータパイプライン導入前の正直なお気持ち CDC導入によって選択肢は増える(はず)。だが検討事項は山積み。 ● 社内に代表的なユースケースなし ※データ推進室内 ● 技術検証 ● 運用設計 ○ 変更ログをどのように扱う？ ○ サービス側の運用(スキーマ変更,etc)に耐えることができる？ ○ サービス<->データ基盤とのI/Fは? ● etc... 多くの時間を費やしリスクを冒してでも導入する価値があるのか...? 🧐

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© Recruit Co., Ltd. All Rights Reserved 実際にCDCで取得できる変更ログの具体イメージ I,2023-07-30T03:00:01.123+0000,101,Smith,Bob,4-Jun-14,New York I,2023-07-30T04:05:03.456+0000,102,Jones,Tom,3-Aug-07,Chicago U,2023-07-31T09:20:02.456+0000,101,Smith,Bob,8-Oct-15,Los Angeles U,2023-07-31T09:25:03.789+0000,102,Jones,Tom,17-Sep-09,Houston D,2023-08-01T12:00:04.752+0000,101,Smith,Bob,8-Oct-15,Los Angeles 操作 commit時刻更新内容の値変更ログは行単位で操作・変更内容示す情報が連携される。サービスの1テーブルとしてデータ基盤上で利用したい場合、変更ログを組み立てて、最新snapshotを生成などの工夫が必要前後引用) https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.S3.html 最新の状態 = 「102,Jones,Tom,17-Sep-09,Houston」 1レコードのみ

Slide 51

Slide 51 text

© Recruit Co., Ltd. All Rights Reserved データ基盤とサービス間のデータ連携で典型的なのは1日1〜N回のバッチによる連携。リクルート社内でもこのパターンがメジャー(現在) バッチでのETLとCDCの比較観点バッチ CDC データ鮮度 × 1時間〜 1日 ○ < 5min データ転送量 △ 毎回全件更新だと大きくなる。差分抽出の場合は少なくできるが物理削除がわからないという課題を抱える ○ 差分データだけが転送されるので全データをコピーする場合と比較して少なくなる運用コスト ○ バッチなのでCDC比では低い △ 常に処理が動いているので高い

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© Recruit Co., Ltd. All Rights Reserved CDC導入によって得られたこと ● データ鮮度という制約をほぼ取り払うことができた ○ 6サービスからのデータ連携をCDC化 ○ DWH(BigQuery)のデータは日次更新->1h程度で更新可能に ■ Databricks上のデータは<5~10min程度の遅延 ○ Event-Drivenな機能開発も容易に ■ Spark(Databricks) + DeltaTableの組み合わせは表現力が高く、できることの幅が広い ● 物理削除を検知できる状態での差分更新ETL ○ 変更が発生したレコードのみ連携されるため👛にやさしく、地味に助かっている

Slide 55

Slide 55 text

© Recruit Co., Ltd. All Rights Reserved CDCパイプライン運用の難しさバッチ方式と比較して運用は少し大変 ● サービス側の変更がパイプラインへと直接影響しやすい ○ 常に変更ログを連携しているのでバッチ方式よりも密結合 ○ サービス側のリリースにデータ基盤側の対応を合わせることも ● データ整合性の担保 ○ 変更ログが「1行」でも欠けるとデータが壊れる ■ 一方で日次全件更新方式の場合は翌日には復旧する ○ 変更ログの取り込み漏れ監視、最新断面のPK一意性監視などで品質担保

Slide 56

Slide 56 text

© Recruit Co., Ltd. All Rights Reserved CDC導入によって「期せずして」得られたこと ● 変更ログは調査タスクで大きな力を発揮する ○ 各テーブルの最新snapshotだけでなく、変更ログも全てデータ基盤に保持＆公開している※PIIはマスキング済 ○ データの変更履歴を全て追うことができるので、データ調査、障害調査においてかなり有用 ■ データ基盤上のデータが壊れている旨の問い合わせをうけ、変更ログを追ったところ、サービス側のバグだった...みたいなことも

Slide 57

Slide 57 text

© Recruit Co., Ltd. All Rights Reserved CDC導入を通じて得られた学び ● データ鮮度向上による、データ基盤の価値向上は大きい ○ できることが増える->想像できることも増える ● 適切な技術スタックを採用することの重要性 ○ ストリーム/バッチを使い分け、自由度が高くデータパイプラインを開発できる技術選定は大事 ● チャレンジングな物事に取り組むことの重要性 ○ 日次バッチ方式では発生しなかった課題、問題に多く直面 ○ 意図しなかった恩恵も多くあり、技術者としての学びは多い