Eigenständige MQTT-Broker-Architektur in Google Cloud

MQTT ist ein OASIS-Standardprotokoll für verbundene Geräteanwendungen, die bidirektionales Messaging mit einer Broker-Architektur zum Veröffentlichen und Abonnieren bietet. Das MQTT-Protokoll hat einen einfachen Aufbau, um den Netzwerkaufwand zu reduzieren, und MQTT-Clients sind sehr klein, um die Nutzung von Ressourcen auf eingeschränkten Geräten zu minimieren. Eine Lösung für Organisationen, die verbundene Geräteanwendungen in Google Cloud unterstützen möchten, ist die Ausführung eines eigenständigen MQTT-Brokers in Compute Engine oder GKE. Um einen MQTT-Broker in Ihrer Organisation bereitzustellen, müssen Sie mehrere wichtige Entscheidungen treffen, die sich auf die Gesamtarchitektur auswirken; insbesondere das Load-Balancing und die Bereitstellungsumgebung. In diesem Dokument wird eine Architektur zum Bereitstellen eines MQTT-Brokers, der Kernanwendung in einer MQTT-Bereitstellung, in Google Cloud beschrieben. Außerdem werden die Entscheidungen beschrieben, die Sie beim Bereitstellen dieses Brokers treffen müssen und wie sie sich auf die Architektur auswirken.

Dieses Dokument ist Teil einer Reihe von Dokumenten, die Informationen zu IoT-Architekturen in Google Cloud und zur Migration von IoT Core enthalten. Die anderen Dokumente in dieser Reihe umfassen die folgenden Punkte:

Das folgende Diagramm zeigt eine MQTT-Broker-Architektur, die in Google Cloud ausgeführt wird.

Diagramm zur MQTT-Broker-Architektur (im folgenden Text erläutert)

Die Architektur im vorherigen Bild ist so zusammengesetzt:

  • Der MQTT-Broker wird als Cluster von drei Instanzen bereitgestellt, die mit dem Cloud Load Balancing-Dienst verbunden sind. Für den Cloud-Load-Balancer können Sie aus einem von mehreren Load-Balancing-Produkten auswählen, die weiter unten in diesem Dokument beschrieben werden.
  • Der Broker-Cluster enthält einen Speicher für Geräte-Anmeldedaten sowie einen Authentifizierungs- und Autorisierungsdienst für Geräte. Der Cluster stellt über Dataflow oder Pub/Sub eine Verbindung zu den Backend-Arbeitslasten her.
  • Auf der Clientseite bieten Edge-Gateways eine bidirektionale Kommunikation zwischen Edge-Geräten und dem MQTT-Broker-Cluster durch MQTT über TLS.

Im Allgemeinen empfehlen wir die Bereitstellung der MQTT-Broker-Anwendung für diese Architektur in einem Cluster, im Sinne der Skalierbarkeit. Faktoren wie Clustering-Funktionen, die Clusterverwaltung zum Hoch- und Herunterskalieren, die Datensynchronisierung und die Verarbeitung von Netzwerkpartitionen werden durch die jeweiligen Broker-Implementierungen (wie HiveMQ, EMQX, VerneMQ, mosquito und andere) behandelt.

Überlegungen und Auswahlmöglichkeiten zu Architekturen

In den folgenden Abschnitten werden die verschiedenen Architekturentscheidungen und -überlegungen beschrieben, die Sie für eine eigenständige MQTT-Broker-Architektur treffen müssen, und die Auswirkungen dieser Auswahl auf die Architektur.

Verbundene Geräte

Mit dem Internet verbundene Edge-Geräte veröffentlichen ihre Telemetrieereignisse und andere Informationen im MQTT-Broker. Zur Implementierung der eigenständigen MQTT-Broker-Architektur, die in diesem Dokument beschrieben wird, muss das Gerät einen MQTT-Client, den öffentlichen Schlüssel des Serverzertifikats für die TLS-Authentifizierung und die Anmeldedaten haben, die für die Authentifizierung beim MQTT-Broker erforderlich sind.

