cloretsblackのテクニカルノート

言葉の意味はよくわからんがとにかくすごい自信だ

技術書典に参加して「VMとコンテナで作るポータブルネットワークシミュレータ」を販売しました。

今回は「VMとコンテナで作るポータブルネットワークシミュレータ」を新刊として販売させていただきました。既刊の「パケットキャプチャで見てみよう MySQLデッドロック編」もまあまあ売れ、利益も出ました。 サークルチェックは、2週間前まで30だったのに、3日前あたりから急に増えててびっくりしました。最終的に140くらいになりました。

弊サークルの本はすべてPDFダウンロードなので、途中増刷に走ってもらい、30部在庫を追加して販売を続けましたが、やはり一日中続けるのは体力的にかなりツラく、鍛錬が必要だなと思いました。

PDFダウンロードで販売するという方針は、弊サークルの商品ラインナップがすべて、構築手法とその手順を紹介する「クックブック」であるため、構築に使用したコードをコピペできないようではクックブックの価値が半減するという考えに基づいています。(在庫リスクや製本、運搬コストを最小化できるという経済的な理由も大きいですが。)

弊サークルは出口近くでほとんどの方が通られる一角にブースを配置していただいたので、場所がものすごくよかったです。ラッキーでした。

しかし人目を引くPOPを用意できなかったため、もったいない事をしました。。

今回販売したネットワークシミュレータ本は、自分で作ってみるとよくわかる不具合(環境を持ち運びしづらい、VM on VMは重い)を解決するための方法を解説したものです。 この環境はハンズオンセミナーなどに適していると思うので、社内教育でも活用したいと考えています。

早速試してくださった方からお喜びの声が!励みになります。

前回の技術書典3から販売しているパケットキャプチャ本はMySQLデバッグを志向しており、アプリケーションエンジニアの方も少し興味をひかれていたようです。パケットキャプチャはよくわからないけど、MySQLデバッグでは困っている、という方もいましたが、やはりパケットキャプチャは敷居が高いようで、何か敷居を下げる良い方法はないかと考えています。どなたか良いアイデアがあれば教えてください。

技術書典の大きなメリットの一つに作者と読者の距離が近いというものがあります。 クックブックの通りに作ってみたけど、うまく動かない、ここをこう変えてみたいけど、どうすればいいのか?など、著者にもよると思うのですが、黒ブラ的にはそういったフィードバックは大歓迎ですので、どんどんお寄せいただければできる限りお答えし、あわよくば次のネタにしたいと思います。

最後に、会場を用意してくださった技術書典スタッフの方々、スポンサーの皆様に感謝申し上げます。 当日各ブースには水分補給のためのメルカリ水が! お心遣い、大変ありがたかったです。

f:id:cloretsblack:20180425195554j:plain

なお、ダウンロード販売も用意しておりますので、よろしければぜひご購入ください!

develup-japan.co.jp

develup-japan.co.jp

4/22 技術書典4に新刊出します

告知です。
4/22 秋葉原UDX アキバ・スクエアで開催される技術書典4に参加します。 サークルDevelup お‐01ブースでお待ちしています!

今回は「VMとコンテナで作るポータブルネットワークシミュレーター」という本を出す予定です。

f:id:cloretsblack:20180410225042p:plain

コマンド、プロトコル仕様の確認、検証作業などに便利なネットワークシミュレータを、VMベースで、コンテナを用いて軽量に作り込んでしまおうという企画です。
コレが実現できれば検証環境を引き継いだり、学習をはじめとする情報共有もスムーズになるかも、というアイデアです。 サンプルとしてソフトウェアルータを用いたマルチパスBGPの構築と、障害試験、パケットキャプチャによる解析手法をご紹介します。

黒ブラの年末年始がたっぷり詰まっていますので、お買い得のはずです!

ぜひご来場いただき、お手にとっていただければと思います。 よろしくお願いします!

技術書典3で同人誌を販売しました。オンライン販売もあります。

先日ブログにて告知させていただいたとおり、10/22の技術書典3で「パケットキャプチャで見てみよう MySQLデッドロック編」を販売させていただきました。

今回のイベント参加でやったこと、感じたことなどを少し書き留めておきたいと思います。

