次の方法で共有

MQTT ブローカーの永続性を構成する

データ永続化機能は、レプリケーション システムの補完的なメカニズムとして設計されています。 ブローカーは複数のノード間でデータをレプリケートしますが、クラスター全体のシャットダウンによってデータが失われる可能性があります。

このリスクを軽減するために、MQTT ブローカーは永続的ストレージをサポートしています。これにより、重要なデータをディスクに書き込み、再起動後も保持できます。 このデータ永続化機能は、 ディスクベースのメッセージ バッファーとは異なり、メモリの拡張機能としてディスクを使用しますが、エフェメラルであり、持続性の保証は提供しません。

ディスクにデータを格納すると、パフォーマンス コストが発生します。 影響は、基になるストレージ メディアの種類と速度によって異なります。

初期デプロイ時のデータ永続化は、Azure portal または Azure CLI を使用して構成できます。 デプロイ後にいくつかの永続化オプションを変更することもできます。

構成方法

次のいずれかの方法を使用して、MQTT ブローカーのデータ永続化を構成します。

  • Azure portal: IoT Operations のデプロイ中にグラフィカル ユーザー インターフェイスを使用して永続化設定を構成します。
  • Azure CLI: --broker-config-file コマンドを使用して IoT Operations をデプロイするときに、az iot ops create フラグを持つ JSON 構成ファイルを使用します。

使用可能な設定の完全な一覧については、Azure IoT Operations API のドキュメントを参照してください。

デプロイ時の構成オプション

これらのオプションはデプロイ時に設定する必要があり、後で変更することはできません。

Von Bedeutung

デプロイ中に永続化を設定し、後でオフにすることはできません。 デプロイ後に永続化関連のオプションをいくつか変更できます。

ボリュームとボリューム のサイズ

MQTT ブローカーは、永続ボリューム (PV) を使用してディスクにデータを格納します。 このボリュームのプロビジョニング方法は、次の 2 つの設定で制御されます。

  • maxSize (必須): ブローカー データを格納するための永続ボリュームの最大サイズを設定します。 カスタム ボリューム要求を指定した場合でも、このフィールドは常に必須です。 値は 100 MB を超える必要があります。

    例：10GiB

  • persistentVolumeClaimSpec (省略可能): 永続ボリュームのプロビジョニング方法を制御するカスタム PersistentVolumeClaim (PVC) テンプレートを定義できます。 このオプションを設定しない場合、ブローカーは、指定された maxSize と既定のストレージ クラスを使用して既定の PVC を作成します。既定のクラスがローカル パス プロビデターによってサポートされていない場合は、パフォーマンスが最適でない可能性があります。

Von Bedeutung

persistentVolumeClaimSpecを指定する場合は、アクセス モードを ReadWriteOncePod に設定する必要があります。

Azure portal でボリューム設定を構成するには:

  1. IoT 操作のデプロイ中に、 MQTT Broker 構成セクションに移動します。

  2. [データの永続化] 設定で、次の手順を実行します。

    • 永続ボリュームの 最大サイズ を設定します (必須)。
    • 必要に応じて、カスタム ストレージ クラスの要件に合 わせて永続ボリューム要求仕様 の設定を構成します。

    [Azure portal でのデプロイ中のデータ永続化オプションを示すスクリーンショット]

暗号化

データを保護するために、MQTT ブローカーは、強力な AES-256-GCM 暗号化を使用して、ディスク上のすべての永続化データを既定で暗号化します。 これにより、攻撃者が基になるボリュームにアクセスした場合でも、機密性の高いブローカーの状態またはセッション データは保護されたままになります。

暗号化は省略可能であり、既定ではオンになっています。 必要に応じて、暗号化を無効にすることができます。 暗号化は保存データのみを保護します。メモリ内のデータは暗号化されません。 暗号化を使用するとパフォーマンス コストは最小限に抑えられますが、キーのローテーションはまだサポートされていません。

暗号化は、Azure portal を使用してデプロイするときに既定で有効になります。 Azure CLI を使用してデプロイする場合は、ブローカー構成ファイルで暗号化を無効にすることができます。

ランタイム構成オプション

これらのオプションは、Azure IoT Operations MQTT ブローカーをデプロイした後に更新できます。

保持されるメッセージの永続化

保持されるメッセージは、ブローカーがトピックに接続するときに、ブローカーが格納して新しいサブスクライバーに配信する MQTT メッセージです。 これらのメッセージは、メッセージが最初に発行されたときに接続されていなくても、サブスクライバーが最新のデータを確実に受信するのに役立ちます。 これは、新しいサブスクライバーが接続時にすぐに必要とする状態の更新、構成データ、または最後の既知の値に特に役立ちます。

保持されたメッセージをディスクに保持すると、これらの重要なメッセージがブローカーの再起動後も維持され、メンテナンス中や予期しないシャットダウン中に失われることはありません。 永続化がないと、保持されたメッセージはメモリ内にのみ存在し、ブローカーの再起動時に失われます。 これにより、重要な初期データなしで新しいサブスクライバーが残る可能性があります。

