ニューラルネットワークを使用して異常を探し、故障を予測します

ソフトウェアシステムの産業開発では、最終製品の耐障害性と、障害や障害が発生した場合の迅速な対応に細心の注意を払う必要があります。 もちろん、監視は障害や失敗へのより効率的かつ迅速な対応に役立ちますが、それだけでは十分ではありません。 まず、多数のサーバーを追跡するのは非常に困難であり、多数の人員が必要です。 次に、アプリケーションの状態を予測するには、アプリケーションがどのように動作するかをよく理解する必要があります。 そのため、私たちが開発しているシステムやその性能、特徴をよく理解している人材が多く必要となります。 これを行う意欲のある人材を十分に見つけたとしても、彼らを訓練するにはまだ多くの時間がかかると仮定しましょう。

何をするか？ ここで人工知能が私たちを助けます。 この記事では次について話します 予知保全 (予知メンテナンス)。 このアプローチは積極的に人気を集めています。 ハブレに関する記事を含め、多数の記事が書かれています。 大企業は、サーバーのパフォーマンスを維持するためにこのアプローチを最大限に活用しています。 多数の論文を検討した結果、このアプローチを試してみることにしました。 何が起こったのでしょうか？

導入

開発されたソフトウェア システムは遅かれ早かれ稼働します。 ユーザーにとって、システムが障害なく動作することが重要です。 緊急事態が発生した場合は、最小限の遅延で解決する必要があります。

ソフトウェア システムのテクニカル サポートを簡素化するため、特に多数のサーバーがある場合、通常、実行中のソフトウェア システムからメトリクスを取得し、その状態を診断して、障害の正確な原因を特定できるようにする監視プログラムが使用されます。 このプロセスはソフトウェア システム監視と呼ばれます。

図 1. Grafana 監視インターフェイス

メトリクスは、ソフトウェア システム、その実行環境、またはシステムが実行されている物理コンピュータのさまざまな指標であり、メトリクスを受信した時点のタイムスタンプが付いています。 静的分析では、これらのメトリックは時系列と呼ばれます。 ソフトウェア システムの状態を監視するために、メトリクスはグラフの形式で表示されます。時間は X 軸に、値は Y 軸に沿って表示されます (図 1)。 実行中のソフトウェア システムから (各ノードから) 数千のメトリクスを取得できます。 それらはメトリクス (多次元時系列) の空間を形成します。

複雑なソフトウェア システムでは多数のメトリクスが収集されるため、手動による監視は困難な作業になります。 管理者が分析するデータの量を減らすために、監視ツールには潜在的な問題を自動的に特定するツールが含まれています。 たとえば、ディスクの空き容量が指定したしきい値を下回ったときにトリガーを起動するように構成できます。 サーバーのシャットダウンやサービス速度の重大な低下を自動的に診断することもできます。 実際には、監視ツールは、すでに発生した障害を検出したり、将来の障害の単純な症状を特定したりするのに優れた仕事をしますが、一般に、起こり得る障害を予測することは依然として困難です。 メトリクスの手動分析による予測には、資格のある専門家の関与が必要です。 生産性が低いのです。 潜在的な障害のほとんどは気付かれない可能性があります。

最近、ソフトウェア システムのいわゆる予知保全が、大手 IT ソフトウェア開発会社の間でますます普及してきています。 このアプローチの本質は、人工知能を使用して、システムの劣化につながる問題を、障害が発生する前の初期段階で発見することです。 このアプローチは、システムの手動監視を完全に排除するものではありません。 これは、監視プロセス全体を補助するものです。

予知保全を実装するための主なツールは、時系列で異常を検索するタスクです。 異常が発生したとき データでは、しばらくすると、 失敗や失敗があるだろう。 異常とは、あるタイプのリクエストの実行速度の低下や、一定レベルのクライアント セッションでサービスされるリクエストの平均数の減少など、ソフトウェア システムのパフォーマンスにおける特定の逸脱を指します。

ソフトウェア システムの異常を検索するタスクには、独自の特性があります。 理論的には、異常の検索は実行されるデータに大きく依存しており、ソフトウェア システムのデータはシステムを実装するツールによって大きく異なるため、ソフトウェア システムごとに既存の手法を開発または改良する必要があります。 、どのコンピュータで実行されているかまで。

