MQTT ブローカーのコア設定を構成する

Broker リソースは、MQTT ブローカーの全体的な設定を定義するメイン リソースです。 また、フロントエンドやバックエンドなど、"ブローカー" 構成を実行するポッドの数と種類も決定します。 Broker リソースを使用して、そのメモリ プロファイルを構成することもできます。 自己復旧メカニズムはブローカーに組み込まれており、多くの場合、コンポーネントの障害から自動的に復旧できます。 たとえば、高可用性のために構成された Kubernetes クラスターでノードが失敗するとします。

フロントエンド レプリカとバックエンド チェーンを追加することで、MQTT ブローカーを水平方向にスケーリングできます。 フロントエンド レプリカは、クライアントからの MQTT 接続を受け入れ、バックエンド チェーンに転送する役割を担います。 バックエンド チェーンは、メッセージを格納してクライアントに配信する役割を担います。 フロントエンド ポッドはバックエンド ポッド間にメッセージ トラフィックを分散し、バックエンド冗長係数によって、クラスター内のノード障害に対する回復性を提供するデータ コピーの数が決まります。

スケーリング設定を構成する

MQTT ブローカーのスケーリング設定を構成するには、Broker カスタム リソースの仕様で mode および cardinality フィールドを指定する必要があります。 Azure CLI を使用してモードとカーディナリティ設定を設定する方法の詳細については、「az iot ops init」を参照してください。

mode フィールドには、次のいずれかの値を指定できます。

• auto: この値は、MQTT ブローカー オペレーターがクラスター ハードウェアに基づいて適切な数のポッドを自動的にデプロイすることを示します。 既定値は auto であり、ほとんどのシナリオで使用されます。
• distributed: この値は、cardinality フィールド内のフロントエンド ポッドとバックエンド チェーンの数を手動で指定できることを示します。 このオプションを使用すると、デプロイをより詳細に制御できますが、より多くの構成が必要になります。

cardinality フィールドは、次のサブフィールドを持つ入れ子になったフィールドです。

• frontend: このサブフィールドは、次のようなフロントエンド ポッドの設定を定義します。
  • replicas: デプロイするフロントエンド ポッドの数。 このサブフィールドは、mode フィールドが distributed に設定されている場合に必要です。
  • workers: フロントエンドごとにデプロイするワーカーの数。現在は、1 に設定する必要があります。 このサブフィールドは、mode フィールドが distributed に設定されている場合に必要です。
• backendChain: このサブフィールドは、次のようなバックエンド チェーンの設定を定義します。
  • redundancyFactor: 各バックエンド チェーン内のデータ コピーの数。 このサブフィールドは、mode フィールドが distributed に設定されている場合に必要です。
  • partitions: デプロイするパーティションの数。 このサブフィールドは、mode フィールドが distributed に設定されている場合に必要です。
  • workers: バックエンドごとにデプロイするワーカーの数。現在は、1 に設定する必要があります。 このサブフィールドは、mode フィールドが distributed に設定されている場合に必要です。

メモリ プロファイルを構成する

MQTT ブローカーのメモリ プロファイル設定を構成するには、Broker カスタム リソースの仕様で memoryProfile フィールドを指定します。 Azure CLI を使用してメモリ プロファイル設定を設定する方法の詳細については、「az iot ops init」を参照してください。

memoryProfile: このサブフィールドは、メモリ プロファイルの設定を定義します。 選択できるメモリ使用量には、いくつかのプロファイルがあります。

最小

このプロファイルを使用する場合:

• 各フロントエンド レプリカの最大メモリ使用量は約 99 MiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
• 各バックエンド レプリカの最大メモリ使用量は約 102 MiB ですが、実際の最大メモリ使用量は高くなる可能性があります。

このプロファイルを使用する場合の推奨事項:

• 使用するフロントエンドは 1 つだけです。
• クライアントは大きなパケットを送信しないでください。 送信するパケットは 4 MiB 未満にする必要があります。

低

このプロファイルを使用する場合:

• 各フロントエンド レプリカの最大メモリ使用量は約 387 MiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
• 各バックエンド レプリカの最大メモリ使用量は、約 390 MiB にバックエンド ワーカーの数を乗算しますすが、実際の最大メモリ使用量は高くなる可能性があります。

このプロファイルを使用する場合の推奨事項:

• 1 つまたは 2 つのフロントエンドのみを使用する必要があります。
• クライアントは大きなパケットを送信しないでください。 送信するパケットは 10 MiB 未満にする必要があります。

中

Medium は既定のプロファイルです。

• 各フロントエンド レプリカの最大メモリ使用量は約 1.9 GiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
• 各バックエンド レプリカの最大メモリ使用量は、約 1.5 GiB にバックエンド ワーカーの数を乗算しますすが、実際の最大メモリ使用量は高くなる可能性があります。

高

• 各フロントエンド レプリカの最大メモリ使用量は約 4.9 GiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
• 各バックエンド レプリカの最大メモリ使用量は、約 5.8 GiB にバックエンド ワーカーの数を乗算しますすが、実際の最大メモリ使用量は高くなる可能性があります。

既定のブローカー

Azure IoT Operations プレビューでは、既定で broker という名前の既定のブローカー リソースをデプロイします。 これは、Azure portal または Azure CLI を使用した初期デプロイ時に構成されたカーディナリティとメモリ プロファイル設定を使用して azure-iot-operations 名前空間にデプロイされます。 設定を確認するには、次のコマンドを実行します。

kubectl get broker broker -n azure-iot-operations -o yaml

再デプロイすることで既定のブローカーを変更する

初期デプロイ時に Azure portal または Azure CLI を使用して構成できるのは、カーディナリティとメモリ プロファイルだけです。 その他の設定は、YAML ファイルを変更し、ブローカーを再デプロイすることでしか構成できません。

既定のブローカーを削除するには、次のコマンドを実行します。

kubectl delete broker broker -n azure-iot-operations

次に、必要な設定で YAML ファイルを作成します。 たとえば、次の YAML ファイルは、broker という名前のブローカーを名前空間 azure-iot-operations 内に medium メモリ プロファイルと distributed モードで、それぞれ 2 つのパーティションと 2 つのワーカーを持つ 2 つのフロントエンド レプリカと 2 つのバックエンド チェーンで構成します。 また、内部トラフィックの暗号化オプションは無効になっています。

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: broker
  namespace: azure-iot-operations
spec:
  memoryProfile: medium
  mode: distributed
  cardinality:
    backendChain:
      partitions: 2
      redundancyFactor: 2
      workers: 2
    frontend:
      replicas: 2
      workers: 2
  encryptInternalTraffic: false

そして、次のコマンドを実行してブローカーをデプロイします。

kubectl apply -f <path-to-yaml-file>

MQTT ブローカーの詳細設定を構成する

次の表に、クライアント構成、内部トラフィックの暗号化、証明書のローテーション、ノードの容認を含むブローカーの詳細設定のプロパティを示します。

以下は、詳細設定を指定した Broker の例です。

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: broker
  namespace: azure-iot-operations
spec:
  advanced:
    clients:
        maxSessionExpirySeconds: 282277
        maxMessageExpirySeconds: 1622
        subscriberQueueLimit:
          length: 1000
          strategy: DropOldest
        maxReceiveMaximum: 15000
        maxKeepAliveSeconds: 300
    encryptInternalTraffic: Enabled
    internalCerts:
      duration: 240h
      renewBefore: 45m
      privateKey:
        algorithm: Rsa2048
        rotationPolicy: Always
    tolerations:
        effect: string
        key: string
        operator: Equal
        value: string

MQTT ブローカー診断設定を構成する

診断設定を使用すると、MQTT ブローカーのメトリックとトレースを有効にすることができます。

• メトリックは、MQTT ブローカーのリソース使用量とスループットに関する情報を提供します。
• トレースは、MQTT ブローカーによって処理される要求と応答に関する詳細情報を提供します。

MQTT ブローカーの既定の診断設定をオーバーライドするには、Broker リソースの spec.diagnostics セクションを更新します。 ログ レベルを調整して、ログされる情報の量と詳細度を制御します。 ログ レベルは、MQTT ブローカーのさまざまなコンポーネントに対して設定できます。 デフォルトのログ レベルは info です。

