- Column
- Industrial IoTが求めるシカケの裏側
自動車の制御／センサーデータ収集におけるペイロード設計【第4回】
ファストデータの遠隔収集の課題解決（その2）
そこで、データ回収性能とリアルタイム性能を同時に確保するためには、以下のような工夫が必要になる。
MQTTとHTTPを併用実装する
第1の選択肢は、一部のデータ（監視したいデータ）に限定したリアルタイムストリームをMQTTで、全データ回収をHTTPで転送するといった具合に、機能を並走させるパターンである。
MQTTによるリアルタイムストリームは表示用に限定されるため、若干の欠損も許容される。HTTP側では効率的にデータをパッキングし、まとめて圧縮するなどして送信することで、遅延は発生するもののデータ回収効率を重視できる。しかし、同一データを別経路で二重に転送することになるので、全体としては帯域を圧迫する方式になる。
WebSocketで実装する
WebSocketを使用する場合、欠損時の再送処理をアプリケーション機能として実装する必要はあるものの、リアルタイムストリームと圧縮処理を同時に実現できる。ただし、あくまでもTCPの特性に依存するため、極端な帯域減少などが発生した場合は、ACK待ちなどが起因してリアルタイム性を失うだけでなく、データが詰まりコネクションが破たんするケースも否めない。
WebSocketの実装でデータ回収性能とリアルタイム性能を実現する場合は、サーバーでの中継処理やコネクション管理を含め、それ相応のアプリケーション開発が必要になる。
ポイント4：データの圧縮率
データ伝送効率においてデータ圧縮は重要な項目だ。だがプロトコルによって圧縮の可否、圧縮性能が異なる。
HTTP：規約上で定められたデータ圧縮としてgzipを用いることができ、圧縮措置の実装も容易だ。これにより約30%の圧縮率でデータ伝送効率を高められる。
MQTT：規約に定められたデータ圧縮方法はない。圧縮済みデータを塊として伝送できるが、本ケースでは単発のデータを都度送信することでリアルタイム性を確保するため、圧縮効果は期待できない。
WebSocket：ストリーム処理を行いながらも、メッセージ単位でのDEFLATE圧縮や同一コンテキストで圧縮するContext Takeover （辞書継承）を利用できる。規約上に定められた方式のため、実装は比較的容易である。データの性質にもよるが、平均して約33%の圧縮率を実現できる。ただし、ストリーム開始から一定の処理経過を経て圧縮率が最大化する。
図2は、実際にストリームデータに辞書継承による圧縮をかけた例だ。だが、約50データくらいの連続ストリームで圧縮率が安定していることがわかる。ただし、流し始めに関しては圧縮率が低いことから帯域を考慮したペイロード設計が重要になる。
