Azure IoT MQ プレビューの MQTT ブリッジ クラウド コネクタを他の MQTT ブローカーに接続する

Azure IoT MQ プレビューの MQTT ブリッジを使用して、Azure Event Grid またはその他の MQTT ブローカーに接続できます。 MQTT ブリッジングは、2 つの MQTT ブローカーを接続してメッセージを交換できるようにするプロセスです。

• 2 つのブローカーがブリッジされると、1 つのブローカーでパブリッシュされたメッセージは自動的に他方に転送され、その逆も同様です。
• MQTT ブリッジングは、相互に通信する MQTT ブローカーのネットワークを作成し、必要に応じてブローカーを追加することで MQTT インフラストラクチャを拡張するのに役立ちます。
• MQTT ブリッジングは、複数の物理的な場所、エッジとクラウドの間で MQTT メッセージとトピックを共有する場合、または MQTT を他のメッセージング システムと統合する場合に役立ちます。

別のブローカーにブリッジするには、Azure IoT MQ でリモート ブローカー エンドポイントの URL、MQTT のバージョン、認証方法、マップするトピックを把握している必要があります。 Kubernetes ネイティブの方法で構成可能性と柔軟性を最大限に高めるために、これらの値は MqttBridgeConnector と MqttBridgeTopicMap と呼ばれる カスタム Kubernetes リソース (CRD) として構成されます。 このガイドでは、これらのリソースを使用して MQTT ブリッジ コネクタを作成する方法について説明します。

1. MqttBridgeConnector リソースを定義する YAML ファイルを作成します。 例の YAML を使用できますが、namespaceAzure IoT MQ がデプロイされている URL と一致するremoteBrokerConnection.endpointように変更し、リモート ブローカー エンドポイントの URL に一致するように変更してください。

2. MqttBridgeTopicMap リソースを定義する YAML ファイルを作成します。 YAML の例を使用できますが、namespaceAzure IoT MQ がデプロイされているリソースと一致するmqttBridgeConnectorRefように変更し、前の手順で作成した MqttBridgeConnector リソースの名前と一致するように変更してください。

3. kubectl apply -f <filename> を使用して MQTT ブリッジ コネクタとトピック マップをデプロイします。

   $ kubectl apply -f my-mqtt-bridge.yaml 
   mqttbridgeconnectors.mq.iotoperations.azure.com my-mqtt-bridge created
   $ kubectl apply -f my-topic-map.yaml
   mqttbridgetopicmaps.mq.iotoperations.azure.com my-topic-map created
   

デプロイが完了したら、kubectl get pods を使用して、エンドポイントとの間でメッセージのフローが開始されていることを確認します。

MqttBridgeConnector の構成

MqttBridgeConnector リソースは、リモート ブローカーと通信できる MQTT ブリッジ コネクタを定義します。 次のコンポーネントが含まれます。

• 1 つ以上の MQTT ブリッジ コネクタ インスタンス。 各インスタンスは、MQTT ブリッジ コネクタを実行するコンテナーです。
• リモート ブローカー接続。
• オプションのローカル ブローカー接続。

次の例は、Azure Event Grid MQTT ブローカーへのブリッジの構成例を示しています。 認証と TLS 暗号化には、システム割り当てマネージド ID が使用されます。

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeConnector
metadata:
  name: my-mqtt-bridge
  namespace: azure-iot-operations
spec:
  image: 
    repository: mcr.microsoft.com/azureiotoperations/mqttbridge 
    tag: 0.4.0-preview
    pullPolicy: IfNotPresent
  protocol: v5
  bridgeInstances: 1
  clientIdPrefix: factory-gateway-
  logLevel: debug
  remoteBrokerConnection:
    endpoint: example.westeurope-1.ts.eventgrid.azure.net:8883
    tls:
      tlsEnabled: true
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

次の表では、MqttBridgeConnector リソースのフィールドについて説明します:

MQTT v3.1.1 のサポート

ブリッジ コネクタは、Azure IoT MQ のローカル ブローカー接続とリモート ブローカー接続の両方で MQTT v3.1.1 を使用するように構成できます。 ただし、リモート ブローカーでサポートされていない場合は、共有サブスクリプションが中断されます。 共有サブスクリプションを使用する場合は、既定の v5 のままにします。

インスタンスの数

高可用性とスケールを実現するには、複数のインスタンスを使用するように MQTT ブリッジ コネクタを構成します。 メッセージ フローとルートは、異なるインスタンス間で自動的に分散されます。