この設定は、保持されるメッセージをディスクに保持する方法を制御します。

  • mode ( retain が設定されている場合は必須): オプションは None、 All、または Custom。

    • None: 保持されたメッセージは保持されません。
    • All: 保持されているすべてのメッセージが保持されます。
    • Custom: retainSettings.topics に記載されているトピックのみが保持されます。

  • Customを選択した場合:

    • retainSettings.topics (省略可能): 保持するトピック パターンの一覧。 ワイルドカードの # と + がサポートされています。

    • retainSettings.dynamic.mode (省略可能、既定値: Enabled): MQTT v5 ユーザー プロパティを使用して、MQTT クライアントが保持メッセージのディスク永続化を要求できるようにします。

Azure portal で保持メッセージの永続化を構成するには:

  1. IoT Operations インスタンスに移動します。

  2. MQTT Broker>Data Persistence に移動します。

  3. [保持メッセージ] セクションで、次 の手順を実行 します。

    • [モード]: [なし]、[すべて]、または [カスタム] を選択します。
    • [カスタム] が選択されている場合は、トピック パターンと動的モードの設定を指定します。

    [Azure portal でのデータ永続化保持メッセージ オプションの変更のスクリーンショット]

サブスクライバー キューの永続化

サブスクライバー キューは、サービス品質 (QoS) 1 サブスクリプションを使用して MQTT クライアントに配信されるのを待機しているメッセージを保持します。 クライアントが QoS 1 でサブスクライブすると、ブローカーは、クライアントが受信確認を行うまでメッセージをキューに入れるという方法でメッセージ配信を保証します。 これらのキューは、一時的に切断されたり、メッセージの処理が遅くなったりする可能性があるクライアントにとって特に重要です。

サブスクライバー キューをディスクに保持すると、ブローカーの再起動中に配信を待機しているメッセージが失われなくなります。 この機能は、デバイスが断続的な接続、低速な処理、またはブローカーの再起動間でメッセージ配信の保証を維持する必要がある永続的なセッションを持つ可能性がある IoT シナリオに不可欠です。 永続化がないと、キューに登録されたメッセージが失われ、重要なデバイス通信でデータが失われる可能性があります。

サブスクライバー キューとメッセージ配信の詳細については、「 ブローカー MQTT クライアント オプションの構成」を参照してください。

この設定では、ディスクに永続化するサブスクライバー メッセージ キューを制御します。 セッション状態メタデータは、これらの設定に関係なく常に保持されます。

  • mode ( subscriberQueue が設定されている場合は必須): オプションは None、 All、または Custom。

  • Customを選択した場合:

    • subscriberQueueSettings.subscriberClientIds (省略可能): 保持するサブスクライバー クライアント ID の一覧。 ワイルドカード * がサポートされています。

    • subscriberQueueSettings.dynamic.mode (省略可能、既定値: Enabled): MQTT クライアントが永続化を動的に要求できるようにします。

Azure portal でサブスクライバー キューの永続化を構成するには:

  1. IoT Operations インスタンスに移動します。

  2. MQTT Broker>Data Persistence に移動します。

  3. [サブスクライバー キュー] セクションで、次の手順 を実行 します。

    • [モード]: [なし]、[すべて]、または [カスタム] を選択します。
    • [カスタム] が選択されている場合は、サブスクライバー クライアント ID と動的モード設定を指定します。

    [Azure portal でのデータ永続化サブスクライバー オプションの変更のスクリーンショット]

Von Bedeutung

以前に永続化されなかったクライアントは、いつでも永続化できます。 ただし、その特定のクライアントに対して永続化が有効になった後に受信した発行済みメッセージのみがディスクに格納されます。 後でクライアントに対して永続化が無効になっている場合、クライアントが MQTT クリーン スタート = true フラグで再接続するまで、その変更は有効になりません。

セッションの有効期限とサブスクライバー キューの永続化

サブスクライバー メッセージ キューをディスクに保持するには、セッションの有効期限間隔とブローカーの永続化構成の両方を調整する必要があります。 具体的には：

  • MQTTv5 クライアント: CONNECT または DISCONNECT パケットのセッション有効期限間隔プロパティを使用して、セッションの有効期限を指定できます。 指定したユーザー プロパティを使用してディスクの永続化動作を要求することもできます。

  • MQTTv3 クライアント: クリーン セッション フラグが true の場合、セッションの有効期限は 0 に設定されます。 それ以外の場合は、ブローカーの構成 maxSessionExpirySeconds 値が使用されます。

ブローカーは、構成モードとセッションの有効期限間隔に基づいて、サブスクライバー キューの永続化を異なる方法で処理します。

モードが Noneに設定されている場合:

  • セッションの有効期限に関係なく、すべてのサブスクライバー キューはメモリ内にのみ残ります

モードが Allに設定されている場合:

  • セッションの有効期限が 0 の場合: キューはメモリ内に残ります
  • セッションの有効期限の間隔 > 0 の場合: キューは、その間隔の間ディスクに保持されます

