ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© 2025 Wantedly, Inc. サマリー ● ウォンテッドリーでは意思決定の正確性とスピードのためにデータパイプラインを整備している ● ETL（の一部）を内製ツールで行っている ○ analytics（2016〜） ■ 複数データソース（PostgreSQL、Salesforce、Zendesk）を扱えるのが強み ■ 良くも悪くも枯れている ■ アクセス制御や型への対応が不十分 ○ rds-exporter（2024〜） ■ analytics の問題点を解決するために現在の需要に則って設計・実装された ■ まだまだ利用箇所が少ないので広げていく

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 2025 Wantedly, Inc. analytics（2016〜） ● PostgreSQL（AWS RDS,Aurora）、Salesforce、Zendesk など複数データソースに対応 ● Ruby で開発 ● インターフェースは DSL 1. rds-exporter（2024〜） ● PostgreSQL（AWS RDS,Aurora）に対応 ● Go で開発 ● インターフェースは YAML 2. 1. ウォンテッドリーのデータパイプライン − 内製ツール

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2025 Wantedly, Inc. ● ビジネス規模の拡大 ○ 上場直前であったり、新サービス（People）のリリースなど ● アーキテクチャ過渡期 ○ モノシリック Rails と並行してマイクロサービス化も始まっていた ○ DWH の BigQuery へ移行が始まっていた ● → データ分析の課題に直面 ○ 分析のためのコードベースがアプリケーションの Rails に密結合していてデプロイ頻度が上がらない ○ 制約が無く、品質にばらつきがある 2. analytics が必要だった過去 − 2016年まで詳しくは「Ruby で作るデータ分析基盤」 , @Altech, 2018 を参照 https://speakerdeck.com/altech/ruby-dezuo-rudetafen-xi-ji-pan

Slide 11

Slide 11 text

© 2025 Wantedly, Inc. 2. analytics が必要だった過去 − インターフェース ● Ruby で実装 ● DSL で設定 ● Kubernetes CronJob でスケジューリング失敗通知については「スケジュールジョブ（ CronJob）の実行失敗通知基盤における成功と失敗」, @unblee, 2024 を参照 https://speakerdeck.com/unblee/success-and-failure-in-scheduled-job-execution-failure-notification-infrastructure

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2025 Wantedly, Inc. ● 需要と設計の乖離 ○ 以前より細やかなアクセス制御が求められるようになった ■ 本番環境だけでなく複数の環境や権限分離を想定する機会が増えた ○ 収集する対象（e.g. テーブル）を opt-in していたが不都合が多かった ■ 収集漏れであとから欲しいデータが無くて困るケースが多発した ○ 中間成果物として CSV を利用しているため表現できない型がある ● → analytics に変化が求められている、がしかし ○ 良くも悪くも枯れていて下手に手を入れられなくなっている ■ ステージング環境が無くて動作確認が大変 ■ そもそもテストコードが無くて変更を入れにくい ○ 設計から刷新した方が求めているものが実現しやすいと判断した ○ → rds-exporter の誕生 3. rds-exporter が必要になった現在 − 2024年から

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2025 Wantedly, Inc. ● 改善できたこと ○ DB 内の全てのテーブルを丸ごとエクスポートできるようになった ■ データ漏れが無くなった ○ 複数環境プロジェクトへの対応できるようになった ■ アクセス制御の要求に対応できるようになった ● 今後の展望 ○ コスト最適化 ■ DB の一部のテーブルだけが必要でも全体に対する費用が発生してしまう ○ 対応データソースの拡大 ■ 現在は Aurora のみ ○ 挙動の改善 ■ 原因不明のレイテンシがあり 1時間くらいの立ち上がり時間が必要になってる ■ TIMESTAMP が STRING になってしまう 3. rds-exporter が必要になった現在 − 改善できたこと、今後の展望

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2025 Wantedly, Inc. ● ウォンテッドリーでは意思決定の正確性とスピードのためにデータパイプラインを整備している ● ETL（の一部）を内製ツールで行っている ○ analytics（2016〜） ■ 複数データソース（PostgreSQL、Salesforce、Zendesk）を扱えるのが強み ■ 良くも悪くも枯れている ■ アクセス制御や型への対応が不十分 ○ rds-exporter（2024〜） ■ analytics の問題点を解決するために現在の需要に則って設計・実装された ■ まだまだ利用箇所が少ないので広げていく 4. まとめ

Slide 20

Slide 20 text

© 2025 Wantedly, Inc. ● データ基盤入門 Wantedly Engineering Handbook ○ https://docs.wantedly.dev/fields/data/data-infra ● Ruby で作るデータ分析基盤 ○ @Altech, 2018 ○ https://speakerdeck.com/altech/ruby-dezuo-rudetafen-xi-ji-pan ● Wantedly のデータ分析基盤を整備した話 ○ @Altech, 2017 ○ https://www.wantedly.com/companies/wantedly/post_articles/65866 ● スケジュールジョブ（ CronJob）の実行失敗通知基盤における成功と失敗 ○ @unblee, 2024 ○ https://speakerdeck.com/unblee/success-and-failure-in-scheduled-job-executio n-failure-notification-infrastructure 参考資料