はじめに
カウシェでは2025年9月にNewRelicを導入し、アラート通知の仕組みを大きく改善しました。
従来のモニタリングベースのアラートから、SLO(Service Level Objective)ベースのアラートへ移行したことで、より意味のあるアラート運用が実現できました。
この記事では、モニタリングベースとSLOベースのアラートの違い、具体的な設定方法、そして実際に起きた変化について共有します。
NewRelic導入前の環境
カウシェでは、エラーログが1件でも出たらアラート通知をする、という設定で運用を行っていました。
この環境下で、以下の課題が顕在化していました。
アラート疲れ（Alert Fatigue）
エラーログが発生するたびにSlackへ通知される設定だったため、大量のアラートが飛んでいました。
- 重要なエラーも些細なエラーも同じように通知される
- アラートが多すぎて、本当に重要な問題を見逃してしまう
- 常にアラートが通知されているのでSlackチャンネルを見なくなる
優先度の欠如
全てのアラートが同じ重要度で通知されるため、どれから対応すべきか判断できませんでした。
- どのアラートがどの程度ユーザー影響があるのか分からない
- 結果として、重大なエラーかどうかの判断ができない
これらの課題を解決するために、SLOベースのアラート運用に移行することにしました。
モニタリングベースとSLOベースのアラートの違い
モニタリングベースのアラートとは
モニタリングベースのアラートは、単一イベントの発生をトリガーにした通知方式です。
例：エラーログが1件出たらアラート発火
この方式の特徴：
- エラーが発生したら即座に通知
- 全てのエラーを同じ重要度で扱う
- 「エラーがあるか/ないか」の二値的な判断
SLOベースのアラートとは
SLOベースのアラートは、一定期間におけるサービスレベルの目標達成度をトリガーにした通知方式です。
例：過去1時間のエラーレートが目標の99.9%を下回ったらアラート発火
この方式の特徴：
- 期間ベースでの評価
- ユーザー影響を定量的に把握できる
- 許容範囲内のエラーではアラートが発火しない
具体例で見る違い
シナリオ：1時間に10件のエラーが発生（総リクエスト数：10,000件）
| 観点 | モニタリングベース | SLOベース |
|---|---|---|
| アラート発火 | 10回アラートが発火 | アラートなし（99.9% = 9,990/10,000 成功） |
| 対応要否 | 10回対応が必要に見える | エラーレート0.1%は許容範囲内 |
| 結果 | アラート疲れ、重要な問題の見落とし | 本当に必要なときだけアラート |
シナリオ：1時間に100件のエラーが発生（総リクエスト数：10,000件）
| 観点 | モニタリングベース | SLOベース |
|---|---|---|
| アラート発火 | 100回アラートが発火 | 1回アラート（SLO目標未達） |
| 対応要否 | どれも同じように見える | Critical：即座に対応が必要 |
| 結果 | ノイズに埋もれる | 明確な優先度付け |
SLOベースのアラート設定
NewRelicエージェントを活用して、SLOベースのアラートを設定しました。
レイテンシ：固定値での設定
レイテンシについては、明確な閾値を設定しました。
設定内容
- SLI: Transaction duration（APMで計測されるリクエスト処理時間）を使用
- 閾値: 平均500ms以下
- 評価期間: 5分間のローリングウィンドウ
レイテンシは「これ以上遅いとユーザー体験が悪化する」という明確な基準があるため、固定値での設定をしています。
エラーレート：Anomaly(異常検知)を利用
エラーレートについては、NewRelicのAnomaly Detection機能を活用しました。
固定値ベースのアラートは、「エラーレートが◯％を超えたら通知する」といったように、あらかじめ設定した閾値で判定します。
そのため、深夜のようにトラフィックが少ない時間帯に数件エラーが出ただけでもエラーレートが急上昇し、実際には大きな問題でなくてもアラートが発火してしまうことがあり、誤検知が増えがちです。
一方、Anomaly（異常検知）は過去のトラフィックやエラーレートの傾向と比較し、通常のパターンから外れているかどうかで判断します。
時間帯や曜日によるトラフィックの変動も加味した上で異常を検知するため、不自然なスパイクだけに反応しやすくなり、結果として誤検知を減らすことができます。
起きた変化
異常に気づけるようになった
SLOベースのアラートに移行してから、まず大きく変わったのが「異常が起きているタイミングに気づけるようになった」ことです。
以前は大量のアラートに埋もれ、重要な問題を見逃してしまったり、通知が来ても「どうせ誤検知だろう」と感じてしまい、アラートを無視することが半ば常態化していました。
しかし移行後は、アラートが発火した時点で本当に対応が必要なケースにほぼ限定されるようになり、ユーザー影響のある異常を確実にキャッチできるようになりました。
もちろん、対応不要なアラートが完全にゼロになったわけではありませんが、ノイズは大幅に減少し、重要なアラートを確実に見分けやすくなっています。
実際に、Slackに届くアラート通知の件数は約95%減りました。
| 月 | アラート件数 |
|---|---|
| 9月 | 1,695件 |
| 11月 | 75件 |
定量的な状況把握
SLOダッシュボードを導入したことで、サービス全体の健全性を定量的に把握できるようになりました。
SuccessRate・レイテンシ・APIごとのSLO達成状況などがリアルタイムに可視化され、どの指標が正常でどこに異常兆候があるのかを瞬時に判断できます。
まだプロアクティブな運用には道半ばですが、従来より状況判断が格段にしやすくなりました。
まだまだ改善点はある
とはいえ、まだ改善の余地はあります
1. SLOの継続的な見直し
現在のSLO目標が適切かどうか、定期的に見直す必要があります。ビジネス要件やユーザーの期待値は変化するため、SLOもそれに合わせて調整していく必要があります。
2. エラーバジェットの活用
SLOを設定したことで、エラーバジェット（許容されるエラーの範囲）という概念が使えるようになります。今後は、エラーバジェットの消費状況に応じて開発の優先度を調整する運用を目指しています。
3. チーム全体への浸透
SLOの考え方をチーム全体に浸透させ、開発者全員がサービスの信頼性を意識できる文化を作っていきたいと考えています。
まとめ
モニタリングベースからSLOベースへの移行により、以下を実現できました：
- アラート疲れの解消：意味のあるアラートのみに集中
- 異常検知の精度向上：Anomalyを活用した適切な判断
- ユーザー中心の運用：ユーザー体験を軸にした評価
まだ改善点はありますが、NewRelicを活用したSLOベースのアラート運用は、サービスの信頼性向上に繋がっていると考えています。
カウシェは採用強化中です！
現在、エンジニア・デザイナー・QAエンジニア・PdMなど、プロダクト開発に関わる方中心に様々なポジションで募集しております。
▼募集ポジションはこちら
▼採用ページはこちら
▼カジュアル面談希望はこちら
技術の力で大きなインパクトを生みたい方、プロダクト系の職種はほぼ全方位で採用中なので、ぜひカジュアルにお話ししましょう！
株式会社カウシェのProduct開発チームによる技術ブログです。 「日常に楽しさを」「新しい生活圏のカタチをつくる」をミッション・ビジョンに掲げ「誰かと一緒に」を楽しむソーシャルEC、カウシェを開発しています。 enjoy-working.kauche.com
Discussion