次の方法で共有

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

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

Azure Event Grid の MQTT ブローカーは、HTTPS 経由で MQTT メッセージを送信するデバイスとサービスもサポートしており、MQTT 以外のクライアントとの統合を簡略化できます。 Event Grid を使用すると、特にデータ分析、ストレージ、視覚化などのユース ケースにおいて MQTT メッセージをクラウドに送信できます。 この機能は現在プレビュー段階です。

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 経由の MQTT v5 (TCP ポート 443)

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

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

詳細については、クライアント認証のページを参照してください。

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

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

名前空間の構成

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

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

Note

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

接続フロー

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

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

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

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

マルチセッションの例を示すダイアグラム。

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

セッションを処理する

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

MQTT の機能

Event Grid MQTT ブローカーは、次の MQTT 機能をサポートしています。

サービスの品質

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 に設定できます。 クライアントは、セキュリティ上の理由から、または前のセッション中に発生した可能性のあるデータの競合を回避するために、短いセッション有効期限を設定することもできます。 クライアントは、永続的セッションの信頼性と効率を確保するために、Clean Start フラグを false に設定するか、セッションの有効期限間隔を長く設定することもできます。

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

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

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

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

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

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

Last Will and Testament メッセージ

Last Will and Testament (LWT) は、MQTT クライアントに、他の MQTT クライアントの突然の切断を通知します。 LWT を使用すると、予期しない切断中の MQTT クライアント間の予測可能で信頼性の高い通信のフローを確保できます。 この機能は、リアルタイム通信、システムの信頼性、協調的なアクションが不可欠なシナリオに役立ちます。 複雑なタスクを実行するために共同作業を行うクライアントは、ビヘイビアーの調整、タスクの再配布、またはシステムのパフォーマンスと安定性を維持するための特定の責任を引き継いで、LWT メッセージに互いに反応できます。

LWT を使用するために、クライアントは Will メッセージを指定し、Will トピックを作成し、接続中に CONNECT パケット内の残りの Will プロパティを指定できます。 クライアントが突然切断されると、MQTT ブローカーは Will トピックをサブスクライブしているすべてのクライアントに Will メッセージを発行します。 クライアントは、変動する切断からのノイズを減らすために、遅延間隔を 0 より大きい値に設定できます。 その場合、クライアントが突然切断しても、遅延間隔が切れる前に接続を復元した場合、Will メッセージは発行されません。

ユーザー プロパティ

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

要求 - 応答パターン

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

要求 - 応答パターンの例を示すダイアグラム。

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

MQTT v5 では、メッセージの有効期限間隔によって、メッセージの有効期間を構成できます。 メッセージの有効期限間隔は、メッセージが 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 ブローカーから否定受信確認応答とサーバー開始の切断パケットを送信できます。これにより、メッセージ配信または接続の失敗に関する詳細情報をクライアントに提供します。 これらの機能は、クライアントが失敗の背後にある理由を診断し、適切な軽減アクションを実行するのに役立ちます。 MQTT ブローカーは、MQTT v5 仕様で定義されている理由コードを使用します。

メッセージの順序付け

MQTT v5 では、QoS レベル 1 が使用されている場合に、各トピックおよび各クライアント内で順序どおりのメッセージ配信を保証しています。これは、シーケンスの整合性を必要とするワークフローにとって重要です。 テレメトリ、コマンド実行、時系列データなどのシナリオに最適です。

ただし、異なるトピック間での順序付けや、さまざまな QoS レベルでメッセージが送信される場合は保証されません。 詳細については、askmqtt@microsoft.com までお問い合わせください。

割り当てられたクライアント識別子

MQTT v5 では、割り当て済みクライアント ID のサポートが導入され、クライアントから提供されない場合でも、MQTT ブローカーで一意のクライアント ID を生成して返すことができるようになりました。 MQTT ブローカーでこの機能がサポートされたことにより、シームレスなクライアント オンボードが確保され、クライアントが自身の識別子を管理する必要性が軽減されます。 これは、クライアント プロビジョニングが動的なシナリオや、デバイスに事前構成済みの ID がない場合に特に便利です。 割り当てられたクライアント ID は CONNACK 応答から取得し、将来のセッションに再利用して一貫性のある識別を維持できます。

MQTT でクライアント識別子とセッション制限を管理する

  • 割り当てられたクライアント識別子を使用すると、定義済みの識別子を指定せずにクライアントが接続でき、一時的または永続的なセッションが有効になります。
  • クライアントは、最初の接続中に短いセッションの有効期限間隔を使用し、割り当てられたクライアント識別子を将来使用するために保存することで、ロックアウトされないようにすることができます。
  • ファームウェアの更新またはリセットの場合、クライアントは既知のクライアント識別子を保持するか、セッションの有効期限の間隔を控えて使用して、ロックアウトが長くなるのを防ぐ必要があります。
  • 名前空間の構成では、更新またはロールバック中の中断を最小限に抑えるために、クライアントごとのセッション制限を増やすことができます。

現在の制限

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

MQTT v5 の現在の制限事項

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

  • 共有サブスクリプションはまだサポートされていません。
  • 最大ウィル遅延間隔は 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 仕様と異なります。

  • QoS 2 はサポートされていません。 RETAIN フラグまたは QoS 2 が指定された発行要求は失敗し、接続が閉じられます。
  • キープ アライブの最大値は 1,160 秒です。

コード サンプル

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

関連コンテンツ

MQTT の詳細については、MQTT v5 仕様を参照してください。 MQTT ブローカーの詳細については、以下を参照してください。

  • Last updated on