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
1
380
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
KubernetesでDatadogを飼うならオートディスカバリーを使わないと損
bgpat
2
470
マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由
bgpat
12
2.7k
400万ユーザーに価値を届けるエンジニアを を支えるインフラ基盤
bgpat
3
340
Ruby製社内ツールのGo移行
bgpat
2
540
導入から5年が経って見えた Datadog APM 運用の課題
bgpat
3
1.1k
取っていてよかった Kubernetes のバックアップ
bgpat
1
580
Terraform と Kubernetes の共存による IaC の実践
bgpat
0
1.7k
Kubernetes Cluster Migration
bgpat
4
4.6k
k8sとNginxでオートスケール / Autoscaling with k8s and Nginx
bgpat
2
1.3k
Other Decks in Technology
See All in Technology
社内イベント管理システムを1週間でAKSからACAに移行した話し
shingo_kawahara
0
170
Jetpack Composeで始めるServer Cache State
ogaclejapan
2
160
生成AIのガバナンスの全体像と現実解
fnifni
1
180
非機能品質を作り込むための実践アーキテクチャ
knih
2
520
Amazon VPC Lattice 最新アップデート紹介 - PrivateLink も似たようなアップデートあったけど違いとは
bigmuramura
0
190
【re:Invent 2024 アプデ】 Prompt Routing の紹介
champ
0
140
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
210
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
150
PHPからGoへのマイグレーション for DMMアフィリエイト
yabakokobayashi
1
160
どちらを使う?GitHub or Azure DevOps Ver. 24H2
kkamegawa
0
580
NW-JAWS #14 re:Invent 2024(予選落ち含)で 発表された推しアップデートについて
nagisa53
0
250
プロダクト開発を加速させるためのQA文化の築き方 / How to build QA culture to accelerate product development
mii3king
1
250
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Thoughts on Productivity
jonyablonski
67
4.4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
How to Ace a Technical Interview
jacobian
276
23k
Side Projects
sachag
452
42k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Designing Experiences People Love
moore
138
23k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
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