Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ネットワーク運用とIoT

3,776 views

Published on

Network operation with IoT

Published in: Engineering
  • Be the first to comment

ネットワーク運用とIoT

  1. 1. ネットワーク運用と npstudy#11
  2. 2. 自己紹介 •@Clorets8lack •ユーザー企業の情シス部門で国際インフラを担当 •株式会社デベルアップジャパン代表 •トラブルシューティングを効率化する パケットレコーダー「Sonarman」を販売中
  3. 3. 今日お話しすること • ユーザー企業のネットワークに を適用してみた • 収集データの活用 • トラブルシューティングの効率化 ※本日の資料は後ほど公開します
  4. 4. 進み方 • 情シスが抱える問題と原因 • やったこと • ユースケース • 考えてる事とか
  5. 5. とは • ネットワークに接続された機器で 情報を取得し、分析することで  便利になる • それってネットワークエンジニアが いつもやってる事じゃない? • 今回は少し違うやり方を考える
  6. 6. 情シスが抱える悩み • 定期的に取得する必要は無いが、 ピンポイントで欲しい情報がある – 企画業務のための情報収集 – 障害対応 – サイジング – 監査対応 例 ・サービス毎のコネクション数 ・特定アドレスへのメール件数
  7. 7. パターン1 • そもそも可視化の仕組みがない – 観測範囲では結構な割合 • データが取得できないと 設計の精度が落ちる – 提案がフワっとする 通らない – 後工程に影響 • 数字を元に合理的な判断が出来ない • 負荷テスト結果を見て判断できない 意味無い
  8. 8. パターン2 • 可視化はしているが、監視製品や 対象、プロトコルによって 取れない情報がある – 製品の機能に依存 – 種類が多いと変更、追加が面倒 • 色んな製品を使う – とっちらかる • 使い方学習地獄 – なるべくシンプルにやりたい
  9. 9. まとめ • 計測、可視化、定量化が単純に難しい – 等にそもそも情報が無い – 製品導入のコストパフォーマンス • でもデータを取れるなら取りたい – 調査依頼をレスポンス良く返せば 信頼感が増す – 数値を元にした議論ができる – 不安が無くなる もっとカジュアルに情報を取れないか
  10. 10. 作りました • 遠隔拠点に置くパケットキャプチャ装置 • 装置に一定期間データを蓄積(容量 ) • 装置にパケット解析ロジックを仕込む • 警告、自動連携を実装 RaspberryPi3ベースの IoTパケットレコーダー Sonarman-R
  11. 11. 構成図 ③遠隔地から参照 ①ミラーリングされた通信デー タを集積しつつ解析 ②解析 警告 一旦設置したら、既存のサーバやネットワー クに影響を与えないので、設定変更がやりや すい
  12. 12. 実装 • • フィルタの書式を で入力させて  ユーザー定義カウンタを作る
  13. 13. 実装パターン1 カウンタ フィルタ文字列 行数を数えてカウンタとする
  14. 14. 実装パターン2 文字列処理 フィルタ 取得したい情報をフィールドとして 出力し、 で重複排除や文字列処理
  15. 15. 設置作業の流れ 手軽さよりも同 じ手順で使い 続けられる汎 用性を重視し た 事前準備 サンプルとなるキャプチャを入手 適切なフィルタがないか検討 設置 Sonarmanにフィルタを設定 計測 既存キャプチャをバッチ処理 もしくは放置して新規に計測 データベースからデータ取得収集
  16. 16. ユースケース 現場で実際に使った事例を ご紹介します
  17. 17. 事例① • 再送カウンタ連携 – プライベートアドレス同士の  コネクションを抽出 – 再送が警告レベルになると、  登録してある に自動ログインして  インタフェース統計を取る仕組み – を見つける目的 • 結果 – が無いのに再送が多い – 無許可で設置された無線 有線コンバータ
  18. 18. 事例② • アドレス追跡 – や からユーザー名やホスト名を 取得し、 アドレスと紐づけて に格納 – 各種警告に対し、ノード、使用者の情物一致 • 結果 – 任意のタイミングで検索でき、情物一致 – 一つの に複数のユーザー名が記録される – 無許可で設置されたルータを発見
  19. 19. 事例③ • 障害の検知と暫定の再発防止策 – のデッドロック障害 – 特定のエラーコードが経路を流れる – 検知してメールで警告 • 結果 – アプリケーション修正までの暫定対策  として採用 – 暫定でも対策案がサクッと出てくると  信頼感が生まれる
  20. 20. まとめ • 机上で考えた事と、実際の現場は違う • わりと斜め上のモノが見つかる • 情報収集は楽になった • フィルタを一々検討するのが 少し面倒だが、自由度 と  トレードオフなので悪くない
  21. 21. 考えてる事とか
  22. 22. 開発の背景 • 情シスは自分で解決できないトラブルのケツ を持たされてる(少し自業自得な所もあるが) • 不安感が常に付きまとう仕事 – この「不安」がベンダーへの  過剰な要求の原因 • トラブルが楽に解決できるだけで、  情シスの負荷はだいぶ減る
  23. 23. トラブル解決を楽にするには • パケットキャプチャを使う – パケットの解析は難しいが、  「ある条件」がそろえば簡単にできる – 現場でこの条件がそろう事はほぼない。 その条件とは。。
  24. 24. トラブル解決を楽にするには • パケットキャプチャを使う – パケットの解析は難しいが、  「ある条件」がそろえば簡単にできる – 現場でこの条件がそろう事はほぼない。 「同じ条件で取得した正常時と異常時の キャプチャを比べること」 既存のやり方を変えていこう
  25. 25. パケットキャプチャの難しさ 本質は間違い探し 右の絵の間違いを探 してください
  26. 26. 正解発表 問題 オリジナル 右下にウォーズマンがいます 違和感はあっても確証を持 つ事は難しい
  27. 27. 対比によるトラブルシューティング • 通信はコンピュータ同士の会話そのもの どういう応答によって中断しているか 普段(正常時)と比べてどうか データはよ マジ早くして 無視すんなや 既読 14:32 既読 14:33 既読 14:34 ちょ、今忙しい もぅマヂ無理 既読 14:33 既読 14:35 何で忙しいのか? リクエスト集中? 内部処理の負荷?
  28. 28. 伝達手段としてのパケットキャプチャ 比較することで説明しやすくなる エビデンスとして有効 パケットキャプチャによって  言語の壁を幾度となく越えてきた
  29. 29. 教育効果 • 障害時のパケットキャプチャのみで 問題を解決する場合 • 初見の間違い探しを予備知識で カバーしている – プロトコルや振る舞いに関する知識がない 初心者には敷居が高い トラブル事例をナレッジとして蓄積して、 レベルの底上げにつなげる
  30. 30. 良い循環が生まれる • 問題がスパッと解決すると 「振り返り」をやろうという気になる 良い循環 解決して 「俺カッコイイ」 と思っているうちに 反省すると、 素直な気持ちになれる
  31. 31. 思い • トラブルに振り回されている現状 を変えたい • 「不安」という感情から起きてい る不幸を無くしたい • 「不安」は減らせる
  32. 32. • で売ってます 製品ページ 
  33. 33. 製品を見たある人の感想 あ、これ検証ルームでノー パソ持ってウロウロしなく ていいやつじゃん 半径 から始める そういうのもあるのか。。
  34. 34. お気軽にお声掛け頂ければうれしく思います ご興味があれば是非お手に取ってみてください VMもあります

×