f:id:cloretsblack:20171029145448j:plain

御礼

台風の中、足を運んでくださり、また本をご購入いただいた皆様、ありがとうございました。すばらしい運営をしてくださったイベント関係者の皆様、売り子をお願いした友人にも感謝致します。

技術書を書くということ

技術書を書くのは初めてだったのですが、参考書は色々読んできたので、どういうものを作ればよいかはある程度頭の中にありました。テーマが「パケットキャプチャ」なので、手元で色々できる環境が便利だと思い、クックブックとして作りこんでいくことに決めました。
実際の執筆期間は3ヶ月くらいでしょうか。勤務先の仕事もバタバタしていましたので、早めに仕上げてゆっくり修正するペース配分でした。今回は環境をそのままVMとしてダウンロードさせようかとも思ったのですが、容量の関係で現実的でなくなったため、Dockerを採用して環境を配布する事にしました。このあたりについては、かつてハンズオンセミナーを開催した際に学んだノウハウが非常に役に立ちました。
執筆ツールはGoogleDocsです。勤務先で昼休みとかにもちょっとずつ書きました。他の参加者の製作記録を読むと、表記ゆれなどを防ぐための仕組みがあったり、Gitを使ったりと、非常にカッコいい感じだったので次回は真似するかもしれないです。
今回最も苦労したのはMySQLデッドロックを意図的に発生させるWEBアプリケーションを作った所です。本の中ではほとんど一瞬で流されている箇所ですが、通常そのような目的を持った実装例があまりないこともあり、すこし試行錯誤を行った部分でもあります。

値決め

今回は一部1000円で販売しました。企業として参加していたこともあり、事前のサークルチェックなどでの数字を元に経済合理性を考慮したうえで設定させていただきました。直前のチェック数で30とかだったので、やっぱりマイナージャンルは厳しいよなぁと思いました。あと、経済的に余裕のない学生さんを対象に、「学生証を提示してくれれば半額キャンペーン」とかやっても喜ばれたかも。。?この辺は次回検討します。

配布形態

今回はダウンロード販売のみとし、A4のカラーコピーにQRコードを印刷し、100枚ほど用意しました。安いカラーコピー屋を探し、結局自宅近くのダイソーで一枚30円で刷りました。印刷屋さんに出さなかったのは滞留在庫のリスクと製本コストを許容できなかったためです。

売ってみた感想

A4カラーコピー一枚ッペラがそこそこのペースで1000円札と交換されていく様は結構気持ちがよかったです。売り子をしてくれた友人曰く、「えっ、これ売れんの?」と衝撃を受けていたみたいです。今回、友人がホワイトボードに絵を描いてくれました。技術書典3のイベントイラストに描かれている女性の顔がガイコツになっています。ひそかに黄金バットを思い出しましたw

https://techbookfest.org/assets/tbf03/images/top.png

当初見本誌を用意せず、目次だけ貼り出していた(すっかり忘れていた)のですが、実際にやってみて、見本誌の存在は重要だと思いました。特にダウンロード販売では、購入者の立場的にもあったほうが良いのは間違いないです。 ちなみに、販売ブースに見本誌がないことを知った知り合いの方が、当日コンビニで印刷してきてくださったので、後半からは見本誌をおいた状態で販売する事ができました。 前半と後半を比較すると、明らかに購入する人が増えました。セールストークもしやすいので、ノウハウとして見本誌は超重要だと分かりました。

具体的には、

  1. ブースの前で視線を送っている人に「見本誌、読んでってくださーい!」と声をかける。
  2. 本を手にとって、パラパラ見て本を戻す時に「パケットキャプチャとかお仕事で使われますか?」等と話しかける
  3. 具体的なユースケースが聞ければ、適宜参考になりそうなTipsやコメントをする

…というような感じで楽しく会話しつつ、最終的には執筆コストもまあまあ回収したので、初めてにしては上出来だったのではないかと思います。

宣伝