Darüber hinaus haben Edge-Geräte im Allgemeinen Connectors zu lokalen Sensoren, zu lokalen Datensystemen und zu anderen Geräten, die nicht über einen Internetzugriff oder eine IP-Verbindung verfügen. Beispielsweise kann das Edge-Gerät als Gateway für andere lokale eingeschränkte Geräte verwendet werden, die über BLE mit dem Gateway verbunden sind, mit einer Kabelverbindung oder einem anderen Nahfeldprotokoll. Eine ausführliche Spezifikation der verbundenen Gerätearchitektur wird in diesem Leitfaden nicht behandelt.

Load-Balancing

In der Architektur wird ein externer Load-Balancing-Dienst zwischen dem öffentlichen Netzwerk und dem MQTT-Broker-Cluster konfiguriert. Dieser Dienst bietet mehrere wichtige Netzwerkfunktionen, einschließlich der Verteilung eingehender Verbindungen über Backend-Knoten, der Sitzungsverschlüsselung und der Authentifizierung.

Google Cloud unterstützt mehrere Load-Balancer-Typen. Berücksichtigen Sie Folgendes, um den besten Load-Balancer für Ihre Architektur auszuwählen:

  • mTLS. mTLS verarbeitet sowohl Verschlüsselungs- als auch Geräteauthentifizierungsmethoden, während Standard-TLS nur die Verschlüsselung und eine separate Geräteauthentifizierungsmethode erfordert:

    • Wenn Ihre Anwendung mTLS für die Geräteauthentifizierung verwendet und den TLS-Tunnel beenden muss, empfehlen wir die Verwendung eines externen Passthrough-Network Load Balancer oder eines externen Proxy-Network Load Balancer durch einen Ziel-TCP-Proxy. Externe SSL-Proxy-Network Load Balancer beenden die TLS-Sitzung und leiten die Verbindung zum Broker-Knoten zusammen mit allen in der Nachricht enthaltenen Anmeldedaten zur Authentifizierung weiter. Wenn Sie die Clientverbindungsinformationen als Teil des Authentifizierungsschemas benötigen, können Sie sie in der Backend-Verbindung beibehalten, indem Sie das PROXY-Protokoll aktivieren.
    • Wenn Ihre Anwendung kein mTLS verwendet, empfehlen wir die Verwendung eines externen Proxy-Network Load Balancers mit einem Ziel-SSL-Proxy, um die externe TLS- und SSL-Verarbeitung an den Load Balancer auszulagern. Externe SSL-Proxy-Network Load Balancer beenden die TLS-Sitzung und leiten die Verbindung zum Broker-Knoten zusammen mit allen in der Nachricht enthaltenen Anmeldedaten zur Authentifizierung weiter. Wenn Sie die Clientverbindungsinformationen als Teil des Authentifizierungsschemas benötigen, können Sie sie in der Backend-Verbindung beibehalten, indem Sie das PROXY-Protokoll aktivieren.

  • HTTP(S)-Endpunkte. Wenn Sie HTTP(S)-Endpunkte verfügbar machen müssen, empfehlen wir Ihnen, einen separaten externen Application Load Balancer für diese Endpunkte zu konfigurieren.

Weitere Informationen zu den von Cloud Load Balancing unterstützten Load Balancer-Typen finden Sie unter Zusammenfassung der Load Balancer von Google Cloud.

Load-Balancing-Strategie

