New Relic NRQLのCOMPARE WITHを使って実現する「いつも通り」の可視化 - インフラ負荷を秒で判断する比較術

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

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

インフラの運用監視をしていると、誰もが一度は直面する判断があります。それは「このCPU使用率80%は、今すぐ対応すべき異常なのか?それとも正常な範囲内なのか?」という問いです。

月曜朝の定例バッチ処理中であれば80%は「いつも通り」の状態ですが、深夜のアイドルタイムに同じ80%が記録されていれば明らかに「異常」といえます。インフラには、絶対的なしきい値だけでは判断できない「周期的な正常状態」が存在します。

多くの監視設定では「CPUが90%を超えたらアラート」といった固定値を設定しますが、インフラの負荷は生き物のように変動します。毎週のバックアップ処理、毎晩のデータ同期、特定曜日のアクセス集中など、これらをすべて固定のしきい値で管理しようとすると、正常なスパイクでもアラートが鳴り響き、現場は疲弊してしまいます。

そこで必要なのが「過去の自分たち」を物差しにするという考え方です。今回は、New RelicのNRQLで利用できるCOMPARE WITH機能を使って、この「いつも通り」を一瞬で可視化するテクニックを解説します。

COMPARE WITHの基本

基本構文と使い方

NRQLクエリの末尾にCOMPARE WITH句を追加するだけで、現在のグラフに過去のデータを重ね合わせて表示できます。

1週間前と比較する例を見てみましょう。

SELECT average(host.cpuPercent) 
FROM Metric 
WHERE entity.name = 'prod-app-01'
TIMESERIES 
SINCE 3 hours ago 
COMPARE WITH 1 week ago

このクエリを実行すると、グラフには2本の線が表示されます。現在のデータは実線で、1週間前のデータは点線(または薄い色)で表示されます。これだけで「先週の月曜日もこの時間帯は負荷が上がっていたな」ということが一目でわかります。

ビジネスサイクルが1週間単位のシステムにおいて、最も信頼できる比較対象は「先週の同じ曜日・同じ時間」です。週次のバッチ処理やユーザーの週間ログイン傾向を把握する際に特に有効でしょう。

利用できる場所と制限

COMPARE WITH機能は、ダッシュボードとクエリビルダーで使用できます。ただし、重要な制限としてNRQLアラート条件では使用できません。アラートで過去との比較を行いたい場合は、New RelicのBaseline Alert機能を検討するとよいでしょう。

また、比較対象として指定できる期間は、お使いのNew Relicプランのデータ保持期間に依存します。標準的なプランでは過去数ヶ月分のデータが保持されていますが、Data Plusなどの上位プランではさらに長期間のデータが利用可能です。

実務で使える比較パターン3選

公式ドキュメントには基本的な使い方が記載されていますが、「いつと比較すべきか」という指針は現場の経験に委ねられています。ここでは、インフラ実務で特に役立つ3つの比較パターンを紹介します。

① 週次サイクルの確認

用途は定例バッチ処理やユーザーの週間アクティビティパターンの把握です。狙いは「いつも通りの月曜日」であることを確認し、不要な調査時間をカットすることにあります。

SELECT average(host.cpuPercent) 
FROM Metric
WHERE entity.name LIKE 'prod-%'
FACET entity.name
TIMESERIES 
SINCE 1 day ago 
COMPARE WITH 1 week ago

この比較により、今週と先週の同じ曜日・時間帯のCPU使用率を並べて確認できます。もしパターンが大きく異なっていれば、何か変化があったことを示すシグナルになります。

② 直近変更の影響確認

用途はOSパッチ適用、設定変更、リリース作業後の検証です。狙いは「昨日の今頃」や「数時間前」と比較して、リソース消費量に変化や劣化がないかを証明することです。

SELECT average(duration) 
FROM Transaction 
WHERE appName = 'ProductionAPI'
TIMESERIES 
SINCE 2 hours ago 
COMPARE WITH 1 day ago

