サムネイル

はじめに

この記事は、DMMグループ Advent Calendar 2025 の 15 日目の記事です。

プラットフォーム開発本部で認可サービスの開発をしている juve_534 です。
私が所属するチームは認可サーバの開発・運用を責務としています。直近で認可サーバのリプレイスを行いました。今回は、リプレイス中に見つかった監視についての課題と対策について紹介します。

課題

認可サーバを運用するためエンドポイントのレイテンシー監視をしています。
閾値はエンドポイントごとに定めており、課題が見つかったエンドポイントは p99 を 100ms で監視していました。
あるときからレイテンシー悪化が発生するようになり、p99 のレイテンシーが 30 分ほど 400ms 近い値になっていました。原因を調査したところ、別システムの日次バッチ連携による HTTP リクエストが原因で、一時的にレイテンシーが悪化していました。
既存の認可サーバでは問題の解決に時間がかかること、サービス品質としては許容範囲内な悪化であったことから、リプレイスが完了するまでは一時的に監視の閾値を変更することにしました。バッチが動いている時間帯以外は、今までの閾値で問題なかったため、単純にモニターの閾値を上げてしまうと問題を検知できない可能性があります。

バッチ実行時→レイテンシー悪化を考慮した閾値で監視したい
上記以外の時間帯→今まで通りの閾値で監視したい

上記 2 つを満たすため、Datadog のダウンタイムを使って複数モニターを運用しました。

対策

Datadog にはダウンタイムという機能があり、特定時間帯だけモニターをミュートにできます。この機能を使い、バッチが動いている時間帯はモニターをミュートにするようにしました。

これだけだとバッチが動いている時間帯で、想定外のレイテンシー悪化が起きても検知できないため、バッチの影響を加味した閾値を設定したモニターを作成しました。一方、このモニターではスケジュールの設定で「繰り返し」を選択し、バッチが動いていない時間帯をダウンタイムに設定しました。これにより、想定外のレイテンシー悪化が起きても検知できるようにしました。