MQTTについて考えた事

MQTT即ちMessage Queuing Telemetry Transportについては、本家IBMの以下の記事あたりが参考になります。

https://www.ibm.com/developerworks/jp/iot/library/iot-mqtt-why-good-for-iot/index.html

我が社ではこの所、MQTTを使ってクラウドから電源設備内の消耗部材の劣化状態を遠隔診断する開発案件に従事しており、いよいよ来月から順次、実設備へのトライアル導入に入る見込みです。
具体的な案件内容は守秘義務があるので書けませんが、開発的には一応一区切り付いた折りでもあり、折角なのでMQTTについて私が感じた事・考えた事など、この機会に少し書き出しておこうと思いました。

MQTTで改めてググったら、以下の記事が単なる建前論でなく現実的な視点に思えて面白かったので引用させて頂きます。

https://gist.github.com/voluntas/e0a90f3e22316144ed3a

「ヘッダーが最小2バイトなのでhttpに比べて軽量」に対し、「たしかに最小なのだが、ペイロードが1メガバイトとかになったら完全に誤差範囲」とか、その通りだと思いました。TLS over TCPの時点で大変重いという指摘にも納得で、以前に某スマートメーター案件で低速PLC通信上でDLMS/COSEMのHLS対応や6LowPANマッピングとかやった時や、某スマートホーム案件で低速通信Zigbee上でのOTAファーム更新処理とかで、理想はともかく現実的には同種の潜在的な問題があった事を思い出しました。そんなに重いMQTTを「低消費電力」とか安直に持ち上げている浅いまとめ記事がネット上にあったりしてどうかと思う、そういう時に良く比較対象にされているWebサービスのhttpも、このあたりをちゃんとチューニングしない限りはMQTTと言う程変わらないとの指摘も、その通りだと思いました。

ではMQTTの一体何が良いのか?ですが、私的には「クラウドに向いたPub/Sub型モデルである事」だと思っています。
とはいえ、非同期システム間連携だとファイル渡しやテーブルポーリングとか以前から普通に使われていましたし、InternetでもMailとかそもそも非同期ですし、JavaにもJMSとか結構以前からありますし、Pub/Sub型モデル自体に特段の新規性があるとは、私はあまり思いません。
要は「クラウドに向いた」という点に尽き、そういう意味ではApache Kafkaとかに志向性が近いと思います。

それでもMQTTは、実際に動くオープンソースのクライアント実装が複数言語で既にあり、かつある程度は枯れているようでもあり、特にプロジェクトに多様なメンバーが参加するケースだと、他の方式よりは開発ハードルが割と下がるようです。
パブリッククラウドでインターネットを介するIoTパターンの案件であれば、比較的ありかも知れません。

一方で、例えばCATVのDOCSIS網やFTTH、4/5G等の通信キャリア内で閉じたアクセス網の末梢機器の監視用途には、TLS over TCPが重過ぎるという意味で、MQTTは向いていないように思います。MQTT-SNというUDPベースの軽量版もあるにはあるらしいのですが、通信機器の監視用としてはSNMPが今現在もデファクトであり、インターネット越えという時代の要請に応じて開発されたhttpベースのTR-069 CWMPですら未普及なのに、MQTT-SNがアクセス網末梢の端末機器にまで普及するような状況は、将来的にもあまり現実的には思えません。
とはいえ例えばCATVのDOCSIS網の場合、パブリッククラウドからインターネットを介して網末梢のCM/EMTA/STBを管理・監視するサービスのビジネス化構想自体は業界内に以前からあり、DOCSIS網との特性差を考えると、MQTT的な非同期Pub/Sub型モデルの導入には、相応の性能向上をある程度期待できるようにも思います。
具体的には、パブリッククラウドの「エッジ」即ち、アクセス網センター設備のCMTS後段にSNMPマネージャー兼Pub/Subブローカーを配置、アクセス網内は同期SNMP通信、パブリッククラウドからアクセス網まではMQTT等で非同期にPub/Subすれば、クラウド側のCPU負荷抑制や通信量の削減目的であれば、ある程度は有効なように思います。
但し上で述べた通り、この場合の非同期プロトコルがMQTTである必要性は必ずしもなく、例えばKafkaでも良いですし、極論すればVPNを張ってファイル渡しやテーブルポーリングでも良いと思います。
例えばSNMPのMIBをパースしてPub/Subラッピングしてくれるマッパー的なものがあれば面白いと思います。
“mqtt snmp bridge”とかでググると色々出てきますが、自社製品のプラグインだったりアプライアンスだったり、GitHubにオープンソースを見つけたと思ったら特定機器に限定したほぼ手定義構造だったりとか今イチです。
“kafka snmp bridge”だと多少はましで、例えばGitHubにあった”jcustenborder/kafka-connect-snmp”とかそれっぽいのですが、snmp実装がTrapだけなのが残念、というのは特にDOCSIS網の場合、定期収集を不用意に下から上へのTrap的なシーケンスで組むと、複数端末からの通信タイミングが上手く散らせず衝突が頻発、処理待ち&再送が多発、経路上の何れかの機器の負荷が上がりバッファオーバーフロー等が発生、最悪だとネットワークパニックに至るケースがあり得ます。DOCSISに限らず他のアクセス網も、割と結構似たり寄ったりの筈です。このため我が社では、トラフィック特性の平滑分散の自律制御周りを、敢えて自社でプログラミング・チューニングできる上から下へのGetで実装している訳であり、そういう意味ではライブラリがGetに対応できていないと、残念ながら我が社的には実用に耐えません。
とはいえGetだと、SNMPで収集した状態情報を一定単位でまとめて一括Pub/Sub操作する概念等も欲しくなってきますから、そうなると安直にSNMP OIDと1:1対応できなくなり、データモデル設計が複雑化して開発ハードルが上がる訳で、そういう意味では何故現状がTrapのみばかりなのか、同稼業の者としてはある程度容易に察せられます。
いっそ、SNMP MIBのMQTT/Kafkaパーサーだけあった方が使い易いのですが、流石にニーズがニッチ過ぎるようで見つかりません。現時点では、何れかの公開ソースを参考にしながら自分で書くしか手がなさそうです。

現在、我が社の監視・管理系製品のアーキテクチャーの抜本的な見直しの一環として、クラウドへの対応方針を策定中であり、このあたりの非同期Pub/Sub型モデルの導入要否や効果等も、できれば一通り検討してみたいと思っています。
因みに非同期Pub/Sub型モデル以外だと、Docker/kubernetes等のコンテナ型仮想化、少し前に流行ったJboss Fuse的なESB型システム間連携、ちょっとだけ新しい所だとTensorFlow等AI技術のナレッジベース応用あたりを検討したりしています。