spec:
  bridgeInstances: 2

クライアント ID の構成

Azure IoT MQ は、指定したプレフィックスを使用して、各 MqttBridgeConnector クライアントのクライアント ID を {clientIdPrefix}-{routeName} 形式で生成します。 MQTT 仕様ではクライアント ID ごとに 1 つの接続のみが許可されるため、Azure IoT MQ では、メッセージ損失を軽減し、既存のクライアント ID との競合や競合を回避するために、このクライアント ID が重要です。

たとえば、 clientIdPrefix: "client-" で、トピック マップに 2 つの routes がある場合、クライアント ID は client-route1 と client-route2です。

リモート ブローカー接続

remoteBrokerConnection フィールドは、リモート ブローカーにブリッジするための接続の詳細を定義します。 次のフィールドがあります。

認証

認証フィールドは、リモート ブローカーで使用する Azure IoT MQ の認証方法を定義します。 次のフィールドがあります。

マネージド ID

systemAssignedManagedIdentity フィールドには、次のフィールドがあります:

Azure IoT MQ が Azure Arc 拡張機能としてデプロイされている場合、既定ではシステム割り当てマネージド ID が取得されます。 資格情報の管理を回避し、高可用性を維持できるため、Azure IoT MQ のマネージド ID を使用して、Event Grid MQTT ブローカーを含む Azure リソースと対話する必要があります。

Azure リソースでの認証にマネージド ID を使用するには、まず、 EventGrid TopicSpaces Publisher などの適切な Azure RBAC ロールを、Arc によって提供される Azure IoT MQ のマネージド ID に割り当てます。

次に、認証方法としてマネージド ID を使用して MQTTBridgeConnector を指定します:

spec:
  remoteBrokerConnection:
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net

マネージド ID を使用する場合、クライアント ID は構成できず、Azure IoT MQ Azure Arc 拡張機能の Azure Resource Manager リソース ID と同じになります。

システム割り当てマネージド ID は、Azure Arc によって提供されます。手動による復旧プロセスを回避するには、マネージド ID に関連付けられている証明書を少なくとも 90 日ごとに更新する必要があります。 詳細については、「期限切れの Azure Arc 対応 Kubernetes リソースに対処する方法」を参照してください

X.509

x509 フィールドには、次のフィールドがあります:

Event Grid などの多くの MQTT ブローカーでは、X.509 認証がサポートされています。 Azure IoT MQ の MQTT ブリッジは、クライアント X.509 証明書を提示し、TLS 通信をネゴシエートできます。 Kubernetes シークレットを使用して、X.509 クライアント証明書、秘密キー、および中間 CA を格納します。

kubectl create secret generic bridge-client-secret \
--from-file=client_cert.pem=mqttbridge.pem \
--from-file=client_key.pem=mqttbridge.key \
--from-file=client_intermediate_certs.pem=intermediate.pem

そして、secretName でそれを参照してください:

spec:
  remoteBrokerConnection:
    authentication:
      x509:
        secretName: bridge-client-cert

ローカル ブローカー接続

localBrokerConnection フィールドは、ローカル ブローカーにブリッジするための接続の詳細を定義します。

既定では、IoT MQ は TLS が有効で SAT 認証が有効な名前空間 azure-iot-operations にデプロイされます。

次に、MqttBridgeConnector ローカル ブローカー接続設定を一致するように構成する必要があります。 MqttBridgeConnector のデプロイ YAML には、remoteBrokerConnection と同じレベルの localBrokerConnection が必要です。 たとえば、既定の IoT MQ デプロイと一致させるために、SAT 認証で TLS を使用するには、次のようにします:

spec:
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

ここでは、trustedCaCertifcateName は、リモート ブローカー のルート ca のConfigMap と同様に、Azure IoT MQ のルート CA の ConfigMap を示します。 既定のルート CA は、aio-ca-trust-bundle-test-only という名前の ConfigMap に格納されます。

ルート CA の取得の詳細については、「MQTT 通信 をセキュリティで保護するための自動証明書管理を使用した TLS の構成」を参照してください。

TLS サポート

tls フィールドは、リモートまたはローカル ブローカー接続の TLS 構成を定義します。 次のフィールドがあります。

TLS 暗号化のサポートは、リモートとローカルの両方のブローカー接続で使用できます。