Jeder Load-Balancing-Dienst verteilt Verbindungen von Edge-Geräten auf die Knoten im Cluster gemäß einem von mehreren Algorithmen oder Balancing-Modi. Für MQTT ist eine Sitzungsaffinität-Load-Balancing-Strategie besser als ein zufälliges Load-Balancing. Da MQTT-Client-Server-Verbindungen persistente bidirektionale Sitzungen sind, wird der Status auf dem Broker-Knoten verwaltet, der die Verbindung beendet. Wenn in einer geclusterten Konfiguration ein Client die Verbindung trennt und dann wieder eine Verbindung zu einem anderen Knoten herstellt, wird der Sitzungsstatus zu dem neuen Knoten verschoben, wodurch der Cluster stärker belastet wird. Dieses Problem lässt sich weitgehend mithilfe des Sitzungsaffinität-Load-Balancings vermeiden. Wenn Clients häufig ihre IP-Adressen ändern, kann die Verbindung unterbrochen werden. In den meisten Fällen ist die Sitzungsaffinität für MQTT jedoch besser. Die Sitzungsaffinität ist in allen Cloud Load Balancing-Produkten verfügbar.

Verwaltung der Geräteauthentifizierung und -anmeldedaten

MQTT-Broker-Anwendungen verarbeiten die Geräteauthentifizierung und die Zugriffssteuerung getrennt von Google Cloud. Eine Broker-Anwendung bietet auch einen eigenen Anmeldedatenspeicher und eine eigene Verwaltungsoberfläche. Das MQTT-Protokoll unterstützt die Authentifizierung mit Nutzernamen und Passwort im ersten Connect-Paket. Diese Felder werden auch häufig von Broker-Implementierungen verwendet, um andere Authentifizierungsformen wie X.509-Zertifikate oder JWT-Authentifizierungen zu unterstützen. MQTT 5.0 unterstützt auch erweiterte Authentifizierungsmethoden, die eine Authentifizierung des Challenge- und Response-Typs verwenden. Die verwendete Authentifizierungsmethode hängt von der Auswahl der MQTT-Broker-Anwendung und dem Anwendungsfall des verbundenen Geräts ab.

Unabhängig von der Authentifizierungsmethode, die der Broker verwendet, verwaltet der Broker einen Speicher für Geräteanmeldedaten. Dieser Speicher kann sich in einer lokalen SQL-Datenbank oder in einer Flatfile befinden. Einige Broker, einschließlich HiveMQ und VerneMQ, unterstützen auch die Verwendung eines verwalteten Datenbankdienstes wie Cloud SQL. Sie benötigen einen separaten Dienst, um den Speicher für Geräte-Anmeldedaten zu verwalten und jedwede Integrationen in andere Authentifizierungsdienste wie IAM zu handhaben. Die Entwicklung dieses Dienstes wird in diesem Leitfaden nicht behandelt.

Weitere Informationen zur Authentifizierung und Verwaltung von Anmeldedaten finden Sie unter Best Practices zum Ausführen eines IoT-Back-Ends in Google Cloud.

Backend-Arbeitslasten

Jeder Anwendungsfall mit verbundenen Geräten umfasst eine oder mehrere Backend-Anwendungen, die die von den verbundenen Geräten aufgenommenen Daten nutzen. Manchmal müssen diese Anwendungen auch Befehle und Konfigurationsaktualisierungen an die Geräte senden. In der eigenständigen MQTT-Broker-Architektur in diesem Dokument werden eingehende Daten und ausgehende Befehle beide über den MQTT-Broker weitergeleitet. Innerhalb der Themenhierarchie des Brokers gibt es verschiedene Themen, um zwischen den Daten und den Befehlen zu unterscheiden.

Daten und Befehle können auf verschiedene Arten zwischen dem Broker und den Backend-Anwendungen gesendet werden. Wenn die Anwendung selbst MQTT unterstützt oder so geändert werden kann, dass sie MQTT unterstützt, kann die Anwendung den Broker direkt als Client abonnieren. Auf diese Weise können Sie die bidirektionale MQTT-Messaging-Funktion direkt mit Ihrer Anwendung verwenden, um Daten von den verbundenen Geräten zu empfangen und an diese zu senden.

Wenn Ihre Anwendung MQTT nicht unterstützt, gibt es mehrere andere Optionen. In der in diesem Dokument beschriebenen Architektur bietet Apache Beam einen MQTT-Treiber, der die bidirektionale Integration in Dataflow und andere Beam-Bereitstellungen ermöglicht. Viele Broker haben außerdem Plug-in-Funktionen, die die Integration in Dienste wie Google Pub/Sub unterstützen. Dies sind in der Regel unidirektionale Integrationen für die Datenintegration, einige Broker unterstützen jedoch die bidirektionale Integration.

