NRQLアラート条件に追加された新しい集計方法とどれを選ぶべきかの指針

本記事は「New aggregation methods for NRQL alert conditions 」および「Relic Solution: How Can I Figure Out Which Aggregation Method To Use?」の抄訳記事です。

10月4日（月）より、ユーザーの皆様にNRQLアラート条件に2つの新しいストリームの集計方法をご提供いたします。これは週が進むにつれて完全に展開される予定です。まだアカウントに表示されていない場合は、週末までには表示されるはずです。

「ストリーミング集約方法（streaming aggregation method）」とは、特定の集約ウィンドウのデータがすべて揃ったことをいつ知らせるかのロジックです。ウィンドウが閉じられると、データは1つのポイントに集約され、閾値に対して評価されます。この記事では、まず新しい集計方法および既存の集計方法の紹介をし、その後いつどのケースでどの方法を選択すべきかについて説明をします。

新しい集計方法の追加と既存の集計方法

なぜ追加されたのですか？：データの遅延により、多くのユーザーが不正確なアラート違反を受けていました。これは、データの到着が遅すぎて評価できない可能性があるためでした。今回の変更には2つのメリットがあります。

• ユーザーがデータの挙動に合わせて柔軟に集計方法を選択できるようになります。
• 潜在的なデータに起因する誤警告(false alerts)が減少します。
• インシデントの検出までの時間が短縮され、解決までの時間が短縮されます。
• 従来の方法ではデータの遅延に対応するために解決までの時間を伸ばす必要がありました。

なにが追加されたのですか？: 従来の集計方法に加えて、新たに2つの集計方法を導入します。

ケイデンス（従来の集計方法）
イベントフロー（新しいデフォルトの集計方法）
イベントタイマー（もう一つの新しい集計方法）

以下では、新しいストリーミングの集約方法について説明し、これまで使用してきた手法との比較を行います。

まず、いくつかの重要なコンセプトを紹介します。

• タイムスタンプ：New Relic に送信されたデータポイントに付随するタイムスタンプです。
• ウォールクロックタイム：New Relic のサーバー時刻です。
• 集約（アグリゲーション）ウィンドウ： 集約し評価を行うデータバケットの別名です。”Window duration”の設定でウィンドウの大きさを調整します。
• Window duration： ストリーミングアラートの集約時に集約・評価されるデータバケットのサイズです。"WD "と省略されます。
• 遅延／タイマー：以前は「評価オフセット（Evaluation Offset）」と呼ばれていたこの設定には、使用する方法によって異なる機能があります。

以下の節では、評価ウィンドウが「出荷」されるという表現は、そのウィンドウ内のすべてのデータポイントが1つのデータポイントに集約され、そのデータポイントがアラートのしきい値に対して評価されることを意味します。集約された評価ウィンドウが出荷されると、それ以上のデータポイントを受け入れることはできません。

ここからそれぞれの方法について説明します。

Cadence

これは皆さんが使ってきた方法です。各評価ウィンドウは、ウォールクロックの時刻をタイマーとして使用し、「遅延（Delay）」設定と同じ時間だけ待機します。この方法では、評価に間に合わずに大量のデータがドロップされることがあります。データの取りこぼしは、誤ったアラートの原因となります。

WDを1分に設定し、Delayを3分に設定した場合: 各1分間のアグリゲーションウィンドウは、「自分の」分を超えて3分間待機します。9:55のウィンドウは、ウォールクロックが9:59になった瞬間に出荷されます。

WD を1分に設定し、Delay を0に設定した場合：各 1 分間の評価ウィンドウは、その時間が終了するとすぐに出荷されます。9:55のウィンドウは、ウォールクロックが9:56になった瞬間に出荷されます。

Event Flow

これの方法は、データが頻繁に取り込まれ、イベントの広がりが少ない(*)ソースに最適です。 スループットが高いメトリクスがこの良い例です。Event Flowが新しくストリーミング集約のデフォルトの方法になります(**)。

