Azure Event Grid の MQTT ブローカー機能でサポートされる MQTT の機能

  • [アーティクル]

MQTT は、制約のある環境向けに設計されたパブリッシュ/サブスクライブ メッセージング トランスポート プロトコルです。 効率的、スケーラブルで信頼性が高く、IoT シナリオでの通信のゴールド スタンダードになりました。 MQTT ブローカーでは、MQTT v3.1.1、MQTT v3.1.1 over WebSockets、MQTT v5、MQTT v5 over WebSockets を介してメッセージのパブリッシュとサブスクライブを行うクライアントがサポートされています。 また、MQTT ブローカーでは、異なる MQTT バージョン間 (MQTT 3.1.1 と MQTT 5) の通信もサポートされています。

MQTT v5 には、よりシームレス、透過的で効率的な通信を実現するために、MQTT v3.1.1 に比べて多くの機能強化が導入されています。 以下が追加されました。

  • エラー レポートの改善。
  • ユーザー プロパティやコンテンツ タイプなどの機能により、より透過的な通信クライアント。
  • メッセージやセッションの有効期限などの機能による、クライアントの通信に関するより詳細な制御。
  • 要求 - 応答パターンなどの標準的な重要なパターン。

接続フロー:

MQTT クライアントは、TLS 1.2 または TLS 1.3 経由で接続する "必要があります"。 この手順をスキップすると、接続が失敗します。

MQTT ブローカーへの接続中、MQTT 経由で通信する間は次のポートを使います。

  • MQTT v3.1.1 と MQTT v5: TCP ポート 8883
  • WebSocket 経由の MQTT v3.1.1 および WebSocket 経由の MQTTv5: TCP ポート 443。

CONNECT パケットには、次のプロパティが含まれている必要があります。

  • ClientId フィールドは必須であり、クライアントのセッション名を含める必要があります。 セッション名は名前空間全体で一意である必要があります。 各クライアントがクライアントごとに 1 つのセッションを使用している場合は、セッション名としてクライアント認証名を使用できます。 1 つのクライアントが複数のセッションを使用している場合は、そのセッションごとに ClientId に異なる値を使用する必要があります。
  • 名前空間の作成時に alternativeAuthenticationNameSources の値を選択しなかった場合、Username フィールドは必須です。 その場合は、Username フィールドにクライアントの認証名を指定する必要があります。 この名前は、指定された認証名と、クライアント リソースの作成時に指定されたクライアントの証明書フィールドの値と一致する必要があります。

クライアント認証の詳細はこちらです。

マルチセッションのサポート

マルチセッションがサポートされているので、複数のアクティブなセッションを同時に使って MQTT ブローカーに接続することで、アプリケーションの MQTT クライアントの実装の拡張性と信頼性を向上させることができます。

名前空間の構成

この機能を使用する前に、クライアントごとに複数のセッションを許可するように名前空間を構成する必要があります。 Azure portal でクライアントごとに複数のセッションを構成するには、次の手順に従います。

  • Azure portal でご使用の名前空間に移動します。
  • [構成] で、[認証名あたりのクライアント セッション数の最大値] の値を、クライアントごとの目的のセッション数に変更します。
  • [適用] を選択します。

注意

Azure CLI 構成の場合は、名前空間ペイロードの MaxClientSessionsPerAuthenticationName プロパティを必要な値に更新します。

接続フロー:

各セッションの CONNECT パケットには、次のプロパティが含まれている必要があります。

  • CONNECT パケットで Username プロパティを指定して、クライアント認証名を示します。
  • CONNECT パケットで ClientID プロパティを指定してセッション名を示します。Username ごとに ClientID に 1 つ以上の値があるためです。

たとえば、CONNECT パケットで次の Username と ClientId を組み合わせることにより、クライアント "Mgmt-application" は 3 つの独立したセッションで MQTT ブローカーに接続できます。

  • 最初のセッション:
    • ユーザー名: Mgmt-application
    • ClientId: Mgmt-Session1
  • 2 番目のセッション:
    • ユーザー名: Mgmt-application
    • ClientId: Mgmt-Session2
  • 3 番目のセッション:
    • ユーザー名: Mgmt-application
    • ClientId: Mgmt-Session3