Anwendungsfälle

Eine MQTT-Broker-Architektur eignet sich besonders für die in den folgenden Abschnitten beschriebenen Geräte-Anwendungsfälle.

Standardbasierte Datenaufnahme von heterogenen Geräten

Wenn Sie Daten von einer großen Flotte heterogener Geräte erfassen und analysieren möchten, ist ein MQTT-Broker häufig eine gute Lösung. Da MQTT ein weit verbreiteter und implementierter Standard ist, bieten viele Edge-Geräte eine integrierte Unterstützung dafür. Außerdem sind einfache MQTT-Clients verfügbar, um Geräten, die dies nicht tun, eine MQTT-Unterstützung hinzuzufügen. Das Publish-and-Subscribe-Paradigma ist auch Teil des MQTT-Standards. Daher können MQTT-fähige Geräte diese Architektur ohne zusätzliche Implementierungsarbeit nutzen. Im Gegensatz dazu müssen Geräte, die eine Verbindung zu Pub/Sub herstellen, die Pub/Sub API implementieren oder das Pub/Sub SDK verwenden. Das Ausführen eines standardkonformen MQTT-Brokers in Google Cloud bietet daher eine einfache Lösung zum Erfassen von Daten von einer Vielzahl von Geräten.

Wenn Ihre verbundenen Geräte nicht von Ihrer Anwendung, sondern von einem Drittanbieter gesteuert werden, haben Sie möglicherweise keinen Zugriff auf die Gerätesystemsoftware und die Verwaltung des Geräts selbst liegt in der Verantwortung des anderen Anbieters. In diesem Fall empfehlen wir, einen MQTT-Broker auszuführen und dem Drittanbieter Authentifizierungsanmeldedaten bereitzustellen, um den Gerät-zu-Cloud-Kommunikationskanal einzurichten.

Bidirektionale Kommunikation für die mehrteilige Anwendungsintegration

Durch die bidirektionale Messaging-Funktion von MQTT eignet es sich sehr gut für einen Anwendungsfall mit mehrteiligen mobilen Anwendungen, z. B. On-Demand-Essenslieferungen oder umfangreiche Webchat-Anwendungen. MQTT hat einen geringen Protokollaufwand und MQTT-Clients haben einen niedrigen Ressourcenbedarf. MQTT bietet außerdem Routing für das Veröffentlichen und Abonnieren, mehrere Dienstqualitätsebenen (QoS), integrierte Nachrichtenaufbewahrung und umfassende Protokollunterstützung. Ein MQTT-Broker kann die Kernkomponente einer skalierbaren Messaging-Plattform für On-Demand-Dienstanwendungen und ähnliche Anwendungsfälle sein.

Integriertes Edge-zu-Cloud-Messaging

Aufgrund der Standardisierung und des geringen Aufwands, die MQTT bietet, kann es auch eine gute Lösung für die Integration lokaler und cloudbasierter Messaging-Anwendungen sein. So kann ein Fabrikoperator beispielsweise mehrere MQTT-Broker in der lokalen Umgebung bereitstellen, um eine Verbindung zu Sensoren, Maschinen, Gateways und anderen Geräten hinter der Firewall herzustellen. Der lokale MQTT-Broker kann das gesamte bidirektionale Befehls-, Kontroll- und Telemetrie-Messaging für die lokale Infrastruktur verarbeiten. Der lokale Broker kann auch durch ein bidirektionales Abo mit einem parallelen MQTT-Broker-Cluster in der Cloud verbunden werden, sodass die Kommunikation zwischen der Cloud und der Edge-Umgebung möglich ist, ohne dass die lokalen Geräte und Systeme für das öffentliche Internet zugänglich gemacht werden.

Nächste Schritte