機械学習によるリモートネットワークの異常検知
•
20 likes•8,307 views
warning of remote network with machine learning
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 機械学習によるリモートネットワークの異常検知
Similar to 機械学習によるリモートネットワークの異常検知 (20)
More from cloretsblack
Recently uploaded
Recently uploaded (9)
機械学習によるリモートネットワークの異常検知
- 2. 最初にお知らせ 本日の資料は後ほど公開しますので、リラックスしてお 聞きください 安心してください 数式は出てきません 専門的な内容を期待していた方、すみません
- 3. 自己紹介 @Clorets8lack 某ユーザー企業の国際インフラ担当 トラブルシューティング専用パケットレコーダー 「Sonarman ソナーマン」を開発 株式会社デベルアップジャパンを設立し、経営、開発、 営業、ユーザーというマルチキャスト（複数役）を実践し つつ奮闘中 自称:意識高い系情シス
- 4. 今日お話すること 開発の背景 海外の実情に即した異常検知とは 機械学習について 実装について 導入結果 余談
- 5. 海外のネットワーク管理（ヘルプデスク含む） ってどんな仕事？ 距離と時差に大きく制約される – 遅延、損失との戦い （インドでは600msを超えることも） – なかなか現地に行けない – 現地業者のレベルが様々、横展開できない コスト削減圧力が高い – 現地の人件費が安いため、IT費用が相対的に大き く見える – 「この仕組みを入れると何人減らせるの？」 – 「そしてそれはいくらのコスト削減なの？」 とか言われる
- 6. 日本では考えられないトラブルの数々 偽物のケーブル スイッチングハブの代わりに使われる無線ルータ 頻発する回線障害（道路工事でケーブル切ったりとかしょっちゅう） 約束という概念が通用しない現地ベンダ 国策による通信のフィルタリング プロバイダのレベルも様々 不可避な災害や気象条件（洪水、地震、雷、静電気等）
- 7. 海外における運用上の問題 現地ベンダに任せきりになってしまう 現地スタッフは頼りにならない本社情シスには協力してく れない 直接PCを触れない情シスが、現地のために何が出来る か？ 1.遠隔でのヘルプデスクサポート（日本品質） 2.現地ベンダの適切なコントロール（チェック機能の提供） 3.高度なトラブルシューティング（効率重視、悪即斬）
- 8. ［CM］ Sonarman（ソナーマン）をつくりました （2ページだけお付き合いください） パケットキャプチャをローテーションしつつ、 継続収集する装置(備えあればうれしい) 障害の原因調査が楽になる – 発生時刻にさかのぼれる – 正常時と異常時の挙動を容易に比較できる 論理的な障害対応（闇雲なトライアンドエラーの排除） 「再現を待たなくていい」という利便性 遠隔サポート業務のコスト（時間）を大幅に削減する
- 9. 実物 この製品に機械学習による障害検知 機能を搭載した ● ファンレス小型筐体 ● Web UI ● x64アーキテクチャの小型サーバ ● 別途、スイッチのポートミラーリング機能 が必須 ● 無償VM版を公開中 http://develup-japan.co.jp/wp/works/sonarman-free-edition/
- 10. 障害検知に必要な機能 パケットキャプチャは容量が大きすぎて扱いづらい – 巨大サイズは宿命 – L7デバッグができることとのトレードオフ 一定サイズに細切れにされたキャプチャ毎に、どのよう な異常が検出されたのかを可視化する必要がある あと、通知もしてほしい でも、しょうもない警告がバンバン来るのは勘弁な
- 11. ネットワークの異常検知とはどうあるべきか 国、地域、規模、業種、使用機材、生活態様等によって、 ネットワークの状態は様々に変化する 画一的な閾値やフィルタのようなものは設定しづらい 一方、エラーは容易に検出できるが本質的に解決すべ きでない事もある – PassMTUなどで発生する ICMP Host Unreachable – 公衆網上の損失など不可避な性質を持つ物 普段とは違う、異常事態を検知する事が出来ないか
- 13. 手段としての機械学習 機械学習の目的 -> 異常値を識別すること – 外れ値検出のための識別関数を作る 収集したエラーカウンタ（70項目ほど）と時間密度から、 それぞれの項目について標準偏差を計算する 標準偏差の2倍を閾値として与えることで上位2％程度を 抽出 具体的には偏差値70以上のスコアを検出
- 14. 散布図 縦軸はTCPシーケンス異常カウンタ 横軸は50Mbyteのキャプチャ取得所要時間 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 0 100 200 300 400 500 600 700 abnormal sequence number この部分を調べてみたら 何か分かるかも？
- 15. データの性質 各データはパケットキャプチャから抽出した、独立したエ ラーカウンタであり、それぞれの値の相関は薄い(時間密 度のみ考慮) 相関が薄いため高次元の特徴抽出は必要ない カウンタが少ない、または時間密度が低い場合は検出 不要 カウンタ別警告レベルの重みづけ自動化は今後の課題 – ゆくゆくは教師あり学習に放り込みたい
- 17. 実装の概要 偏差スコアの精度を高めるため、標本となるデータは過 去の同一時間帯、月末月初、曜日などを考慮して収集 機械学習だけでなく、一発レッドなエラーはフィルタとして 個別に実装 一発レッドな例 – Bittorrent （フラッディングによるポート枯渇） – SMTP レスポンスエラー (400番以上の頻発) – SMB I/Oタイムアウト （Disk故障の予兆） – DHCP NAK （IP Pool枯渇）
- 18. エラーカウンタの実装 パケットキャプチャがあるので、L7まで元気よく読む Deep Packet InspectionをCで実装 – libpcapを使用 – IPv6周りの実装が面倒（小並感） 省力化目的で一部 Wiresharkのフィルタを使う – TCPシーケンス異常系検出は便利 実網の運用経験を活かして警告パラメータを実装
- 19. 実際の導入について 海外での導入実績 – 海外拠点LANの監視 – OpenFlowでスイッチのポートミラーリング機能を制御 – 海外3拠点に導入（従業員60名未満の拠点） 国内での導入実績 – 基幹系システムの夜間処理監視 – 時差のきつい地域からのサーバアクセス監視
- 20. 海外拠点での使用方法 LAN内のWindowsサーバでキャプチャ & ローテーション VirtualBox上でSonarmanのVMを動かす – Windows上のキャプチャ格納ディレクトリをVMと共有 – VMからキャプチャファイルを参照しつつ機械学習 – 問題発生時にはVMから警告メールを飛ばす ミラーリング cap SonarmanVM 警告メール 異常
- 21. 見つけたもの 異常値には何らかの問題が介在している例が殆ど DNSエラー -> ルータに設定したDNSサーバの故障を検知 ARP重複 -> BYODのAndroid端末のdhcpd不具合、なぜか古いアドレ スを適切に開放できておらず、IPが被る TCPコネクション毎の累積転送量 -> 巨大ダウンロードの検出 TCP/UDP比率 -> ウイルス検出 TCP再送 -> 現地NASで再送多発、20-30%程度の通信容量ロス インタ フェースのネゴシエーション不良？（調査中） かなり良い精度で問題に到達できている （というかエラーをカウントしているから、ある意味当然）
- 22. 導入した感想 今まで見えなかった問題が可視化されるため結構仕 事が増えた 米国など日本との時差のきつい地域ではサポートレベ ルが向上した（外人特有のオーバーリアクションで超感謝される） 夜間処理エラーなどの原因も切り分けたので、他人の仕 事も増やしたｗ 困ったときの頼れる可視化ツール 面倒事が舞い込む恐怖の可視化ツールでもある。。
- 23. ［余談］ 製品開発と営業活動の軌跡 自分が欲しいものを作る これ超便利だし絶対売れるよ（ソースは俺） 情シス（同業者）の人たち、あんまり興味無さそう。。 あ、あれ？ ← New
- 25. 半年ほど（ユーザー情シスに）営業した感想 色々な情シス部門が存在する（ワタシ含め） – アウトソースの管理業務が多い – バリバリキャプチャ読む人にはリーチしにくい 可視化にも意欲的でない？ – 「可視化ツール入れたけど見てない」例多し 前からちょっと思ってたけど、ターゲット間違ってね？ うわっ…私の戦略、ダメすぎ？
- 26. 今後どうすんの？ やっぱり価値の分かる人と組まないとムリ 問題発見ツールとして提案活動とコラボすると強力 – エンドユーザーへの提案実績はボチボチ出始めた 顧客の了解を取った上で、サポートツールとして導入し、 ソリューション営業のツールとしても使っていく 局所的なパケットから問題を検知する技術を考えていく