マルチセッションの例の図。

詳細については、「1 つのクライアントに対して複数のセッションを確立する方法」を参照してください。

セッションの処理:

  • クライアントが別の認証名でセッション名を提示して別のクライアントのアクティブなセッションを引き継ごうとすると、その接続要求は未認可エラーで拒否されます。 たとえば、クライアント B が、その時点でクライアント A に割り当てられているセッション 123 に接続しようとすると、クライアント B の接続要求は拒否されます。 つまり、同じクライアントが同じセッション名と同じ認証名で再接続しようとすると、既存のセッションを引き継ぐことができます。
  • セッションを終了せずにクライアント リソースが削除された場合、そのセッションの有効期限が切れるまで、他のクライアントはそのセッション名を使用できません。 たとえば、クライアント B がセッション名 123 でセッションを作成し、クライアント B が削除された場合、クライアント A はセッション 123 の有効期限が切れるまでそのセッションに接続できません。
  • クライアントごとのセッション数の制限は、常にオンラインおよびオフライン セッションに適用されます。 たとえば、認証名あたりの最大クライアント セッション数が 1 に設定されている名前空間を考えてみます。 クライアント A が永続的なセッション 123 に接続してから切断された場合、クライアント A がオフラインであってもそのセッション 123 はアクティブであるため、新しいセッション 456 に接続できません。 そのため、再接続するたびに新しいセッション名を生成するのではなく、同じクライアントは常に同じ静的なセッション名で再接続することをお勧めします。

MQTT の機能

Azure Event Grid の MQTT ブローカー機能では、MQTT の次の機能がサポートされています。

サービスの品質 (QoS)

MQTT ブローカーでは、クライアントと MQTT ブローカー間の PUBLISH と SUBSCRIBE パケットでのメッセージ配信の保証を定義する QoS 0 と 1 がサポートされています。 QoS 0 では、最大 1 回の配信が保証されます。QoS 0 のメッセージは、サブスクライバーによって受信確認されず、パブリッシャーによって再送信されることもありません。 QoS 1 では、少なくとも 1 回の配信が保証されます。メッセージはサブスクライバーによって受信確認され、確認されなかった場合はパブリッシャーによって再送信されます。 QoS を使用することで、クライアントは通信の効率と信頼性を制御できます。

永続的セッション

MQTT ブローカーでは MQTT v3.1.1 の永続セッションがサポートされており、MQTT ブローカーは切断に備えてクライアントのセッションに関する情報を保持しているため、通信の信頼性が確保されます。 この情報には、クライアントのサブスクリプションと、欠落したまたは未確認の QoS 1 メッセージが含まれます。 クライアントは、CONNECT パケットの cleanSession フラグを false に設定することで、永続的なセッションを構成できます。

クリーン スタートとセッションの有効期限

MQTT v5 には、セッション永続化の処理において MQTT v3.1.1 に比べて、クリーン スタートとセッションの有効期限の機能が導入されています。 クリーン スタートは、クライアントが前のセッションのデータをすべて破棄して MQTT ブローカーとの新しいセッションを開始できる機能です。 セッションの有効期限を使うと、クライアントは、非アクティブなセッションがいつ期限切れと見なされて自動的に削除されるかを、MQTT ブローカーに通知できます。 クライアントはセキュリティ上の理由から、または前のセッション中に発生した可能性のあるデータ競合を回避するために、CONNECT パケットで Clean Start フラグを true に設定したり、短いセッション有効期限を設定したりすることができます。 クライアントは、永続的なセッションの信頼性と効率を確保するために、クリーン スタートを false にし、長いセッションの有効期限を設定することもできます。

セッションの最大有効期限間隔の構成

Event Grid 名前空間に接続するすべてのクライアントに許可されるセッションの最大有効期限間隔を構成できます。 MQTT v3.1.1 クライアントの場合、構成された制限は、すべての永続セッションの既定のセッション有効期限間隔として適用されます。 MQTT v5 クライアントの場合、構成された制限は、CONNECT パケットのセッション有効期限間隔プロパティの最大値として適用されます。制限を超える値は調整されます。 この名前空間プロパティの既定値は 1 時間で、最大 8 時間まで延長できます。 Azure portal でセッションの最大有効期限間隔を構成するには、次の手順を使用します。

  • Azure portal でご使用の名前空間に移動します。
  • [構成] で、[セッションの最大有効期限間隔 (時間単位)] の値を目的の制限に変更します。
  • [適用] を選択します。

