【ITニュース解説】MQTT Last Will Messages: What an Offline Alert Actually Means

MQTT（Message Queuing Telemetry Transport）は、IoTデバイスなどの小さな機器とインターネットの間で効率よくデータをやり取りするための軽量な通信プロトコルである。このMQTTの世界では、「ブローカー」と呼ばれるサーバーがメッセージを中継し、「クライアント」と呼ばれるデバイスやアプリケーションがメッセージを送受信する。ブローカーは、クライアントが送信したメッセージを適切な受信者に届ける役割を担っている。

このMQTTには、「Last Will and Testament（LWT）」、一般に「LWT」と呼ばれる特別な機能がある。これは、クライアントがブローカーとの接続を予期せぬ形で失った場合に備え、あらかじめ「遺言メッセージ」をブローカーに預けておく仕組みである。もしクライアントが突然ネットワークから切断されたり、電源が落ちたりして、正常な切断手続きを行えなかった場合、ブローカーは預けられたこのLWTメッセージを、そのクライアントが指定したトピック（メッセージの種類や宛先を示すラベルのようなもの）に自動的に公開する。これにより、監視システムなどはデバイスがオフラインになったことを素早く検知できるため、特にデバイスが常に接続を維持していることが期待される状況では非常に有用だ。

しかし、このLWTによる「オフライン」アラートを過剰に解釈しないことが重要である。LWTメッセージが伝えるのは、あくまで「MQTTクライアントの接続がブローカーから見て予期せず失われた」という事実のみである。このアラートだけで、例えば「NAS（ネットワーク接続ストレージ）が故障した」とか、「特定のサービスが停止した」とか、「ネットワーク全体がダウンした」といった具体的な原因を断定することはできない。ブローカーはクライアントの接続状態を監視しているだけであり、デバイスの内部で動いている全てのプロセスや、ネットワークインターフェースの状態、ファイル共有の状態などを一つ一つ確認しているわけではないからだ。

例えば、あるデバイスが「オンライン」を示すメッセージを送信して接続し、同時に「オフライン」を示すLWTを設定したとする。もしWi-Fiが途切れたり、デバイスの電源が失われたり、ネットワーク経路に障害が発生したりすれば、ブローカーは最終的に「オフライン」のLWTを公開するだろう。これは、ブローカーがクライアントからの正常な切断信号を受け取らなかったことの良い証拠となる。しかし、それが具体的にどの原因によるものなのかはLWTだけでは分からない。また、同じデバイス上で動作しているファイル共有やウェブインターフェース、ストレージの状況なども、LWTからは一切読み取れないのだ。

LWTは、あくまで「予期せぬ接続の喪失」を報告するための機能であり、アプリケーションが意図的にシャットダウンされた場合のような「正常な切断」時には、通常、LWTは公開されない。そのため、誰かが意図的にサービスを停止したかどうかをLWTで判別することは信頼できない。

また、LWTメッセージの公開タイミングにも注意が必要だ。MQTTクライアントとブローカーは、「Keepalive（キープアライブ）」と呼ばれる定期的な通信を利用して、接続が生きているかどうかを確認している。もし接続が途絶えても、ブローカーはKeepaliveの応答がないことを確認するまで、すぐに切断を検知するわけではない。そのため、ケーブルが抜かれた瞬間にアラートが出るわけではなく、設定されたKeepaliveの間隔やネットワークの状況によって、検出までに多少の遅延が生じる。MQTTバージョン5.0では、LWTが公開されるタイミングをさらに細かく制御する「Will Delay」といったオプションも導入されており、これらもメッセージの受信時間に影響を与える可能性がある。

さらに、LWTメッセージには「Retain（リテイン）」という設定が付与されることがある。これは、ブローカーがそのトピックの最新のメッセージを保持しておき、新しいサブスクライバーが接続したときにそれをすぐに送信する機能だ。もしオフラインのLWTがRetainされていると、新しいサブスクライバーが起動したときに、その過去のオフラインメッセージを受け取ることがある。これは「最後に記録された状態」を報告しているだけであり、サブスクライバーが接続したまさにその瞬間に新しい障害が発生したことを意味するわけではないため、誤解を招かないよう注意が必要だ。

LWT機能を実際にテストする際は、本番環境に影響を与えないよう細心の注意を払うべきである。テストは、管理者が管理するブローカーとネットワーク上で行い、本番のデバイス制御トピックや、物理的なアクション（ロック、スイッチ、アラートの発生など）を引き起こす可能性のあるトピックではなく、明確にラベル付けされた専用のテストトピックを使用することが不可欠だ。テスト用のクライアントを準備し、オンライン通知とオフラインLWTを設定し、別のクライアントでそのトピックを購読して、メッセージの内容、受信時刻、Retainフラグなどを記録する。まず正常にクライアントを切断した場合にLWTが発行されないことを確認し、次にクライアントのネットワーク経路を遮断したり、プロセスを強制終了したりして、予期せぬ切断時にLWTが正しく受信されるか、そしていつ受信されるかを確認する。テスト用のメッセージの内容は、「test-online」や「test-offline」のような、機密情報を含まない簡潔なものにすることが推奨される。もしRetainを設定してテストした場合は、テスト終了後に残ったRetainメッセージを削除するのも良い習慣である。

結局のところ、LWTアラートだけでは具体的な問題の答えにはならない。もし「NASのファイルサービスにアクセスできるか」を知りたいのであれば、実際にそのサービスに対して認証された経路で接続テストを行うべきだ。ホストが再起動したかを確認したいのであれば、システムログや稼働時間を示す記録を調べるのが適切である。Wi-Fiの状態変化を知りたいのであれば、ネットワーク機器の現在の接続情報を確認する必要がある。LWTが伝えるのはMQTTの接続イベントであり、これら一つ一つの問いには、それぞれ独立した確認方法が必要となる。

自動化システムを構築する際、LWTによるオフラインアラートを受け取った後、短時間のWi-Fiの不安定さやブローカーの再起動による一時的な切断をノイズとして扱わないように、通知を送る前に短時間の猶予期間を設けることも有効である。この猶予期間を過ぎてもオフライン状態が続いている場合にのみ通知することで、不要なアラートを減らすことができる。ただし、これもLWTをデバイスの「健全性チェック」に変えるものではないことを理解しておくべきだ。

ブローカーやサブスクライバーの再起動は通常の運用の一部である。これらが一時的に接続を中断させたり、RetainされたLWTメッセージを再送したりすることがある。特定のトピックに通知を紐付ける前に、テスト環境でサブスクライバーを再起動し、以前にRetainされた状態を受け取るかを確認しておくことが重要である。また、ブローカーの再起動時には、パブリッシャー（メッセージ送信側）がどのように再接続するかを観察することも大切だ。

信頼できるトラブルシューティングの記録は簡潔に「この時、サブスクライバーは設定されたアベイラビリティトピックでオフラインメッセージを受信した」と記述するのが良い。そして、それとは別に独立した確認とその結果を記録する。LWTの実際の価値は、管理システムが予期せぬMQTT切断を標準的な方法で伝える手段を提供することにある。定義されたトピック、管理されたテスト、そして独立した追跡調査と組み合わせることで、次に何をチェックすべきかを判断するための貴重な手がかりとなる。しかし、単独で受信したオフラインメッセージは、ブローカー接続の問題を示す場合もあるが、意図的なLWTの公開やRetainされた過去の状態を反映している可能性もあることを理解し、それがデバイス全体の状態を断定するものではないと認識することが極めて重要である。