Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Wantedly での Datadog 活用事例
Search
Atsushi Tanaka
December 18, 2024
Technology
2
4.6k
Wantedly での Datadog 活用事例
https://www.datadoghq.com/ja/event/datadoglive-tokyo202412/
Atsushi Tanaka
December 18, 2024
Tweet
Share
More Decks by Atsushi Tanaka
See All by Atsushi Tanaka
ウォンテッドリーにおける Platform Engineering
bgpat
0
300
KubernetesでDatadogを飼うならオートディスカバリーを使わないと損
bgpat
2
710
マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由
bgpat
12
3.3k
400万ユーザーに価値を届けるエンジニアを を支えるインフラ基盤
bgpat
3
420
Ruby製社内ツールのGo移行
bgpat
2
640
導入から5年が経って見えた Datadog APM 運用の課題
bgpat
3
1.3k
取っていてよかった Kubernetes のバックアップ
bgpat
1
710
Terraform と Kubernetes の共存による IaC の実践
bgpat
0
2k
Kubernetes Cluster Migration
bgpat
4
4.7k
Other Decks in Technology
See All in Technology
Azure AI Foundryでマルチエージェントワークフロー
seosoft
0
110
活きてなかったデータを活かしてみた話 / Shirokane Kougyou vol 19
sansan_randd
1
370
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
2
780
IAMのマニアックな話 2025を執筆して、 見えてきたAWSアカウント管理の現在
nrinetcom
PRO
4
610
AI技術トレンド勉強会 #1MCPの基礎と実務での応用
nisei_k
1
220
讓測試不再 BB! 從 BDD 到 CI/CD, 不靠人力也能 MVP
line_developers_tw
PRO
0
260
生成AIをテストプロセスに活用し"よう"としている話 #jasstnano
makky_tyuyan
0
230
DB 醬,嗨!哪泥嘎斯基?
line_developers_tw
PRO
0
260
Workflows から Agents へ ~ 生成 AI アプリの成長過程とアプローチ~
belongadmin
3
170
doda開発 生成AI元年宣言!自家製AIエージェントから始める生産性改革 / doda Development Declaration of the First Year of Generated AI! Productivity Reforms Starting with Home-grown AI Agents
techtekt
0
180
Tenstorrent 開発者プログラム
tenstorrent_japan
0
310
DenoとJSRで実現する最速MCPサーバー開発記 / Building MCP Servers at Lightning Speed with Deno and JSR
yamanoku
1
120
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Raft: Consensus for Rubyists
vanstee
140
7k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
A Modern Web Designer's Workflow
chriscoyier
693
190k
How GitHub (no longer) Works
holman
314
140k
Embracing the Ebb and Flow
colly
86
4.7k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
How STYLIGHT went responsive
nonsquared
100
5.6k
Transcript
© 2024 Wantedly, Inc. Wantedly での Datadog 活⽤事例 Datadog Live
Tokyo 2024 Reprise Dec. 18 2024 - Atsushi Tanaka @bgpat
© 2024 Wantedly, Inc. 話すこと Wantedly では10年以上 Datadog を継続利⽤ どうやって
Datadog を利⽤してきたか振り返る • ツールやサービス導⼊をするだけではダメ どう使ってもらいたいか設計して価値を最⼤化 • 要求は時間経過で変化するため継続的な⾒直しも⼤事 2
© 2024 Wantedly, Inc. @bgpat / 田中 篤志 ウォンテッドリー株式会社 2018年入社
Infrastructure Engineer / Squad Leader Japan Datadog User Group Member Datadog 歴 8年くらい 3 ⾃⼰紹介
© 2024 Wantedly, Inc. ⾃⼰紹介 4 Japan Datadog User Group
での発表
© 2024 Wantedly, Inc. 会社紹介 究極の適材適所により、 シゴトでココロオドルひとを ふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを2012 年から創出。
はたらくすべての⼈が共感を通じて「であい」「つながり」「つなが りを深める」ためのビジネスSNS「Wantedly」を提供しています。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合えるよ うな世界を実現するために、国境を超えて「はたらくすべての⼈の イ ンフラ」を創っていきます。 5
© 2024 Wantedly, Inc. インフラや開発運⽤に関わる機能とプラクティスをプラットフォームとして提供していく ウォンテッドリーの Infra Squad の役割 6
© 2024 Wantedly, Inc. 2024年時点のインフラ構成 7
© 2024 Wantedly, Inc. 2024年時点のインフラ構成 • マイクロサービスを Kubernetes 上で運⽤ ◦
1つのクラスタで約60個のマイクロサービスを運⽤ ◦ コンテナ数は1クラスタあたり約2,500個 • AWS と Google Cloud のマルチクラウド環境 • モニタリングは Datadog をメインに 複数サービスを利⽤ 8
© 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 基盤検証
© 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 基盤検証
© 2024 Wantedly, Inc. 2012年 - サービス開始 • 正式ローンチ🎉 ◦
ユーザーの流⼊も定着もない状態で売上がない ◦ どれだけ早く変更して試⾏回数を増やせるかの勝負 • インフラ構成には Heroku を採⽤ ◦ サービス運⽤に必要なものが1サービスで完結した ◦ モニタリングも Heroku におまかせ ◦ Rails サーバーと RDB がそれぞれ1つずつの構成 11
© 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 基盤検証
© 2024 Wantedly, Inc. 2014年 - AWS への移⾏ • アクセス増加により⾃由度の⾼い
AWS に移⾏ ◦ 当時 Heroku は US East リージョンしかなかった ◦ データベースの拡張性にも課題があった ◦ Heroku のよさを維持するため Docker によるコンテナ環境を構築 • インフラのモニタリングに Datadog を導⼊ ◦ AWS の標準機能だけでは監視が難しかった ◦ コンテナと相性のよい Datadog を導⼊ ◦ 当時は Infrastructure 機能しか存在しなかった 13
© 2024 Wantedly, Inc. 2014年 - AWS への移⾏ 当時利⽤していた機能 •
Dashboard • Monitoring 14
© 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 基盤検証
© 2024 Wantedly, Inc. 2016年 - マイクロサービス化のはじまり • Kubernetes の運⽤を開始
◦ ボトルネックにならないインフラを⽬指して k8s でのマイクロサービス運⽤を開始 ◦ 主に新規事業で採⽤ • Datadog が k8s に対応していたため利⽤ ◦ 当時 Kubernetes に対応しているサービスは Datadog のみ ◦ Datadog Agent を DaemonSet としてインストールするだけ 16
© 2024 Wantedly, Inc. 2016年 - マイクロサービス化のはじまり 17 https://speakerdeck.com/koudaiii/number-k8sjp?slide=34
© 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 基盤検証
© 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 • 全サービスの Kubernetes
移⾏が完了 ◦ マイクロサービス化が上⼿くいったため既存サービスにも展開 ◦ デバッグが以前よりも難しくなったという声が出始めた • デバッグ体験の改善のため Datadog APM を導⼊ ◦ 世間的にも APM や分散トレーシングが話題に上がっていたので試しに導⼊ ◦ 環境が整っていなかったため Datadog 以外の他社サービスも併⽤し検証 19
© 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 環境が整っていなかったため Datadog 以外の他社サービスも併⽤し検証
• サービスの選択肢はいくつかあったが決めきれなかった ◦ 新しい概念のため対応しているサービスや機能だけでなく情報も少なかった ◦ ベンダーロックインによるリスクを⾼く⾒積もった • OpenCensus により複数サービスにトレース情報を送信 ◦ 1回の計装で実現でき後で送信先を変更するのも容易 ◦ OpenCensus は のちに OpenTelemetry に統合された 20
© 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 21 https://speakerdeck.com/bgpat/distributed-tracing-for-microservices
© 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 22 https://speakerdeck.com/bgpat/distributed-tracing-for-microservices
© 2024 Wantedly, Inc. 2018年 - マイクロサービス化の推進 23 https://speakerdeck.com/bgpat/distributed-tracing-for-microservices
© 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 基盤検証
© 2024 Wantedly, Inc. 2020年 - マイクロサービス化のつらみとの戦い • マイクロサービスのつらみが浮き彫りに ◦
マイクロサービス化が加速し当時は2週間に1つくらいのペースで作られていた ◦ 問題が発⽣したときの原因特定が難しく MTTR が増加 • 問題調査をやりやすくする⽅法を模索 ◦ APM でカバーできる範囲を拡⼤ ◦ Logs を活⽤した SLO 基盤の検討を始める ◦ RUM の利⽤も検討したが原因特定には繋げられないと判断し断念 25
© 2024 Wantedly, Inc. 2020年 - マイクロサービス化のつらみとの戦い 26 https://speakerdeck.com/koudaiii/cloudnative-days-tokyo-2019-number-cndt2019-number-osdt2019-number-roomb
© 2024 Wantedly, Inc. 2020年 - マイクロサービス化のつらみとの戦い 27 https://speakerdeck.com/koudaiii/cloudnative-days-tokyo-2019-number-cndt2019-number-osdt2019-number-roomb
© 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 基盤検証
© 2024 Wantedly, Inc. 2022年 - 利⽤しているサービスの⾒直し • 運⽤しているサービスが多いことが課題に ◦
可能なら既存の運⽤ではなく新しい価値にリソースを割きたい ◦ Kubernetes は運⽤コストを下げるために EKS に移⾏ • モニタリング / オブザーバビリティも⾒直しを開始 ◦ マイクロサービスによって利⽤するサービスが異なっていた ◦ インフラを利⽤するエンジニアが迷う状態だった 29
© 2024 Wantedly, Inc. 2022年 - モニタリング / オブザーバビリティサービスの⾒直し Datadog
APM と N社のサービスを併⽤している • 元々は異なる⽬的で導⼊ ◦ インフラの監視: Datadog ◦ 分散ではない APM: N社 ◦ 徐々に互いのサービスのカバー範囲が近づいた • 時期尚早と判断し併⽤を継続 ◦ どちらに寄せるべきか判断する情報が⾜りなかった ◦ 移⾏にかかる⼯数も未知数だった 30
© 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 基盤検証
© 2024 Wantedly, Inc. 2024年 - SLO 基盤と APM を
Datadog に移⾏ • モニタリング / オブザーバビリティ サービスの集約 ◦ Datadog APM に寄せる決断をし移⾏を実施中 ◦ 詳細は後述 • SLO 基盤の体験向上のため Datadog に移⾏ ◦ サービス信頼性の維持のため2018年から SLO を導⼊している ◦ モニタリング基盤は⾃前実装していたが体験が悪かった ◦ Datadog SLO への移⾏で信頼性⾼くかつ簡単に運⽤できるように 32
© 2024 Wantedly, Inc. 2024年 - SLO 基盤を Datadog に移⾏
33 https://speakerdeck.com/fohte/datadog-logs-wohuo-yong-site-slo-jian-shi-ji-pan-wogou-zhu-suru
© 2024 Wantedly, Inc. 2024年 - SLO 基盤を Datadog に移⾏
34 https://speakerdeck.com/fohte/datadog-logs-wohuo-yong-site-slo-jian-shi-ji-pan-wogou-zhu-suru
© 2024 Wantedly, Inc. 2024年 - モニタリング / オブザーバビリティ サービスの集約
移⾏を決断した理由 • 利⽤するツールを減らすことによるメリット ◦ 計装ライブラリへの依存が減りパフォーマンスが向上 ◦ 計装ライブラリ同⼠の競合による不具合の解消 ◦ サービス利⽤費⽤の圧縮 • オブザーバビリティの推進 ◦ 障害対応や問題調査に時間がかかる課題を解決したい ◦ デバッグ環境の整備による開発体験の向上の狙い 35
© 2024 Wantedly, Inc. 2024年 - モニタリング / オブザーバビリティ サービスの集約
Datadog を選んだ理由 • サービス思想との相性の良さ ◦ ユーザー数課⾦でないことがオブザーバビリティ思想の社内展開を後押し ◦ アプリケーションライブラリがカスタマイズしやすい設計になっている • 集約後の姿が理想に近い ◦ インフラの監視はDatadog を使い続けるべきと判断 ▪ 10年間運⽤してきたデータや知⾒が溜まっている ▪ 移⾏コストに対してメリットが薄い ◦ インフラと APM は同じサービス上で⾒れた⽅が活⽤しやすい 36
© 2024 Wantedly, Inc. まとめ • Wantedly ではフェーズ毎に最適な監視/o11yツールを 模索した結果として Datadog
を採⽤している ◦ そのタイミングで必要な機能に合うサービスが Datadog だった ◦ 時間経過により状況が変化するため継続的に価値を⽣んでいるか確認すべき • 技術選定では成し遂げたいことと 採⽤するサービスの思想がマッチしていることが重要 ◦ まずは何をやるのか、何のためにやるのかを⾔語化 ◦ 実際にツールを⽐較検討する中で⽬指す⽅向が合っているのか確認する 37
© 2024 Wantedly, Inc. https://www.wantedly.com/projects/522096