各集約ウィンドウは、自身の遅延設定を過ぎたタイムスタンプの到着が確認され始めるまで待機します。一つでも到着すればすぐに出荷されます。この方法は到着したデータのタイムスタンプに依存しており、ウォールクロックの時刻には最早関係ないことに注意してください。言い換えればデータが流れてこない場合、システムは集計を行わずにデータが流入するのをひたすら待ちます。

WDを1分に設定し、Delayを3mに設定した場合：1分ごとの集計ウィンドウは、4分後以降のタイムスタンプが到着し始めるまで待機します（1分ごとの集計ウィンドウにDelay3分ぶん加えた値）。9:55のウィンドウは、9:59以降のタイムスタンプの到着をシステムが確認し始めた時点で出荷されます。

WDを1mに設定し、Delayを0に設定した場合：各1分間のアグリゲーションウィンドウは、そのアグリゲーションウィンドウ以降のタイムスタンプの到着をシステムが確認するとすぐに出荷されます。9:55のウィンドウは、9:56以降タイムスタンプの投薬をシステムが確認し始めた時点で出荷されます。

Event Timer

この方法は、頻繁に来ないデータやバッチで来る可能性のあるデータに最適です。クラウドインテグレーションのデータやたまにしか発生しないエラーログの検知はこの方法の良い例です。

各集約ウィンドウには、Delay設定（このアグリゲーション方法のUIではTimerと表記しています）の値に設定されたタイマーがあります。タイマーはその集約ウィンドウに（データポイントのタイムスタンプに基づく）最初のデータポイントが到着するとすぐに開始されます。そのウィンドウに別のデータポイントが到着するたびにタイマーはリセットされます。タイマーが0になると評価ウィンドウは出荷されます。

後の集約ウィンドウの出荷準備が整っていても、先のウィンドウのタイマーがまだ動いている場合、後のウィンドウは先のウィンドウが終了するのを待ってから、自分自身を出荷することに注意してください。例えば、9:56のウィンドウのタイマーが0になっていても、9:55のウィンドウのタイマーが0になっていない場合、9:56のウィンドウは9:55のウィンドウのタイマーが0になるまで待ちます。

WDを1分に設定し、Delayを3分に設定した場合：各1分間のアグリゲーションウィンドウは、そのウィンドウの最後のデータポイントが到着してから3分間待機します。新しいデータポイントが到着するたびに、タイマーは3分にリセットされます。タイマーが0になると、そのウィンドウは出荷されます。

WDを1分に設定し、Delayを0に設定した場合：各1分間のアグリゲーション・ウィンドウは、最初のデータポイントが到着するとすぐに出荷されます。

どの集計方法を使うべきか

次によくあるユースケースで、状況に応じてどの集計方法を使うかについて考えてみたいと思います。

集計方法は3つありますが、Cadenseはレガシーな方法につけた名前にすぎません。後方互換性のために利用できるようにしていますが、いまのところ、Event FlowやEvet Timerよりも優れた機能を持つ使用例はありません。

集約ウィンドウには様々な値を設定できますが、この記事では議論を簡単にするためにデフォルトの1分を使用します。

なぜこれが重要なのでしょうか？

集約ウィンドウで集約がトリガーされると、現在そのウィンドウにあるすべてのデータポイントが、NRQLクエリで指定した関数（sum、average、min、maxなど）に基づいて集されれます。集約により、多くのデータポイントが 1 つの数値になり、しきい値に対して評価されるために送信されます。

重要なのは、一度集計が行われると、そのウィンドウにはそれ以上のデータポイントは追加されないということです。つまり、より多くのデータポイントが表示されるのを待つことと、可能な限り早くウィンドウを集約して評価すること（Mean Time To Detectを短縮すること）のバランスを取ることが重要です。より多くのデータポイントが到着するよう集計がすぐに開始されないようにする一方で、必要以上に待たされないようにすることでより早くアラートを受け取ることができます。

Event Flow

New RelicのAPMエージェントやインフラストラクチャエージェントからデータが送られてくる場合、監視しているすべてのエンティティについて、少なくとも1分に1回はデータが到着する可能性があります。データが頻繁に、かつ比較的安定して届く場合は、Event Flowを利用するのがベストです。

