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例目のほうがなお良いという意味で満点ではありません。 私の子供時代はこのようなことは深く考えずに適当にやってきましたが、 今エンジニアになってみて、単純なことを素直に分かりやすく表現することは、非常に重要だと感じています。 これからの子供たちはこのようなところから、少しずつ基礎を積み上げることを意識して教育されていくのかもしれません。
がんばれ！ 子供たち！（笑）
パケット解析を簡単に行う方法
皆様こんにちわ。 パケットキャプチャ使ってますか？ 今回はキャプチャファイルを簡単に解析する方法をご紹介します。
以前、パケットキャプチャの敷居の高さについて書いたことがあります。
要約すると、パケットキャプチャでは何がおかしいのか分からないことが「難しい」ということになります。 なので、何を無視するか、何に注目するべきかを絞り込む方法について紹介します。
パケットキャプチャ教の普及にまつわる問題
私はユーザー企業の情報システム部門で勤務した経験があります。 そこでシステム上の問題が発生するたびに、トラブルシュート（障害対応）を行わなければならないのですが、私はいつもパケットキャプチャを使用して問題に対処していました。この方法は非常に精度よく問題に対処できるため、同僚にも勧めたのですが、反応が良くありません。
トラブル解決のときには、なるべく詳細に問題の発生原因や見つけ方などを情報共有し、社内勉強会も数回開催しましたが、こちらの説明を理解しているのかいないのか、興味がないとしか思えないリアクションをされるのがいつも不思議でした。だったら勉強会に出席するなよ！ と割と毎回思っていました。
なぜこのような反応をされてしまうのか、ということを考察してみたのですが、 パケットキャプチャを使ったトラブルシュートの実例を聞いていると、問題解決に必要な前提知識の多さに引いてしまうことが原因ではないかと思い当たりました。
パケットキャプチャはネットワークのデバッグ行為に相当します。 デバッグとはコードを解読する能力のある人が、入出力やコードの記述を調査することで解析を進めます。 入出力の内容が理解できない人が実施することは基本的にできません。
そのため、分からなさ過ぎてテンションが下がってしまうのではないかと考えました。
具体例
ここで少し例を出したいと思います。 パケット解析は間違い探しです。 しかも、多くの場合「間違った絵」だけをみて、間違いを指摘しなければなりません。
以下の絵について間違いを指摘してみましょう。
未来の世界の猫型ロボット
予備知識のない状態だと、
- このロボットは黒猫タイプ？
- ツメは標準装備なのか
- 暗闇で目が光りそう
ということで違和感があまりありません。
ハッ、もしかして、声が間違いなのでは？と、思ってしまうかもしれませんよね。
正解は「何もかも違う」です。
間違えた方はいないと思いますが、それは「未来の世界の猫型ロボット」というキーワードから既知のキャラクターをイメージできるからです。
予備知識のない状態で、比較対象のない間違い探しを行うことは、
非常に困難を伴うということがお分かりいただけたかと思います。
解決策
それではどうしたらよいか。 答えは「比較対象を常に用意し、見比べることを前提にトラブルシュートをする」です。
以下のサイトで 継続的にパケットを収集する仮想アプライアンス、 「Sonarman」を無料で配布しています。
Sonarmanについて
無償版配布ページ
この仕組みを利用して、常に正常系と異常系を見比べてトラブルシュートが出来るようになれば、2種類のパケットキャプチャの差分だけを意識して解析すればよいということになります。
そのため、結果的に難易度が下がり、解決のスピードが速くなるのではないかと思います。
もしよければ使ってみてください。
