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

ソフトウェア システムの産業開発では、最終製品のフォールト トレランスに細心の注意を払う必要があり、障害や誤動作が発生した場合には迅速に対応する必要があります。監視は確かに障害やクラッシュに効率的かつ迅速に対応するのに役立ちますが、それだけでは十分ではありません。まず、多数のサーバーを管理するのは非常に困難で、多くの人員が必要になります。次に、アプリケーションの状態を予測するには、アプリケーションの構造をよく理解する必要があります。そのため、私たちが開発しているシステムやそのパフォーマンス指標、機能について十分な理解を持つ人材が数多く必要です。これを実行する意思のある人材が十分に見つかったとしても、彼らをトレーニングするには依然として長い時間がかかるでしょう。

私たちは何をすべきでしょうか?ここで人工知能が役に立ちます。この記事は、 予知保全 （予知保全）。このアプローチは急速に人気を集めています。 Habr を含む多数の記事が書かれています。大企業は、サーバーの稼働を維持するためにこのアプローチを使用しています。多数の記事を検討した後、このアプローチを試してみることにしました。それはどうなりましたか？

導入

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

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

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

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

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

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

予知保全を実施するための主なツールは、時系列で異常を検索するタスクです。 異常が発生したとき データでは、しばらくすると 故障や不具合が発生する。異常とは、ある種類のリクエストの実行速度の低下の検出や、一定レベルのクライアント セッションで処理されるリクエストの平均数の減少など、ソフトウェア システムのパフォーマンスにおける何らかの逸脱のことです。

ソフトウェア システムの異常を見つけるタスクには、独自の特徴があります。理論的には、異常の探索は実行されるデータに大きく依存し、ソフトウェア システムのデータは、システムを実行するために使用されるツール、さらにはシステムが実行されているコンピューターによって大きく異なるため、各ソフトウェア システムでは既存の方法の開発または改良が必要です。

ソフトウェアシステムの障害を予測するための異常探索手法

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

すべてのメトリックは、グラファイトを使用してシステムから取得されます。当初、Grafana の標準ソリューションとして Whisper ベースが使用されていましたが、クライアント ベースが拡大するにつれて、Graphite では対応できなくなり、DC のディスク サブシステムのスループットが枯渇しました。この後、より効果的な解決策を見つける決断が下されました。選択は グラファイト+クリックハウスこれにより、ディスク サブシステムの負荷を 2 桁軽減し、占有ディスク領域を XNUMX ～ XNUMX 倍削減することが可能になりました。以下は、graphite+clickhouse を使用したメトリック収集メカニズムの図です (図 XNUMX)。

図2. メトリクスの取得方法

この図は内部文書から抜粋したものです。これは、Grafana (使用する監視 UI) と Graphite 間のデータ交換を示しています。メトリクスは別のソフトウェアを使用してアプリケーションから収集されます – jmxtrans。彼はまたそれらをグラファイトの中に入れます。
Web 統合システムには、障害予測に問題を引き起こす機能がいくつかあります。

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

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

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

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

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

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

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

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

図 4 からわかるように、RNN LSTM はこの期間の異常の探索に対処できました。結果の平均誤差が大きい場合、パフォーマンスに実際に異常がありました。 RNN LSTM を XNUMX つ使用するだけでは明らかに不十分です。これは、適用可能なメトリックの数が限られているためです。異常を探すための補助手段として使えます。

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

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

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

オートエンコーダーは通常のデータでトレーニングされ、その後モデルに入力されたデータ内の異常なものを検出します。まさにこのタスクに必要なものです。残っているのは、どのオートエンコーダがタスクに適しているかを選択することだけです。構造的に、オートエンコーダの最も単純な形式は、前向きの非再帰型ニューラルネットワークであり、これは 多層パーセプトロン (多層パーセプトロン、MLP) は、入力層、出力層、およびそれらを接続する 1 つ以上の隠し層で構成されます。
ただし、オートエンコーダと MLP の違いは、オートエンコーダでは出力層に入力層と同じ数のノードがあり、入力 X が与えられたときにターゲット値 Y を予測することを学習するのではなく、オートエンコーダは独自の X を再構築することを学習するという点です。したがって、オートエンコーダは教師なし学習モデルです。

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

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

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

偽陽性最小化メカニズム

さまざまな異常な状況が発生することや、ニューラルネットワークのトレーニングが不十分な状況が発生する可能性があることから、開発中の異常検出モデルの誤検知を最小限に抑えるメカニズムを開発する必要があると判断されました。このメカニズムは、管理者によって分類されたテンプレート ベースに基づいています。

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

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

その結果、上記のニューラル ネットワーク手法に基づいて、Web 統合システムの障害を予測する実験プログラムが構築されました。このプログラムの目的は、既存の監視データ アーカイブと過去の障害に関する情報を使用して、このアプローチが当社のソフトウェア システムに適しているかどうかを評価することでした。プログラムの動作図を図 7 に示します。

図7. メトリック空間解析に基づく故障予測スキーム

この図は、監視データ フロー (メトリック) 内の異常な期間の検索と、誤検知を最小限に抑えるメカニズムという 2 つの主なブロックに分けられます。注: 実験的な目的で、データは、Graphite が保存するデータベースから JDBC 接続を介して取得されます。
結果として得られる監視システムのインターフェースを以下に示します (図 8)。

図8. 実験監視システムのインターフェース

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

RNN LSTM ニューラル ネットワークを使用して CPU メトリックに基づいて異常を検出する例 (図 9)。

図9. RNN LSTM検出

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

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

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

まとめ

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

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

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

この記事の執筆と妥当性の維持に協力してくれた同僚に感謝したいと思います。 ヴィクター・ヴェルビツキー セルゲイ・フィノジェノフ。

出所： habr.com