Column
Industrial IoTが求めるシカケの裏側

自動車の制御／センサーデータをどう収集するか【第３回】

ファストデータの遠隔データ収集の課題解決（その1）

坂元淳一（アプトポッド代表取締役）

2018年2月2日

考慮点2：データの欠損回収処理

　モバイルネットワークでデータを転送する場合は、いかなるインターネットプロトコルを利用しても、通信そのものが切断されてしまう可能性がある。そのためデータの欠損回収処理は必須である。欠損回収処理では以下のように、車載ゲートウェイシステムで送信ができない時のキューイング処理と、送信復帰時のサーバー側との送受信チェックが必要だ（図2）。

図２：欠損回収処理の概要

　サーバー側では、すでに送信できているデータを先にストアし、歯抜けになった欠損部のデータが到達次第データをストアしていく。

考慮点3：通信プロトコルの選択

　採用する通信プロトコルは、その目的によって選択肢が変わる。リアルタイム性の確保が不要で、データをできるだけ多く送りたい場合は、ある程度データを塊にし、圧縮率を上げて送ることが有用だ。その際、HTTPによって一定量のデータをパケット化して送信する方法や、FTPでファイル化して送信するなどの方法が代表的である。

　いずれにしても通信が断絶した状態においては、予定のタイミングで送信できなかったデータをゲートウェイ側でキューイングし、再送処理を実行しなければならない。サーバーから見れば、順次データが時系列順に送られてくるだけでなく、過去のデータも飛んでくる。タイムスタンプによって順番と重複をチェックしながらデータストアに格納していく必要がある。

　こうした仕組みを確立するためには、プロトコルの特性を考慮したAPIを実装し、エッジとサーバーの間で送受信をチェックする必要がある。たとえば、HTTPであればレスポンスが返ってくるので判断がしやすい。FTPでファイル転送を行うような場合は、ファイル単位で管理すれば比較的実装はシンプルにできる。

　問題はリアルタイム性を確保するケースだ。たとえば、リアルタイムな監視やイベント処理を要求されるケースの場合は、UDPやTCP系あれば「MQTT」「WebSocket」などリアルタイム性を確保できるプロトコルを選択し、発生するデータを連続的にストリーム送信する必要がある。

　UDPやMQTTの「QoS0」など、リアルタイム性は高いが到達保証がない方法を使って大量のミリ秒ストリームデータを投げ続けるケースにおいては、もはや送受信チェックをすることは現実的ではない。

　MQTTもQoSを「１」または「２」へ上げることで到達保証は上がる。だがリアルタイム性が低下し、オーバーヘッドも肥大化するため有効ではない。リアルタイム性が高いプロトコルで伝送されたデータは、データ回収に向かないという矛盾が生じる。

　結果的に「リアルタイム性がほしい」だが「データを完全回収したい」といった相反する要件を同時実装するために、オーバーヘッドを覚悟のうえで実装しなければならない。実際筆者が過去にとった実装では、次のように転送量を多重化したオーバーヘッドが大きなアプローチを採っていた。

リアルタイム系をMQTTのQoS0で送信し、サーバーではイベント処理やアプリケーションでのリアルタイムデータ表示でしか使わず、データストアしない
データ回収系は、データを1秒単位の塊にしてHTTPで送信し、データストアへ登録する
欠損回収処理もHTTP側で担保する

　現在では様々な検討の結果、WebSocket上に、リアルタイム送信と欠損回収処理などを同時処理するために、アプリケーションレベルで独自のプロトコルを実装することで、リアルタイム系とデータ回収系の両方の要求に柔軟に対応する工夫をしている。このように、遠隔データ回収においては、目的に応じたプロトコル選択とアプリケーションレベルでの工夫が必須になる。