Wantedly での Datadog 活用事例

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2024 Wantedly, Inc. 会社紹介究極の適材適所により、シゴトでココロオドルひとをふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを2012 年から創出。はたらくすべての⼈が共感を通じて「であい」「つながり」「つながりを深める」ためのビジネスSNS「Wantedly」を提供しています。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合えるような世界を実現するために、国境を超えて「はたらくすべての⼈のインフラ」を創っていきます。 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 9 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 10

Slide 10 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 10 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 11

Slide 11 text

© 2024 Wantedly, Inc. 2012年 - サービス開始 ● 正式ローンチ🎉 ○ ユーザーの流⼊も定着もない状態で売上がない ○ どれだけ早く変更して試⾏回数を増やせるかの勝負 ● インフラ構成には Heroku を採⽤ ○ サービス運⽤に必要なものが1サービスで完結した ○ モニタリングも Heroku におまかせ ○ Rails サーバーと RDB がそれぞれ1つずつの構成 11

Slide 12

Slide 12 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 12 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 13

Slide 13 text

© 2024 Wantedly, Inc. 2014年 - AWS への移⾏ ● アクセス増加により⾃由度の⾼い AWS に移⾏ ○ 当時 Heroku は US East リージョンしかなかった ○ データベースの拡張性にも課題があった ○ Heroku のよさを維持するため Docker によるコンテナ環境を構築 ● インフラのモニタリングに Datadog を導⼊ ○ AWS の標準機能だけでは監視が難しかった ○ コンテナと相性のよい Datadog を導⼊ ○ 当時は Infrastructure 機能しか存在しなかった 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 15 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 16

Slide 16 text

© 2024 Wantedly, Inc. 2016年 - マイクロサービス化のはじまり ● Kubernetes の運⽤を開始 ○ ボトルネックにならないインフラを⽬指して k8s でのマイクロサービス運⽤を開始 ○ 主に新規事業で採⽤ ● Datadog が k8s に対応していたため利⽤ ○ 当時 Kubernetes に対応しているサービスは Datadog のみ ○ Datadog Agent を DaemonSet としてインストールするだけ 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 18 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 19

Slide 19 text

© 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 ● 全サービスの Kubernetes 移⾏が完了 ○ マイクロサービス化が上⼿くいったため既存サービスにも展開 ○ デバッグが以前よりも難しくなったという声が出始めた ● デバッグ体験の改善のため Datadog APM を導⼊ ○ 世間的にも APM や分散トレーシングが話題に上がっていたので試しに導⼊ ○ 環境が整っていなかったため Datadog 以外の他社サービスも併⽤し検証 19

Slide 20

Slide 20 text

© 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進環境が整っていなかったため Datadog 以外の他社サービスも併⽤し検証 ● サービスの選択肢はいくつかあったが決めきれなかった ○ 新しい概念のため対応しているサービスや機能だけでなく情報も少なかった ○ ベンダーロックインによるリスクを⾼く⾒積もった ● OpenCensus により複数サービスにトレース情報を送信 ○ 1回の計装で実現でき後で送信先を変更するのも容易 ○ OpenCensus はのちに OpenTelemetry に統合された 20

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 24 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 25

Slide 25 text

© 2024 Wantedly, Inc. 2020年 - マイクロサービス化のつらみとの戦い ● マイクロサービスのつらみが浮き彫りに ○ マイクロサービス化が加速し当時は2週間に1つくらいのペースで作られていた ○ 問題が発⽣したときの原因特定が難しく MTTR が増加 ● 問題調査をやりやすくする⽅法を模索 ○ APM でカバーできる範囲を拡⼤ ○ Logs を活⽤した SLO 基盤の検討を始める ○ RUM の利⽤も検討したが原因特定には繋げられないと判断し断念 25

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 28 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 29

Slide 29 text

© 2024 Wantedly, Inc. 2022年 - 利⽤しているサービスの⾒直し ● 運⽤しているサービスが多いことが課題に ○ 可能なら既存の運⽤ではなく新しい価値にリソースを割きたい ○ Kubernetes は運⽤コストを下げるために EKS に移⾏ ● モニタリング / オブザーバビリティも⾒直しを開始 ○ マイクロサービスによって利⽤するサービスが異なっていた ○ インフラを利⽤するエンジニアが迷う状態だった 29

Slide 30

Slide 30 text

© 2024 Wantedly, Inc. 2022年 - モニタリング / オブザーバビリティサービスの⾒直し Datadog APM と N社のサービスを併⽤している ● 元々は異なる⽬的で導⼊ ○ インフラの監視: Datadog ○ 分散ではない APM: N社 ○ 徐々に互いのサービスのカバー範囲が近づいた ● 時期尚早と判断し併⽤を継続 ○ どちらに寄せるべきか判断する情報が⾜りなかった ○ 移⾏にかかる⼯数も未知数だった 30

Slide 31

Slide 31 text

© 2024 Wantedly, Inc. ウォンテッドリーの歴史と Datadog 31 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始サービス開始インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始全サービスが Kubernetes 上にデバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証

Slide 32

Slide 32 text

© 2024 Wantedly, Inc. 2024年 - SLO 基盤と APM を Datadog に移⾏ ● モニタリング / オブザーバビリティサービスの集約 ○ Datadog APM に寄せる決断をし移⾏を実施中 ○ 詳細は後述 ● SLO 基盤の体験向上のため Datadog に移⾏ ○ サービス信頼性の維持のため2018年から SLO を導⼊している ○ モニタリング基盤は⾃前実装していたが体験が悪かった ○ Datadog SLO への移⾏で信頼性⾼くかつ簡単に運⽤できるように 32

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2024 Wantedly, Inc. 2024年 - モニタリング / オブザーバビリティサービスの集約移⾏を決断した理由 ● 利⽤するツールを減らすことによるメリット ○ 計装ライブラリへの依存が減りパフォーマンスが向上 ○ 計装ライブラリ同⼠の競合による不具合の解消 ○ サービス利⽤費⽤の圧縮 ● オブザーバビリティの推進 ○ 障害対応や問題調査に時間がかかる課題を解決したい ○ デバッグ環境の整備による開発体験の向上の狙い 35

Slide 36

Slide 36 text

© 2024 Wantedly, Inc. 2024年 - モニタリング / オブザーバビリティサービスの集約 Datadog を選んだ理由 ● サービス思想との相性の良さ ○ ユーザー数課⾦でないことがオブザーバビリティ思想の社内展開を後押し ○ アプリケーションライブラリがカスタマイズしやすい設計になっている ● 集約後の姿が理想に近い ○ インフラの監視はDatadog を使い続けるべきと判断 ■ 10年間運⽤してきたデータや知⾒が溜まっている ■ 移⾏コストに対してメリットが薄い ○ インフラと APM は同じサービス上で⾒れた⽅が活⽤しやすい 36

Slide 37

Slide 37 text

© 2024 Wantedly, Inc. まとめ ● Wantedly ではフェーズ毎に最適な監視/o11yツールを模索した結果として Datadog を採⽤している ○ そのタイミングで必要な機能に合うサービスが Datadog だった ○ 時間経過により状況が変化するため継続的に価値を⽣んでいるか確認すべき ● 技術選定では成し遂げたいことと採⽤するサービスの思想がマッチしていることが重要 ○ まずは何をやるのか、何のためにやるのかを⾔語化 ○ 実際にツールを⽐較検討する中で⽬指す⽅向が合っているのか確認する 37