イベント前に勉強会でLTとかして宣伝しました。勉強会で知って来てくださった方もいらっしゃいましたので、そこそこ宣伝効果があったかもしれません。苦労の大部分を台風が吹き飛ばした気もしますが。。
宣伝といえば、イベント前に別件でTwitterがバズり、黒ブラのプロフィール画面と固定ツイートが非常に多くの方に閲覧されていたようです。しかし同人誌の告知をしていた固定ツイートのインプレッションが29700で、ふぁぼ(いいね)が衝撃の97、実に0.32%。バズる前に告知していた時点からほとんど増えていないという悲しい現実を見てしまいました。
なんか広告って難しいなぁ。(小並感)

オンライン販売について

以下のサイトでPaypal決済にてオンライン販売を行っております。 地方の方や台風で当日来られなかった方もいらっしゃるようなので、ぜひお買い求めください。

develup-japan.co.jp

決済やダウンロードに問題が発生した場合は上記サイトのコンタクトページかTwitterでご連絡ください。

NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13でLTしました。

以下に資料を公開しました。

www.slideshare.net

5分のLTだったので簡潔な内容ですが、黒ブラの職場で実際に起きたことをネタにしてみました。たぶん運用現場ではあるあるネタではないかと思います。

ぶっちゃけユーザー企業の情シスとしては、対応開始から原因究明+暫定対応まで、約1時間というタイムは悪くないと思っています。
この環境は障害対応時間をなるべく削減したいと願い、政治的にもかなり大ナタを振るった結果なので、いざ同様の環境を作ろうとすると、なかなか難しい部分もあると思います。

もしご興味があれば、コメントなどいただけると励みになります。
Twitterでもリプライやメンションいただければ反応しますのでよろしくお願いします。

同人誌出します

f:id:cloretsblack:20170930172608p:plain:w300
同人誌表紙

前回の投稿で、少し予告っぽく書いていたのですが、来る10/22(日)技術書典3 (会場:秋葉原UDX)において、パケットキャプチャの応用例とお手元で動作する環境を構築するためのクックブックを頒布します。

WEBシステムにおいて、データアクセスはアプリとインフラが入り混じる領域ではないかと思います。この領域におけるエラートラップと監視という課題に対し、データベースのコネクションをソケット経由にする事でパケットキャプチャというネットワークのデバッグ手法を応用する事ができます。
今回は例としてデータベースへのCRUDと内部エラー(デッドロック)をパケットキャプチャで解析してみました。また、エラーの検知から警告へ繋げる一連のシステムについても実装例を紹介しています。

ちなみに今回一番時間がかかったのはデッドロックを人為的に発生させるWEBアプリケーションの開発です(笑)

現時点でサークルチェック数が12と、非常に不安を掻き立てられていますが、何事も経験だと思いますので、とにかくやってみようと考えています。
配布はPDFですので、品切れはありません。
是非「い07企」ブースへお立ち寄りくださればありがたく思います。

techbookfest.org

JTF2017で発表しました

昨年に引き続き、今年もJTF2017で発表させていただきました。 当日は過去最高の参加人数だったとのことで、運営の皆様は非常に大変だったかと思いますが、おかげさまで気持ちよく発表や交流を行う事ができました。 このようなすばらしい機会を与えてくださった皆様に、心より感謝申し上げます。

今回のテーマは「情シスのひみつ」という事で、16年勤務した情報システム部門で得た様々な経験についてお話しました。
申し遅れましたが、黒ブラはこの8月に部署異動をしており、情報システム部門を離れ、ソフトウェア開発部門に配属されています。

www.slideshare.net

今回の発表は、個人的には「卒業研究」と位置づけています。 退職エントリとかではないのですが、すこし、自分の話をしてみたいと思います。

黒ブラは新卒でユーザー企業の情シス部門でインフラチームに配属され、パソコンのヘルプデスク業務からキャリアをスタートさせました。 たまたま、新システムの開発の手が足りないという事で、Oracleデータベースの夜間バッチ開発を手伝う事になり、割と早いうちからデータベースを覚えました。 その後、本格的にサーバ、ネットワークの管理を担当し、LinuxやDBA業務を覚えていく事になります。

