IoTシステムに最適なMQTTネットワーク設計

MQTTを効率的に活用するには、IoTシステムに最適化されたネットワーク設計が不可欠であり、これがシステム全体の信頼性を大きく左右します。

本記事では、以下の重要なテーマについて詳しく解説します。
- MQTTブローカーとクライアントの構成
- IoTデバイスのネットワーク切断対策
- 大規模IoTシステムのパフォーマンスとスケーラビリティ

MQTTとは

MQTT（Message Queuing Telemetry Transport）は、軽量かつ効率的なメッセージングプロトコルであり、IoT（Internet of Things）やM2M（Machine to Machine）通信の分野で利用されています。
TCP/IPをベースとしたパブリッシュ/サブスクライブモデルを採用しており、限られた帯域幅や不安定なネットワーク環境下でも信頼性の高い通信を実現します。

MQTTブローカーとクライアントの構成

MQTTブローカーの構成

MQTTブローカーは一般的にクラウド環境に構築されることが多いですが、システム要件に応じてオンプレミス環境やエッジデバイス上に配置することも可能です。

クラウド配置

クラウド環境にMQTTブローカーを配置する構成です。クラウドサービスの機能を活用することで、迅速かつ容易にスケーラブルなMQTTブローカー環境を構築できます。

オンプレミス配置

組織インフラ内にMQTTブローカーを配置する構成です。データが組織内インフラに留まるため、機密情報の取り扱いが求められる場合や、セキュリティーおよびプライバシーが重視される用途に適しています。また、既存システムとの連携が容易である点もメリットの1つです。

エッジデバイス配置

エッジデバイス上にMQTTブローカーを配置する構成です。
エッジデバイス上で完結できる小規模なシステムに使われたり、手軽にMQTTを試す環境として利用されます。

クライアントの構成

IoTデバイスには、セルラー通信(4G/5G)、Wi-Fi、Bluetooth、LoRaWAN、ZigBeeなどさまざまな無線通信規格が用いられています。

MQTTプロトコル対応デバイスの接続

IoTデバイス自身がMQTTプロトコルを使用できる場合は、MQTTブローカーに直接接続することが可能です。
セルラー通信やWi-Fiを使用するデバイスの多くは、TCP/IPをサポートしているため、MQTTプロトコルを動作させるための通信基盤が整っています。
そのため、デバイスにMQTTクライアントを導入するだけで、MQTTブローカーとの直接通信が実現できます。

MQTTプロトコル非対応デバイスのIoTゲートウェイ接続

Bluetooth、LoRaWAN、ZigBee等を利用するIoTデバイスの中には、デバイスの制約やプロトコル上の特性でMQTTプロトコルを使用することが難しいものがあります。
こうした接続性の課題を解決するのが「IoTゲートウェイ」です。IoTゲートウェイは、MQTTクライアントとして動作し、エンドデバイスとMQTTブローカー間の中継役として機能します。具体的には、エンドデバイスから送信されたデータを受信し、MQTTメッセージに変換してMQTTブローカーに転送します。

IoTデバイスのネットワーク切断対策

電波状況が不安定な現場や移動中のIoTデバイスでは、ネットワークの接続断と再接続が頻発する可能性があり、データ損失や予期せぬ不具合が発生するおそれがあります。
MQTTプロトコルには、こうした不安定なネットワーク環境下でも確実なデータ伝送を実現する機能が組み込まれています。

ネットワーク切断後も状態を維持するセッション管理

MQTTプロトコルは、IoTデバイスとMQTTブローカーの接続が確立すると「セッション」という状態管理の仕組みが作成されます。
セッションには、トピックのサブスクリプション情報や送信中のメッセージ（QoS1,2）などの状態情報が保持されています。 ネットワーク切断が発生しても、再接続時にセッションを引き継ぐことで、ネットワーク切断前の状態から継続して通信を行うことが可能になります。
セッションには、有効期限があり接続時にSession Expiry Interval（MQTT v5.0）を指定して設定します。

また前回のセッション情報を引き継ぐか、新規セッションとして開始するかは、クライアント接続時に指定するClean Startフラグ（MQTT v5.0）によって明示的に制御することができます。

Clean Startを0に設定した場合
前回のセッション情報を引き継ぎます（前回のセッションが存在しない場合は、新規セッションとして接続されます）。
再接続時には、以前のサブスクリプションが自動的に復元されます。
ネットワーク切断中に送信できなかったQoS1やQoS2のメッセージは、再接続後にメッセージの送信者側が自動的に再送信を行います。
このため、ネットワーク切断が発生してもデータが失われることがありません。

Clean Startを1に設定した場合
前回のセッション情報を破棄し、新規セッションとして接続します。
一時的な接続（テスト端末など）や前回情報が不要な場合に使用します。

未達メッセージの再配信（QoS1, 2）

メッセージのQoSレベルの設定によって、ネットワーク復旧後にメッセージを再送するかどうかが決まります。
QoS1またはQoS2が設定されたメッセージについては、再接続時にセッション情報を引き継ぐことで自動的に再送されます。

クライアントとMQTTブローカー間の再送動作

パブリッシャ(送信側) → MQTTブローカー
パブリッシャがメッセージをMQTTブローカーに送信して到達確認ができなかった場合、再接続時にパブリッシャがメッセージを再送します。

MQTTブローカー → サブスクライバ（受信側）
MQTTブローカーまで到達したメッセージをサブスクライバに送信する間に、サブスクライバへの到達確認ができなかった場合、サブスクライバの再接続時にMQTTブローカーがメッセージを再送します。

QoSレベルを設定する際の注意点

