次の方法で共有

ディスクベース メッセージ バッファーの動作を構成する

  • [アーティクル]

重要

この設定では、ブローカー リソースを変更する必要があり、Azure CLI または Azure portal を使用して初期デプロイ時にのみ構成できます。 "ブローカー" 構成の変更が必要な場合は、新しいデプロイが必要です。 詳細については、既定のブローカーのカスタマイズに関する記事を参照してください。

ディスクベース メッセージ バッファー機能は、MQTT ブローカー分散 MQTT ブローカー内のメッセージ キューを効率的に管理するために使用されます。 次のようなメリットがあります。

  • 効率的なキュー管理: MQTT ブローカーでは、各サブスクライバーはメッセージ キューに関連付けられます。 サブスクライバーがメッセージを処理する速度は、キューのサイズに直接影響します。 サブスクライバーがメッセージを処理する速度が遅い場合、または切断しても MQTT 永続セッションを要求する場合、キューは使用可能なメモリよりも大きくなる可能性があります。

  • 永続的なセッションのデータ保持: ディスクベース メッセージ バッファー機能により、キューが使用可能なメモリを超えたときに、ディスクにシームレスにバッファーされます。 この機能は、データ損失を防ぎ、MQTT 永続セッションをサポートするため、サブスクライバーは再接続時にメッセージ キューをそのまま使用してセッションを再開できます。 ディスクはエフェメラル ストレージとして使用され、メモリからのスピルオーバーとして機能します。 ディスクに書き込まれたデータは永続的ではなく、ポッドが終了すると失われますが、各バックエンド チェーン内で少なくとも 1 つのポッドが機能している限り、ブローカー全体でデータが失われることはありません。

  • 接続の課題への対応: クラウド コネクタは、ネットワーク切断のために Event Grid MQTT ブローカーなどの外部システムと通信できない場合に接続の問題に直面する可能性がある永続的なセッションを持つサブスクライバーとして扱われます。 このようなシナリオでは、メッセージ (PUBLISHes) が蓄積されます。 MQTT ブローカーは、接続が復元されるまでこれらのメッセージをメモリまたはディスクにインテリジェントにバッファーし、メッセージの整合性を確保します。

既定では、ディスクベース メッセージ バッファー機能は無効になっています。 この場合、メッセージはメモリ内に残り、リーダー プールまたはスクラッチ プールがサブスクライバー キューの制限で定義されている制限に達すると、バック プレッシャーがクライアントに適用されます。

特にメッセージ処理速度と接続性が重要なシナリオでは、堅牢で信頼性の高いメッセージ キュー システムを維持するために、ディスクベース メッセージ バッファーの構成が不可欠です。

Note

MQTT ブローカーは、追加の暗号化を行わずに、クライアントから受け取ったとおりにデータをディスクに書き込みます。 ブローカーによって格納されるデータを保護するには、ディスクのセキュリティ保護が不可欠です。

構成オプション

ディスクベース メッセージ バッファーを構成するには、ブローカー リソースの diskBackedMessageBuffer セクションを編集します。 現在、これは az iot ops create コマンドを使用して Azure IoT Operations を展開するときに --broker-config-file フラグを使用する場合にのみサポートされます。

開始するには、DiskBackedMessageBuffer API リファレンスに従って、ブローカー構成ファイルを準備します。

たとえば、最も簡単な構成では、最大サイズのみを指定します。 この場合、emptyDir ボリュームがマウントされます。 maxSize 値は、emptyDir ボリュームのサイズ制限として使用されます。 ただし、これは、emptyDir ボリュームの制限を与えるための最も優先されないオプションです。

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

ディスクベース メッセージ バッファー構成を改善するには、エフェメラル ボリュームまたは永続ボリューム要求を指定して、メッセージ バッファー用の専用ストレージ ボリュームをマウントします。 次に例を示します。

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

以下の設定を調整することで、ブローカー メッセージ バッファー オプションを調整します。

  • ボリュームの構成: メッセージ バッファー用の専用ストレージ ボリュームをマウントするためのボリューム要求テンプレートを指定します。

  • ストレージ クラスの選択: storageClassName プロパティを使用して目的の StorageClass を定義します。

  • アクセス モードの定義: ボリュームに必要なアクセス モードを決定します。 詳細については、「永続ボリュームのアクセス モード」を参照してください。

以降のセクションを使用して、さまざまなボリューム モードを理解してください。

