プロトコルの選択肢と検討ポイント

今回は具体的なプロトコルの種類や転送方法についてご紹介したいと思います。

これまでに4つのIoTアーキテクチャが登場しましたが、通信プロトコルについてもいくつかの選択肢があります。

では、IoTという文脈で最適なプロトコルは何なのかというと、それは状況に応じて、さまざまなトレードオフを考慮して選択する必要があります。

以下では、IoTの文脈で頻繁に登場する代表的なプロトコルについての特徴を大まかに把握し、次にそれらをどのようにシステムに適用できるかを検討していきます。

HTTP

HTTPは最も良く知られたプロトコルの一つです。

• シンプルで汎用性が高い
• オーバーヘッドが大きい
• 既存の仕組みを流用しやすい

特徴は、TCPを使用し、非常にシンプルで汎用性が高いことです。

HTTPのリクエストとレスポンスには必ずメッセージヘッダーという、HTTPメッセージをそれぞれが処理するために必要な情報を添付する必要があります。

IoTの文脈では、HTTPの仕様の中でもとりわけメッセージヘッダーを作成し、転送するコストを鑑みて、HTTPを避ける場合があります。

MQTT

続いては MQTTです。こちらは、Pub/Sub型の通信を行う軽量なプロトコルで、IoTシステムでは比較的採用されることが多いプロトコルです。

MQTTには以下のような特徴があります。

• オーバーヘッドが小さい
• 一度に遅れるメッセージは 256バイトまで
• Pub/Sub型通信
• QoS(到達保証)
• 製品ごとの機能の違いが大きい

MQTTは HTTPよりも軽量で、データを送信する側のリソースが限られている場合に適しています。

MQTT通信を行うためには、データを送信するクライアントと、データを実際に処理するサービスの間に MQTTブローカーというサーバーを配置します。

大量に発生する粒度の小さいタスクを、サブスクライバーを多数用意して分散処理することが可能です。

状況に応じていくつか QoSレベルを選択することができ、クライアントとブローカー間の到達保証を設定できます。

低レイヤな通信手段 - TCP、UDP

IoTシステムでは、さらに軽量なプロトコルとして、HTTPや MQTTよりも低レイヤなプロトコルを採用する場合もあります。

• TCP
• UDP

その一つがTCPです。

TCPは信頼性を重視したプロトコルで、HTTPとMQTTのベースとなるプロトコルです。TCPはスリーウェイハンドシェイクという方法を用いて、データ転送の信頼性を確保しますが、その分通信回数が増えます。

対照的に、UDPでは通信相手にデータを送ったら送りっぱなしの通信を行います。そのため、データ転送の確実性には欠けますが、非常に軽量な通信を行うことができます。

たとえいくらかのデータが抜け落ちてしまっても、軽量さを優先させたいときに使われる場合があります。

トレードオフと選択

それでは実際にどのような状況でどのようなプロトコルが使えるのかを検討したいと思います。

またプロトコルの周辺で独自の工夫が求められるポイントについても検討します。

• 通信品質
• 通信量(料)
• マシンリソース
• バッテリー
• ミッションクリティカル性
• リアルタイム性
• セキュリティ

通信品質

考慮すべき点

• データの欠損
• 通信速度

特に「Device to Cloud」「Using Gateway」「Using Mobile」パターンでは、セルラ回線を使用する場合が多々あります。

使用するセルラ回線の品質によっては、データの欠損が想定されます。転送するデータが重要である場合は、欠損を何らかの方法でカバーする必要があります。

例えば、HTTPでは独自にデータの欠損を検知し、リトライを実施する仕組みを実装するなどの対応が必要になります。

また、通信品質が低いと、通信の遅延によりリアルタイム性が損なわれたり、バッファリング機能が求められたりすることもあります。

通信量(料)

考慮すべき点

• 転送量
• 転送頻度(通信のオーバーヘッド)

セルラ回線を使用していたり、通信量(料)を抑えたりするため、なるべく軽量なプロトコルを採用したいという場合もあると思います。

リアルタイム性も確保する必要があるのであれば、MQTTか、あるいは独自のプロトコルを模索することになるかと思います。

リアルタイム性を妥協できるのであれば、データをある程度バッファリングし、圧縮してからバッチ送信するなどの手段も考えられます。

マシンリソース/バッテリー

考慮すべき点

• 暗号化通信
• プロトコルの複雑さ

特に、「Device to Cloud」パターンや、「Using Gateway」パターンで考慮する必要があります。

データを送信するマシンのリソースが限られている場合、可能なかぎりシンプルなプロトコルを採用したい場合があります。

MQTTはHTTPよりもシンプルですが、暗号化通信が必要となると、一概にどちらが有効とは言い切れません。

ミッションクリティカル性

考慮すべき点

• 到達保証
• 順序保証
• トランザクション

MQTTの場合であれば QoSを上げることが考えられます。

MQTTの到達保証は、あくまでパブリッシャーとブローカー間の到達保証なので、さらにバックエンドで正常にデータを処理できたかまでを担保したい場合は、AMQPというプロトコルも選択肢として検討の余地があります。

また MQTTには順序保証がありません。トランザクションや順序保証などを意識した処理を行うためには、IoTに特化したプロトコルよりも、一般的に使用されているメッセージキューシステムを検討することも必要です。

リアルタイム性

考慮すべき点

• 転送頻度
• 通信のオーバーヘッド

リアルタイム性を実現しようとすると、頻繁にデータ転送が発生することになります。

通信のオーバーヘッドを減らすためであれば MQTTが有効です。

ある程度のデータの欠損はあったとしても、常に最新のデータを転送したい、というような場合、UDPを採用することも考えられます。

デバイス制御

考慮すべき点

• 双方向通信

デバイス、特にIoTゲートウェイに何らかの指示を与えたい場合、双方向通信ができるプロトコルか、メッセージキューを使用して、定期的にデバイスから指示を取得させる方法が考えられます。

双方向通信を実現するプロトコルとしては、WebSocketがあります。

WebSocketはサーバーとの持続的接続を利用するため、サーバー側に求められるリソースは多くなります。MQTTは、デバイス側もサブスクライバーとして機能することが可能なので、デバイス制御にも有効です。

*　　*　　*

IoTシステムの構築を考えるとき、比較検討する通信プロトコルと手段は多種多様にあります。

IoTの文脈では何かとMQTTが注目を浴びがちですが、MQTTが最高のプロトコルだから採用しているわけではなく、さまざまなトレードオフの結果、MQTTを採用している面があります。

実際にプロトコルや通信手段を選択する場合は、プロトコルの特徴をさまざまな面から把握するだけでなく、プロトコルの欠点をどのようにカバーするかまで含めて検討することが重要であると思います。

次回は、ファイル転送というデータ転送方法にフォーカスを当てて、より安全で確実なデータ転送について検討して行きたいと思います。