セッションの最大有効期限間隔の構成のスクリーンショット。

セッション オーバーフロー

MQTT ブローカーは、クライアントが MQTT ブローカーに再度接続してキュー内のメッセージを受信するまで、接続されていないアクティブな MQTT セッションごとにメッセージのキューを維持します。 クライアントがキューに入れられた QOS1 メッセージを受信するために接続しない場合、セッション キューは、制限 (100 メッセージまたは 1 MB) に達するまでメッセージの蓄積を開始します。 セッションの存続期間中にキューが制限に達すると、セッションは終了します。

Last Will and Testament (LWT) メッセージ

Last Will and Testament (LWT) は、MQTT クライアントに、他の MQTT クライアントの突然の切断を通知します。 LWT を使用すると、予期しない切断中の MQTT クライアント間の予測可能で信頼性の高い通信のフローを確保できます。これは、リアルタイム通信、システムの信頼性、および調整されたアクションが重要なシナリオに有用です。 複雑なタスクを実行するために共同作業を行うクライアントは、ビヘイビアーの調整、タスクの再配布、またはシステムのパフォーマンスと安定性を維持するための特定の責任を引き継いで、LWT メッセージに互いに反応できます。 LWT を使用するために、クライアントは will メッセージを指定し、will トピックを作成し、接続中に CONNECT パケット内の残りの will プロパティを指定できます。 クライアントが突然切断されると、MQTT ブローカーは will トピックをサブスクライブしているすべてのクライアントに will メッセージを発行します。 変動する切断からのノイズを減らすには、クライアントでウィル遅延間隔を 0 より大きい値に設定できます。 その場合、クライアントが突然切断しても、ウィル遅延間隔が切れる前に接続を復元した場合、ウィル メッセージは発行されません。

ユーザー プロパティ

MQTT ブローカーでは、MQTT v5 PUBLISH パケットでのユーザー プロパティがサポートされているため、カスタムのキーと値のペアをメッセージ ヘッダーに追加して、メッセージに関するコンテキストをさらに提供できます。 ユーザー プロパティのユース ケースはさまざまです。 この機能を使用してメッセージの目的または配信元を含めることができるため、受信側はペイロードを解析せずにメッセージを処理することができ、コンピューティング リソースの節約になります。 たとえば、"警告" の目的を示すユーザー プロパティを含むメッセージでは、"情報" を目的とするものとは異なる処理ロジックをトリガーすることができます。

要求 - 応答パターン

MQTTv5 では、MQTT PUBLISH パケット ヘッダーに、要求 - 応答パターンの応答メッセージのコンテキストを提供するフィールドが導入されました。 これらのフィールドには、レスポンダーが事前の構成なしで応答で使用できる、応答トピックと関連付け ID が含まれます。 応答情報を使用すると、コマンドと制御のシナリオで使用される標準の要求 - 応答パターンに対して、より効率的な通信が可能になります。

要求 - 応答パターンの例の図。

メッセージの有効期限の間隔:

MQTT v5 では、メッセージの有効期限の間隔によって、メッセージの有効期間を構成できます。 メッセージの有効期間の間隔は、メッセージが MQTT ブローカーにパブリッシュされた時間と MQTT ブローカーが未配信のメッセージを破棄する必要がある時間の時間間隔として定義されます。 この機能は、時間の影響を受けるコマンド、リアルタイム データ ストリーミング、セキュリティ アラートなど、メッセージが一定の期間のみ有効なシナリオで役立ちます。 メッセージの有効期間を設定することで、MQTT ブローカーは古くなったメッセージを自動的に削除し、関連情報のみがサブスクライバーによって使われるようにすることができます。 メッセージの有効期限間隔が 0 に設定されている場合は、メッセージの有効期限が切れないことを意味します。

トピックの別名:

MQTT v5 では、トピックの別名を使用するとことで、クライアントは発行されたメッセージでトピック名全体の代わりに短い別名を使用できます。 MQTT ブローカーは、トピックの別名と実際のトピック名の間のマッピングを保持しています。 この機能を使用すると、特に名前が長いトピックの場合、ネットワーク帯域幅を節約し、メッセージ ヘッダーのサイズを小さくできます。 これは、センサー ネットワークなど、複数のメッセージで同じトピックが繰り返し発行されるシナリオで役立ちます。 MQTT ブローカーでは、最大 10 個のトピックの別名がサポートされます。 クライアントは、PUBLISH パケットの Topic Alias フィールドを使用して、完全なトピック名を対応する別名に置き換えることができます。

トピックの別名の例の図。

フロー制御

MQTT v5 では、フロー制御とは、クライアントが処理できるメッセージのレートとサイズを管理するためのメカニズムを指します。 フロー制御を構成するには、CONNECT パケットで Maximum Packet Size と Receive Maximum パラメーターを設定します。 Receive Maximum パラメーターを使用すると、クライアントはブローカーによって送信されるメッセージの数を、クライアントが処理できるメッセージ数に制限できます。 Maximum Packet Size パラメーターは、クライアントが受信できるパケットの最大サイズを定義します。 MQTT ブローカーのメッセージ サイズ制限は 512 KiB です。 この機能により、処理速度やストレージ機能が制限された制約付きデバイスの通信の信頼性と安定性が保証されます。

否定受信確認とサーバーによって開始される切断パケット

MQTT v5 の場合、MQTT ブローカーは、メッセージ配信または接続の失敗に関する詳細情報をクライアントに提供する、否定受信確認応答 (NACK) とサーバー開始の切断パケットを送信できます。 これらの機能は、クライアントが失敗の背後にある理由を診断し、適切な軽減アクションを実行するのに役立ちます。 MQTT ブローカーでは、MQTT v5 仕様で定義されている理由コードが使われます。

現在の制限

MQTT ブローカーでは、MQTT 仕様との適合をさらに高めるため、MQTT v5 と MQTT v3.1.1 の機能が今後追加されます。 次の一覧では、MQTT ブローカーによってサポートされている機能と MQTT 仕様の現在の違いについて詳しく説明します。

MQTT v5 の現在の制限

MQTT v5 は現在、次の点で MQTT v5 仕様と異なります。

  • 共有サブスクリプションはまだサポートされていません。
  • Retain フラグはまだサポートされていません。
  • 最大ウィル遅延間隔は 300 です。
  • 最大 QoS は 1 です。
  • 最大パケット サイズは 512 KiB です
  • メッセージの順序は保証されません。
  • サブスクリプション ID はサポートされていません。
  • 割り当てられたクライアント識別子はまだサポートされていません。
  • トピック別名の最大数は 10 です。 現時点では、サーバーは送信メッセージのトピックの別名を割り当てません。 クライアントは、設定された制限内でトピックの別名を割り当てて使用できます。
  • CONNECT 要求に Request Response Information プロパティが含まれている場合でも、CONNACK は Response Information プロパティを返しません。
  • CONNECT、SUBSCRIBE、DISCONNECT、PUBACK、AUTH パケットでのユーザー プロパティはサービスで使われないため、サポートされていません。 これらの要求のいずれかにユーザー プロパティが含まれる場合、要求は失敗します。
  • サーバーが成功以外の応答コードを含む PUBACK をクライアントから受信した場合、接続は終了します。
  • キープ アライブの最大は 1,160 秒です。

MQTTv3.1.1 の現在の制限事項

MQTT v5 は現在、次の点で MQTT v3.1.1 仕様と異なります。

  • QoS2 と Retain フラグはまだサポートされていません。 保持フラグまたは QoS2 を使用した発行要求は失敗し、接続が閉じられます。
  • メッセージの順序は保証されません。
  • キープ アライブの最大は 1,160 秒です。

コード サンプル

このリポジトリには、テレメトリの送信、コマンドの送信、アラートのブロードキャスト方法を示す C#、C、Python のコード サンプルが含まれています。 なお、サンプルを通じて作成された証明書はテストには適していますが、運用環境には適していません。

次のステップ:

MQTT の詳細については、以下を確認してください。

MQTT ブローカーについて詳しくは、以下をご覧ください。