• リモート ブローカー接続の場合: TLS が有効になっている場合は、信頼された CA 証明書を Kubernetes ConfigMap 参照として指定する必要があります。 そうでない場合、リモート エンドポイントが広く信頼されている場合を除き、TLS ハンドシェイクは失敗する可能性があります。信頼された CA 証明書は既に OS 証明書ストアにあります。 たとえば、Event Grid では広く信頼されている CA ルートが使用されるため、指定する必要はありません。
• ローカル (Azure IoT MQ) ブローカー接続の場合: Azure IoT MQ ブローカー リスナーに対して TLS が有効になっている場合は、リスナー サーバー証明書を発行した CA 証明書を Kubernetes ConfigMap 参照として指定する必要があります。

信頼された CA を指定する必要がある場合は、CA のパブリック ポーションを含む ConfigMap を作成し、 trustedCaCertificateConfigMap プロパティに configmap 名を指定します。 次に例を示します。

kubectl create configmap client-ca-configmap --from-file ~/.step/certs/root_ca.crt

MqttBridgeTopicMap の構成

MqttBridgeTopicMap リソースは、ローカル ブローカーとリモート ブローカー間のトピック マッピングを定義します。 MqttBridgeConnector リソースと共に使用する必要があります。 次のコンポーネントが含まれます。

• リンク先の MqttBridgeConnector リソースの名前。
• ブリッジのためのルートのリスト。
• オプションの共有サブスクリプション構成。

MqttBridgeConnector では、それにリンクされた複数の MqttBridgeTopicMap を使用できます。 MqttBridgeConnector リソースがデプロイされると、Azure IoT MQ オペレーターは、それにリンクされている MqttBridgeTopicMaps の名前空間のスキャンを開始し、MqttBridgeConnector インスタンス間 のメッセージ フローを自動的に管理します。 その後、デプロイされると、MqttBridgeTopicMap が MqttBridgeConnector にリンクされます。 各 MqttBridgeTopicMap は、1 つの MqttBridgeConnector でのみリンクできます。

次の例は、リモート トピック remote-topic からローカル トピック local-topic にメッセージをブリッジするための、MqttBridgeTopicMap 構成を示しています:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeTopicMap
metadata:
  name: my-topic-map
  namespace: azure-iot-operations 
spec:
  mqttBridgeConnectorRef: my-mqtt-bridge
  routes:
    - direction: remote-to-local
      name: first-route
      qos: 0
      source: remote-topic
      target: local-topic
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: group1
    - direction: local-to-remote
      name: second-route
      qos: 1
      source: local-topic
      target: remote-topic

次の表では、MqttBridgeTopicMap リソースのフィールドについて説明します:

Routes

MqttBridgeTopicMap には複数のルートを含めることができます。 routes フィールドは、ルートのリストを定義します。 次のフィールドがあります。

Direction

たとえば、方向がローカルからリモートの場合、Azure IoT MQ は指定されたローカル トピックのすべてのメッセージをリモート トピックに発行します:

routes:
  - direction: local-to-remote
    name: "send-alerts"
    source: "alerts"
    target: "factory/alerts"

方向が逆の場合、Azure IoT MQ はリモート ブローカーからメッセージを受信します。 ここでは、ターゲットは省略され、リモート ブローカー上の commands/factory トピックのすべてのメッセージが同じトピックでローカルに発行されます。

routes:
  - direction: remote-to-local
    name: "receive-commands"
    source: "commands/factory"

ソース トピックのワイルドカード

非静的トピックからブリッジするには、ワイルドカードを使用して、トピック パターンの照合方法とトピック名変換の規則を定義します。 たとえば、telemetry のすべてのサブトピック内のすべてのメッセージをブリッジするには、複数レベルの # ワイルドカードを使用します:

routes:
  - direction: local-to-remote
    name: "wildcard-source"
    source: "telemetry/#"
    target: "factory/telemetry"

この例では、telemetry/furnace/temperature のように、telemetry の任意のトピックにメッセージが発行された場合、Azure IoT MQ は静的 factory/telemetry トピックの下でリモート ブリッジブローカーに発行します。

単一レベルのトピックワイルドカードの場合は、 telemetry/+/temperature のように、代わりに + を使用します。

MQTT ブリッジ コネクタは、ターゲット ブローカー内の正確なトピックを、あいまいさなしでリモートまたは Azure IoT MQ で認識する必要があります。 ワイルドカードは、source トピックの一部としてのみ使用できます。

ターゲットの参照ソース トピック

ソース トピック全体を参照するには、ルート内のターゲット トピックの構成を完全に省略します。 ワイルドカードを利用できます。

