独自アクセスログ基盤の構築

2026/2/27に、RECRUIT TECH CONFERENCE 2026で発表した山本の資料になります。

Transcript

1. RECRUIT TECH CONFERENCE 2026 マッチング技術の進化 独自アクセスログ基盤の構築 インディードリクルートテクノロジーズ 山本 航平
2. 山本 航平 ホラー映画鑑賞 経歴 / Career 2019年にリクルートテクノロジーズ（現リクルート）に キャリア入社。 人材領域のデータ基盤の開発運用を担当しています。 趣味 / Hobbies （株）インディードリクルートテクノロジーズ ＨＲプロダクト　データ データソリューションユニット データエンジニアリング部
3. 今日の内容をざっくり3行で 人材領域で利用しているアクセス解析ツールを、 独自のログ収集基盤にリプレースし、 コスト / 保守性 / データ鮮度の3つが GOOD な状態にしました
4. Agenda 1. 背景と課題 2. 解決 3. 結果
5. Agenda 1. 背景と課題 2. 解決 3. 結果
6. 背景と課題 人材領域で生じていたアクセスログの3つの課題 ① ログ設計の管理が横断的にできていない ② データウェアハウスで分析可能になるまでのリードタイムが長い ③ アクセス解析と機械学習でログを二重取得しており効率が悪い
7. 背景と課題 ① ログ設計の管理が横断的にできていない • 施策ごと（ABテストや、画面改修等）にadhocにログ設計と追加をしているため、プロダ クト横断でのログ設計思想がない • 施策担当者やプロダクトごとに設計がブレてしまい、データマートでの利用の都度仕様の キャッチアップと検算から入らなければならない
8. 背景と課題 ② データウェアハウスで分析可能になるまでのリードタイムが長い • アクセス解析ツール上ではニアリアルタイムにデータ更新されるが、データウェアハウスに ある他データと組み合わせないとできない分析が多数ある • そのためアクセス解析ツールに付帯しているExport機能を使ってデータをデータウェアハ ウス（BigQuery）に連携して分析利用している • このExport機能にサービスレベルがなく、だいたい2~3時間後にデータが入ってくるだろ うという経験則での運用になっていた（かつ遅い）
9. 背景と課題 ③ アクセス解析と機械学習でログを二重取得しており効率が悪い • 前ページに記載した制約（2~3hの遅延）があるため、機械学習施策でのニアリアルタイム なデータ活用に対してデータ鮮度が要求を満たさない • 機械学習用の別データパイプラインを構築することになり、結果、アクセスログを二重取得 している状態になっていた
10. Agenda 1. 背景と課題 2. 解決 3. 結果
11. 解決 基盤刷新とセットでログ設計運用の見直しをする • 課題を同時に解決するため、ログ収集基盤の刷新を決定 • 既存サービスを継続利用することも考えたが、課題③の解決や、インフラコストを大幅に削 減できる見立て（現行の10~20%程度まで下がる）があったため、独自基盤を作る方向と なった • アクセス解析ツールが入っているサービス側のリアーキテクチャが同時期に実行されていた ため、そことタイミングを合わせることで導入をスムーズにした
12. 構成のBefore / After
13. 構成のBefore / After ログの二重管理 2 ~ 3時間の遅延 (SLA なし)
14. 構成のBefore / After ログの二重管理 2 ~ 3時間の遅延 (SLA なし) 1秒未満 一本化 施策リリース後、即時に分析が可能になり、検知や対応が高速に。 機械学習モデルの特徴量として利用可能なデータの種類が増加。
15. アーキテクチャ • インフラは AWS • ログを直接受け取るのは ALB + ECS Fargate。API は Rust で実装 • メッセージングシステムは Kafka、共通の加工処理を Flink、DWHへの連携は BigQuery Connector。全て Confluent Cloud 上で実行 • Online Feature Store （DynamoDB）への連携は Databricks or Custom Connector
16. アーキテクチャ • DNS、ALB は共通で API Key を元にサービスごとの API へリクエストをルー ティング • Topic や Flink のクエリは サービスごと • BigQuery Connector は複 数 Topic をサポートしてい る、かつ、スケーラブルで あるため共用
17. 変更プロセスのBefore / After 各案件で自由に 実装まで決定 基本はそのまま 実装される
18. 変更プロセスのBefore / After 各案件で自由に 実装まで決定 基本はそのまま 実装される 担当者は 分析要求を出す 共通の担当者が 分析要求から実装 を決定
19. Agenda 1. 背景と課題 2. 解決 3. 結果
20. 結果 ① ログ設計の管理が横断的にできていない ② データウェアハウスで分析可能になるまでのリードタイムが長い ③ アクセス解析と機械学習でログを二重取得しており効率が悪い 🟢 基盤刷新に合わせてフローを刷新し集約された管理を確立 🟢 一本化して二重取得を撤廃。コスト面も既存の10~20%程度まで圧縮 🟢 2~3h → 数秒まで短縮