センサの値をどう届ける？｜HTTP・MQTT・ゲートウェイと通信量

センサの値は、測るたびにクラウドへ送ればよいのでしょうか。台数が増えたり、回線が切れたりすると、通信量、遅れ、欠測、重複を考える必要があります。必要な鮮度と、失ってはいけない情報を先に決めましょう。

事例：100台のセンサで温度を監視する

工場の100台のセンサが10秒ごとに計測し、ゲートウェイを経由して監視サービスへ値を送ります。一件の計測データは80バイトです。異常値を計測してから監視側が受け取るまでの遅れは最大5秒、10分の回線切断でも計測を保存する要件があります。

最初の通信量計算では、一件ごとの通信負荷を40バイトと仮定します。これはHTTPやMQTTの固定サイズではなく、指定したモデルの値です。実際のヘッダ、TLS、再送、接続維持の負荷は別に見積もります。

ブローカは送信されたメッセージを、トピック等の条件に合う購読者へ届ける中継サーバです。業務データを長期間保存するDBとは役割が異なります。

HTTPとMQTTは、何が違う？

HTTPは要求と応答で資源を操作するためのプロトコルです。APIへ計測値を送る、設定を取得するなどに使えます。HTTPでも接続を再利用でき、毎回必ず新しいTCP接続を作るとは限りません。

MQTTは送信側がトピックへ発行し、受信側が購読する方式です。送信側が監視アプリの個別の接続先を知らずに、ブローカを介して複数の利用者へ配信できます。ここではMQTT 5.0をTCP上で使う構成を扱います。

ゲートウェイは端末側の通信をまとめ、形式変換、認証、保存、再送などを担当できます。一方で故障時の共通停止点にもなるため、必要な容量と復旧を設計します。MQTTを選んだだけで切断に強い保存機能が完成するわけではありません。

QoSを上げれば、業務処理も一回だけ？

MQTTのQoSはメッセージ配送の扱いです。0は最大一回で欠落があり得る方式、1は少なくとも一回で重複があり得る方式、2は一回の配送を確認手順で実現する方式です。高いQoSほど確認や状態管理の負荷が増えます。

QoS 2でも、監視アプリのDB更新や機器制御が常に一回だけ実行される保証ではありません。発行側からブローカ、ブローカから購読側は別の配送です。アプリ側の再送や、処理後の応答を失った場合も考えます。

配送保証は、プロトコルの状態やセッションの条件が保たれる範囲で考えます。切断後に再開できる条件や保存期限、機器の電源断で失われる状態を確認し、QoSの番号だけで永続保存まで保証しません。

再送による二重登録を防ぐなら、センサIDと計測番号などの識別子を付け、同じデータを再受信した際に同じ結果として扱います。時刻だけを識別子にすると、同時刻の別計測や時計の補正で区別できない場合があります。

Retain、セッション、保存は同じもの？

1. Retain

   トピックの最新の保持メッセージを、新しい購読時などに受け取る仕組み。全履歴の保存ではありません。

2. セッション

   購読や配送途中の状態等を保持する仕組み。MQTT 5.0では開始・期限の条件を確認します。

3. ローカル保存

   回線切断中の計測をゲートウェイ等に保存する処理。容量、消失条件、再送順序を設計します。

4. Will

   接続が異常に終わった場合などの通知に使う仕組み。通知条件や遅延設定、計画切断を確認します。

保持された最新値が届いても、今測った値とは限りません。計測時刻と受信時刻を区別し、古い値を現在の異常として扱わない条件を決めます。履歴が必要なら、別の永続保存と検索の設計が必要です。

電源断でも計測を残すなら、メモリだけのバッファでよいかを検討します。保存領域が満杯のときに古い値を捨てる、計測を止める、優先する値を残すなど、欠測や遅延の要件に合う方針を決めます。

必要な帯域と保存容量を計算する

100台が10秒ごとに一件なら、毎秒平均10件です。一件を80＋40＝120バイトとするモデルでは、1200バイト/秒、9600bit/sです。平均値だけでなく、100台が同時に送る瞬間の集中や、再接続時の再送も確認します。

480000バイトは計測データだけの最低量です。識別子、時刻、保存管理の負荷、余裕、電源断からの回復を加えて容量を決めます。通信時の40バイトを、そのまま保存領域の負荷とみなす必要はありません。