ちなみに、経験ゼロで入ったヘルプデスク時代に、部署にあった、当時誰も触っていなかったSniffer Basic(商用のパケットキャプチャツール)を見よう見まねで弄り倒していた経験が入社4年目辺りから徐々に形になりだし、サーバ、DBなどの構築や操作は素人の癖に、何故かトラブルシューティングの精度だけ高いという不思議な覚え方をしました。

今にして思えば、分からない事に対し、分からないなりに取り組む時の姿勢として、

  • エビデンスを探し、Factを積み上げる
  • 正常と異常をI/Oレベルで見比べ、切り分ける

を習慣化していたことが、壁に突き当たってくじけたりする事もなく、長期間学習を継続できたポイントだったのかもしれません。

このスキルはその後、WEBプログラミング等、新しい技術を学ぶ際に幾度となく黒ブラを助けてくれ、 今ではデータベースのデバッグや監視すらもパケットキャプチャを応用する事ができるようになりました。

この辺りの事は以前ハンズオンセミナーをやったときに興味をもたれていた方がいらっしゃったので、少しノウハウとして書き残しておきたいと考えています。 今後何らかの形で皆様のお目に触れる事があるかも知れません。 そのときにはどうかよろしくお願いします。

IoTシステムのトポロジの話

ネットワークのトラブルシューティングのためのIoTを作っています。
先日発表した勉強会資料で、参加者から質問が出ていました。

www.slideshare.net

時間の関係でうまく説明できていなかったかもしれないと思いましたので、ブログ記事にします。

前置きとして、IoTシステムという文脈で語られる典型的な例として、デバイスによるセンシングとそれを集積するクラウドという構成があります。
このような構成はネットワークをはじめとするインフラの運用監視システムとしてはおなじみのもので、監視対象機器を設定し、トラフィック量、サーバのCPU使用率、DISK負荷、サービス応答時間、各種ログ等々を収集します。
勉強会ではインフラの運用管理システムがIoTシステムに、非常によく似ており、IoTデバイス=ネットワーク機器という図式が成り立ち、機器から集めたデータを可視化する運用管理システムは、すなわちIoTシステムではないかという所から話がスタートします。

頂いたご質問は、
「一般的なIoTシステムとして、デバイスで採取したデータをクラウドなどのサーバに集積して見せる形態が多く取られているが、今回の発表は同様のものではないのか?」
という趣旨のものでした。

両者の比較

一般的なトポロジ
f:id:cloretsblack:20170304095434p:plain

今回発表したトポロジ
f:id:cloretsblack:20170304095458p:plain

ご指摘の通り、IoTシステムの構成としては少し変わった形ではないかと思います。
トポロジが特徴的な理由としては色々あるのですが、黒ブラは普段システムを使う側の人間なので、ユーザー(黒ブラ)が本質的に何を望んでおり、どの様なシステムがマッチするのか、という問いに対する一つの結論だと思っています。
要点は以下の通りです。

・本来の目的
・やりたいこと
・データの解像度の問題
・最適なトポロジ

本来の目的

ネットワークやサーバの運用監視に用いられるシステムはOSS含め大量に存在し、日々しのぎを削っています。

これらの製品の目的は「継続的にサービスを提供すること」です。

安定してサービスを提供するためには
1.システムトラブルをいち早く発見すること
サービスの停止前に問題を発見できたらラッキーです。ユーザーが気づく前に修正できれば問題は起きていないのと同じです。

2.素早く復旧すること
不運にもサービスが停止してしまったら、素早く復旧することでビジネス損失を最小化できます。極端な話、利用ユーザーの少ない深夜に5分だけの停止で済めば、ビジネス上の問題は少ないケースがあり得るでしょう。

3.再発防止に取り組むこと
再発防止に取り組むことで問題そのものの発生頻度を減らすことができます。

サービスやプロダクトの安定性というものは、こうした問題解決のプロセスを数多く回し、それぞれの問題にきちんと対策が取られることにより向上するものです。
f:id:cloretsblack:20170304153043p:plain
集英社ジャンプコミックス 車田正美聖闘士星矢より引用

やりたいこと

これらの製品を使う上でユーザーが知りたい情報は下記の二つに集約されます。

・監視対象機器に問題が起きていないか
・問題が起きていたらその原因は何か