ソフトウェアシステムの障害を予測する際の異常を検索する方法

まず第一に、失敗を予測するというアイデアはこの記事からインスピレーションを得たということは価値があります。 「IT監視における機械学習」。 異常の自動検索によるアプローチの有効性をテストするために、NPO クリスタ社のプロジェクトの XNUMX つである Web-Consolidation ソフトウェア システムが選択されました。 以前は、受信したメトリックに基づいて手動監視が実行されていました。 システムは非常に複雑であるため、JVM インジケーター (ガベージ コレクターの負荷)、コードが実行される OS のインジケーター (仮想メモリ、OS CPU 負荷の %)、ネットワーク インジケーター (ネットワーク負荷) など、多数のメトリクスが取得されます。 )、サーバー自体 (CPU 負荷、メモリ)、ワイルドフライ メトリクス、およびすべての重要なサブシステムのアプリケーション独自のメトリクス。

すべてのメトリクスは、グラファイトを使用してシステムから取得されます。 当初、ウィスパー データベースは grafana の標準ソリューションとして使用されていましたが、クライアント ベースが拡大するにつれて、DC ディスク サブシステムのスループットを使い果たしたため、graphite では対応できなくなりました。 その後、より効果的な解決策を見つけることが決定されました。 その選択は有利に行われた グラファイト+クリックハウスこれにより、ディスク サブシステムの負荷が 2 桁減少し、占有ディスク容量が XNUMX ～ XNUMX 分の XNUMX に削減されました。 以下は、グラファイト+クリックハウスを使用してメトリクスを収集するメカニズムの図です (図 XNUMX)。

図 2. メトリクスを収集するためのスキーム

この図は内部文書から抜粋したものです。 これは、grafana (使用する監視 UI) とグラファイト間の通信を示しています。 アプリケーションからのメトリクスの削除は、別のソフトウェアによって実行されます。 jmxtrans。 彼はそれらをグラファイトに入れます。
Web Consolidation システムには、障害を予測する際に問題を引き起こす多くの機能があります。

1. 傾向はよく変わります。 このソフトウェア システムにはさまざまなバージョンが用意されています。 それらはそれぞれ、システムのソフトウェア部分に変更をもたらします。 したがって、このようにして、開発者は特定のシステムのメトリクスに直接影響を与え、傾向の変化を引き起こすことができます。
2. 実装機能、およびクライアントがこのシステムを使用する目的によって、以前の機能低下がなくても異常が発生することがよくあります。
3. データセット全体に対する異常の割合は小さい (< 5%)。
4. システムからインジケーターを受信する際にギャップが生じる可能性があります。 短期間のうちに、監視システムがメトリックの取得に失敗することがあります。 たとえば、サーバーが過負荷になっている場合です。 これはニューラル ネットワークのトレーニングにとって重要です。 ギャップを総合的に埋める必要があります。
5. 異常のあるケースは、多くの場合、特定の日付/月/時刻 (季節性) にのみ関連します。 このシステムには、ユーザーによる使用に関して明確な規制があります。 したがって、メトリクスは特定の時間にのみ関連します。 このシステムは常に使用できるわけではなく、年に応じて選択的に数か月だけ使用されます。 あるケースではメトリクスの同じ動作がソフトウェア システムの障害につながる可能性があるが、別のケースではそうではないという状況が発生します。
   まず、ソフトウェアシステムの監視データの異常を検出する方法を分析しました。 このトピックに関する記事では、異常の割合がデータセットの残りの部分に比べて小さい場合、ニューラル ネットワークの使用が提案されることがよくあります。

ニューラル ネットワーク データを使用して異常を検索するための基本ロジックを図 3 に示します。

図 3. ニューラル ネットワークを使用した異常の検索

メトリクスの現在のフローのウィンドウの予測または復元の結果に基づいて、実行中のソフトウェア システムから受信したものとの偏差が計算されます。 ソフトウェア システムとニューラル ネットワークから取得したメトリクスの間に大きな違いがある場合、現在のデータ セグメントは異常であると結論付けることができます。 ニューラル ネットワークを使用すると、次の一連の問題が発生します。

