관련링크

最近、人工知能、機械学習、ディープラーニング分野が第4次産業革命の風に乗って熱く浮上しています。その中には、アルファゴがイセドル9段に勝った事件が、私たちが感じるには最も現実的に触れたきっかけではないかと思います。私は最初はこのような機械学習、ディープラーニングが何なのかについて作成しようと思いましたが、インターネットに投稿された多くの文が存在し、実際にWhaTabにディープラーニングを適用しながら悩んだこととプロセスを簡単にまとめて話してみたいと思います。

障害は予測できますか？

まず、顧客やユーザーに最も多く聞かれたのは障害は予測できませんか？ または障害を認識し、知らせることができますか？です。結論から申し上げますと、まだ難しいです。なぜなら、障害が何かに対する答えを正確に出せないからです。もし普段CPU使用率が30%程度のサーバーがあるというとき、ある日CPU使用率が60%になったとしたらこれは障害か？ への答えを出すのがあいまいです。

異常値の兆候検知(Anomaly detection)機能は導入が容易ですが、異常値の基準が異なるだけで、異常値が検出されたといっても障害と判断する根拠が何かについて明確な答えを出すことはできません。では、数％以上に設定すれば良いのではないかと言われたら、既存のしきい値ベースの方式と異なるものがないという限界点があります。これは私たちが求めているディープラーニングではないということです。

ディープラーニング(Deep Learning)

再びディープラーニングの話に戻り、ディープラーニングは収集したデータを学習して判断を出すことができるという利点があります。それでは、学習をさせるとしましょう。データは準備ができています。膨大な量のデータ(ビッグデータ)があります。何を学びますか？ 判断を出すためのデータは多いが、判断された結果が不足しています。つまり、分類されたデータがないというのが現在の限界です。

ディープラーニングを適用するためのプロセス

① データを収集します。

② 集められたデータを分類(Classification)する。

③ データを学習してモデル(Model)を作成します。

④ APIを貼り付け、サービスに適用します。

ディープラーニングで勝手に分類されるようにできるのか？

たとえば、1台のサーバーを10年間管理してきたとしましょう。10年間の値のサーバーのCPU、メモリなどの動作に関するすべての資料を収集して保存してきたとなった時に学習するとしたら、蓄積されたデータを入れるのではなく、状況に関する分類が必要です。問題があった状況、イベントをして負荷量が増えた状況、突然サーバーがダウンした状況など、このような状況を分類できるときに機械に学習をさせることができ、これらの学習に基づいて判断まで出すことができます。

これまで適用しながら感じていた悩み、限界点を説明させていただき、これからはどう解決したかについて話してみたいと思います。前述のように、すべてのケースの分類を行うには時間がかかりすぎます。不可能ではありませんが、現在のステップでできる方法は、最初に問題になった、または問題になる可能性のあるパターンを見つけることです。これらのパターンを見つけたら、それに似たデータを集め、集められたデータに基づいてそのパターンが正しいかどうかを確認し、パターン別データを分類することです。

ディープラーニングで分類されたパターン

幸いなのは、SaaS(サス)でモニタリングを提供するという利点として、特定のサービスだけデータを収集するのではなく、さまざまな顧客やサービス、環境に関するデータを収集しており、パターンごとに様々なケースを収集することができました。個々のサービスからこれらのケースを収集しようとすると、問題の発生頻度が少なく、特定のパターンが発生するためのさまざまな状況に関するデータを収集するのがかなり困難だったと思います。

WhaTapでのディープラーニング

それでは、実際にどのように適用されたかを見てみましょう。

ヒートマップとは

ヒートマップは応答時間分布図です。アプリケーション(WAS)で発生したトランザクションは、終了時間に対してx軸、応答時間に対してy軸と表記され、それぞれのx、y軸に対するそれぞれの区間が決まります。また、該当区間別のトランザクションの数が累積され、累積された数だけ色が濃く表示される形です。

一般的なヒートマップ

ヒートマップパターンの種類

① 横線パターン

複数のトランザクションが一定時間内に終了するパターン。 リソースを取得したり外部HTTS Callを行うときにタイムアウトや遅延が発生した場合に発生する。

② 縦線パターン

呼び出し時点が異なるが同じ時点でトランザクションが終了するパターン。

トランザクションが使用する共通リソースに一時的なボトルネックが発生した場合に発生する。

③ フライングパターン

特定のリソースやログなどの共通リソース不足現象に間隔をあけて波打つようなパターンで発生する。

④ 過負荷パターン

全体または一部の応答で一時的に問題が発生する一時的にトランザクションが密集するパターンで発生する。

⑤ 暴走パターン

過剰なトランザクションの要求や負荷が発生した場合、応答時間が全体的に増加するパターンで発生する。

ヒートマップ 横線、縦線、フライング、過負荷、暴走パターンについて、それぞれ多数のケースが学習されており、リアルタイムで収集されるデータで学習されたパターンと同様のパターンが発生すると通知を受け取ることができる形になっています。

まとめ

開発者として、あれこれ調査を(グーグル)してみても、どのように実装したのかどうすればいいのか、コードはほとんど見つけることもできず、序盤には苦しいだけでした。しかし、結果として、私がしたことは、データを分類してモデルを学習させることがすべてであり、コードも数行ではありません。最も多くの時間を費やした部分は、データを分類する部分であり、この分類を機械に知らせるためのプロセスでした。

クラウド化、マイクロサービスで構造化され、それぞれのサーバーやアプリケーションのサイズは小さくなりますが、数は増えています。個人が管理するサーバー、アプリケーションも数十代から数百台、多くは千台まで増えています。このような管理要素が増えるにつれて、今後のモニタリングは、より多くのより多様なデータを提供することを越えて、すぐに必要なデータだけ、問題の状況だけをすぐに確認できるサービスに発展する必要があると思います。