QoS設定は、パブリッシャとサブスクライバがそれぞれ個別に行います。この仕組みについて理解しておくべき重要なポイントがあります。

エンドツーエンドではないQoS保証

パブリッシャが設定したQoSレベルがそのままサブスクライバに適用されるわけではありません。MQTTの通信は「パブリッシャ→MQTTブローカー」と「MQTTブローカー→サブスクライバ」の2区間に分かれており、それぞれの区間で設定されたQoSに従って配信されます。

パブリッシャがQoS2、サブスクライバがQoS1で設定した場合

・ パブリッシャ-MQTTブローカー間：QoS2
(パブリッシャがQoS2で送信しても、重複しないことが保証されるのはMQTTブローカー到達まで)
・ MQTTブローカー-サブスクライバ間：QoS1（重複の可能性あり）

QoSのダウングレード

サブスクライバが設定するQoSは「期待する最大のQoS」を意味します。パブリッシャが低いQoSで発行した場合、メッセージは低い方のQoSレベルで配信されます。

パブリッシャがQoS0、サブスクライバがQoS2で設定した場合

・ パブリッシャ-MQTTブローカー間：QoS0
・ MQTTブローカー-サブスクライバ間：QoS0
（サブスクライバがQoS2を要求していても、実際はQoS0で配信されるためデータが損失する可能性がある）

Willメッセージによるネットワーク切断検知

MQTTのWillメッセージ機能を活用することで、IoTデバイスが予期せず切断された場合に、他のクライアントやシステムに対して自動的に切断通知を行うことが可能です。これにより、デバイスの異常状態を迅速に検知し、適切な対応を取ることができます。

一方、一時的なネットワーク不良による頻繁な切断が想定される環境では、短期的な切断ごとにWillメッセージが発行されると不要なアラートが増加する課題があります。
このような状況に対応するため、MQTT v5.0で導入されたWill Delay Interval機能を利用することで、切断発生後も指定した時間内はWillメッセージの通知を遅延させることが可能です。
この遅延時間内にMQTTブローカーへの再接続が完了した場合、Willメッセージは発行されず、不要な通知を抑制できます。

Willメッセージの設定例

大規模IoTシステムのパフォーマンスとスケーラビリティ

大規模IoTシステムの運用においては、デバイス数やメッセージの増加に伴い、MQTTブローカーやクライアントへの負荷も増大します。
これらの負荷要素が増加すると、メッセージ処理の遅延やメモリ使用量の増加が問題になることがあります。安定したIoTシステムを構築するためには、適切な負荷分散とスケーリングが不可欠です。

クラスタリングによるスケールアウト

大規模IoTシステムの性能向上には、MQTTブローカーの「クラスタリング」が効果的です。
クラスタリングは、複数のMQTTブローカーを1つの論理的なMQTTブローカーとして動作させることで、メッセージのスループットが向上し、より多くのIoTデバイスを接続することが可能になります。
この機能は全てのMQTTブローカー製品で対応しているわけではありませんが、大規模IoTシステムでは重要な選択肢となります。

MQTTブローカー間の効率的な負荷分散

クラスタリング環境では、複数のブローカー間で処理負荷を適切に配分することがパフォーマンス向上に繋がります。
この負荷分散を実現する方法として、主に以下の2つが広く採用されています。

ロードバランサーによる負荷分散
この方法では、クライアントからの接続をロードバランサーが受け取り、適切なMQTTブローカーへと振り分けます。また負荷を均等に分散させるだけでなく、MQTTブローカーの冗長性も確保できます。ある特定のMQTTブローカーで障害が発生しても、ロードバランサーは正常に動作しているMQTTブローカーへと接続を転送するため、システム全体が停止することなく動作し続けることが可能です。

サーバーリダイレクトによる負荷分散
外部から振り分けを行う方法に対して、MQTT v5.0では「サーバーリダイレクト」というMQTTブローカー自身が振り分けを行う方法があります。
この機能を使用することで、MQTTブローカーがクライアントに別のサーバーへ接続するように要求することができます。
MQTTブローカー自身が負荷状況に応じて要求を行うため、より効率的な負荷分散を実現することができます。

比較

クライアント受信処理の負荷を軽減する方法

クライアントの性能によっては、大量のメッセージを一度に受信すると処理が追いつかないことがあります。
このような場合の対策として、「共有サブスクリプション(MQTT v5.0)」を利用して複数クライアントで処理を分担する方法が効果的です。

共有サブスクリプションを利用する場合、サブスクライブは `$share/{共有名}/{トピック名}` という形式で指定します。同じ共有名でサブスクライブしているクライアントのうち、いずれか1つにだけメッセージが配信されます。
これにより、同一トピックのメッセージ処理を複数のクライアントに分散することができます。（どのクライアントにメッセージが配信されるかはブローカーの実装に依存します）。

まとめ

適切なMQTTネットワーク設計により、大規模IoTシステムにおいても信頼性の高い通信を実現できます。特に無線通信を利用する環境では、ネットワーク切断を想定した堅牢な設計が重要です。IoTシステムの規模や要件に応じて、最適なネットワーク構成を選択することで、安定したシステム運用が可能になります。

「MessagePub+」のご紹介

オージス総研が提供する「MessagePub+」は、MQTT v3.1.1と最新のv5.0に対応した高性能なMQTTブローカーです。
本記事で解説したMQTTネットワークの課題を解決し、クラスタリング対応による高いスケーラビリティを実現しながら、優れた安定性とセキュリティーでIoTシステムを強力に支えます。

ネットワーク設計に関するご相談も受け付けております。
無料トライアルで「MessagePub+」の機能をぜひご確認ください。

2025年7月9日

※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。