Google Cloud のスタンドアロン MQTT ブローカー アーキテクチャ

Last reviewed 2024-08-09 UTC

MQTT は、パブリッシュ / サブスクライブのブローカー アーキテクチャを使用して双方向のメッセージングを行う、コネクテッド デバイス アプリケーション向けの OASIS 標準プロトコルです。MQTT プロトコルは軽量でネットワークのオーバーヘッドが少なく、また MQTT クライアントはきわめて小さく、制約のあるデバイスでのリソースの使用を最小限に抑えます。Google Cloud 上で接続済みのデバイス アプリケーションをサポートする必要がある組織向けのソリューションの 1 つは、Compute Engine または GKE でスタンドアロンの MQTT ブローカーを実行することです。MQTT ブローカーを組織にデプロイするには、アーキテクチャ全体に影響するいくつかの重要な決定を行う必要があり、特に負荷分散とデプロイ環境が対象になります。このドキュメントでは、MQTT デプロイのコア アプリケーションである MQTT ブローカーを Google Cloud にデプロイするためのアーキテクチャについて説明します。また、このブローカーをデプロイする際に必要な決定事項と、それがアーキテクチャに与える影響についても説明します。

このドキュメントは、Google Cloud の IoT アーキテクチャに関する情報を提供する一連のドキュメントの一部です。このシリーズには、このほかに次のドキュメントが含まれています。

次の図は、Google Cloud 上で動作する MQTT ブローカー アーキテクチャを示しています。

MQTT ブローカー アーキテクチャの図（後述）。

上の画像のアーキテクチャは次のように構成されています。

  • MQTT ブローカーは、Cloud Load Balancing サービスに接続されている 3 つのインスタンスからなるクラスタとしてデプロイされます。クラウド ロードバランサには、このドキュメントの後半で説明する複数の負荷分散プロダクトのいずれかを選択できます。
  • ブローカー クラスタには、デバイス認証情報ストアとデバイス認証・認可サービスが含まれています。クラスタは、Dataflow または Pub/Sub を介してバックエンド ワークロードに接続します。
  • クライアント側では、エッジ ゲートウェイが、MQTT over TLS を介してエッジデバイスと MQTT ブローカー クラスタの間の双方向通信を実現します。

一般に、このアーキテクチャの MQTT ブローカー アプリケーションは、スケーラビリティの観点からクラスタにデプロイすることをおすすめします。クラスタリング機能、スケールアップとスケールダウンのクラスタ管理、データの同期、ネットワーク パーティションの処理などの要素については、特定のブローカー実装（HiveMQ、EMQX、VerneMQ、mosquito など）で対応します。

アーキテクチャに関する比較検討と選択

以下のセクションでは、スタンドアロンの MQTT ブローカー アーキテクチャで必要なさまざまなアーキテクチャの選択と比較検討、このような選択がアーキテクチャに与える影響について説明します。

接続済みのデバイス

インターネットに接続されたエッジデバイスは、テレメトリー イベントやその他の情報を MQTT ブローカーにパブリッシュします。本ドキュメントで説明するスタンドアロンの MQTT ブローカー アーキテクチャを実装するには、デバイスに MQTT クライアント、TLS 認証用のサーバー証明書の公開鍵、MQTT ブローカーで認証するために必要な認証情報が必要です。

また、エッジデバイスは一般的に、ローカル センサー、オンプレミス データシステム、インターネット アクセスや IP 接続がない他のデバイスへのコネクタを備えています。たとえば、エッジデバイスは、BLE でゲートウェイに接続されたローカル制約のある他のデバイス、有線接続、別の近傍プロトコルのゲートウェイとして機能することが可能です。接続済みのデバイス アーキテクチャの詳細な仕様は、本ガイドの範囲外です。

負荷分散

このアーキテクチャでは、パブリック ネットワークと MQTT ブローカー クラスタの間に外部ロード バランシング サービスが構成されます。このサービスにより、バックエンド ノード間での受信接続の分散、セッションの暗号化、認証といったいくつかの重要なネットワーキング機能が提供されます。

Google Cloud は、複数のロードバランサ タイプをサポートしています。アーキテクチャに最適なロードバランサを選択するには、次の点を考慮してください。

  • mTLS。mTLS は暗号化とデバイス認証方法の両方を処理しますが、標準 TLS は暗号化のみを処理し、別のデバイス認証方法が必要です。

  • HTTP(S) エンドポイント。HTTP(S) エンドポイントを公開する必要がある場合は、これらのエンドポイントに別の外部アプリケーション ロードバランサを構成することをおすすめします。

Cloud Load Balancing がサポートするロードバランサ タイプの詳細については、Google Cloud ロードバランサの概要をご覧ください。

ロード バランシング戦略

ロード バランシング サービスは、複数のアルゴリズムまたは分散モードのいずれかに従って、エッジデバイスからの接続をクラスタ内のノード間に分散させます。MQTT の場合、ランダム ロード バランシングよりもセッション アフィニティ ロード バランシング戦略をおすすめします。MQTT クライアント / サーバー接続は永続的な双方向セッションであるため、状態は接続を停止したブローカー ノードで維持されます。クラスタ構成では、クライアントが切断した後に別のノードに再接続すると、セッションの状態が新しいノードに移動してクラスタに負荷がかかります。この問題は、セッション アフィニティの負荷分散を使用することでほぼ回避できます。クライアントが IP アドレスを頻繁に変更すると接続が切断される可能性がありますが、ほとんどの場合、MQTT にはセッション アフィニティの方が適しています。セッション アフィニティは、すべての Cloud Load Balancing プロダクトで使用できます。

デバイスの認証と認証情報の管理