たとえば、トピック my-topic/# で発行されたメッセージ(my-topic/foo や my-topic/bar など) は、同じトピックの下でリモート ブローカーにブリッジされます:

routes:
  - direction: local-to-remote
    name: "target-same-as-source"
    source: "my-topic/#"
    # No target

ソース トピック参照の他のメソッドはサポートされていません。

共有サブスクリプション

sharedSubscription フィールドは、ルートの共有サブスクリプション構成を定義します。 次のフィールドがあります。

共有サブスクリプションは、Azure IoT MQ で MQTT ブリッジ用のクライアントをさらに作成するのに役立ちます。 ルートごとに異なる共有サブスクリプションを設定できます。 Azure IoT MQ は、ソース トピックからのメッセージをサブスクライブし、ラウンド ロビンを使用して一度に 1 つのクライアントに送信します。 次に、クライアントはブリッジされたブローカーにメッセージを発行します。

たとえば、共有サブスクリプションを使用してルートを設定し、 groupMinimumShareNumber を 3として設定するとします:

routes:
    - direction: local-to-remote
      qos: 1
      source: "shared-sub-topic"
      target: "remote/topic"
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: "sub-group"

Azure IoT MQ の MQTT ブリッジは、インスタンスの数に関係なく、3 つのサブスクライバー クライアントを作成します。 $share/sub-group/shared-sub-topic から各メッセージを取得するクライアントは 1 つだけです。 次に、同じクライアントが、トピック remote/topic の下にあるブリッジされたリモート ブローカーにメッセージを発行します。 次のメッセージは次のクライアントに送信されます。

これにより、異なる ID を持つ複数のクライアント間でブリッジのメッセージ トラフィックのバランスを取るのに役立ちます。 これは、ブリッジされたブローカーが各クライアントが送信できるメッセージの数を制限する場合に便利です。

Azure Event Grid MQTT ブローカーのサポート

資格情報管理を最小限に抑えるには、システム割り当てマネージド ID と Azure RBAC を使用して、Azure IoT MQ と Azure Event Grid の MQTT ブローカー機能をブリッジする方法をお勧めします。

エンドツーエンドのチュートリアルについては、「Azure IoT MQ プレビューと Azure Event Grid の間に MQTT ブリッジを構成する」を参照してください。

マネージド ID を使用して Event Grid の MQTT ブローカーに接続する

まず、az k8s-extension show を使用して、Azure IoT MQ Arc 拡張機能のプリンシパル ID を見つけます。 identity.principalId の出力値は abcd1234-5678-90ab-cdef-1234567890ab のようになることに注意してください。

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-name <CLUSTER_NAME> --name mq --cluster-type connectedClusters --query identity.principalId -o tsv

次に、Azure CLI を使用して、ロール Azure IoT MQ Arc 拡張機能のマネージド ID に割り当てます。 <MQ_ID> を、前の手順で見つけたプリンシパル ID に置き換えます。 たとえば、EventGrid TopicSpaces Publisher ロールを割り当てるには、次のようにします:

az role assignment create --assignee <MQ_ID> --role 'EventGrid TopicSpaces Publisher' --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.EventGrid/namespaces/<EVENT_GRID_NAMESPACE>

最後に、MQTTBridgeConnector を作成し、認証方法としてマネージド ID を選択します。 MqttBridgeTopicMaps を作成し、 kubectlを使用して MQTT ブリッジをデプロイします。

認証名あたりのクライアント セッションの最大数

bridgeInstances が 1より大きく設定されている場合は、インスタンス数と一致するように Event Grid MQTT ブローカー 構成>認証名あたりの最大クライアント セッション数を構成します。 この構成により、エラー 151 クォータの超過などの問題が回避されます。

接続ごとの制限

マネージド ID を使用できない場合は、セットアップの設計時に Event Grid MQTT ブローカーの接続ごとの制限に留意してください。 発行時の制限は、接続の方向ごとに 100 メッセージ/秒です。 MQTT ブリッジのスループットを高めるには、共有サブスクリプションを使用して、各ルートにサービスを提供するクライアントの数を増やします。

別のブローカーから Azure IoT MQ プレビューへのブリッジ

Azure IoT MQ は準拠している MQTT ブローカーであり、他のブローカーは適切な認証と承認の資格情報を使用してブリッジできます。 たとえば、HiveMQ、VerneMQ、 EMQX、および Mosquitto の MQTT ブリッジのドキュメントを参照してください。

関連するコンテンツ

• Azure IoT MQ プレビューを使用して MQTT メッセージを発行およびサブスクライブする