モードが Customに設定されている場合:

  • セッションの有効期限が 0 の場合: キューはメモリ内に残ります
  • セッションの有効期限が 0 > 場合: キューは、次の場合にのみ、その間隔の間ディスクに保持されます。
    • クライアント ID は、 subscriberQueueSettings.subscriberClientIds(OR)で構成されたリストと一致します
    • 動的モードが有効になっており、MQTTv5 クライアントが CONNECT パケット内の一致するユーザー・プロパティーを提供しました

サブスクライバー キューがディスクに保持されるようにするには、次の重要な点に注意してください。

  • サブスクライバー キューは、セッションの有効期限が 0 より長い場合にのみ保持されます
  • Custom モードの場合は、クライアント ID を明示的に一覧表示する必要があります。または、適切なユーザー プロパティを使用して動的永続化を有効にする必要があります
  • MQTTv5 クライアントは、構成されたユーザー プロパティ (既定: aio-persistence=true) を CONNECT パケットに含めることで、動的永続化を使用できます

状態ストアの永続化

状態ストアは MQTT ブローカーの内部コンポーネントであり、標準の MQTT メッセージを超えてさまざまな種類の運用データとメタデータを保持します。 これには、ブローカーの構成状態、セッション情報、サブスクリプションの詳細、およびブローカーがクライアント接続とメッセージ ルーティングを効率的に管理するために使用するその他の内部データ構造が含まれます。

状態ストア のデータをディスクに保持することで、ブローカーは再起動後も運用継続性を維持できます。 これは、ブローカーが内部データ構造を最初から再構築する際に、内部状態を失うと接続の問題、サブスクリプションの損失、またはパフォーマンスの低下につながる可能性がある複雑な IoT デプロイでは特に重要です。

状態ストアの永続化は、復旧時間を最小限に抑え、サービスの整合性を維持することが重要な運用環境では特に重要です。 永続化を使用しない場合、ブローカーは再起動時にすべての内部状態を再構築する必要があります。これにより、一時的なサービスの中断とパフォーマンスへの影響が発生する可能性があります。

状態ストアの詳細については、 MQTT ブローカーの状態ストア プロトコルの詳細を参照してください。

この設定では、内部状態ストアのどのキーを永続化するかを制御します。

  • mode (stateStore が設定されている場合は必須): オプションは None、 All、または Custom。

  • Customを選択した場合:

    • stateStoreSettings.stateStoreResources (省略可能): 保持するキーの種類とキーの一覧。

      • keyType: パターン、文字列、またはバイナリ

      • keys: 保持するキー/パターンの一覧。

    • stateStoreSettings.dynamic.mode (省略可能、既定値: Enabled): MQTT クライアントが永続化を動的に要求できるようにします。

Azure portal で状態ストアの永続化を構成するには:

  1. IoT Operations インスタンスに移動します。
  2. MQTT Broker>Data Persistence に移動します。
  3. [ State Store]\(状態ストア\ ) セクションで、次の手順を実行します。
    • [モード]: [なし]、[すべて]、または [カスタム] を選択します。
    • [カスタム] が選択されている場合は、キーの種類、キー、および動的モードの設定で状態ストア リソースを指定します。 [Azure portal でのデータ永続化状態ストア オプションの変更のスクリーンショット]

動的永続化設定を使用してクライアントに永続化を要求する

クライアントは、メッセージで MQTT v5 ユーザー プロパティを送信することで、データの永続化を要求できます。 これにより、クライアントは、ブローカー構成を変更することなく、メッセージ、サブスクライバー キュー、または状態ストア エントリの永続化を動的に有効にすることができます。

クライアントが永続化を要求すると、ブローカーは現在の永続化設定を確認して適用します。 要求された永続化モードが有効で、動的要求を許可するように設定されている場合、ブローカーは構成で指定されたとおりにクライアントのデータを永続化します。

各構成セクションで dynamic.mode を Enabled に設定することで、各データ型 (保持メッセージ、サブスクライバー キュー、および状態ストア エントリ) の動的永続化設定を有効または無効にすることができます。 動的永続性要求に使用される MQTT ユーザー・プロパティー・キーと値は、ブローカー・レベルで個別に構成されます。

Azure portal で動的永続化設定を構成するには:

  1. IoT Operations インスタンスに移動します。

  2. MQTT Broker>Data Persistence に移動します。

  3. グローバル MQTT ユーザー プロパティの設定を構成します。

    • User プロパティ キーを設定する (既定値: aio-persistence)
    • User プロパティの値を設定します (既定値: true)

  4. 各永続化セクション (保持メッセージ、サブスクライバー キュー、状態ストア):

    • クライアントがそのデータ型 の永続化 を要求できるようにするには、動的永続化を有効に設定します。

    [Azure portal でのデータ永続化の動的オプションの変更のスクリーンショット]

関連コンテンツ

高度な MQTT ブローカー構成に対する Azure CLI のサポートの詳細については、 高度な MQTT ブローカー構成に対する Azure CLI のサポートに関するページを参照してください。

  • Last updated on