Broker カスタム リソース定義 (CRD) を使用して診断を構成できます。 次の表に、ブローカー診断設定のプロパティとすべての既定値を示します。

メトリックとトレースが有効でセルフチェックが無効になっている Broker カスタム リソースの例を次に示します。

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: broker
  namespace: azure-iot-operations
spec:
  mode: auto
  diagnostics:
    logs:
      exportIntervalSeconds: 220
      exportLogLevel: nym
      level: debug
      openTelemetryCollectorAddress: acfqqatmodusdbzgomgcrtulvjy
    metrics:
      stalenessTimeSeconds: 463
      mode: Enabled
      exportIntervalSeconds: 246
      openTelemetryCollectorAddress: vyasdzsemxfckcorfbfx
      prometheusPort: 60607
      updateIntervalSeconds: 15
    selfCheck:
      mode: Enabled
      intervalSeconds: 106
      timeoutSeconds: 70
    traces:
      cacheSizeMegabytes: 97
      mode: Enabled
      exportIntervalSeconds: 114
      openTelemetryCollectorAddress: oyujxiemzlqlcsdamytj
      selfTracing:
        mode: Enabled
        intervalSeconds: 179
      spanChannelCapacity: 47152

内部トラフィックの暗号化を構成する

encryptInternalTraffic 機能は、フロントエンド ポッドとバックエンド ポッド間の内部トラフィックを暗号化するために使用されます。 この機能を使用するには、クラスターに cert-manager をインストールする必要があります。これは、Azure IoT Operations を使用する場合は既定でインストールされます。

次のようなメリットがあります。

• 内部トラフィックのセキュリティ保護: フロントエンド ポッドとバックエンド ポッド間のすべての内部トラフィックが暗号化されます。

• 保存データのセキュリティ保護: すべての保存データが暗号化されます。

• 転送中のデータのセキュリティ保護: 転送中のすべてのデータが暗号化されます。

• メモリ内のデータのセキュリティ保護: メモリ内のすべてのデータが暗号化されます。

• メッセージ バッファー内のデータのセキュリティ保護: メッセージ バッファー内のすべてのデータが暗号化されます。

• ディスク上のメッセージ バッファー内のデータのセキュリティ保護: ディスク上のメッセージ バッファー内のすべてのデータが暗号化されます。

既定では、encryptInternalTraffic 機能は有効になっています。 この機能を無効にするには、ブローカーを再デプロイするときに、"ブローカー" カスタム リソースの仕様で encryptInternalTraffic フィールドを false に設定します。

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

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

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

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

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

diskBackedMessageBufferSettings 機能を理解して構成することで、堅牢で信頼性の高いメッセージ キュー システムが維持されます。 メッセージ処理速度と接続性が重要な要因であるシナリオでは、適切な構成が重要です。

構成オプション

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

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

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

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

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

"エフェメラル" ボリュームが推奨されるオプションです。 その次に推奨されるのが "永続" ボリュームで、その次が emptyDir ボリュームになります。 通常、永続ボリュームとエフェメラル・ボリュームは両方とも、同じストレージ・クラスによって提供されます。 どちらも選択できる場合は、エフェメラルを選択します。 ただし、エフェメラルには Kubernetes 1.23 以上が必要です。

無効

ディスクベースのメッセージ バッファーを使用したくない場合は、"ブローカー" CRD に diskBackedMessageBufferSettings プロパティを含めないでください。

エフェメラル ボリューム

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

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

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

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

diskBackedMessageBufferSettings:
  maxSize: "1G"

  ephemeralVolumeClaimSpec:
    storageClassName: "foo"
    accessModes:
    - "ReadWriteOnce"

永続ボリューム

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

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

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

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

diskBackedMessageBufferSettings:
  maxSize: "1G"

  persistentVolumeClaimSpec:
    storageClassName: "foo"
    accessModes:
    - "ReadWriteOnce"

emptyDir ボリューム

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

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

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

      diskBackedMessageBufferSettings:
        maxSize: "1G"

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

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

永続化

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