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

by Kazuki Obata

Embed

Start on current slide

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

Slide 6

Slide 6 text

© 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

Slide 7

Slide 7 text

© 2025 Wantedly, Inc. ● New Relic でアプリケーションを監視 ● 2014年：Datadog をインフラ監視に採⽤ ● 2018〜2023年：アプリケーション監視基盤の混在期 ○ 2018年：APM の導⼊、分散トレーシングの整備 ○ 2020年：Logs による SLO 基盤の検証 ○ 2021年：アラート疲れ問題が顕在化、改善プロジェクト始動 i. 後述のアラート設計‧運⽤ポリシーを定めた ○ 2022年：モニタリング‧オブザーバビリティ基盤の⾒直し ● 2024年：Datadogに統⼀移⾏、アプリ‧インフラ監視の⼀元化ウォンテッドリーの監視・アラート運用の変遷アラート設計の起点

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2025 Wantedly, Inc. アラートの指針アラートの分類 ● PagerDuty で通知、#war_room で緊急対応 ● エンドユーザーに直接影響が出るもの ● アラートチャンネルに通知、各チームで対応 ● 事業を継続するための社内業務に著しく影響が出るもの ● 対応が必要なアプリケーションメトリクス ● 対応が必要なインフラストラクチャメトリクス ● 参考程度のアラート ● 対応が必要ないインフラメトリクス

Slide 10

Slide 10 text

© 2025 Wantedly, Inc. アラートの指針 ● Runbook の整備‧影響範囲の可視化 ○ GitHub repository で⼀括管理 i. 急ぎのものや対応が定まっていないものはアラートに直接書いている ii. coverage で拡充できているかの評価 ○ APM の Service Map を活⽤して関連するサービスの可視化 ● PagerDuty の Open/Close で計測、記録 ○ MTTR が計測可能に ● アラート対応の振り返りはポストモーテムで実施アラートそのもの以外の仕組み化

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 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 移⾏

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2025 Wantedly, Inc. Datadog 移⾏でうまくいったこと‧いかなかったこと ● 👎 New Relic のアラートと同じものを Datadog で実装できない ○ e.g. エラーレート‧レイテンシアラート ○ APM ベースのアラートではサンプリングされてしまう ● 👎 設定ミスもあった ○ Datadog では設定が前提なので New Relic のようにレールに乗れない移⾏で⾒えてきた問題

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2025 Wantedly, Inc. 設定ミスへの対応 ● 平均値での閾値設定 ○ ⼀部の異常が埋もれる ○ 対策：最⼩値（min）集計でフラッピング抑制 ● as_count() ＋ avg() 使⽤で平滑化 ○ 本来のピークを検知できない ○ 対策：as_rate() による評価を使う ✅ うるさい‧静かなアラートへの対応 https://docs.datadoghq.com/ja/monitors/guide/as-count-in-monitor-evaluations/