また、データに「タイムスタンプのずれ」が多すぎないことも重要です。つまり、New Relicではどのタイミングでも比較的狭い時間範囲のタイムスタンプを持つデータポイントが表示される必要があります。

これは、すべての集約ウィンドウを「出荷」するために、イベントフローが後続のウィンドウに入ってくるデータポイントに依存しているためです。例えば、12:03以降のタイムスタンプを持つデータが入ってきた場合、システムは12:00～12:01のアグリゲーションウィンドウを「出荷」します（2分の遅延設定を想定）。これは、「アクティブ」ウィンドウを数分過ぎたデータが到着したので、そのウィンドウは満たされているはずであり、それを集約して評価のために送信する時が来たのだと仮定しています。

ここで覚えておくべき重要な要素は、後から入ってくるデータによりシステムを駆動させているということです。つまり、New Relicが1つのデータポイントしか確認していない状況で、次のデータポイントが到着するまで1時間かかるのであれば、1時間後にならないとシステムは駆動しない（最初のデータポイントが集約されて評価されない）ということになります。一方で、New Relicが見る次のいくつかのデータポイントが、最初のタイムスタンプから数秒から数分しか経過していない場合は、イベントフローが適しています。

Event Flowに最適なユースケース：

• APMエージェントデータ
• インフラストラクチャエージェントデータ
• サードパーティから頻繁かつ確実に送られてくるあらゆるデータ
• （API pollingではなく）AWS Metric Streamから来るほとんどのAWS Cloudwatchのメトリクス
  • 一部のAWS Cloudwatchデータは、Metrics StreamかPollingかに関わらず、非常に不定期です（S3ボリュームデータなど） - この場合はイベントタイマーを使用します。

このように、最も頻繁に使用されるケースをカバーしているため、Event Flowを新しいデフォルト設定にしました。

Event Timer

データが一貫性なくNew Relicに入ってくる場合や、タイムスタンプ間のギャップが大きい場合は、Event Timerが最適です。

タイムスタンプ間のギャップが大きい場合は、現在のアグリゲーション ウィンドウが一杯になり終わるまで、一定期間待つ方が良いでしょう。これは、システムが（Event Flowのように）後続のデータポイントを待つのではなく、アクティブな集約ウィンドウでタイマーが期限切れになるのを待つことを意味します。

たとえば、エラーの数を返すクエリでは、まったくカウントされないまま何分も経過したかと思うと、突然1分間に5つのエラーが表示されることがあります。以下にその例を示します。

FROM Transaction SELECT count(*) WHERE error IS TRUE FACET appName

Event Timerを使用すると、任意の集約ウィンドウのタイマーが切れるまでシステムは駆動しません。また、集計を開始するためには、そのウィンドウのデータが到着するだけで十分であり、（Event Flowのように）後続のウィンドウのデータが到着するまで待つ必要はありません。

上の例と同じように、システムが12:00-12:01の集計ウィンドウにデータが入ってくるのを監視している場合、最初に表示されたデータポイントがタイマーを開始します。タイマーの設定が1分の場合、システムはそのウィンドウにさらにデータが到着するのを1分間待ちます。新たなデータが到着すると、到着するたびにタイマーがリセットされます。タイマーが0になると、12:00-12:01の集計ウィンドウが集計され、評価されます。

イベントタイマーに最適なユースケース：

• New Relic が生成したUsage Data (遅延が大きく、データポイントが送信されると約 1 時間は次のデータが投稿されないことがわかっている)
• Pollingで取得しているCloud Integrationsのデータ（GCPやAzure、またはAWSのAPI Polling方式）
• いつデータが送られてくるかわからないが、データが送られてきた場合は、1分単位のバッチで送られてくることが多く、1分あたり1つのデータポイントしかない場合
  • これは、1分間の集計ウィンドウと0秒のタイマー設定を使用したEvent Timerで非常にうまく機能します（任意の1分間に最初のデータポイントが表示された時点で、その1分間にそれ以上のデータポイントが表示されないことがすでにわかっているため、その時点でウィンドウを出荷することができます）。
  • まばらなデータや頻度の低いデータを提供するクエリ - エラーカウントがその好例です。