Wantedly での Datadog 活用事例

https://www.datadoghq.com/ja/event/datadoglive-tokyo202412/

Transcript

1. © 2024 Wantedly, Inc. Wantedly での Datadog 活⽤事例 Datadog Live Tokyo 2024 Reprise Dec. 18 2024 - Atsushi Tanaka @bgpat
2. © 2024 Wantedly, Inc. 話すこと Wantedly では10年以上 Datadog を継続利⽤ どうやって Datadog を利⽤してきたか振り返る • ツールやサービス導⼊をするだけではダメ どう使ってもらいたいか設計して価値を最⼤化 • 要求は時間経過で変化するため継続的な⾒直しも⼤事 2
3. © 2024 Wantedly, Inc. @bgpat / 田中 篤志 ウォンテッドリー株式会社 2018年入社 Infrastructure Engineer / Squad Leader Japan Datadog User Group Member Datadog 歴 8年くらい 3 ⾃⼰紹介
4. © 2024 Wantedly, Inc. ⾃⼰紹介 4 Japan Datadog User Group での発表
5. © 2024 Wantedly, Inc. 会社紹介 究極の適材適所により、 シゴトでココロオドルひとを ふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを2012 年から創出。 はたらくすべての⼈が共感を通じて「であい」「つながり」「つなが りを深める」ためのビジネスSNS「Wantedly」を提供しています。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合えるよ うな世界を実現するために、国境を超えて「はたらくすべての⼈の イ ンフラ」を創っていきます。 5
6. © 2024 Wantedly, Inc. インフラや開発運⽤に関わる機能とプラクティスをプラットフォームとして提供していく ウォンテッドリーの Infra Squad の役割 6
7. © 2024 Wantedly, Inc. 2024年時点のインフラ構成 7
8. © 2024 Wantedly, Inc. 2024年時点のインフラ構成 • マイクロサービスを Kubernetes 上で運⽤ ◦ 1つのクラスタで約60個のマイクロサービスを運⽤ ◦ コンテナ数は1クラスタあたり約2,500個 • AWS と Google Cloud のマルチクラウド環境 • モニタリングは Datadog をメインに 複数サービスを利⽤ 8
9. © 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 基盤検証
10. © 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 基盤検証
11. © 2024 Wantedly, Inc. 2012年 - サービス開始 • 正式ローンチ🎉 ◦ ユーザーの流⼊も定着もない状態で売上がない ◦ どれだけ早く変更して試⾏回数を増やせるかの勝負 • インフラ構成には Heroku を採⽤ ◦ サービス運⽤に必要なものが1サービスで完結した ◦ モニタリングも Heroku におまかせ ◦ Rails サーバーと RDB がそれぞれ1つずつの構成 11
12. © 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 基盤検証
13. © 2024 Wantedly, Inc. 2014年 - AWS への移⾏ • アクセス増加により⾃由度の⾼い AWS に移⾏ ◦ 当時 Heroku は US East リージョンしかなかった ◦ データベースの拡張性にも課題があった ◦ Heroku のよさを維持するため Docker によるコンテナ環境を構築 • インフラのモニタリングに Datadog を導⼊ ◦ AWS の標準機能だけでは監視が難しかった ◦ コンテナと相性のよい Datadog を導⼊ ◦ 当時は Infrastructure 機能しか存在しなかった 13
14. © 2024 Wantedly, Inc. 2014年 - AWS への移⾏ 当時利⽤していた機能 • Dashboard • Monitoring 14
15. © 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 基盤検証
16. © 2024 Wantedly, Inc. 2016年 - マイクロサービス化のはじまり • Kubernetes の運⽤を開始 ◦ ボトルネックにならないインフラを⽬指して k8s でのマイクロサービス運⽤を開始 ◦ 主に新規事業で採⽤ • Datadog が k8s に対応していたため利⽤ ◦ 当時 Kubernetes に対応しているサービスは Datadog のみ ◦ Datadog Agent を DaemonSet としてインストールするだけ 16
17. © 2024 Wantedly, Inc. 2016年 - マイクロサービス化のはじまり 17 https://speakerdeck.com/koudaiii/number-k8sjp?slide=34
18. © 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 基盤検証
19. © 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 • 全サービスの Kubernetes 移⾏が完了 ◦ マイクロサービス化が上⼿くいったため既存サービスにも展開 ◦ デバッグが以前よりも難しくなったという声が出始めた • デバッグ体験の改善のため Datadog APM を導⼊ ◦ 世間的にも APM や分散トレーシングが話題に上がっていたので試しに導⼊ ◦ 環境が整っていなかったため Datadog 以外の他社サービスも併⽤し検証 19
20. © 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 環境が整っていなかったため Datadog 以外の他社サービスも併⽤し検証 • サービスの選択肢はいくつかあったが決めきれなかった ◦ 新しい概念のため対応しているサービスや機能だけでなく情報も少なかった ◦ ベンダーロックインによるリスクを⾼く⾒積もった • OpenCensus により複数サービスにトレース情報を送信 ◦ 1回の計装で実現でき後で送信先を変更するのも容易 ◦ OpenCensus は のちに OpenTelemetry に統合された 20
21. © 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 21 https://speakerdeck.com/bgpat/distributed-tracing-for-microservices
22. © 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 22 https://speakerdeck.com/bgpat/distributed-tracing-for-microservices
23. © 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 23 https://speakerdeck.com/bgpat/distributed-tracing-for-microservices
24. © 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 基盤検証
25. © 2024 Wantedly, Inc. 2020年 - マイクロサービス化のつらみとの戦い • マイクロサービスのつらみが浮き彫りに ◦ マイクロサービス化が加速し当時は2週間に1つくらいのペースで作られていた ◦ 問題が発⽣したときの原因特定が難しく MTTR が増加 • 問題調査をやりやすくする⽅法を模索 ◦ APM でカバーできる範囲を拡⼤ ◦ Logs を活⽤した SLO 基盤の検討を始める ◦ RUM の利⽤も検討したが原因特定には繋げられないと判断し断念 25
26. © 2024 Wantedly, Inc. 2020年 - マイクロサービス化のつらみとの戦い 26 https://speakerdeck.com/koudaiii/cloudnative-days-tokyo-2019-number-cndt2019-number-osdt2019-number-roomb
27. © 2024 Wantedly, Inc. 2020年 - マイクロサービス化のつらみとの戦い 27 https://speakerdeck.com/koudaiii/cloudnative-days-tokyo-2019-number-cndt2019-number-osdt2019-number-roomb
28. © 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 基盤検証
29. © 2024 Wantedly, Inc. 2022年 - 利⽤しているサービスの⾒直し • 運⽤しているサービスが多いことが課題に ◦ 可能なら既存の運⽤ではなく新しい価値にリソースを割きたい ◦ Kubernetes は運⽤コストを下げるために EKS に移⾏ • モニタリング / オブザーバビリティも⾒直しを開始 ◦ マイクロサービスによって利⽤するサービスが異なっていた ◦ インフラを利⽤するエンジニアが迷う状態だった 29
30. © 2024 Wantedly, Inc. 2022年 - モニタリング / オブザーバビリティサービスの⾒直し Datadog APM と N社のサービスを併⽤している • 元々は異なる⽬的で導⼊ ◦ インフラの監視: Datadog ◦ 分散ではない APM: N社 ◦ 徐々に互いのサービスのカバー範囲が近づいた • 時期尚早と判断し併⽤を継続 ◦ どちらに寄せるべきか判断する情報が⾜りなかった ◦ 移⾏にかかる⼯数も未知数だった 30
31. © 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 基盤検証
32. © 2024 Wantedly, Inc. 2024年 - SLO 基盤と APM を Datadog に移⾏ • モニタリング / オブザーバビリティ サービスの集約 ◦ Datadog APM に寄せる決断をし移⾏を実施中 ◦ 詳細は後述 • SLO 基盤の体験向上のため Datadog に移⾏ ◦ サービス信頼性の維持のため2018年から SLO を導⼊している ◦ モニタリング基盤は⾃前実装していたが体験が悪かった ◦ Datadog SLO への移⾏で信頼性⾼くかつ簡単に運⽤できるように 32
33. © 2024 Wantedly, Inc. 2024年 - SLO 基盤を Datadog に移⾏ 33 https://speakerdeck.com/fohte/datadog-logs-wohuo-yong-site-slo-jian-shi-ji-pan-wogou-zhu-suru
34. © 2024 Wantedly, Inc. 2024年 - SLO 基盤を Datadog に移⾏ 34 https://speakerdeck.com/fohte/datadog-logs-wohuo-yong-site-slo-jian-shi-ji-pan-wogou-zhu-suru
35. © 2024 Wantedly, Inc. 2024年 - モニタリング / オブザーバビリティ サービスの集約 移⾏を決断した理由 • 利⽤するツールを減らすことによるメリット ◦ 計装ライブラリへの依存が減りパフォーマンスが向上 ◦ 計装ライブラリ同⼠の競合による不具合の解消 ◦ サービス利⽤費⽤の圧縮 • オブザーバビリティの推進 ◦ 障害対応や問題調査に時間がかかる課題を解決したい ◦ デバッグ環境の整備による開発体験の向上の狙い 35
36. © 2024 Wantedly, Inc. 2024年 - モニタリング / オブザーバビリティ サービスの集約 Datadog を選んだ理由 • サービス思想との相性の良さ ◦ ユーザー数課⾦でないことがオブザーバビリティ思想の社内展開を後押し ◦ アプリケーションライブラリがカスタマイズしやすい設計になっている • 集約後の姿が理想に近い ◦ インフラの監視はDatadog を使い続けるべきと判断 ▪ 10年間運⽤してきたデータや知⾒が溜まっている ▪ 移⾏コストに対してメリットが薄い ◦ インフラと APM は同じサービス上で⾒れた⽅が活⽤しやすい 36
37. © 2024 Wantedly, Inc. まとめ • Wantedly ではフェーズ毎に最適な監視/o11yツールを 模索した結果として Datadog を採⽤している ◦ そのタイミングで必要な機能に合うサービスが Datadog だった ◦ 時間経過により状況が変化するため継続的に価値を⽣んでいるか確認すべき • 技術選定では成し遂げたいことと 採⽤するサービスの思想がマッチしていることが重要 ◦ まずは何をやるのか、何のためにやるのかを⾔語化 ◦ 実際にツールを⽐較検討する中で⽬指す⽅向が合っているのか確認する 37
38. © 2024 Wantedly, Inc. https://www.wantedly.com/projects/522096