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

[アーティクル]
02/21/2025

重要

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

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

効率的なキュー管理: MQTT ブローカーでは、各サブスクライバーはメッセージキューに関連付けられます。サブスクライバーのメッセージ処理速度は、キューのサイズに直接影響します。サブスクライバーがメッセージを処理する速度が遅い場合、または切断しても MQTT 永続セッションを要求する場合、キューは使用可能なメモリよりも大きくなる可能性があります。
永続的なセッションのデータ保持: ディスクベースメッセージバッファー機能により、キューが使用可能なメモリを超えたときに、ディスクにシームレスにバッファーされます。この機能は、データ損失を防ぎ、MQTT 永続セッションをサポートして、サブスクライバーが再接続時にメッセージキューをそのまま使ってセッションを再開できるようにします。ディスクはエフェメラルストレージとして使用され、メモリからのスピルオーバーとして機能します。ディスクに書き込まれたデータは永続的ではなく、ポッドが終了すると失われます。各バックエンドチェーンに機能するポッドが少なくとも 1 つ残っている場合、ブローカー全体のデータが失われることはありません。
接続の課題への対応: クラウドコネクタは、ネットワーク切断のために Azure 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 プロパティを使って目的のストレージクラスを定義します。
アクセスモードの定義: ボリュームに必要なアクセスモードを決定します。詳しくは、永続ボリュームのアクセスモードに関する説明をご覧ください。

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

"エフェメラル" ボリュームが推奨されるオプションです。
永続ボリュームが、次に推奨されるオプションです。
emptyDir ボリュームは、最も推奨されないオプションです。

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

ヒント

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

Kubernetes ノードにメッセージバッファー用の十分なローカルディスク領域がない場合は、Azure Blob Storage などのネットワークストレージを提供するストレージクラスを使います。メッセージバッファーはアクセスが速い方がよく、持続性は必要ないため、小さい maxSize 値でローカルディスクを使うのが適しています。

ディスクベースメッセージバッファーを使用して IoT Operations をデプロイする

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

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

デプロイ後にこの設定を変更することはできません。ディスクベースメッセージバッファーの構成を変更するには、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 プロパティを含めないでください。この動作は既定でもあります。

永続化

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

次の方法で共有

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

構成オプション

ディスクベースメッセージバッファーを使用して IoT Operations をデプロイする

エフェメラルボリューム

永続ボリューム

emptyDir ボリューム

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

無効

永続化

フィードバック

その他のリソース

次の方法で共有

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

構成オプション

ディスクベース メッセージ バッファーを使用して IoT Operations をデプロイする

エフェメラル ボリューム

永続ボリューム

emptyDir ボリューム

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

無効

永続化

フィードバック

その他のリソース

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

ディスクベースメッセージバッファーを使用して IoT Operations をデプロイする

エフェメラルボリューム