ウォンテッドリーのアラート設計と Datadog 移行での知見

Japan Datadog User Group Meetup#12@東京
https://datadog-jp.connpass.com/event/360923/

Transcript

1. © 2025 Wantedly, Inc. ウォンテッドリーのアラート設計と Datadog 移行での知見 Japan Datadog User Group Meetup#12 Aug.20 2025 - Kazuki Obata (@donkomura)
2. © 2025 Wantedly, Inc. ⾃⼰紹介 • Wantedly, inc (2024-09 ~) • Infra Squad #k8s #分散システム #ストレージ #ボルダリング󰩥 巨畠 和樹 (Obata Kazuki)
3. © 2025 Wantedly, Inc. 話すこと • アラート運⽤を設計しておく ◦ アラート移⾏‧棚卸しがスムーズに • 移⾏は実装を⾒直すチャンス ◦ 細かな調整が効く Datadog の良いところ‧つまづきポイント
4. © 2025 Wantedly, Inc. 01 ウォンテッドリーの監視・アラート運用の変遷 02 アラートの指針 03 New Relic → Datadog 移行中の問題とその対応 04 まとめ 目次
5. © 2025 Wantedly, Inc. ウォンテッドリーの監視・アラート運用 の変遷 01
6. © 2025 Wantedly, Inc. ウォンテッドリーの監視‧アラート運⽤の変遷 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始 サービス開始 インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始 全サービスが Kubernetes 上に デバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏ サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証 「Wantedly での Datadog 活用事例」p10
7. © 2025 Wantedly, Inc. • New Relic でアプリケーションを監視 • 2014年：Datadog をインフラ監視に採⽤ • 2018〜2023年：アプリケーション監視基盤の混在期 ◦ 2018年：APM の導⼊、分散トレーシングの整備 ◦ 2020年：Logs による SLO 基盤の検証 ◦ 2021年：アラート疲れ問題が顕在化、改善プロジェクト始動 i. 後述のアラート設計‧運⽤ポリシーを定めた ◦ 2022年：モニタリング‧オブザーバビリティ基盤の⾒直し • 2024年：Datadogに統⼀移⾏、アプリ‧インフラ監視の⼀元化 ウォンテッドリーの監視・アラート運用の変遷 アラート設計の起点
8. © 2025 Wantedly, Inc. アラートの指針 02
9. © 2025 Wantedly, Inc. アラートの指針 アラートの分類 • PagerDuty で通知、#war_room で緊急対応 • エンドユーザーに直接影響が出るもの • アラートチャンネルに通知、各チームで対応 • 事業を継続するための社内業務に著しく影響が出るもの • 対応が必要なアプリケーションメトリクス • 対応が必要なインフラストラクチャメトリクス • 参考程度のアラート • 対応が必要ないインフラメトリクス
10. © 2025 Wantedly, Inc. アラートの指針 • Runbook の整備‧影響範囲の可視化 ◦ GitHub repository で⼀括管理 i. 急ぎのものや対応が定まっていないものはアラートに直接書いている ii. coverage で拡充できているかの評価 ◦ APM の Service Map を活⽤して関連するサービスの可視化 • PagerDuty の Open/Close で計測、記録 ◦ MTTR が計測可能に • アラート対応の振り返りはポストモーテムで実施 アラートそのもの以外の仕組み化
11. © 2025 Wantedly, Inc. Datadog 移行でうまくいったこと・いか なかったこと 03
12. © 2025 Wantedly, Inc. Datadog 移⾏でうまくいったこと‧いかなかったこと 2012 Heroku から AWS に移⾏ Datadog の利⽤を開始 サービス開始 インフラは Heroku 2014 2016 2018 2020 2022 2024 マイクロサービス化 Kubernetes の運⽤を開始 全サービスが Kubernetes 上に デバッグの難しさ解消のため APM を導⼊ Amazon EKS に移⾏ サービスの集約検討を開始 SLO 基盤と APM を Datadog に移⾏ APM の利⽤を拡⼤ Logs による SLO 基盤検証 New Relic → Datadog 移⾏
13. © 2025 Wantedly, Inc. Datadog 移⾏でうまくいったこと‧いかなかったこと • エンドユーザーに直接影響が出るものは優先度⾼く移⾏ ◦ 重要サービスのメトリクス • Datadog と New Relic で重複していたものは廃⽌ ◦ SLO Burn rate alert に移⾏したものもある 👍 ポリシーの再確認、アラートの整理
14. © 2025 Wantedly, Inc. Datadog 移⾏でうまくいったこと‧いかなかったこと • 👎 New Relic のアラートと同じものを Datadog で実装できない ◦ e.g. エラーレート‧レイテンシアラート ◦ APM ベースのアラートではサンプリングされてしまう • 👎 設定ミスもあった ◦ Datadog では設定が前提なので New Relic のようにレールに乗れない 移⾏で⾒えてきた問題
15. © 2025 Wantedly, Inc. Datadog 移⾏でうまくいったこと‧いかなかったこと • サンプリングされていないメトリクスで評価することができた ✅トレースメトリクスなどを駆使してアラートを設定
16. © 2025 Wantedly, Inc. 設定ミスへの対応 • 平均値での閾値設定 ◦ ⼀部の異常が埋もれる ◦ 対策：最⼩値（min）集計でフラッピング抑制 • as_count() ＋ avg() 使⽤で平滑化 ◦ 本来のピークを検知できない ◦ 対策：as_rate() による評価を使う ✅ うるさい‧静かなアラートへの対応 https://docs.datadoghq.com/ja/monitors/guide/as-count-in-monitor-evaluations/
17. © 2025 Wantedly, Inc. まとめ 04
18. © 2025 Wantedly, Inc. まとめ • アラート運⽤を設計しておく ◦ アラートの棚卸しがスムーズになる ◦ 通知先、対応フローを仕組み化‧可視化 • 移⾏は実装を⾒直すチャンス ◦ 細かな調整がしやすい ◦ 誤ると正常に監視できなくなるので注意
19. © 2025 Wantedly, Inc. 宣伝 We are hiring! https://www.wantedly.com/projects/522096
20. © 2025 Wantedly, Inc. 宣伝 ⽣成AIのイベントやります [09-17(⽔)] #wantedly_tn