MQTT ブローカー アプリケーションは、Google Cloud とは別にデバイスの認証とアクセス制御を処理します。ブローカー アプリケーションには、独自の認証情報ストアと管理インターフェースも用意されています。MQTT プロトコルは、初期の Connect パケットで基本的なユーザー名とパスワードの認証をサポートしています。これらのフィールドは、X.509 証明書や JWT 認証などの他の形式の認証をサポートするために、ブローカーの実装でも頻繁に使用されます。MQTT 5.0 では、チャレンジ / レスポンス スタイルの認証を使用する拡張認証方法のサポートも追加されています。使用される認証方法は、MQTT ブローカー アプリケーションと接続済みのデバイスのユースケースの選択によって異なります。

ブローカーは、使用する認証方法に関係なく、デバイスの認証情報ストアを管理します。このストアは、ローカル SQL データベースまたはフラット ファイルに格納できます。HiveMQ や VerneMQ といった一部のブローカーは、Cloud SQL などのマネージド データベース サービスの使用もサポートしています。デバイスの認証情報ストアを管理し、IAM などの他の認証サービスとの統合を行うには、別のサービスが必要となります。こうしたサービスの開発は、このガイドの範囲外です。

認証と認証情報の管理の詳細については、Google Cloud で IoT バックエンドを実行するためのベスト プラクティスをご覧ください。

バックエンド ワークロード

接続済みのデバイスのユースケースには、接続済みのデバイスから取り込まれたデータを使用する 1 つまたは複数のバックエンド アプリケーションが含まれます。場合によっては、これらのアプリケーションはデバイスにコマンドと構成の更新を送信する必要があります。このドキュメントのスタンドアロン MQTT ブローカー アーキテクチャでは、受信データと送信コマンドの両方が MQTT ブローカー経由で転送されます。ブローカーのトピック階層内には、データとコマンドを区別するためのさまざまなトピックがあります。

データとコマンドは、いくつかの方法のいずれかでブローカーとバックエンド アプリケーションの間で送信できます。アプリケーション自体が MQTT をサポートしている場合、または MQTT をサポートするように変更できる場合は、アプリケーションはクライアントとしてブローカーに直接登録できます。この方法により、アプリケーションを使用して接続済みのデバイスとの間でデータの受信とコマンドの送信を行い、MQTT Pub/Sub 双方向メッセージング機能を直接使用することが可能になります。

アプリケーションが MQTT をサポートしていない場合は、他にもいくつかのオプションがあります。このドキュメントで説明するアーキテクチャでは、Apache Beam の MQTT ドライバを使用して、Dataflow やその他の Beam デプロイメントとの双方向の統合が可能です。多くのブローカーは、Google Pub/Sub などのサービスとの統合をサポートするプラグイン機能も備えています。これらは通常、一方向のデータ統合ですが、一部のブローカーは双方向の統合をサポートしています。

ユースケース

MQTT ブローカーのアーキテクチャは、以降のセクションで説明するデバイスのユースケースに特に適しています。

異種デバイスからの標準ベースのデータ取り込み

大規模な異種混合デバイス群からデータを収集して分析する場合、MQTT ブローカーが優れたソリューションになることがよくあります。MQTT は広く採用され、実装されている標準規格であるため、多くのエッジデバイスに MQTT サポートが組み込れていますが、組み込まれていないデバイスには軽量の MQTT クライアントを使用して MQTT サポートを追加できます。パブリッシュ / サブスクライブ パラダイムも MQTT 標準の一部であるため、MQTT 対応デバイスは追加の実装作業なしにこのアーキテクチャを利用できます。一方、Pub/Sub に接続するデバイスでは、Pub/Sub API を実装するか、Pub/Sub SDK を使用する必要があります。このように、Google Cloud 上で標準に準拠した MQTT ブローカーを実行することで、さまざまなデバイスからデータを収集するためのシンプルなソリューションを実現できます。

接続済みのデバイスがアプリケーションではなく第三者によって制御されている場合、デバイスのシステム ソフトウェアにアクセスできず、デバイス自体の管理が相手の責任となる可能性があります。そのような場合は、MQTT ブローカーを実行し、認証情報を第三者に提供してデバイスとクラウドの通信チャネルを設定することをおすすめします。

マルチパーティ アプリケーション統合のための双方向通信

MQTT の双方向メッセージング機能は、オンデマンドのフードデリバリや大規模なウェブチャット アプリケーションといった、マルチパーティ モバイル アプリケーションのユースケースに非常に適しています。MQTT はプロトコル オーバーヘッドが少なく、MQTT クライアントはリソースの要求があまりありません。MQTT は、パブリッシュ / サブスクライブのルーティング、複数の Quality of Service（QoS）レベル、組み込みのメッセージ保持、幅広いプロトコルのサポートも備えています。MQTT ブローカーは、オンデマンド サービス アプリケーションのようなユースケースに対応する、スケーラブルなメッセージング プラットフォームのコア コンポーネントとなることが可能です。

エッジからクラウドへの統合メッセージング

MQTT は標準化を実現し、オーバーヘッドが少ないため、オンプレミスとクラウドベースのメッセージング アプリケーションを統合するのに適したソリューションになる可能性もあります。たとえば、工場のオペレーターは、オンプレミス環境に複数の MQTT ブローカーを導入して、ファイアウォールの内側にあるセンサー、マシン、ゲートウェイなどのデバイスに接続できます。ローカル MQTT ブローカーは、オンプレミス インフラストラクチャのすべての双方向コマンドと制御 / テレメトリー メッセージを処理できます。ローカル ブローカーは、クラウド上の並列 MQTT ブローカー クラスタに双方向サブスクリプションでも接続できるため、オンプレミスのデバイスやシステムをパブリックなインターネットに公開することなく、クラウドとエッジ環境間の通信が可能になります。

次のステップ