Azure IoT Operations の組み込みローカル MQTT ブローカー

Azure IoT Operations には、エンタープライズ グレードと標準に準拠した MQTT ブローカーが含まれています。 MQTT ブローカーはスケーラブルで可用性が高く、Kubernetes ネイティブです。 IoT Operations のメッセージング プレーンを提供し、双方向のエッジからクラウドへの通信を可能にし、エッジでの イベント ドリブン アプリケーション をサポートします。

MQTT コンプライアンス

MQTT は、IoT 空間の一般的なプロトコルです。 そのシンプルな設計により、1 つのブローカーが軽量のパブリッシュ/サブスクライブ トピックの作成と管理を使用して、数千のクライアントに同時にサービスを提供できます。 多くの IoT デバイスでは、MQTT がネイティブにサポートされています。 ダウンストリーム変換ゲートウェイは、さまざまな IoT プロトコルを MQTT に変換します。

MQTT ブローカーは、IoT 操作でメッセージング層をサポートし、MQTT v3.1.1 および MQTT v5 と互換性があります。 サポートされている MQTT 機能の詳細情報については、「MQTT ブローカーでの MQTT 機能のサポート」を参照してください。

アーキテクチャ

MQTT ブローカーには、次の 2 つのメジャー レイヤーがあります。

• ステートレス フロントエンド レイヤー
• ステートフル バックエンド レイヤーとシャード化されたバックエンド レイヤー

フロントエンド レイヤーは、クライアント接続と要求を処理し、バックエンドにルーティングします。 バックエンド レイヤーは、クライアント セッションのクライアント ID やトピック メッセージのトピック名など、キーによってデータをパーティション分割します。 バックエンド レイヤーでは、チェーン レプリケーションを使用して各パーティション内のデータをコピーします。

アーキテクチャの目標は、次のとおりです。

• フォールトトレランスと分離: バックエンドポッドが障害を発生しても、メッセージの発行は続行され、システムの他の部分に障害が伝播することはありません。
• 障害復旧: オペレーターが介入しない自動障害復旧です。
• メッセージ損失なし: 少なくとも 1 つのフロントエンド ポッドとパーティション内の 1 つのバックエンド ポッドが実行されている場合、メッセージが配信されます。
• エラスティック スケーリング: 発行スループットとサブスクライブ スループットの水平方向のスケーリングでは、エッジデプロイとクラウド デプロイがサポートされます。
• 大規模な一貫したパフォーマンス: チェーン レプリケーションによるメッセージ待機時間のオーバーヘッドを制限します。
• 運用の簡素化: メンテナンスと複雑さを簡素化するために、外部コンポーネントへの依存関係を減らします。

構成

構成の場合、MQTT ブローカーは、いくつかの Kubernetes カスタム リソースを使用して、ブローカーの動作と機能のさまざまな側面を定義します。

• メイン リソースは Broker で、これは、カーディナリティ、メモリ使用量プロファイル、診断設定などのグローバル設定を定義します。
• Broker リソースには最大 3 つの BrokerListeners を含めることができます。これらの各ブローカーでは、指定された種類のサービス (NodePort、LoadBalancer、または ClusterIP) で着信 MQTT 接続をリッスンします。 各 BrokerListener リソースには複数のポートを含めることができます。
• BrokerListener リソース内の各ポートには、BrokerAuthentication リソースと BrokerAuthorization リソースを関連付けることができます。 これらの認証および承認ポリシーにより、ポートに接続できるクライアントと、それらがブローカーに対して実行できるアクションが決定されます。

Broker と BrokerListener の関係は 1 対多ですが、BrokerListener と BrokerAuthentication/BrokerAuthorization の関係は 多対多です。 これらのリソースのエンティティ関係図は、次のとおりです。

Azure IoT Operations では、既定で、default Broker、default BrokerListener、default BrokerAuthentication をデプロイします。 これらのリソースはすべて、default という名前が付けられています。 これらのリソースを組み合わせることで、Azure IoT Operations が機能するために必要な基本的な MQTT ブローカーのセットアップが提供されます。 既定のセットアップは、次のとおりです。

完全なデプロイでは、複数の BrokerListeners を使用でき、これら各リスナーに複数のポートを使用でき、これら各ポートに異なる BrokerAuthentication リソースと BrokerAuthorization リソースを関連付けることができます。

たとえば、既定の構成から始めて、次を追加します。

• 2 つのポート 1883 と 8883 を持つ example-lb-listener という名前の LoadBalancer BrokerListener。
• 1 つのポート 1884 (　31884) を持つ nodePort という名前の NodePort BrokerListener。
• カスタム認証方法を使用する example-authn という名前の BrokerAuthentication リソース。
• カスタム承認設定を持つ example-authz という名前の BrokerAuthorization リソース。

同じ BrokerAuthentication リソースと BrokerAuthorization リソースを使用してすべての新しいポートを構成すると、セットアップは次のようになります。

この方法では、既定のセットアップはそのまま維持され、MQTT ブローカーのデプロイをカスタマイズするための新しいリソースを追加できます。

既定の Broker リソース

各 IoT Operations デプロイにはブローカーを 1 つだけ含めることができます。 既定の名前を付ける必要があります。 IoT 操作を機能させるためには、既定のブローカー リソースが必要です。 これは不変であり、デプロイ後に変更することはできません。

default Broker をカスタマイズする

ほとんどのセットアップでは、既定のブローカー リソースをカスタマイズする必要はありません。 カスタマイズが必要な設定は、次のとおりです。

• カーディナリティ: より多くの接続とメッセージを処理するブローカーの能力を決定し、ポッドまたはノードの障害が発生した場合の高可用性が向上します。
• メモリ プロファイル: ブローカーの最大メモリ使用量と、ブローカーのスケールアップ時にメモリ使用量を処理する方法を設定します。
• ディスクベースのメッセージ バッファー: RAM がいっぱいになったときにディスクにメッセージをバッファー処理するための構成。
• 診断設定: ログ レベルやメトリック エンドポイントなどの診断設定の構成。
• 高度な MQTT クライアント オプション: セッションの有効期限、メッセージの有効期限、キープアライブ設定などの詳細な MQTT クライアント オプションの構成。
• 内部トラフィックの暗号化: ブローカー フロントエンドとバックエンド ポッド間の内部トラフィックを暗号化するための構成。

既定のブローカーは、Azure CLI または Azure portal を使用して、初期デプロイ中にのみカスタマイズできます。 異なるブローカー構成設定が必要な場合は、新しいデプロイが必要です。

デプロイ時に default Broker をカスタマイズするには:

default Broker の設定を表示する

既定のブローカーの設定を表示するには:

az iot ops broker show --name default --instance <INSTANCE_NAME> --resource-group <RESOURCE_GROUP>

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

関連するコンテンツ

• IoT Operations を Azure Arc 対応 Kubernetes クラスターにデプロイする