Npstudy#11で発表しました。
発表内容
以下資料です。
ネットワーク運用とIoT from cloretsblack
www.slideshare.net
要約すると、パケットキャプチャを集積しておくことで、ビッグデータのように扱えるので、保守運用に必要な各種データが任意のタイミングで同じ手順で取り出せるようになりますよというお話です。
同じ手順とは言いましたが、簡単とは言ってません。
ある程度ネットワークの知識がないと難しいのではないかと思いますが、手法としてはそれなりに使えます。
本番稼働中のサーバに置いてあるデータ収集用のスクリプトを変更するなどの作業は現場の人間にとって非常にやりにくい作業の一つです。
その点、Sonarmanは一旦設置してしまえば、稼働中のサーバやネットワークに一切の変更を与えることなくデータを取得できるので、安心感があります。
情シスというポジション
情シスというポジションについても触れました。ITのエキスパートであるベンダと、業務のエキスパートであるユーザーの間に挟まれ、ある意味最も理解されづらいポジションではないかと思う時があります。
情シスにおけるインフラ担当者としての価値、すなわち自社での利用状況や課題を把握し、ユーザー価値を最大化するための施策を立案、実行する事ですが、そういった活動の元となる各種数値を効率よく正確に把握するためにはどうすれば良いかという問いに対する、私なりのアイデアと実行結果についてお話しました。
重要な事は2つ。
・何かを検討する際に正確な数字を持っている
・問題発生のときにエビデンスを持っている
これらの条件を満たす事は、話し合いの主導権を握るという事です。
このアドバンテージは非常に大きく、対人交渉や重要な判断の際に必ず役に立ちます。
事実、私自身過去に何度も助けられました。
私の経験が皆様のお役に立てばうれしく思います。
ご興味があれば、お気軽にTwitterでお声掛けください。
ジョジョの奇妙なケーススタディ【ネットワーク遅延】
きっかけ
ネットワーク遅延について書かれた資料を拝見し、インスパイアされてしまいました。
本記事とは異なり、大変真面目な内容です。
すごく整理されてていい。
— cloretsblack (@Clorets8lack) 2016年12月26日
LAN障害の中で「遅延」って解決しにくい問題の一つだけど、現場のケーススタディって需要あるかな？
ネットワークでなぜ遅延が生じるのか #congestion #latency https://t.co/mucCW4Nzjn @SlideShareさんから
はじめに
一言にネットワーク遅延と言っても多くのケースが想定されます。
ネットワークを構成する様々な要素、例えば、サーバやクライアントPC、アプリケーションなどに原因が潜んでいる可能性があり、比較的難易度の高い障害ではないかと思います。
ただし、私の経験上、遅延の原因は解決してみればごく当たり前の現象であることがほとんどなので、ケーススタディを充実させるよりもネットワークの原理原則を理解したエンジニアに都度対応させるほうが理にかなっている一面もあり、遅延問題について具体的な事例と解説があまりインターネット上に存在しないように思います。
そのため、初心者がどれだけ検索しても問題事例に行き当たらないという現象が発生しており、ユーザー企業の情報システム部門などではユーザーとサポートベンダの板挟みにあい、苦しんでいる人々がいます。かくいう私もその一人でした。かつての私のような人々に少しでもご参考となればと思い、この記事を書きました。
大体こんなテンションで進んでいきます
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用
注意
本記事ではネットワークのスループットが断続的に低下する事象を「遅延」と定義します。
具体的には理論値よりも明らかに速度が出ていない、以前よりも遅くなったなどの問題を扱います。
また、基本的にLANを中心に解説します。
パケットキャプチャを表示するソフトウェアにはWiresharkを使用しました。
私が今まで現場で見たことのあるネットワーク遅延とその検出方法、解決手法を具体的に書いてみたいと思います。
- すべての「遅延」問題の調査に共通する基本
- ネゴシエーション不一致
- ケーブル不良
- アプリケーションの問題
- ネットワーク容量
- サーバレスポンス遅延
- ポート/セッション数枯渇
- ジャンボフレームとフラグメント
すべての「遅延」問題の調査に共通する基本
もし、あなたの手元で問題が再現するなら、まずパケットキャプチャを取得するところから始めてください。
なぜパケットキャプチャを取らなければならないのですか？
ネットワークでは様々な機器が連携して動いています。サーバ、クライアントPC、スイッチ、ルータ、それらを繋ぐケーブルなどです。
これら全てをしらみつぶしにチェックすることは手間がかかり、さらに必要な情報が必ずしも取得できるとは限りません。
一方、パケットキャプチャには解析に有用な情報が非常に多く含まれており、またパケットキャプチャにしか現れない情報も存在するからです。
パケットキャプチャは非常に読みづらいのですが、読まなければなりませんか？
パケットキャプチャの解析はネットワークのデバッグ行為に相当します。ソフトウェアと同様に、動作を理解し、原因を突き止めなければ問題を正しく修正することはできません。
しかし、必ずしも解析のスキルを身に着ける必要はありません。パケットキャプチャは問題の状況を伝える最も有効な手段の一つです。
つまり、原因究明のアウトソースが容易になるという利点もありますので積極的に活用していきましょう。
思わず納得
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用
それでは具体的にネットワーク遅延のケーススタディをみていきましょう
ネゴシエーション不一致
ケーブルの両端にあるネットワークインタフェースでネゴシエーションの不一致が発生するとパケットのドロップが発生しスループットが著しく低下します。
パケットのドロップが発生するとTCPの再送が起きるので、パケットキャプチャの再送の数をカウントするのはネットワークの品質をチェックするのによい方法です。ただし、無線の場合は様々な条件で再送が発生するので、この方法は有線限定です。
Wiresharkで再送を検出するフィルタには以下のものを使います。
tcp.analysis.flags
ちなみにもし様々な事情でWiresharkを使うことができない場合は、端末上で
netstat -s
コマンドにより再送数を簡易的に把握することができます。
再送が多い場合、まず疑うべきはネゴシエーションの不一致です。
GigabitEthernetの普及にともない、古い100Mのスイッチを使用している場合、ネゴシエーション不一致が起こりやすいです。現在では端末のインタフェースもほぼ全てGigabitEthernetになっているのでネットワーク上の100Mのスイッチには要注意です。
ネゴシエーションの状態を知るには接続しているスイッチのランプを確認するか、インテリジェントL2スイッチやルータなどで、インタフェース情報を見てください。
Half-duplexなどになっていた場合はネゴシエーションに失敗している可能性が高いです。 このあたりの不一致にはインタフェース同士の相性も出ます。あまり深追いせずに古いスイッチは交換しましょう。
なお、ネゴシエーション不一致の場合、後述するケーブル不良と同様に runts, giants, CRCなどのカウンタが記録されていることがあります。 これらの項目は深刻なエラーです。必ずゼロにしなければなりません。
GigabitEthernetでは基本的に自動（オートネゴシエーション）で対抗のlinkを識別します。その際、対抗の設定が自動でない場合は半二重でリンクしてしまいます。
一般的にネットワークの管理ではLAN内の機器のスペックやlink状態を把握しておくことは非常に重要です。
オートネゴはオートネゴでしか倒せない。それがイーサネットのルールッ！
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 Part7 スティール・ボール・ランより引用
余談ですが、回線業者に依頼してルータのLAN側のインタフェースを10M固定に設定させた同僚がいました。理由を聞くとWANの帯域が10M以下だったので、10Mがふさわしいと思ったそうです。
その結果、周囲の機器が10Mというレガシー規格にうまく対応できず、パケットドロップが頻発するという事態が発生しました。
当該ルータは業者しか触れない契約だったため、最終的に全部のリンク設定をオートネゴシエーションに戻すのに結構なお金と時間がかかったというオチでしたが、
緊急の回避方法として、10Mのスタティックモードを設定できる、懐かしのNetscreen-5GTを5000円で仕入れ、ルータとスイッチの間に設置するという荒技を使ったことがあります。
というか、業者さんも止めてほしいです。そういうときは。
まとめ
- 有線ネットワークの品質は再送数でチェック
- リンクの状態を確認し、ネゴシエーションの設定をチェック
- 解決策：すべてのスイッチをGigabitEthernetのオートネゴシエーションに統一する
- 打ち合わせ中に業者さんが変な顔をしたら、自分が間違っているかもしれないので聞いてみる
ケーブル不良
メーカー製のケーブルを使用する限り、日本ではほとんど起きないのですが、海外や自作のケーブルを使用していたり、UTPのカテゴリが合っていないなどの場合でまれに発生します。
このケースも前項と同様に再送数のチェック、確実には機器のインタフェース統計で判別します。
大前提として、ローカルエリア内の有線ネットワークにおけるTCP再送はゼロにできます。
少量の再送はスループットに大きな影響を与えないのですが、がんばってゼロにしておくと、異常時に気が付きやすくなるのでおススメです。
伝われ、このスッキリ感
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用
ケーブル不良のうち、銅線の「より」が少ないことが原因でノイズが乗りやすい状態になっている場合があります。不定期に通信品質が悪化する現象が発生しますので、インタフェース統計の runts, giants, CRCのカウンタは最低でも敷設時、理想的には定期的にチェックするとよいでしょう。
ちなみにCRCエラーが出ると、スイッチによってはCRCチェックの負荷によりpingのRTTに数ミリ秒の遅延が出る場合があります。同一拠点内でのpingに遅延がみられる場合には上記のカウンタを確認すべきです。
まとめ
- ケーブル不良はインタフェース統計でチェック
- runts, giants, CRCのカウンタがゼロでない場合は要注意
- 解決策：ケーブル交換
アプリケーションの問題
アプリケーションの使い方によって、以下の例のように非効率的な通信が発生してしまうケースがあります。
ネットワーク上の共有フォルダにインストーラーを置いて、端末から直接実行する
巨大なパワーポイントを共有フォルダに置いて直接開く
1.のケースではファイルの読み込みだけでなく圧縮ファイルの展開、解凍などで共有フォルダに大量の読み書きが発生しがちです。 インストール作業を自動化するためにパスを固定したい場合もありますが、一旦ローカルへファイルをコピーしてから実行するよう変更するべきです。
2.のケースではMS Officeがカレントディレクトリにキャッシュを作るという動作を行うために、非効率な読み書きが発生する場合があります。 参照用途で、かつ容量の大きい場合にはWEBなどから配布するなどの工夫をすると幸せになれるかもしれません。
ネットワークにおけるアプリケーションの挙動を詳細に解析するのは比較的難しいので、ネットワークの存在を意識した上でアプリケーションの使い方をトライアンドエラーするのがいいかもしれません。その際パケットキャプチャはトラフィックを定量化したり、レスポンスを正確に計測する用途にも使えますので、積極的に活用してみてください。
まとめ
- ネットワーク特性を意識したアプリケーションの使い方をすることが大切
- トライアンドエラーの効果測定にパケットキャプチャを使うと便利
ネットワーク容量
単純にネットワークに大きなデータが流れているために他の通信が送れないという現象です。
解決策としてはスイッチやルータの流量を収集してトラフィックを可視化するのが良いと思います。
具体的にはSNMPを使って流量のカウンタを収集するZabbixやCacti、MRTG、またはSNMPよりも多くの情報が得られるCiscoのNetFlowコレクタなどの可視化ツールの導入を検討してください。
手前味噌で大変恐縮ですが弊社のSonarmanもおススメです。
私の個人的な観測ですが、ユーザー企業の現場では意外なほどトラフィック可視化が行われていません。
トラブルシューティングにおいては、障害が起きた時のために普段から準備をしておくことがとても大切です。
問題の具体例として、WindowsUpdateやiPhoneの更新が集中するケースの他に、WSUS等の分散配布システムを使用する場合に、多人数の出張などで予期しないトラフィックパターンが生じるケース、クラウド等への大容量バックアップ、P2Pアプリケーションによる巨大ファイルのダウンロードなどが挙げられます。
まとめ
- トラフィックの可視化を検討する
- 人為的ミスが多い
- 発生状況をヒアリングし個別に検討が必要
サーバレスポンス遅延
サーバそのものの反応が遅い場合があります。WiresharkではSMB2やDNS、LDAPなどのレスポンスタイムを可視化する機能がありますので、そういった機能を使ってもよいですし、WEBサーバであればブラウザの開発ツールがダウンロードに要した時間や処理のレスポンスを可視化してくれます。
注意点として、ファイル共有等でDISKのI/Oタイムアウトがエラーとして返される場合があります。パケットキャプチャでしか見つけられませんが、もし見つけたら絶対に無視してはいけません。DISKが壊れかけています。
まとめ
- ブラウザの開発ツールやパケットキャプチャで遅延を計測できる
- 解決策：サーバ増強
ポート/セッション数枯渇
ルータやプロキシサーバを長期間入れ替えていない、利用者が急激に増えたなどの場合にはセッション数やポートの枯渇を疑ってみるとよいかもしれません。
まずnetstatで機器のコネクション数を確認してください。
さらにパケットキャプチャで不自然な待ち時間やコネクションの切断が発生していないか、ルータのログにNATのセッションテーブルの枯渇が記録されていないか等もチェックポイントです。
最近のブラウザでは表示速度の向上を目的とした分散ダウンロードが一般的になっています。CSSや画像、スクリプトなどは異なるTCPコネクションを利用して並列にダウンロードすることで速度を出しており、それらは一つずつ異なるコネクションを使ってルータやファイアーウォールを通過します。
また、ブラウザの動きに合わせて、サイズの小さな部品をたくさん配置するデザインのWEBサイトも増えています。トップページの表示だけで数百のコネクションを使用するWEBサイトも存在しますので、注意が必要です。
ダウンロードが完了したコネクションは破棄され、ソケットは再利用されますが再利用の際に発生する負荷や、純粋なNATセッション数が上限に達してしまうことが原因で、待ち時間が生じてしまうことがあります。ネットワーク上でコネクションが集中する箇所は常時監視や定期的に点検してみることが大切です。
大量のセッションを消費するアプリケーションの具体例として、Bittorrent等のP2Pアプリケーションのフラッディングや、Bitcoinのマイニングツールなど、特殊なものも存在します。
間違いない
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用
まとめ
- ルータやプロキシサーバなどトラフィックが集中する箇所はコネクション数を監視する
- 解決策：機器のアップグレードや分散配置
ジャンボフレームとフラグメント
通常のイーサネットフレームは1500バイト程度ですが、ジャンボフレームの普及により、LAN内で高速にデータ通信ができる環境が整いつつあります。しかしVPN等でWANに流れる通信の場合、パケットの分割すなわちフラグメントが問題になるケースがあります。問題の把握にはパケットキャプチャを取得する必要があります。
ジャンボフレームの分割に際し再送が発生していないか、PathMTUで発生するICMPのDestination Host Unreachable メッセージが端末まできちんと返っているかなどがチェックポイントです。
パケットキャプチャではTCPのシーケンスナンバーを条件にフィルタすることで再送が発生する元のパケット（到達しなかったパケット）がどのような状態であったかがわかります。元のパケットがジャンボフレームだった場合には設定を変更してパケットのサイズを小さくしてみると状況が変化する可能性があります。
(5446バイトのジャンボフレームが分割して再送されている)
ちょっと違いますが
集英社ジャンプコミックス 荒木飛呂彦著 ジョジョの奇妙な冒険 より引用
まとめ
- パケットキャプチャで再送やICMP、フレームの長さをチェックする
- 解決策：ジャンボフレームの設定解除
最後に
非常にダラダラと読みにくい記事だったと思います。お疲れ様でした。
黒ブラとしてはコラを貼りたかっただけなので、説明はだいぶ端折っています。もしご質問などがあればTwitterでリプください。
Sonarman-Rを発売しました
Amazonにて発売中です。
- 出版社/メーカー: デベルアップジャパン
- メディア: エレクトロニクス
- この商品を含むブログを見る
いやーAmazonに置くまでが長かったです。
製品バーコード（JANコード）を取らないといけない等、知らないことばかりで黒ブラ的にもいい経験（？）になりました。
初期設定とデプロイ・テストを自動化したり、梱包資材を買ったり、挙句の果てにはバーコードが貼ってないとかで納品できず、返品食らったりもしました。
そんなこんなで、箱の中には黒ブラの年末年始がたっぷり詰まっています！
もともとこの製品は遠隔で海外のエンドユーザーをサポートをするために開発されました。 RTT400ms越えが当り前の拠点で「聞いたこともないようなメーカーのプリントサーバから印刷が出ない」みたいなクラクラするようなトラブルを解決するためのツールです。
黒ブラはインフラ担当として、そのような環境を10年以上サポートしており、実務から得られたノウハウもしっかり搭載しております。
ソフトウェアの開発には2年以上かかっていますし、お値段以上の価値があるのは間違いありません！
違いの分かる方にぜひお手に取っていただきたいと思います。
今後とも黒ブラとSonarmanをよろしくお願いします。
エンジニアの報連相について
先日、後輩君と一緒に会議に出まして、 そこで後輩君の報告を聞きながらちょっと思ったので書いてみることにします。
まあ、後輩君が要領を得ない説明をするというのは、非常にありがちで自分もそうだったなーと思い出しました。
恥をさらすようですが、昔自分がやっていたことと、今気を付けていることを整理してみたいと思います。
昔の自分
上司「黒ブラくん、進捗はどうですか？」
ぼく「えっと、いまプログラムを書いていて、コンパイルエラーがやっとなくなりました」
上司「コンパイルエラーが無くなるのは当り前でしょ」
ぼく「あっはい」
上司「どうなの？」
ぼく「これから流してみます」
上司「間に合いそうなの？」
ぼく「大丈夫だと思います」
今思うと、だいぶアチャーな感じですね。。
このようなやり取りをしていたのは、ぼくが商社の情報システム部門で入社2年目くらいのころでした。
非コンピュータ系の学部を卒業した状態で、1年目はPCヘルプデスクをやり、2年目の後半からは基幹システムの新規開発プロジェクトに参加し、プログラム製造を担当していました。
初めてのプログラミングはPLSQLで、SQLの文法を理解するところからでしたが、商社の新人として入社したので、情報処理の教育はほぼ受けていません。
「SQLを覚えて」と言われて本を渡される感じの現場です。
当時、基本情報処理試験には3回落ちており、受験自体をやめてしまったので、基礎はだいぶ抜けていたと思います。
（今ではさすがに受かると思いますが。。）
なので、非常に聞いていて不安を感じる報告ですね。これからの工程とか理解してんのかという感じです。
もちろん当時は理解せずに報告しており、後で大変な目に合うのですが。。
どうすれば良かったか？
その場にいる人のレベルや会議の趣旨を理解した上で質問の意図と求められるレベルを想定する
想定するレベルに合わせて報連相する
具体的に進捗確認であれば、現在の状態、今後の予定、スケジュールとの差異、問題が発生しているか、等を簡潔に述べる
必要であれば、ホワイトボードに図を書く（積極的に）
報連相の常として結論から先に言うというのも大事だと思います。
あと、上司から質問が何回も出るというのは「こいつ本当にわかっているのか？」という疑問を払しょくするためでもあります。
そこで4に挙げたように、図を描くと「わかっている感」が生まれるので、聞いているほうに安心感が出てきます。
会議の時間を使ってしまうという問題はあるのですが、積極的に使っていきたいテクニックです。
製造工程の理解とマイルストーンの設置、スケジュールの感覚などは基礎的な教育と経験で得られるものなのですが、進捗の報告をする前に理解しておかないとそもそも話が通じないので、そこは上司や先輩とかがフォローしてほしいですね。
ちなみに後輩君はぼくと比べて基礎が非常にしっかりしており、「おまえこの年齢でこのスキルって、無敵じゃね？」ってぐらいの逸材なので、この手のテクニックを積極的に伝授してパーフェクト超人にパワーアップしてもらおうと思っています。
だいぶ待っていたよ
ハンズオン体験記
試してわかるSDN ～Tremaではじめるパケット生成ハンズオン～ で講師を務めました。
試してわかるSDN from cloretsblack
www.slideshare.net
ハンズオンは難しい
私にとっても初めてのハンズオンだったので、様々な学びがありました。
参加者のレベルやペースも様々ですし、フォローが難しいです。
Tech-Circleの皆様のご協力で何とか形にできた感じです。
本当にありがとうございました。
参加者の環境がマチマチ
やはりプラットフォームの差異を甘く見てはいけないですね。
当初VMでやれば大丈夫だろうと思っていましたが、インポート時にネットワーク周りで予想しなかった挙動があり、一瞬戸惑いました。
Windows10での予行演習はしていたのですが、私の環境とは違う動作をしていたことと、ハンズオン中に出てくるとアナウンスが難しいというのは貴重な経験でした。
お一人、Windows7の32bit環境でおそらく64bitのVMを動かすのが初めてという方がいて、インポートのエラーで躓き、実質放置状態になってしまいました。
BIOSのVT-x拡張を調整してみてもらえますかと言ったのですが、ハンズオンに来てBIOSの設定変えるの嫌ですよね。。
予め案内等に書いておけばよかったです。ごめんなさい。
それ以外は比較的スムーズに進捗しましたので、至らない点は少々あったものの、 VMで環境をまとめておいたのは良いアイデアだったと思います。
ちなみに資料中、後半のCMが長いのは尺の関係です。。
このハンズオンをご自宅ででもやってみたいという方がいらっしゃれば、 VMをご提供いたしますのでtwitterまでお知らせください。
パケットレコーダー「Sonarman」をRaspberryPi 3に移植してみました
「Sonarman」とは？
「機械学習による警告機能」と「遠隔での高い操作性」が特徴のパケットキャプチャ装置です。 一定期間のパケットを保存しておくことにより、ネットワークのトラブルシューティングを強力に支援します。
システム障害の原因が分からないなどの理由で「再現待ち」ステータスで障害票が積み残ることがありますが、そんな負の遺産を一掃するために開発された製品です。
システム管理者の切実な願い
圧倒的感謝
小学館コロコロコミックス『ドラえもん のび太のドラビアンナイト』より引用
「Sonarman」について詳しくはこちらをご参照ください。
今回の挑戦
x64アーキテクチャからARMへの移植作業として、Cで書いたDPIプログラムのクロスコンパイルと細かいバージョンが異なるパッケージ間の調整作業がメインでした。少々戸惑うこともありましたが、現時点で確認できている範囲では概ね問題なく動作しています。
以下に作業を通して感じたこと、考えたことなどを、書き留めておこうと思います。
メリット
HWの調達コストが劇的に下がった
広く流通しているシングルボードコンピュータであるRaspberryPiの採用でHWの入手性が大きく向上しました。 また、原価も大幅に下げられたので、拠点等、複数の計測箇所に安価に設置することが可能になります。 営業的な視点で言うと、原価が広く知られているというのは良いことなのか？という気は非常にしていますが。。
コアが増えた
既存の2コア->4コアになりました。 ただし、メニーコアのメリットを十分享受できる構造のアプリケーションではないため、コア増による速度向上はあまりありません。 動作の安定性には寄与していると思います。
発熱が減った
さすがの低消費電力。発熱は劇的に少なくなりました。これは大きなメリットです。
GPIOによる応用の余地が広がった
不正なパケットによる緊急事態に音を鳴らしたりLEDを光らせるなどのアクションを取らせることができます。 たとえば「IPアドレスの重複を検知して光る箱」を作ることができます。 何の意味があるかはさておき、面白い使い方を考えてみようと思います。
小型化
大分小さくなり、非常に満足しています。 現行機種の約4分1のサイズです。
省スペース電源
USB電源になりますので、省スペースになりました。スイッチやサーバから給電するようなことも可能になるかもしれません。
その他
現行機種の「Sonarman」はシリアルで設定するのですが、シリアルケーブルを持っていないというお客さんも普通にいらっしゃいますので、「HDMIを挿せば普通のPC」というのは、かなりユーザーフレンドリーです。（RaspberryPiもシリアル接続できます）
デメリット
性能
あまり速くないです。50Mバイトのパケットキャプチャを読んで、機械学習など諸々の処理を行うのに300秒ほどかかるケースがちらほら。キャプチャの内容によって処理速度が異なってくるのであまり単純な比較はできませんが速くはないです。 したがって警告などのリアルタイム性はそれなりです。 実運用での経験から言えば上記の制約はそれほど重要ではないですが。
Ethernetポート数
3ポートから1ポートに減りました。 唯一のRJ45ポートはキャプチャ用にせざるをえませんので、操作用のインタフェースはWiFiになります。 どうしても必要なときにはUSBで増設することも可能です。 実際の設置で発生していた、UTPケーブルを挿し間違えてキャプチャが取れなかったという悲しい事故は減るはずです。
容量
キャプチャを格納するDISKの容量は増設に頼ることになります。 128GのUSB小型フラッシュメモリをマウントして使います。 アマゾンで3000円くらいなので非常に安価ですが、 USBが2.0ということもあり、速度としてはそれなりかと。
感想
全体として、かなり満足感があります。 正直、もうこれでいいじゃん的な何かです。 価格も含めて良く知られているプラットフォームであるということもあり、 購入/評価の敷居が下がることを期待しています。 開発用途には非常に便利ではないかと思います。
IoTというキーワードは、今まであまり意識していなかったのですが、 安価なレコーダーを潤沢に設置することで、「数で押す」という戦い方が出来るような気がしています。 結果として障害に関するトレーサビリティが劇的に向上するため、 システム管理者にとっては嬉しいことではないかと思います。
「ピンチに頼れる飛び道具」として小型化と大幅なコスト削減を実現した、新型「Sonarman」にご期待ください！
JTF2016に参加しました。
今回のJTFは「IoTxAIxインフラ時代の最新技術、やってみたSP - 俺の屍を越えて行け -」というテーマだったので、 DevOps、人工知能、機械学習等の分野に付随するインフラに関するセッションが多く、実際にやってみてどうだったかという、非常に興味深いプログラムが目白押しでした。
そんな中、発表者として登壇させていただいた中で考えたことなどを書きとめておきたいと思います。
何をやったのか
海外のネットワーク運用という比較的珍しい状況の中で編み出したパケットキャプチャ術と解析技術の紹介をしました。 以前発表した内容に加え、失敗と試行錯誤の中で生まれたダッシュボードの機能とユーザーの追跡機能にフォーカスして、その改善プロセスと考えた事を発表してみました。
www.slideshare.net
結果どうだったか
多くの方から勉強になったとの声を頂きました。
情シスという立場でこのような発表をする人は多分変わり者なので、珍しさも手伝って少し過大評価されているところもあると思います。
当日Sonarmanの開発者ライセンスをお配りしたこともあり、ご来場いただいた方に、単なる主張/情報だけでなく明日から役立つ何かを提供できたのではないかと勝手に思っています。
自分自身の感想
今回参加させていただいた事は自分自身にとって、非常に楽しく勉強になりました。 運営の方々には大変お世話になりました。 このようなイベントを用意することはものすごく大変な事だと思います。（準備に半年かかったそうです。。） この場を借りて心より御礼申し上げます。
一方で当日の発表や懇親会などで色々な方のお話を伺い、エンジニアとしてだけではなく、経営者の立場で考えたときに、周囲の方がまぶしく思え少々へこんでしまった所があります。
会場にいらっしゃった社長さんは皆さんすごい人ばかりで、やっている事も全然違うので、参考にするのは大分難しいな、というのが正直な所です。
しかし上を見ればキリがありません。
そもそもJTFを運営/スポンサードされるような経営者と自らを同じカテゴリーに入れることが大きな間違いと言えます。
自分は自分なりに必要とされる場所で必要とされる仕事を粛々とやるしかないのだということが一つの学びでした。
余談ですが、ある来場者から弊社の経営に関する「やっちゃったスペシャル」を聞きたいという要望を頂きました。。
まだ全然経営がしっかりしていないのにそんな話をするのは百年早いので、地道に一つずつ積み上げていこうかと思います。
