IoTの再送と冪等性｜通信が届いても二重登録が起こる理由

倉庫の温度計が、観測した温度をサーバーに送る場面を考えます。端末に「送信完了」が出なかったとしても、サーバー側に記録がないとは限りません。送信要求が届く前に回線が切れた場合と、サーバーが保存した後に確認応答が失われた場合は、端末から見ると同じ待ち時間切れになります。

ここで端末が記録を捨てれば、前者では欠測になります。反対に新しい記録として送信し直せば、後者では同じ観測が二つ保存されるかもしれません。「再送するか、しないか」の二択だけでは、欠落と重複を同時に解決できません。失敗した場所が分からない状況を扱う設計が必要です。

自作例では、端末Aの観測に「A-104」というIDを付けます。通信をやり直すときも同じ観測なら同じIDを使い、次の観測には「A-105」を使います。サーバーはA-104を初めて受け取ったときだけ保存し、再び受け取ったときは保存済みであることを確認して応答します。

IDは温度の値とは別です。10時と10時1分に同じ20度を観測することはあります。値が同じだから重複と判断すると、別の観測を消してしまいます。逆に再送のたびに新しいIDを発行すると、同じ観測と分からず重複防止になりません。何を「同じ一件」とするかを先に決めます。

冪等性は、同じ操作を複数回行ったときの意図された効果が、一回行った場合と同じになる性質です。HTTPのRFC 9110では、PUTやDELETEなどをこの性質で扱います。例えば設定値を20にする操作と、現在値に20を加える操作は異なり、後者を二回実行すると増分は40になります。

同じHTTPメソッドなら、どんな実装でも安全に再送できるという意味ではありません。業務側が意図どおりの意味で実装されている必要があります。また一回目と二回目で応答コードやログの内容が変わっても、それだけで冪等性が失われるわけではありません。確認するのは、狙った状態変更が繰り返されていないかです。

POSTを使う登録APIでも、サービス独自の処理IDを使って重複効果を防ぐ設計は可能です。ただしPOST一般に冪等性が保証されるわけではなく、利用側はそのAPIの仕様と、同じIDを保持する期間や同一性の判定条件を確認します。

メッセージが到達した、データベースに保存した、通知や請求などの業務処理を完了した、という三つは別の状態です。保存後に通知処理が失敗することもあります。受信済みの印だけを先に付けて再送を無視すると、まだ終わっていない業務処理まで終わったものとして扱う危険があります。

逆に業務処理が終わってから受信済みの印を書く途中で停止すると、復旧後に同じ業務処理をやり直す可能性があります。重複確認と状態更新の一貫性、処理途中の記録、再開できる段階を設計する必要があります。IDを追加したという一点だけで「重複は起こらない」と断定しないでください。

MQTTのQoSは、プロトコル上の送信者と受信者の間でメッセージをどう届けるかに関わります。QoS 1では重複配信があり得るため、アプリケーション側でも同じメッセージを受ける可能性を考えます。QoS 2の一回配信という性質を、別システムへの登録や請求まで含めた一回実行の保証に広げないことが重要です。

プロトコルが保護する区間と、業務が完了したと扱う区間を図に書くと、追加で必要な管理が見えます。MQTTの基本構造はMQTTとQoSの解説で扱い、本記事はその先の再送・保存・業務処理の境界に絞っています。

再送IDを毎回変えたらどうなるか、同じ温度を別時刻に測ったらどうするか、保存後に通知だけ止まったら何を再開するか。この三つを説明してみてください。「通信を安定させる」と「障害が起きても整合性を保つ」は、補い合う別の課題です。

設計条件を読み分ける練習はIoT中級の問題集の選び方、科目を横断した設計の確認はモバイル1級の問題集ガイドへ進めます。実際の教材範囲はIoT中級コースで確認してください。この解説だけで実システムの安全性や試験の得点を保証するものではありません。