復帰後に再送へ8000バイト/秒を使え、保存された80バイトの各件にも40バイトの通信負荷が掛かるなら、再送量は6000×120＝720000バイトです。通常通信の帯域とは別にこの容量を確保したモデルで、解消には90秒です。

帯域に余裕がないまま再送を優先すると、新しい異常値が遅れる場合があります。最新の警報と履歴の再送を分け、どのデータを先に届けるかを設計します。

まとめて送ると、遅延要件はどう変わる？

まとめ送りはヘッダや接続処理の回数を減らせますが、送信まで待つ時間が増えます。30秒ごとのまとめ送りだけで異常を通知するなら、直後に発生した異常は最大約30秒待ち、5秒以内の要件を満たせません。

事例では通常値はまとめ、異常値は即時送るなどの候補を比較します。計測自体が10秒ごとなので、物理的な異常発生から必ず5秒以内に検知する要件なら、計測周期も見直す必要があります。『計測後から受信まで』と『異常発生から受信まで』を混同しません。

通信を暗号化しても、トピックの権限は必要？

TLSで通信路を守り、接続先の証明書を検証します。送信側の認証、資格情報の更新・失効、トピックへの発行・購読権限も必要です。すべての端末に同じ強い管理権限を与えると、一台の侵害が広い操作へつながります。

センサが値を送るトピックと、機器へ制御を送るトピックは分け、必要な操作だけを許可します。古い制御や重複した制御を再実行しない条件も決めます。受信した値を信用するかは、送信元、時刻、範囲、欠落を含めて確認します。

演習1：平均帯域

条件：100台、10秒ごと、一件の通信量120バイト。再送等は無視する。

問い：平均の必要帯域をbit/sで求める。

解答例：100÷10×120×8＝9600bit/s。

根拠：毎秒の件数に一件のバイト量を掛け、bitへ変換する。

誤答の理由：『1200bit/s』はバイトとbitを取り違えている。

演習2：切断中の保存

条件：一件の計測データ80バイト。演習1の台数と周期で10分切断する。

問い：管理情報を除いた保存量を求める。

解答例：100÷10×600×80＝480000バイト。

根拠：切断中に作る6000件の計測データを保存する。

誤答の理由：通信ヘッダの40バイトを必ず保存すると決め付けず、保存形式の負荷を別に確認する。

演習3：再送の時間

条件：6000件を一件120バイトで再送し、再送専用に8000バイト/秒を使える。

問い：モデル上の解消時間を求める。

解答例：6000×120÷8000＝90秒。

根拠：再送する通信量を、通常通信とは別に確保した速度で割る。

誤答の理由：『保存量480000÷8000＝60秒』は再送時の通信負荷を落としている。

演習4：QoSと二重登録

条件：QoS 1で値を送り、監視DBへ同じ計測が二度届く可能性がある。

問い：追加するデータと処理を答える。

解答例：センサIDと計測番号等を付け、同じ識別子の再受信を重複として扱う。

根拠：配送で重複があり得るため、業務側で同じ計測を区別する。

誤答の理由：『TCPだから業務DBも必ず一回』はアプリの再送・再処理を区別していない。

演習5：Retainの限界

条件：新しく購読した監視画面に保持された最新値が届いた。

問い：過去10分の全計測も取得できたと言えるか。

解答例：言えない。Retainは全履歴の保存・取得ではない。

根拠：保持メッセージと、履歴を保存するDBは役割が違う。

誤答の理由：『最新値があるので過去の全値もある』は保持の範囲を広げ過ぎている。

演習6：遅延の起点

条件：10秒周期で計測する。要件を『物理的な異常発生から5秒以内の受信』へ変更した。

問い：送信だけを即時化すれば必ず満たせるか。

解答例：満たせない。異常が次の計測まで待つ可能性があり、計測周期や検知方式も見直す。

根拠：要件の起点が計測後ではなく、異常の発生時である。

誤答の理由：『即時送信なら遅れはゼロ』は計測までの待ち時間を落としている。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

OASIS：MQTT Version 5.0

RFC 9110：HTTPの意味と再実行

RFC 8446：TLS 1.3

NIST SP 800-213：IoT機器のセキュリティ要件

関連テーマを続けて学ぶ

TCPと通信性能

認証とアクセス制御