Download as PDF, PPTX
![[事例紹介]スクラッチソフト「XFDを導入してみると」](https://cdn.slidesharecdn.com/ss_thumbnails/xfd-120729014834-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
機械学習によるリモートネットワークの異常検知
- 1.
- 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 – 公衆網上の損失など不可避な性質を持つ物 普段とは違う、異常事態を検知する事が出来ないか
- 12.
- 13. 手段としての機械学習 機械学習の目的 -> 異常値を識別すること – 外れ値検出のための識別関数を作る 収集したエラーカウンタ（70項目ほど）と時間密度から、 それぞれの項目について標準偏差を計算する 標準偏差の2倍を閾値として与えることで上位2％程度を 抽出 具体的には偏差値70以上のスコアを検出
- 14. 散布図 縦軸はTCPシーケンス異常カウンタ 横軸は50Mbyteのキャプチャ取得所要時間 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 0100 200 300 400 500 600 700 abnormal sequence number この部分を調べてみたら 何か分かるかも？
- 15. データの性質 各データはパケットキャプチャから抽出した、独立したエ ラーカウンタであり、それぞれの値の相関は薄い(時間密 度のみ考慮) 相関が薄いため高次元の特徴抽出は必要ない カウンタが少ない、または時間密度が低い場合は検出 不要 カウンタ別警告レベルの重みづけ自動化は今後の課題 – ゆくゆくは教師あり学習に放り込みたい
- 16.
- 17. 実装の概要 偏差スコアの精度を高めるため、標本となるデータは過 去の同一時間帯、月末月初、曜日などを考慮して収集 機械学習だけでなく、一発レッドなエラーはフィルタとして 個別に実装 一発レッドな例 – Bittorrent （フラッディングによるポート枯渇） – SMTP レスポンスエラー (400番以上の頻発) – SMB I/Oタイムアウト （Disk故障の予兆） – DHCP NAK （IP Pool枯渇）
- 18. エラーカウンタの実装 パケットキャプチャがあるので、L7まで元気よく読む DeepPacket 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
- 24.
- 25. 半年ほど（ユーザー情シスに）営業した感想 色々な情シス部門が存在する（ワタシ含め） – アウトソースの管理業務が多い –バリバリキャプチャ読む人にはリーチしにくい 可視化にも意欲的でない？ – 「可視化ツール入れたけど見てない」例多し 前からちょっと思ってたけど、ターゲット間違ってね？ うわっ…私の戦略、ダメすぎ？
- 26. 今後どうすんの？ やっぱり価値の分かる人と組まないとムリ 問題発見ツールとして提案活動とコラボすると強力 –エンドユーザーへの提案実績はボチボチ出始めた 顧客の了解を取った上で、サポートツールとして導入し、 ソリューション営業のツールとしても使っていく 局所的なパケットから問題を検知する技術を考えていく
- 27.