MQTTシステム設計上の課題
IoT（Internet of Things）では、比較的小さなメッセージが定期的に送られてくるシステムを想定して作られています。デバイス上での軽量化するために、データ手順も簡素化されています。MQTTも軽量化されたプロトコルとして策定され導入が進んでいることは事実です。それでは前述のようにMQTTでのデータ通信を暗号化させた場合とそうでない場合では、データ通信量や手順に差が出てくるのでしょうか。さらに深く分析を行ったグラフを使って見ていきましょう。
図12はPublisherとMQTT Brokerでやり取りされるパケットを暗号化ありと暗号化なしで比較したものです。暗号化なしの場合SSL/TLSのやり取りがありませんので、その部分でのデータ通信はありません。いかがですか？ SSL/TLSのHandshakeを除けば、MQTTでのメッセージ発行にそれほど大きな差がないことがお分かりいただけるかと思います。暗号化によるデータ通信上でのオーバーヘッドはゼロではありませんが比較的軽微です。
より詳細にデータ通信比較について見ていきましょう。図13は「Publisher, BrokerにおけるMQTTコマンドの動作と暗号化データ通信」のMQTTコマンド部分に焦点を当てたグラフです。MQTT Connect commandからMQTT Publish Messageまで暗号化ありと暗号化なし、それぞれをデータ通信上でのパケットサイズを比較しています。
ご覧いただいたように、暗号化あり／なしに関わらず、IoTのデバイスが比較的小さなメッセージを発行する時には、比例してデータ通信のパケットサイズも小さくなります。至極当たり前ですね。
以前の連載記事『10Gigabit Ethernetでベンチマークする！』でお話したことがありますが、現在私たちが使っているOS（オペレーティングシステム）で使っている標準的なNICとTCP/IPドライバは、比較的小さいパケットサイズの処理が苦手とされています（図14）。
読者の皆様の中でも「そんな400万パケットのデータ通信なんて起こるわけがない！」とおっしゃる方もいらっしゃるかと思います。私もまったくもってそのとおりだと思います。また、いくら10GbE-NICを装備したサーバだからといって、すんなり処理性能の理論値までたたき出せることも稀でしょう。
ここで読者の皆様と共有したかったことは「仮に性能を出し切るだけの仕様要件があったなら、現在のシステムでもボトルネックを抱えている部分がある」コトを知っていただきたかったからです。
さらにMQTTシステム設計上の課題について考えてきましょう。
図15は、IoTセンサネットワークをMQTTで設計する際に取り得る方式を比較したものです。
IoTのデバイスは比較的安価でありCPU処理性能も極めて低いことが想定されています。大量のデバイスをセンサネットワークとして展開する場合、ユーザ認証や暗号化がコストや運用のボトルネックとなり得る場合も考えられます。こういった場合、従来からIP閉域網を用いて外部からの干渉を一切遮断したセキュリティポリシーによりシステム全体のコストと運用低減を計ることが良く用いられます。また、ユーザ認証と暗号化により強固なセキュリティを保持した状態でIoTデバイスをセンサネットワークとして展開することもあるでしょう。
いずれの方式を取るかはサービス事業者によって大きく異なってくるでしょうが、おおよそこの2つの方式に結論が帰結してくることでしょう。
