New Relicで過去データとの比較結果をアラート化する方法～Anomaly Detection完全ガイド～

みなさんこんにちは。マネージドサービス課の塩野です。

今回もNew Relicのクエリ言語であるNew Relic Query Language（NRQL）についての話題です。

前回の記事では、New RelicのNRQLにおけるCOMPARE WITH句を使って、過去のデータと現在のデータを比較する可視化方法を学びました。ダッシュボード上で「先週の同じ時間と比べてトラフィックが増えているか」「昨日と比較してエラー率に変化があるか」といった情報を一目で把握できるようになったかと思います。

しかし、可視化だけでは24時間365日システムを監視し続けることはできません。人間がダッシュボードを常に見続けるのは現実的ではなく、異常が発生したときに自動で通知を受け取る仕組みが必要です。そこで今回は、比較可視化で得た知見をアラート運用に活かす方法を解説します。

本記事では、可視化とアラートの技術的な違いを理解した上で、New Relicが提供するAnomaly Detection（異常検知）機能を使って、過去の傾向から外れた動きを自動で検知する実践的な方法をお伝えします。

blog.serverworks.co.jp

可視化とアラートの技術的な違いを理解する

まず理解しておくべき重要な点は、COMPARE WITHはアラート条件では使用できないということです。これは技術的な制約によるもので、New Relicの公式ドキュメントにも明記されています。

なぜCOMPARE WITHはアラートで使えないのか

New Relicのアラートは「ストリーミングアラート」という仕組みで動作しています。データが到着するたびにリアルタイムで評価を行い、設定したしきい値を超えたらすぐにインシデントを作成する方式です。

一方、COMPARE WITHは複数の時間帯のデータを取得して比較する「表示専用」の機能です。過去1週間前のデータと現在のデータを同時に取得して並べて表示するという処理は、リアルタイムなストリーミング処理とは相性が悪いのです。

アラート条件で使えないNRQL機能

同様の理由で、以下のNRQL機能もアラート条件では使用できません。

COMPARE WITH句（複数の時間範囲の結果を返すため）
TIMESERIES句（複数のデータポイントを返すため）
サブクエリ（複数回のデータ走査が必要なため）

これらはダッシュボードでの可視化には非常に便利な機能ですが、アラート設定では別のアプローチが必要になります。

比較の知見をアラートに活かす：Anomaly Detection入門

COMPARE WITHが使えないなら、どうやって「過去と比べて異常」を検知すればいいのでしょうか。その答えがNew RelicのAnomaly Detection（異常検知）機能です。

Anomaly Detectionの仕組み

Anomaly Detectionは、AIが過去のデータを学習して「予測される正常範囲」を自動で算出する機能です。具体的には、過去1週間から数週間分のデータを分析し、以下の要素を考慮して予測値を計算します。

データの経年変化（トレンド）
データの一貫性（ばらつきの大きさ）
定期的な変動パターン（周期性）

たとえば、毎週月曜日の朝9時にアクセスが急増するパターンがあれば、AIはそれを学習して「月曜朝のスパイクは正常」と判断します。逆に、普段は静かな深夜帯に突然アクセスが増えた場合は、それを異常として検知してくれます。

Seasonality（季節性）設定で精度を高める

Anomaly Detectionでは、データの周期性を明示的に設定することで、より正確な異常検知が可能になります。New Relicでは以下の設定が用意されています。

NEW_RELIC_CALCULATION（デフォルト）

AIが自動でデータの周期性を判断します。データの経過時間、一貫性、定期的な変動パターンなど複数の要素から、最適な周期性を自動で選択してくれます。初めて設定する場合や、データパターンがよくわからない場合はこの設定がおすすめです。

HOURLY（1時間周期）

1時間ごとに繰り返されるパターンがある場合に使用します。たとえば、毎時0分にバッチ処理が走るようなシステムに適しています。

DAILY（24時間周期）

1日の中で決まった時間帯にパターンがある場合に使用します。営業時間と夜間で明確にトラフィックパターンが異なるWebサイトなどに有効です。

WEEKLY（1週間周期）

曜日によって傾向が大きく異なる場合に使用します。平日と週末でアクセス数が大きく変わるサービスや、特定の曜日にメンテナンスやバッチ処理を行うシステムに適しています。

NONE（季節性なし）

周期性を一切考慮しない設定です。常に一定の値を保つべき指標や、周期的な変動がないデータに使用します。

Threshold Sensitivity（感度）の調整

異常を検知する感度は、標準偏差を使って調整します。デフォルトでは「予測値から3標準偏差離れた場合」に異常と判定されます。

感度を高くする（2標準偏差など）: 小さな変化でもアラートが発生。細かい異常を見逃したくない重要なシステム向け。
感度を低くする（4標準偏差など）: 大きな変化のみアラートが発生。ノイズの多いデータや、多少の変動は許容できるシステム向け。

標準偏差の設定は、過去7日間のデータから計算された予測値と実測値のばらつきに基づいて評価されます。