監視チームとデバッグ担当者が分かれている場合には、監視チームが担当者に通知して終わり、というケースがあり得ますが問題の解決には不十分です。

最低でも問題解決の糸口になる、欲を言えば問題個所の切り分けと、再現条件が得られるレベルの情報を集めることが理想です。

データの解像度の問題

どのような情報を集めるべきかというのはアプリケーションの作りによっても違いますが、従来の運用監視システムにおいてサーバのログや稼働情報を集めたとしても、問題の解決につながらないケースがわりと存在します。
これはデータの解像度の問題です。

実例を挙げて考えてみましょう。
f:id:cloretsblack:20170304100856p:plain

「A」という業務WEBシステムでは、データの参照、登録、削除機能に加え、クライアントPCからのファイルアップロード機能を備えています。アップロードされたExcelファイルの内容を読み込み、データベースに反映し、後続処理を行います。

あるとき、Aシステムで夜間バッチのメールが飛んでいないという問題がありました。
調べてみると、アプリケーションサーバがハングアップしていました。
サーバ再起動によって問題は解消し、リカバリー処理も完了しましたが、原因が分かりません。
ログを調べると夜間バッチ処理が起動していないことが分かったので、おそらく夜間処理前にアプリケーションサーバに何らかの障害があったのだと推測されました。

たいていのシステム障害はログに残っていなければ何もわかりません。この例ではアプリケーションサーバに問題があることは明白なので、まだだいぶマシですが、サポートに問い合わせても対策できない可能性はかなり高いでしょう。

次の手としては、
・ログの詳細度をデバッグレベルまで高め、一時的な負荷と引き換えに、問題の再現条件を探す
・とりあえずベンダーから出ているパッチを全部当ててみる(スクラッチ開発の場合は難しい)
ということになり、完全に出たとこ勝負のトライアンドエラーになります。

この例では、あるユーザーが深夜にアップロードしたファイルのデータバグが原因でした。
ログの詳細度を上げていれば発見可能だったかもしれませんが、厳密にはプログラムは異なる分岐を通りますし、負荷の状態も異なりますので、解決までのリードタイムは確実に伸びていたと予想されます。

結果として、この障害はSonarmanで解決しました。
・パケットキャプチャでログに残った時刻より、問題の通信とユーザーを特定
・発生時のサーバレスポンスから、処理負荷によるタイムアウトである可能性を排除
・その場でユーザーに電話して、問題のファイルを取得し、検証用としてベンダーに引き渡し
・証跡としてパケットキャプチャを添えた上で、開発環境での検証と修正を依頼
復旧作業完了後に原因究明を始めて、一時間以内に対応できました。
あまりにもサクサク進んだためか、この一連のやり取りでベンダーの担当者がちょっと引いていましたが…。

Sonarmanは、サーバに一切の変更を加えることなく、最大の解像度で障害に関する情報を取得するというコンセプトで開発されました。 解像度の低いデータをクラウドに集積してざっくりと全体を把握するのではなく、一撃で解決につながる濃い情報を現地に持つというイメージです。
ちなみに高解像度情報をクラウドに持つのは容量の問題で現実的ではないです。(そういった間を取るソリューションがNetflowコレクタです)

最適なトポロジ

それでは、ネットワーク機器をIoTとしてとらえた時に、トラブルシューティングを目的としたIoTでは、どのようなトポロジが最適なのでしょうか。
誤解してほしくないのは、従来のSNMPをはじめとする運用監視ツールは依然として必要だということです。
私自身も運用監視ツールは使っていますし、どちらが優れているというというよりは、ケースによりどのような情報が見たいかというユーザー要求の問題だと思っています。
様々なレイヤの異なる解像度の情報を組み合わせて分散して持っておいて、困ったときはちゃんと調べられる状態にしておくのが良い、というのが私の結論です。

f:id:cloretsblack:20170304154203p:plain

この記事を読んで下さった方のご参考になればうれしく思います。
最後に、手前味噌で大変恐縮ですが、IoT パケットレコーダー「Sonarman-R」Amazonにて発売中です!
この手のパケットキャプチャ装置としては業界に激震が走るレベルのコストパフォーマンスです。

Sonarman-R

Sonarman-R