IoTシステムのトポロジの話 - cloretsblackのテクニカルノート

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

ネットワーク運用とIoT from cloretsblack

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