デプロイ計画 - ディスクベースのメッセージ バッファー

ディスクに基づくメッセージ バッファーは、MQTT ブローカーが使用可能なメモリを超えたときにサブスクライバー メッセージ キューをディスクにスピルできるようにする機能です。 MQTT ブローカーのディスクバックアップメッセージバッファリングが必要かどうかをデプロイ前に決定します。

ディスクベースのメッセージ バッファー機能は、分散 MQTT ブローカー内のメッセージ キューを効率的に管理するために使用されます。 利点は次のとおりです。

• 効率的なキュー管理: MQTT ブローカーでは、各サブスクライバーはメッセージ キューに関連付けられます。 サブスクライバーのメッセージ処理速度は、キューのサイズに直接影響します。 サブスクライバーがメッセージを処理する速度が遅い場合、または切断しても MQTT 永続セッションを要求した場合、キューは使用可能なメモリよりも大きくなる可能性があります。
• 永続的なセッションのデータ保持: ディスクに基づくメッセージ バッファー機能により、キューが使用可能なメモリを超えたときに、ディスクにシームレスにバッファーされます。 この機能は、データ損失を防ぎ、MQTT 永続セッションをサポートするため、サブスクライバーは再接続時にメッセージ キューをそのまま使用してセッションを再開できます。 ディスクはエフェメラル ストレージとして使用され、メモリからのスピルオーバーとして機能します。 ディスクに書き込まれたデータは永続的ではなく、ポッドが終了すると失われます。 各バックエンド チェーン内の少なくとも 1 つのポッドが引き続き機能している場合、ブローカー全体でデータが失われることはありません。
• ハンドリング接続の課題: クラウド コネクタは、ネットワーク切断のためにAzure Event Grid MQTT ブローカーなどの外部システムと通信できない場合に接続の問題に直面する可能性がある永続的なセッションを持つサブスクライバーとして扱われます。 このようなシナリオでは、メッセージ (PUBLISHes) が蓄積されます。 MQTT ブローカーは、接続が復元されるまで、これらのメッセージをメモリまたはディスクにインテリジェントにバッファーし、メッセージの整合性を確保します。

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

ディスク バックアップ メッセージ バッファーを構成する

ディスクに基づくメッセージ バッファーを構成するには、Broker リソースの diskBackedMessageBuffer セクションを編集します。 現在、この構成は、--broker-config-file コマンドを使用してAzure IoT Operationsをデプロイするときに、az iot ops create フラグを使用してのみサポートされています。 詳細については、 高度な MQTT ブローカー構成に対する Azure CLI のサポートを参照してください。

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

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

次に、 --broker-config-file フラグを使用して IoT Operations をデプロイします (簡潔にするために他のパラメーターは省略されています)。

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

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

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

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

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

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

次の設定を調整して、ブローカー メッセージ バッファー オプションを調整します。

• ボリュームの構成: メッセージ バッファー用の専用ストレージ ボリュームをマウントするボリューム要求テンプレートを指定します。
• ストレージ クラスを選択する: storageClassName プロパティを使用して目的のストレージ クラスを定義します。
• アクセス モードの定義: ボリュームに必要なアクセス モードを決定します。 詳細については、「 永続ボリューム アクセス モード」を参照してください。

一時ボリューム

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

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

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

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

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

永続ボリューム

永続ボリューム は、一時ボリュームの後のメッセージ・バッファーに対して次に推奨されるオプションです。

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

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

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

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

emptyDir ボリューム

emptyDir ボリュームは、永続ボリュームの後に最も優先されないオプションです。

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

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

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

ストレージ プロバイダーに関する考慮事項

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

Disabled

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

ディスク バッファーと永続化

ディスクに基づくメッセージ バッファーと ブローカーの永続化 は、どちらもディスクにデータを書き込みますが、異なる目的で機能します。

次のステップ

• 永続化の設定を確認する
• 診断設定を確認する
• 詳細な MQTT オプションを確認する
• クラスターを準備する