変更作業を実施した後、このようなクエリで前日同時刻のパフォーマンスと比較することで、変更による影響を素早く把握できます。実線と点線がほぼ重なっていれば、変更の影響は少なかったと判断できるでしょう。

③ 長期トレンドの把握

用途は月末処理や前年のセール時との比較、キャパシティプランニングです。

SELECT count(*) 
FROM Transaction 
WHERE transactionType = 'Web'
TIMESERIES 
SINCE 7 days ago 
COMPARE WITH 4 weeks ago

4週間前(約1ヶ月前)との比較により、トラフィックの増加傾向やシステム負荷の変化を長期的な視点で捉えられます。来月のキャパシティ計画を立てる際の重要な判断材料になります。

TIMESERIESとの組み合わせ

COMPARE WITHの真価は、TIMESERIES句と組み合わせることで発揮されます。

SELECT average(host.memoryUsedPercent) 
FROM Metric 
WHERE entity.name = 'db-master-01'
TIMESERIES AUTO
SINCE 6 hours ago 
COMPARE WITH 1 week ago

TIMESERIES句を使うことで、時系列グラフとして比較データが可視化されます。現在と過去のデータが同じグラフ上に描画されるため、傾向の違いが視覚的に把握しやすくなります。

TIMESERIESにはAUTOを指定することで、New Relicが自動的に適切な時間間隔を選択してくれます。もちろんTIMESERIES 10 minutesのように明示的に間隔を指定することも可能です。

運用への組み込み

ダッシュボードへの配置

このクエリをダッシュボードに配置すると、障害対応の初動が劇的に変わります。

運用時の流れはシンプルです。まずアラートが鳴ったらダッシュボードを確認します。次に実線(今)と点線(過去)を見比べます。両者がほぼ重なっていれば「静観」、大きく乖離していれば「即座に調査」と判断できます。

この判断プロセスにより、無駄な緊急対応を減らし、本当に必要な調査に集中できるようになります。

Baseline Alertへのステップアップ

COMPARE WITHで可視化した内容をさらに自動化したい場合は、New RelicのBaseline Alert機能の活用を検討してください。

Baseline Alertは、COMPARE WITHと同じく「過去の傾向」という考え方を採用していますが、AIが自動的に正常な範囲を学習し、その範囲から外れた時だけ通知してくれる機能です。手動でしきい値を設定する必要がなく、システムの特性に応じて動的に判断してくれます。

COMPARE WITHで可視化して理解した後、Baseline Alertで自動化するという流れが、運用の効率化につながるでしょう。

応用的な使い方のヒント

複数期間を意識した分析

比較対象はhours、days、weeksの単位で指定できます。

-- 3時間前との比較
COMPARE WITH 3 hours ago

-- 2日前との比較
COMPARE WITH 2 days ago

-- 4週間前との比較
COMPARE WITH 4 weeks ago

どの単位を選ぶかは、システムの特性や調査目的によって変わります。日次バッチがあるシステムなら1日前、週次の定期処理があるなら1週間前との比較が有効です。

データ保持期間の考慮

比較できる期間は、契約プランのデータ保持期間内に限られます。標準プランでは数週間から数ヶ月程度のデータが保持されていますが、より長期のデータが必要な場合はData Plusプランの検討が必要になります。

過去1年前のデータと比較したいといった要望がある場合は、事前にデータ保持設定を確認しておくことをおすすめします。

まとめ

インフラエンジニアにとって、正常と異常の境界線は常に変動しています。固定のしきい値だけでは捉えきれない「周期的な正常状態」を理解することが、効率的な運用監視には不可欠です。

COMPARE WITH機能を使えば、過去の同じタイミングと現在を比較することで「いつも通り」の状態なのか、何か変化があったのかを瞬時に判断できます。この小さな工夫が、深夜のオンコール対応を減らし、本当に重要な問題に集中する時間を生み出してくれます。

まずは負荷が高いサーバーに対してCOMPARE WITH 1 week agoを実行してみてください。「このスパイク、先週もあったんだ」というその一瞬の気づきが、あなたの運用業務を変える第一歩になるはずです。

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

blog.serverworks.co.jp