1. ストリーミング モードで正しく動作するには、ニューラル ネットワーク モデルをトレーニングするためのデータには「通常の」データのみが含まれている必要があります。
2. 正しく検出するには、最新のモデルが必要です。 メトリクスの傾向や季節性の変化により、モデル内で多数の誤検知が発生する可能性があります。 更新するには、モデルが古くなる時期を明確に判断する必要があります。 モデルの更新が遅かったり、早かったりすると、おそらく、多数の誤検知が発生することになります。
   多発する誤検知の探索と防止も忘れてはなりません。 最も頻繁に発生するのは緊急事態であると想定されています。 ただし、トレーニングが不十分であることによるニューラル ネットワーク エラーの結果である可能性もあります。 モデルの誤検知の数を最小限に抑える必要があります。 そうしないと、誤った予測により、管理者がシステムをチェックするために多大な時間を浪費することになります。 遅かれ早かれ、管理者は「偏執的な」監視システムに応答しなくなるだけです。

リカレント ニューラル ネットワーク

時系列の異常を検出するには、次を使用できます。 リカレントニューラルネットワーク LSTMメモリを搭載。 唯一の問題は、予測時系列にのみ使用できることです。 私たちの場合、すべての指標が予測可能であるわけではありません。 RNN LSTM を時系列に適用する試みを図 4 に示します。

図 4. LSTM メモリ セルを使用したリカレント ニューラル ネットワークの例

図 4 からわかるように、RNN LSTM はこの期間の異常の検索に対処できました。 結果の予測誤差 (平均誤差) が大きい場合、実際には指標に異常が発生しています。 単一の RNN LSTM を使用するだけでは、少数のメトリックに適用できるため、明らかに十分ではありません。 異常を検索するための補助的な方法として使用できます。

故障予測のためのオートエンコーダ

オートエンコーダ – 本質的には人工ニューラルネットワークです。 入力層はエンコーダー、出力層はデコーダーです。 このタイプのすべてのニューラル ネットワークの欠点は、異常の位置を適切に特定できないことです。 同期オートエンコーダ アーキテクチャが選択されました。

図 5. オートエンコーダの動作例

オートエンコーダーは通常のデータでトレーニングされ、モデルに供給されたデータ内で異常なものを検出します。 このタスクに必要なものだけです。 残っているのは、このタスクに適したオートエンコーダを選択することだけです。 アーキテクチャ的に最も単純な形式のオートエンコーダーは、順方向、非戻り型のニューラル ネットワークです。これは、次のようなものに非常によく似ています。 多層パーセプトロン (多層パーセプトロン、MLP)、入力層、出力層、およびそれらを接続する XNUMX つ以上の隠れ層を備えます。
ただし、オートエンコーダーと MLP の違いは、オートエンコーダーでは出力層が入力層と同じ数のノードを持ち、入力 X によって与えられるターゲット値 Y を予測するようにトレーニングされる代わりに、オートエンコーダーがトレーニングされることです。したがって、オートエンコーダーは教師なし学習モデルです。

オートエンコーダのタスクは、入力ベクトル X 内の異常な要素に対応する時間インデックス r0 ... rn を見つけることです。この効果は、二乗誤差を検索することによって達成されます。

図 6. 同期オートエンコーダー

オートエンコーダーが選択された場合 同期アーキテクチャ。 その利点は、ストリーミング処理モードを使用できることと、他のアーキテクチャに比べてニューラル ネットワーク パラメーターの数が比較的少ないことです。

誤検知を最小限に抑えるメカニズム

開発中の異常検知モデルでは、さまざまな異常事態が発生することに加え、ニューラルネットワークの学習が不十分な状況も考えられるため、誤検知を最小限に抑える仕組みを開発する必要があると判断しました。 この仕組みは、管理者が分類したテンプレートベースに基づいています。

動的なタイムライン変換のアルゴリズム (DTW アルゴリズム、英語のダイナミック タイム ワーピングに由来) を使用すると、時間シーケンス間の最適な対応関係を見つけることができます。 音声認識で最初に使用されました。XNUMX つの音声信号が同じ元の話されたフレーズをどのように表現するかを判断するために使用されました。 その後、他の分野でも応用が見出されました。

誤検知を最小限に抑える主な原則は、ニューラル ネットワークを使用して検出された疑わしいケースを分類するオペレーターの助けを借りて標準のデータベースを収集することです。 次に、機密化された標準とシステムが検出したケースが比較され、そのケースが誤りであるか、または失敗につながるかについて結論が下されます。 DTW アルゴリズムは、XNUMX つの時系列を比較するために正確に使用されます。 主な最小化ツールは依然として分類です。 多数の参照ケースを収集した後は、ほとんどのケースが類似しており、同様のケースが発生するため、システムはオペレータに質問することが少なくなることが予想されます。