通常、永続ボリュームとエフェメラル ボリュームは両方とも、同じストレージ クラスによって提供されます。 両方のオプションを使用できる場合は、エフェメラルを選択します。 エフェメラル ボリュームには Kubernetes 1.23 以上が必要であることに注意してください。

ヒント

エフェメラル ボリューム要求 (EVC) または永続ボリューム要求 (PVC) テンプレートを指定すると、任意のストレージ クラスを使用できるため、一部のデプロイ シナリオの場合は柔軟性が向上します。 たとえば、PVC テンプレートを使用してプロビジョニングされた永続ボリューム (PV) は、クラスターの状態を調べるのに役立つ kubectl get pv などのコマンドに表示されます。

Kubernetes ノードにメッセージ バッファー用の十分なローカル ディスク領域がない場合は、Azure BLOB などのネットワーク ストレージを提供するストレージ クラスを使用します。 ただし、一般に maxSize 値が小さいローカル ディスクを使用するのが適しています。これは、メッセージ バッファーはアクセスが速い利点があり、持続性を必要としないためです。

ディスクベース メッセージ バッファーを使用して Azure IoT Operations を展開する

ディスクベース メッセージ バッファーを使用するには、--broker-config-file フラグを指定して az iot ops create コマンドを使用し、Azure IoT Operations を展開します。 次のコマンドを参照してください (簡潔にするために他のパラメーターは省略されています)。

az iot ops create ... --broker-config-file <FILE>.json

この設定は、デプロイ後に変更することはできません。 ディスクベース メッセージ バッファーの構成を変更するには、Azure IoT Operations インスタンスを再展開します。

エフェメラル ボリューム

エフェメラル ボリュームは、メッセージ バッファーに推奨されるオプションです。

"エフェメラル" ボリュームについては、「ストレージ プロバイダーに関する考慮事項」セクションのアドバイスに従ってください。

ephemeralVolumeClaimSpec プロパティの値は、バックエンド チェーンの StatefulSet 仕様のボリュームの ephemeral.volumeClaimTemplate.spec プロパティとして使用されます。

たとえば、容量が 1 ギガバイトのエフェメラル ボリュームを使用するには、ブローカー リソースで次のパラメーターを指定します。

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

永続ボリューム

永続ボリュームは、"エフェメラル" ボリュームに次いで推奨されるメッセージ バッファー用の選択肢です。

"永続" ボリュームについては、「ストレージ プロバイダーに関する考慮事項」セクションのアドバイスに従ってください。

persistentVolumeClaimSpec プロパティの値は、バックエンド チェーンの StatefulSet 仕様の volumeClaimTemplates.spec プロパティとして使用されます。

たとえば、容量が 1 ギガバイトの "永続" ボリュームを使用するには、ブローカー リソースで次のパラメーターを指定します。

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

emptyDir ボリューム

emptyDir ボリュームは、永続ボリュームの次に推奨されるオプションです。

emptyDir ボリュームは、ファイルシステム クォータを持つクラスターを使用するときにだけ使用します。 詳細については、「ファイルシステム プロジェクト クォータ タブ」の詳細を参照してください。この機能が有効になっていない場合、クラスターは "定期的なスキャン" を実行し、どのような制限も適用しないため、ホスト ノードがディスク領域を埋め、ホスト ノード全体が異常とマークされる可能性があります。

たとえば、容量が 1 ギガバイトの emptyDir ボリュームを使用するには、ブローカー リソースで次のパラメーターを指定します。

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

ストレージ・プロバイダーの考慮事項

選択したストレージ プロバイダーの動作を検討します。 たとえば、rancher.io/local-path のようなプロバイダーを使用する場合です。 プロバイダーが制限をサポートしていない場合、ボリュームをいっぱいにするとノードのディスク領域が消費されます。 これにより、Kubernetes によってノードおよび関連するすべてのポッドが異常としてマークされる可能性があります。 このようなシナリオで、ご利用のストレージ プロバイダーがどのように動作するかを理解することが重要です。

無効

ディスクベース メッセージ バッファーを使用しない場合は、ブローカー リソースに diskBackedMessageBufferSettings プロパティを含めないでください。 これは既定の動作でもあります。

永続化

ディスクベース メッセージ バッファー機能は、"永続性" と同義ではないことを理解するのが重要です。 このコンテキストでは、"永続性" はポッドの再起動後も存続するデータのことを指します。 しかし、この機能が提供するのは、データをディスクに保存するための一時的なストレージ領域であり、ポッドの再起動中のメモリ オーバーフローやデータ損失を防ぎます。