パケットレコーダー「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を運営/スポンサードされるような経営者と自らを同じカテゴリーに入れることが大きな間違いと言えます。
自分は自分なりに必要とされる場所で必要とされる仕事を粛々とやるしかないのだということが一つの学びでした。
余談ですが、ある来場者から弊社の経営に関する「やっちゃったスペシャル」を聞きたいという要望を頂きました。。
まだ全然経営がしっかりしていないのにそんな話をするのは百年早いので、地道に一つずつ積み上げていこうかと思います。
TremaDay#9に参加しました
中国のインターネット規制とOpenflow networkについてTremaDay#9で発表してきました。
TremaDayとはオープンソースのOpenflowフレームワークであるTremaを中心としたネットワーク関連のオモシロ発表会です。
発表資料
www.slideshare.netこれが許される雰囲気といえばTremaDayの空気感はおわかりいただけると思います。
今回のブログのテーマは2つ、
TremaDayという素晴らしいコミュニティ
発表をしていて思ったこと
です。
- TremaDayはいいぞ
一言で言うと大分自由です。 発表する方々のレベルがかなり高いのは、Trema自体が誰でも使えるソフトウェアではないということもあり、必然的に高いレベルの人しか興味を示さないこともあると思います（少なくとも今のところは）
tremadayのいいところは、課題やグッド・バッドノウハウの共有に加えて、あたらしいものへ向けたブレインストーミングみたいな側面も備えているところだ。
— localhost (@qb0C80aE) 2016年7月2日
自ら手を動かす人たちと面白いことを考えるのは最高です。 ちなみに上記のツイートの方は携帯電話端末にOpenvSwitchを入れて次世代データセンターを手のひらに収めるという、なんだろう、野心的すぎる発表をしてくださいました。控え目に申し上げて常人ではありません。
2．発表をしていて思ったこと
他の人たちの発表を見ていて、自分との違いや己のレベルについては常に意識するのですが、私の今いる場所（情シス担当者）の特徴として、エンドユーザーと直にやり取りが出来、試したことのフィードバックを非常に得やすいポジションであることが挙げられます。 Software Definedなネットワークやそれに付随するシステムを開発するにあたり、これは思ったよりも大きなメリットではないかと思います。
IDEやソース管理、DevOpsなどの各種ツールにより開発が効率化し、高速化している昨今、このようにPDCAを高速に回してソフトウェアを作りこむプロセスはなかなか充実しており、改めて現場に近いことのメリットを感じています。 今後とも、色々考えて楽しく手を動かしていこうと思います。
最後に 皆もTremaDayに行こう！
NPStudy#8で発表しました（追記）
前のエントリで発表について書いていたのですが、 思ったよりも反応を頂いておりまして、 その中で鋭いご指摘があったので追記したいと思います。
機械学習というほど機械学習ではなかった。ただエラー検出精度はたかいとのこと。すごい/ 機械学習によるリモートネットワークの異常検知 https://t.co/dFNN4JGV6t
— はちたい (@haccht) 2016年3月1日
今回発表した機能には、「フィルタ」と呼んでいるモジュールがありまして、これは私が10年以上に及ぶ国内外でのトラブルシューティング経験と採り溜めた数百ケースのパケットキャプチャを分析した結果を元に、マニュアルで実装されているものです。
機械学習というと、このようなフィルタをコンピュータが賢く自動生成するようなイメージがあり、結局手で書いてるのか、という意味で少し期待はずれだったのではないかと思います。スミマセン。。（ご指摘有難うございます！）
ただ、このフィルタを自動生成するのはパケットというデータの構造と性質上、技術的に難しい気がしています。（もし「出来るよ」という方がいれば是非教えていただきたい部分です。）
結局、どこに機械学習的な要素を入れたのかというと、フィルタを通して検出された値が、警告に値するか否かの判断基準の部分です。 外れ値としてのボーダーラインを、設置環境における過去データから導かれる平均値との距離で判断しているという考え方になります。計算コストや実装難易度、説明のしやすさなども考慮して採用しました。
ネットワーク障害対応の常として、問題の検出だけでなく、人間によるパケットキャプチャの検証作業を平行して行うため、機械学習のアルゴリズムはその判断過程を検証できるものを選択する必要があると思っています。 そのため、決定木のようなものを検討中ですが、まだまとまっておらず未実装です。。
この機能についてはまだまだ発展させていけると思っていますので、手元にある豊富な実データを元に、様々に分析してみたいと思っています。
NPStudy#8で発表しました
ネットワークプログラマビリティ勉強会#8で発表させていただきました。
www.slideshare.net
テーマが分散して、まとまりのない発表になってしまった感あり、反省です。 技術的には泥臭くフィルタを書いたりしていてスマートとは言い難いですが、実運用上の細かい話がネタとして多少受けていたようです。。
参加者はみなさんネットワークのエキスパートぞろいで、小さなユーザー企業ではリーチ不能な人たちばかりです。 久しぶりにネットワークの濃い話をたっぷりできたので、非常に癒されました。 情シス担当者は周りに技術に対する理解者が少ないという意味で、とても孤独な一面があります。 このようなコミュニティに参加することができて、とても幸せです。
今、世の中では盛んに情シスへのdisが言われています。 いわく、デジタルビジネスに対応できていないとか、 基幹システムのお守りが精いっぱいとか、技術力が低いとか。
確かにうなづける部分もあり、どうすればいいのか、私なりにいつも考えています。 その中で私は経営まで含めたオールラウンダーとしてのキャリアを目指そうと考えており、 そのためにプロダクトの製作や販売に取り組んでいます。
外野は色々な事を言いますが、日々ユーザーと向かい合っているのは情シス部門のスタッフなわけで、全体最適、コスト配分を考えながら高品質なサポートとチェック機能を提供し続けるというミッションを遂行しなければなりません。 自分でも「分不相応に意識高いなー」と思わなくもないですが、思考停止が一番良くないことだと思うので、少しずつでも考え、手を動かし、発信していこうと思います。
Tremaday #8に参加してきました。
Tremaday #8に参加して登壇してきました。
非常にレベルの高い講演の中、多少場違い感のある内容でしたが、一服の清涼剤程度になれば良いかなと思います。
発表資料
www.slideshare.net
この中で、だいぶ真田さんのことをDisってるんですが、少しフォローをしておきたいと思います。
宇宙戦艦ヤマトでは
- 色々あって地球滅亡まであと1年
- コスモクリーナーDを取りに来いというメッセージと波動エンジンの設計図が送られてくる。
- 送信元は地球から14万8千光年離れたイスカンダル星
つまり、物語の始まりでまず波動エンジンを作るところから始めなければならないのですが、 設計図という割には波動エンジンや構成部品の材質など肝心なところは省かれており、 宇宙飛行の途中で入手した材料を使い急遽補修するなどの場当たり的対応を強いられます。 宇宙船を旅の途中で材料調達して直すんですよ？意味が分からない。
そもそも、宇宙戦艦ヤマトの飛行テストすら行われていないのであり、 一発始動させた真田さんマジハンパないッス。
そんな綱渡りでイスカンダルまで到着したら、渡されたのはコスモクリーナーDの「部品」。
どういうこと？イジメ？ そんな部品から帰りの道中にコスモクリーナーDを完成させてしまう真田さん。 でもテストしないからコスモクリーナーを動かしたヒロイン死んじゃいますけどね。
ほら言わんこっちゃない。。
でも最終的にはヒロインは蘇りますので結果オーライと言えなくもないでしょうか？ ここまでくると、この天才にはテスト必要ないよねという気がしてきます。
テスト？ お前それ真田さんの前でも同じこと言えんの？
私のような、天才ではない人間にこそ、テストは必要なのです。 そんなわけで、私もこれからmininetの使い方を習得しようと思います。
算数と足し算の順序、これからの教育
この件が話題になっているようなので一言。
小学校の算数教育で、 「車が5台止まっています、9台来ると、全部で何台になりますか」 という答えに9+5=14と書いた答案がバツになるのはおかしいのでは？ という内容です。
私の意見はバツはおかしい、でも 5+9=14 のほうが 9+5=14よりも優れた回答だと思います。 テストは理解度を測るものであり、マルをつけてしまうと、そこに疑問が発生しませんので、改善の機会が失われかねません。 三角をつけるくらいが適当ではないかと思います。
等価交換だからとかそういうことではなく、日本語として問題文を解釈し、素直に数式に表現すると、5+9=14 になり、この形は誰の目にも「問題文がそのまま反映された数式」になると思います。 例として、
<?php $Current=5; $Arrival=9; //現在の数に新着の数を足す $Total= $Current + $Arrival; echo 'Total Car = '.$Total."\n";
<?php $Current=5; $Arrival=9; //現在の数に新着の数を足す $Total= $Arrival + $Current; echo 'Total Car = '.$Total."\n";
上記2例で結果は変わりませんが、2例目はコメントと式が逆になっています。 変数の数が多くなってくると単純な足し算でもコメントと合っていないと理解しづらくなっていきます。 CurrentとArrivalという二つの英単語の意味がパッと分からなかったりする場面でも、対応が取れている最初の例では意味が分かりやすくなっています。
小学生の算数のテストであっても、文章題を解くときには計算力だけでなく文意を正しくとらえること、 数式として表現することが求められています。 数式は単なる計算過程ではなく、自分のイメージを表現する手段でもあります。
回答の際、文章題を見ていない他人でもイメージしやすい形で、文章が素直に式に反映されていれば、 それは素晴らしいことです。将来違う場面で自分の考えを他人に説明するような場面でも、きっと役に立つと思います。
2例目も決して間違いではありませんが、1例目のほうがなお良いという意味で満点ではありません。 私の子供時代はこのようなことは深く考えずに適当にやってきましたが、 今エンジニアになってみて、単純なことを素直に分かりやすく表現することは、非常に重要だと感じています。 これからの子供たちはこのようなところから、少しずつ基礎を積み上げることを意識して教育されていくのかもしれません。
がんばれ！ 子供たち！（笑）
