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

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

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

次の図は、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 ブローカー クラスタに双方向サブスクリプションで接続することもでき、それによりオンプレミスのデバイスやシステムを公共のインターネットに公開することなく、クラウドとエッジ環境間の通信が可能になります。

次のステップ