機械学習を活用して見えないインフラ障害を検知――九州のISPサービスを担う、QTnet運用エンジニアの挑戦：＠ITソフトウェア品質向上セミナー2018

九州のISPサービスを担う、QTnet運用エンジニア木村氏は、ITインフラの監視に機械学習を活用し、これまで見えていなかった異常の検知や予測に取り組んでいる。「機械学習に関しては、ほぼど素人の取り組みだが、ソフトウェア開発に活用する際のヒントになれば」と謙遜しながら、その歩みを紹介した。

[高橋睦美，＠IT]

QTnet 技術部 監視システムグループ 木村裕氏

　九州電力グループの電気通信事業者としてITサービス、インターネット接続サービスを提供しているQTnetでは、ITインフラの監視に機械学習を活用し、これまで見えていなかった異常の検知や予測に取り組んでいる。

　＠ITが2018年12月14日に開催した「＠IT ソフトウェア品質向上セミナー AI／機械学習、自動化で開発現場にも訪れるシンギュラリティにどう備えるか」のランチセッション「九州のISPサービスを担う運用エンジニアが挑戦！　リソースデータを活用した異常の予測検知で機械学習を使ってみた」において、同社 技術部 監視システムグループの木村裕氏は、「機械学習に関しては、ほぼど素人の取り組みだが、ソフトウェア開発に活用する際のヒントになれば」と謙遜しながら、その歩みを紹介した。

しきい値に基づくインフラ監視、2つの課題

　以前からオープンソースソフトウェア（OSS）の活用に積極的だったQTnetでは、ネットワーク機器やサーバ、ストレージの稼働監視に「Zabbix」「RRDtool」を採用してきた。SNMP（Simple Network Management Protocol）を用いてデータを取得し、あらかじめ定めたしきい値を超えるような数値が出れば監視サーバに送り、運用者に異常の発生を通知する、という仕組みだ。

監視の構成

　木村氏らはこの取り組みを一歩進め、「アラートが出るのを待つという今までの“受動的な監視”から、“能動的に取りに行く監視”へのシフトを行っている。そして、サイレント障害やこれまで目に見えなかった異常を捉えられるようにしていきたい」と話す。

　これまでのしきい値に基づく監視には、主に2つの課題があった。

　一つは、しきい値の範囲で発生するサイレント障害の検知が困難という問題だ。しきい値の範囲内であるため明らかな異常ではないが、一定水準以上の値が続くと顧客に迷惑を掛ける恐れがある。同氏ら監視グループではトレンドをその都度確認したり、しきい値を調整したりして、こうした隠れた問題を捉えたいと考えていた。

　もう一つは、運用監視チームの負荷の問題だ。QTnetは通信事業者として多数のネットワーク機器やサーバ類を運用しているが、監視のメトリクスごとに、一つずつ異なるしきい値を手作業で設定していくのは面倒だ。それだけではなく、運用工数の増大はひいてはコストの増大につながるため、この部分を何とか効率化したいと考えていた。

　そこで着目したのが機械学習だ。「まず、収集したデータを用いて機械学習を行い、予測分析を行えば、しきい値の中に隠れている潜在的障害を検知できるのではないかという思いがあった。また、機械学習で予測した値から逸脱したものを異常として検知することで、そもそものしきい値の設定が不要になるのではないかと考えた」

実践してみて初めて分かった機械学習の利点と課題

　こうして機械学習に取り組み始めたQTnetでは、ZabbixとRRDtoolという監視の仕組みはそのままに、収集したデータをCassandraやRedis、KafkaといったOSSのツール群と組み合わせて蓄積し、機械学習ライブラリのSparkを用いて教師なし学習、分析を実施した。

機械学習、分析の基盤の構成

分析モデルの作成方法

　ネットワークトラフィックを分析してのサイレント障害検知にはSparseCodingを、またディスクやメモリの使用率増減にはARIMAを、という具合に、課題とデータの特性に応じたアルゴリズムを利用した。特にSparseCodingでは、平日と休日とではトラフィックパターンが異なることを踏まえ、それぞれ学習させることで正しい分析につなげたという。

SparseCodingの特徴

ARIMAの特徴

ARIMAの分析に適したデータ、SparseCodingの分析に適したデータ

　「実践を通じ、幾つか分かってきたポイントがある。QTnetでは教師なし学習を行ったが、教師なし学習にはシグネチャを考える必要がなく、『何か異常が起きているらしい』という判断の実装が簡単だったし、過去に起きたことのない事例にも対応できた。裏を返せば、ナレッジがないため若干、信ぴょう性に欠けるところもある。シグネチャなら過去の類似障害を見てすぐに異常を判断できるが、今回のケースでは『なぜ異常なのか』の判断に困り、後々確認する必要があった」

　そもそも監視を楽にするために導入したはずが、実際にはトレンドデータとにらめっこしながらPDCAを回す必要があるため、現状では、全体的に見たら、監視に関する稼働時間が増えている側面もあるそうだ。

　また、データが少しずつ増減してカレント値と学習データとの差が広がっていくと、異常検知の頻度、すなわち誤検知の増加につながる可能性がある。

　「そのため、トレンドが変化したら、現在のトレンドデータに沿った形で分析できるよう、学習データをもう一度再シミュレーションして最適化する必要がある」

　QTnetの場合、1日に5回以上の変化を2日連続で検知したら「トレンドが変わった」と判断し、新しい学習を行っているが、その「トレンドの変化」の見極めは人間が行う必要がある。

　誤検知と見逃しの相関関係にも注意が必要だ。

　「誤検知を減らすために定義の精度を下げると、見逃しの確率が上がってしまう。『見逃したくないから』と定義の精度を上げると、今度は誤検知が増えてしまうという問題がある。実際には、妥協するポイントを設定することが大事だ。余計なアラートで現場に負担をかけてしまうことは申し訳ない。しかし、『ある程度の誤検知はしょうがないよね』というおおらかな気持ちを持つことが大事かもしれない」

誤検知と見逃し

数値の分析からワードクラウド分析へ、広がる可能性

　新たな取り組みには試行錯誤が付きものだ。木村氏らも、たとえうまくいかないことがあっても「くじけない心」で取り組んできたという。最近では経営層から過剰な期待を持たれがちな機械学習だが、「決して魔法ではない、という気持ちを秘めつつ頑張ってきた」

　これまでの取り組みを振り返ってみると、「設備の異常をシグネチャのようなしきい値を付けずに検知することがある程度可能になっており、まずまずいい結果を出している」と言う。

　ただ、実現できたのはあくまで数値型の分析だ。次は、syslogやアプリケーションのログなど各種ログデータを収集し、テキスト型の分析、ワードクラウドの分析をやっていきたいという。

　「普段よりも『fail』といった文字列が多いといった判断や、本来出力されるはずのログが出力されていないといった状況を確認し、ログから異常を見つけられたらいいなと考えている。今後もくじけず、前向きに取り組んでいく」