新機能スライディングウィンドウアラートのリリース

本投稿は「New Release: Sliding Windows Aggregation Alert Conditions」と「What’s On Deck for Alerts: Sliding Windows Aggregation!」の抄訳です。

新機能リリース

本日、Sliding Windows Aggregation Alerts (SWA)を正式にリリースします。これは、指定した期間に変動するシグナルを滑らかにする素晴らしい方法です。SWAがどのように機能するのか、またSWAアラートの条件が正しく機能するように「ガードレール」を提供する方法については、Whats’on deck（翻訳では本記事後半）に記載しています。
SWAのドキュメントはこちらのリンクからご覧いただけます。
上のリンク先の記事で触れている制限を設定するためには、UIのスライダーを使って間隔を指定します。

スライダーに表示される値は、ウィンドウの継続時間(window duration)の設定値に応じて変化します。このスクリーンショットでは、最小値が青で、最大値が赤で、現在の選択値が緑で囲まれています。スライダを動かすと、ウィンドウの継続時間の設定に応じて、さまざまな可能性のある値に変化します。また、スライダーの表示を「秒」に変更することで、より多くの選択肢が得られます（例えば、上のスクリーンショットでは、「分」ではなく「秒」に変更すると、最も低い値が30秒になります）。
ウィンドウの継続時間を編集すると、このスライダーは新しい値に応じて調整されます。継続時間に対して設定可能な値が1つしか存在しない場合、スライダーは完全に消え、その値がボックスに表示されます。例えば、ウィンドウの表示時間を1分に設定した場合、スライドの間隔は30秒以下には設定できないため、30秒に固定されます。このときスライダーは消えて、その値が自動的に選択されています。
また、追加機能として、Windowの最大継続時間（別名「集計ウィンドウ」）を120分に引き上げました。この最大値の引き上げは、SWAだけでなく、NRQLのすべてのアラート条件で利用可能です。

揮発性の高いシグナルにアラートを出す必要があり、集約された値を使いたいというユースケースには、ぜひこの機能を使ってみてください（CPU %やスループットがすぐに思い浮かびます）。SWAを使ってみて良かったこと、疑問に思ったことなどがありましたら、下記までご連絡ください。

ここからは、What’s on Deckとして投稿された内容でSWAの詳細を説明します。

What’s on Deck

スライディングウィンドウ自体はすでにNRQLクエリで利用できるものです。このドキュメントで詳細を読むことをお勧めします。

どのような点が素晴らしいのでしょうか？

• 不安定なシグナルや変動の激しいシグナルをより一貫して集約することが可能に
• 頻繁でない、または一貫性のないシグナルに対して、より正確で信頼性の高いアラートが可能に
• トラブルシューティングの容易性 - アドホックなNRQLクエリでスライディング・ウィンドウの動作を復元可能に
• 合計以外の集約関数が使用可能に

OK、どうやって使うの？

NRQLクエリのスライディングウィンドウに関するドキュメントには基本的な内容が記載されていますが、ここでは、「クエリ結果の合計」のアラート条件をSWAを使用するように変換するために使用する（そして皆さんも使用できる）式について簡単に説明します。
まず最初に、この式をご紹介します。今のところNRQLで再現するために、通常のアラート条件では許可されていないTIMESERIESを使用しています。

「3分間に1回以上、クエリの結果の合計が100を超える」というような閾値を設定した場合、閾値ウィンドウは3分となります。集約ウィンドウを1分（デフォルト）に設定したとします。この場合、毎分、直近の3分相当のデータが集約されることになります。
これがどのようなものか、例を示します。各ブロックが1つの集計ウィンドウのデータで、ブロックの中にはそのウィンドウの集計値が入っているとします。集約関数にはsumを使うことにします。

• 時刻1分と時刻2分では、評価が行われません。これはバッファが満たされているためで、まだ3分間相当のデータはありません。
• 時刻3分では、バッファのデータがすべて（3分相当）揃ったので、値を集計することができます。時刻3分での評価値は6（1＋2＋3）となります。
• 時刻4分では、3分間のウィンドウが1分ずつスライドし、9という値が評価されます（2 + 3 + 4）。
• 時刻5分では、3分間のウィンドウが再び1分ずつスライドし、12という値が評価されます（3 + 4 + 5）。
• といった具合です。

クエリで TIMESERIES や SLIDE BY を使用できるようになりますか？

これを可能にする計画はありますが、現時点では、これらの値を制御するためにはUIのスライダーを使ってください。ただし、SLIDE BYで使用する集約ウィンドウはTIMESERIESで使用する閾値ウィンドウよりも小さくする必要があり、集約ウィンドウは閾値ウィンドウの約数である必要があります。

さて、ここからが本題です。

スライドバイ条件が動作しなくなる方法:

これらの方法は設定できないように実装する予定ですが、その理由を皆さんにご理解いただきたいと思います。

スライドバイを壊す1つ目の方法：SLIDE BY設定と集約ウィンドウの値が同じ

これはひどい方法ではありませんが、実際にはスライドバイの機能が得られていないことになります。
SLIDE BYと集約ウィンドウを同じ値にすると、実際には従来のアラートの動作になってしまいます。つまり、次のように、きれいな、段階的なスライドになるのではなく

最終的には「カスケード」集約となり、次のような形になります。

スライドバイを破壊する2つ目の方法: 集約ウィンドウよりも大きいスライドバイ設定を使用する。

これは、評価されないギャップが発生してしまうため、条件を崩すにはかなりひどい方法です。
例えば、閾値ウィンドウを3分に設定し、集計ウィンドウを6分に設定したとします。この場合、「TIMESERIES 3 minutes SLIDE BY 6 minutes」のようになります。
次のような動作になります。

スライドバイを破壊する第3の方法：集約ウィンドウを均等に分割しないスライドバイ設定を使用する

これは、条件を崩すには少々ひどい方法です。スライドバイの設定が集計ウィンドウよりも低いため、たまに隙間ができてしまうのです。
例えば、スライドバイウィンドウを60秒、集約ウィンドウを90秒に設定した場合を考えてみましょう。最初の1分間は順調ですが、1分おきに、スライドバイの設定が集約ウィンドウの半分だけ進み、集約ウィンドウの半分が評価されない「ギャップ」として残ります。

SWAは聞き覚えがあると思われるかもしれません。それは、私の重大な発表の中にこの機能が含まれていたからです。まだご覧になっていない方は、このリンクからチェックされることをお勧めします。

Sliding Windows Aggregationは、NRQLのアラート条件における「クエリ結果の合計の(Sum of query results)」しきい値タイプ（ここで説明されています）に代わるものです。これは徐々に置き換えられる予定で、SWAがリリースされた後もしばらくの間は、クエリ結果の合計のしきい値を使用することができます。

「クエリ結果の合計」のしきい値の何が問題なのでしょう？

一言で言えば、データの合計だけだからです。最大値、最小値、平均値などは得られず、データポイントを加算して時間軸上の合計を算出するだけです。これは確かに便利なケースもありますが、平均値、最小値、最大値、その他の集約関数が必要なケースは他にもたくさんあります。

つまり......スライディングウィンドウアグリゲーションがこの問題を解決するということですね？

はい、そうです。スライディングウィンドウ集約(SWA)を使用すると、集約関数を使用する際に、NRQLクエリのスライディングウィンドウを制御することができます。常に合計のみではなく、例えばaverage を使用するとスライディングウィンドウでの平均を得られます。