その結果、上記のニューラル ネットワーク手法に基づいて、「Web-Consolidation」システムの障害を予測する実験プログラムが構築されました。 このプログラムの目的は、監視データと以前の障害に関する情報の既存のアーカイブを使用して、ソフトウェア システムに対するこのアプローチの能力を評価することでした。 プログラムのスキームを以下の図 7 に示します。

図 7. 計量空間分析に基づく故障予測スキーム

この図では、監視データ ストリーム (メトリクス) 内の異常な期間の検索と、誤検知を最小限に抑えるメカニズムという XNUMX つの主要なブロックを区別できます。 注: 実験目的で、データは JDBC 接続を介してデータベースから取得され、グラファイトによって保存されます。
開発の結果得られた監視システムのインターフェースは以下のとおりです（図8）。

図 8. 実験モニタリング システムのインターフェイス

インターフェイスには、受信したメトリックに基づいて異常の割合が表示されます。 この場合、領収書はシミュレートされます。 すでに数週間分のすべてのデータがあり、障害につながる異常が発生した場合を確認するために徐々にロードしています。 下部のステータス バーには、オートエンコーダを使用して決定された、特定の時点でのデータ異常の全体的な割合が表示されます。 また、RNN LSTM によって計算された予測メトリックに対して別のパーセンテージが表示されます。

RNN LSTM ニューラル ネットワークを使用した CPU パフォーマンスに基づく異常検出の例 (図 9)。

図 9. RNN LSTM 検出

本質的には通常の異常値ですが、システム障害につながるかなり単純なケースは、RNN LSTM を使用して正常に計算されました。 この期間の異常指標は 85 ～ 95% で、80% (しきい値は実験的に決定された) を超えるものはすべて異常とみなされます。
アップデート後にシステムが起動できなくなった場合の異常検出の例。 この状況はオートエンコーダーによって検出されます (図 10)。

図 10. オートエンコーダ検出の例

図からわかるように、PermGen は 100 つのレベルで止まっています。 オートエンコーダーは、これまでそのようなものを見たことがなかったため、これを奇妙に感じました。 ここでは、システムが動作状態に戻るまで、異常は XNUMX% のままです。 すべてのメトリクスに異常が表示されます。 前述したように、オートエンコーダーは異常の位置を特定できません。 このような状況では、オペレーターはこの機能を実行する必要があります。

まとめ

PC「Web-Consolidation」は数年前から開発されています。 システムはかなり安定した状態にあり、記録されたインシデントの数は少ないです。 ただし、障害が発生する 5 ～ 10 分前に障害につながる異常を発見することは可能でした。 場合によっては、障害を事前に通知することで、「修復」作業の実行に割り当てられる予定時間を節約することができます。

実施された実験に基づいて、最終的な結論を出すのは時期尚早です。 これまでのところ、結果は矛盾しています。 一方で、ニューラル ネットワークに基づくアルゴリズムが「有用な」異常を発見できることは明らかです。 一方で、依然として偽陽性の割合が高く、ニューラル ネットワークの資格のある専門家によって検出されたすべての異常を検出できるわけではありません。 欠点としては、ニューラル ネットワークを通常に操作するには教師によるトレーニングが必要になるという事実が挙げられます。

故障予測システムをさらに開発し、満足のいく状態にするために、いくつかの方法が考えられます。 これは、システムの状態に大きな影響を与える重要なメトリクスのリストに追加され、システムに影響を与えない不要なメトリクスが破棄されることにより、障害につながる異常が発生したケースをより詳細に分析するものです。 また、この方向に進むと、失敗につながる異常のあるケースに特化してアルゴリズムを特殊化する試みを行うことができます。 別の方法もあります。 これはニューラル ネットワーク アーキテクチャの改良であり、それによってトレーニング時間が短縮され、検出精度が向上します。

この記事の執筆と関連性の維持に協力してくれた同僚に感謝の意を表します。 ヴィクトル・ヴェルビツキー そしてセルゲイ・フィノジェノフ。

出所： habr.com