実践：COMPARE WITHの可視化からAnomaly Detectionへ

ここからは、具体的にCOMPARE WITHで得た知見をAnomaly Detectionに活かす手順を見ていきます。

ステップ1: COMPARE WITHでパターンを把握

まず、ダッシュボードでCOMPARE WITHを使ってデータの傾向を観察します。たとえば、Webアプリケーションのレスポンスタイムを1週間前と比較するクエリは次のようになります。

SELECT average(duration) 
FROM Transaction 
WHERE appName = 'WebPortal' 
TIMESERIES 
COMPARE WITH 1 week ago

このクエリで1週間のデータを眺めることで、以下のようなパターンが見えてきます。

毎週月曜日の朝にレスポンスタイムが上昇する
平日と週末で明確にパターンが異なる
水曜日の深夜にメンテナンスウィンドウがある

ステップ2: パターンに基づいてSeasonality設定を選択

COMPARE WITHで観察したパターンをもとに、適切なSeasonality設定を選びます。上記の例では、曜日によって明確にパターンが異なるため、WEEKLY設定が適していることがわかります。

ステップ3: Anomaly Detection条件の作成

New Relicの管理画面から、以下の手順でAnomaly Detection条件を作成します。

Alerts > Alert Conditionsに移動し、+ New alert conditionをクリック
Use guided modeを選択、ガイドに従ってクエリを設定
「Set thresholds」のセクションでAnomalyを選択
SeasonalityとしてWeeklyを選択
Threshold directionでUpper and lower（上下両方）またはUpper only（上昇のみ）を選択
Critical thresholdとして、デフォルトの3標準偏差から開始

この設定により、毎週月曜の朝のスパイクは正常として扱われ、それ以外の時間帯で通常と異なる動きがあった場合のみアラートが発生します。

運用のベストプラクティス

Warning（警告）とCritical（重大）の使い分け

New Relicでは、2段階のしきい値を設定できます。

Critical（重大）: すぐに対応が必要な重大な問題。たとえば「5分間、予測値から3標準偏差以上離れた場合」など、明確に異常な状態を設定します。このアラートが発生したら、担当者がすぐに調査を開始すべきです。

Warning（警告）: 注意が必要だが、すぐに対応は不要な状態。たとえば「5分間、予測値から2標準偏差以上離れた場合」など、やや緩めの条件を設定します。このアラートは、ダッシュボードで状況を確認するきっかけとして使用します。

この2段階設定により、UIの健全性ステータスインジケーターが色分けされます（Critical=赤、Warning=黄色）。重大な問題が発生する前に警告レベルで気づけるため、予防的な対応が可能になります。

アラート疲れを防ぐ感度調整

初期設定では、デフォルトの3標準偏差から始めることをおすすめします。運用を続ける中で、以下のような調整を行います。

アラートが多すぎる場合: 感度を下げる（4標準偏差に変更）、またはSeasonality設定を見直す
異常を見逃している場合: 感度を上げる（2標準偏差に変更）
特定の時間帯だけ問題がある場合: より細かいSeasonality設定（HOURLYやDAILY）を試す

重要なのは、運用しながら継続的に改善していくことです。New RelicのAnomaly Detectionは、データが増えるほど予測精度が向上していきます。

Loss of Signal（シグナル喪失）設定の活用

アラート条件では、データが届かなくなった場合の挙動も設定できます。たとえば、Webサイトが完全にダウンしてトラフィックがゼロになった場合、対応するテレメトリデータもNew Relicに送信されなくなります。

Loss of Signal設定では、以下のような設定が可能です。

新しいインシデントを開く: データが途絶えたことを通知
既存のインシデントを閉じる: 一時的なサービス（コンテナなど）が正常に終了した際に、関連するインシデントを自動でクローズ
インシデントを開かない: 計画的な停止など、シグナル喪失が想定される場合

この設定により、システムダウンの早期検知や、不要なアラートの抑制が実現できます。

まとめ

今回は、New RelicのCOMPARE WITHによる可視化から、Anomaly Detectionを使ったアラート運用への橋渡しについて解説しました。

重要なポイントをまとめると、以下のようになります。

まず、COMPARE WITHはアラート条件では技術的に使用できないため、過去データとの比較は別のアプローチが必要です。その解決策として、New RelicのAnomaly Detectionを活用することで、AIが過去のパターンを学習し、自動で異常を検知してくれます。

実践的な運用では、まずCOMPARE WITHでデータパターンを把握し、そこで得た知見をもとに適切なSeasonality設定を選択します。そしてWarningとCriticalの2段階しきい値を活用することで、予防的な監視と重大な問題への即座の対応を両立できます。

技術的制約を正しく理解した上で適切なツールを組み合わせることで、効果的なアラート運用が実現できます。可視化で異常のパターンを理解し、それをアラート設定に反映させることで、24時間365日の見守り体制が構築できるのです。

この記事がどなたかのお役に立てれば幸いです。