Azure IoT Operations の組み込みローカル MQTT ブローカー
重要
このページには、プレビュー段階にある Kubernetes デプロイ マニフェストを使用して Azure IoT Operations コンポーネントを管理する手順が含まれます。 この機能はいくつかの制限を設けて提供されており、運用環境のワークロードには使用しないでください。
ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
Azure IoT Operations は、スケーラブル、高可用性、Kubernetes ネイティブといった特性を持つ、標準に準拠したエンタープライズレベルの MQTT ブローカーを備えています。 Azure IoT Operations のメッセージング プレーンを提供し、双方向のエッジ/クラウド通信を可能にし、エッジではイベント ドリブン アプリケーションをサポートします。
MQTT コンプライアンス
メッセージ キュー テレメトリ トランスポート (MQTT) は、IoT 空間に存在するプロトコル間の共通言語として役割を果たしてきました。 MQTT のシンプルな設計により、1 つのブローカーが、軽量のパブリッシュ/サブスクライブ トピックの作成と管理を行って、数万のクライアントに同時にサービスを提供できます。 多くの IoT デバイスでは、そのままの設定で使用できるように MQTT がネイティブでサポートされています。さまざまな IoT プロトコルが使用されていますが、ダウンストリーム変換ゲートウェイで MQTT に変換され、合理化されています。
MQTT ブローカーは、IoT Operations のメッセージング レイヤーを支え、MQTT v3.1.1 と MQTT v5 の両方をサポートします。 サポートされている MQTT 機能の詳細情報については、「MQTT ブローカーでの MQTT 機能のサポート」を参照してください。
Architecture
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 の関係は多対多です。 これらのリソースのエンティティ関係図 (ERD) は、次のとおりです。
既定では、Azure IoT Operations は、default Broker、 default BrokerListener、default BrokerAuthentication をデプロイします。 これらのリソースはすべて、default という名前が付けられています。 これらのリソースを組み合わせることで、Azure IoT Operations が機能するために必要な基本的な MQTT ブローカーの構成が提供されます。 既定値の構成は、次のとおりです。
重要
Azure IoT Operations の内部コンポーネント間の通信の意図しない中断を防ぐために、既定の構成を変更しないことをお勧めします。
MQTT ブローカーのデプロイをカスタマイズするには、BrokerListeners、BrokerAuthentication、BrokerAuthorization などの新しいリソースを default Broker に追加します。
Broker リソース自体は不変であり、デプロイ後に変更することはできませんが、高度なシナリオの場合のみカスタマイズが必要です。 Broker リソースのカスタマイズの詳細については、「default Broker をカスタマイズする」を参照してください。
完全なデプロイでは、複数の BrokerListeners を使用でき、これら各リスナーに複数のポートを使用でき、これら各ポートに異なる BrokerAuthentication リソースと BrokerAuthorization リソースを関連付けることができます。
たとえば、既定の構成から始めて、次を追加します。
- 2 つのポート 1883 と 8883 を持つ example-lb-listener という名前の LoadBalancer BrokerListener
- 1 つのポート 1884 (nodePort 31884) を持つ example-nodeport-listener という名前の NodePort BrokerListener
- カスタム認証方法を使用する example-authnという名前の BrokerAuthentication リソース
- カスタム承認設定を持つ example-authz という名前の BrokerAuthorization リソース
次に、すべての新しいポートが同じ BrokerAuthentication リソースと BrokerAuthorization リソースを使用するように構成すると、構成は次のようになります。
この方法により、既定の構成をそのまま維持し、新しいリソースを追加して、MQTT ブローカーのデプロイをニーズに合わせてカスタマイズします。
既定の Broker リソース
各 Azure IoT Operations デプロイには、1 つのブローカーのみを使用できます。各デプロイには default という名前を付ける必要があります。 Azure IoT 操作を機能させるためには、default Broker リソースが必要です。 これは不変であり、デプロイ後に変更することはできません。
注意事項
default Broker リソースは削除しないでください。 削除すると、Azure IoT Operations の内部コンポーネント間の通信が中断され、デプロイが機能しなくなります。
default Broker をカスタマイズする
ほとんどの構成では、default Broker リソースをカスタマイズする必要はありません。 カスタマイズが必要な設定は、次のとおりです。
- カーディナリティ: より多くの接続とメッセージを処理するブローカーの能力を決定し、ポッドまたはノードの障害が発生した場合の高可用性が向上します。
- メモリ プロファイル: ブローカーの最大メモリ使用量と、ブローカーのスケールアップ時にメモリ使用量を処理する方法を設定します。
- ディスクベースのメッセージ バッファー: RAM がいっぱいになったときにディスクにメッセージをバッファー処理するための構成。
- 診断設定: ログ レベルやメトリック エンドポイントなどの診断設定の構成。
- 高度な MQTT クライアント オプション: セッションの有効期限、メッセージの有効期限、キープアライブ設定などの詳細な MQTT クライアント オプションの構成。
- 内部トラフィックの暗号化: ブローカー フロントエンドとバックエンド ポッド間の内部トラフィックを暗号化するための構成。
default Broker のカスタマイズは、Azure CLI または Azure portal を使用して、初期デプロイ時に行う必要があります。 異なる Broker 構成設定が必要な場合は、新しいデプロイが必要です。
デプロイ時に default Broker をカスタマイズするには:
Azure IoT Operations をデプロイするためのガイドに従う場合は、[構成] セクションで [MQTT ブローカーの構成] を確認します。 ここでは、カーディナリティとメモリ プロファイルの設定をカスタマイズできます。 ディスクベース メッセージ バッファーや高度な MQTT クライアント オプションなどのその他の設定を構成するには、Azure CLI を使用してください。
default Broker の設定を表示する
default Broker の設定を表示するには:
- Azure portal で、Azure IoT Operations インスタンスに移動します。
- [コンポーネント] で、[MQTT ブローカー] を選択します。
- [ブローカー詳細] で、[JSON ビュー] を選択します。