Eigenständige MQTT-Broker-Architektur in Google Cloud

MQTT ist ein OASIS-Standardprotokoll für Anwendungen mit verbundenen Geräten, das bidirektionale Nachrichtenübertragung über eine Publish-and-Subscribe-Broker-Architektur ermöglicht. 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 Anwendungen für verbundene Geräte aufGoogle Cloud unterstützen möchten, besteht darin, einen eigenständigen MQTT-Broker in Compute Engine oder GKE auszuführen. Wenn Sie einen MQTT-Broker in Ihrer Organisation bereitstellen möchten, müssen Sie mehrere wichtige Entscheidungen treffen, die sich auf die Gesamtarchitektur auswirken, insbesondere auf den Lastenausgleich und die Bereitstellungsumgebung. In diesem Dokument wird eine Architektur zum Bereitstellen eines MQTT-Brokers, der Kernanwendung in einer MQTT-Bereitstellung, in Google Cloudbeschrieben. 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 auf Google Cloudenthalten. Die anderen Dokumente in dieser Reihe umfassen die folgenden Punkte:

Das folgende Diagramm zeigt eine MQTT-Broker-Architektur, die aufGoogle Cloudausgeführt wird.

Diagramm der MQTT-Broker-Architektur (Erläuterung im folgenden Text)

Die Architektur im vorherigen Bild setzt sich so zusammen:

  • Der MQTT-Broker wird als Cluster mit drei Instanzen bereitgestellt, die mit dem Cloud Load Balancing-Dienst verbunden sind. Für den Cloud-Load-Balancer können Sie eines von mehreren Load-Balancing-Produkten auswählen, die weiter unten in diesem Dokument beschrieben werden.
  • Der Broker-Cluster umfasst einen Speicher für Geräteanmeldedaten sowie einen Dienst für Geräteauthentifizierung und ‑autorisierung. 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 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.

Außerdem haben Edge-Geräte in der Regel Anschlüsse für lokale Sensoren, lokale Datensysteme und andere Geräte, die keinen Internetzugang oder keine IP-Verbindung haben. 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 detaillierte Spezifikation der Architektur verbundener Geräte wird in diesem Leitfaden nicht behandelt.

Load-Balancing

In der Architektur ist ein externer Load-Balancing-Dienst zwischen dem öffentlichen Netzwerk und dem MQTT-Broker-Cluster konfiguriert. Dieser Dienst bietet mehrere wichtige Netzwerkfunktionen, darunter die Verteilung eingehender Verbindungen auf Back-End-Knoten, Sitzungsverschlüsselung und Authentifizierung.

Google Cloud unterstützt mehrere Load-Balancer-Typen. Berücksichtigen Sie bei der Auswahl des besten Load-Balancers für Ihre Architektur Folgendes:

  • 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 die Verbindungsinformationen des Clients als Teil des Authentifizierungsschemas erforderlich sind, können Sie diese Informationen 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 die Verbindungsinformationen des Clients als Teil des Authentifizierungsschemas erforderlich sind, können Sie diese Informationen 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 Google Cloud Load Balancer.

Load-Balancing-Strategie

Jeder Load-Balancing-Dienst verteilt Verbindungen von Edge-Geräten gemäß einem von mehreren Algorithmen oder Balancing-Modi auf die Knoten im Cluster. Für MQTT ist eine Load-Balancing-Strategie mit Sitzungsaffinität besser als 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 Clusterkonfiguration ein Client die Verbindung trennt und dann eine neue Verbindung zu einem anderen Knoten herstellt, wird der Sitzungsstatus auf den neuen Knoten verschoben, was die Last des Clusters erhöht. Dieses Problem lässt sich weitgehend mithilfe des Sitzungsaffinität-Load-Balancings vermeiden. Wenn Clients ihre IP-Adressen häufig ändern, kann die Verbindung unterbrochen werden. In den meisten Fällen ist die Sitzungsaffinität jedoch besser für MQTT geeignet. Die Sitzungsaffinität ist in allen Cloud Load Balancing-Produkten verfügbar.

Verwaltung der Geräteauthentifizierung und -anmeldedaten

MQTT-Brokeranwendungen verarbeiten die Geräteauthentifizierung und Zugriffssteuerung getrennt von Google Cloud. Eine Brokeranwendung bietet auch einen eigenen Anmeldedatenspeicher und eine eigene Verwaltungsschnittstelle. 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 Ihres 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 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 dieser Anleitung nicht behandelt.

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

Back-End-Arbeitslasten

Jeder Anwendungsfall für verbundene Geräte umfasst eine oder mehrere Backend-Anwendungen, die die von den verbundenen Geräten aufgenommenen Daten verwenden. Manchmal müssen diese Anwendungen auch Befehle und Konfigurationsupdates 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. In 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 als Client direkt den Broker abonnieren. Mit diesem Ansatz können Sie die bidirektionale MQTT Pub/Sub-Messaging-Funktion direkt nutzen, indem Sie Ihre Anwendung verwenden, um Daten von den verbundenen Geräten zu empfangen und Befehle an sie zu senden.

Wenn Ihre Anwendung MQTT nicht unterstützt, gibt es mehrere andere Optionen. In der in diesem Dokument beschriebenen Architektur stellt Apache Beam einen MQTT-Treiber bereit, der eine bidirektionale Integration mit Dataflow und anderen Beam-Bereitstellungen ermöglicht. Viele Broker haben auch Plug-in-Funktionen, die die Integration mit Diensten wie Google Pub/Sub unterstützen. In der Regel handelt es sich um unidirektionale Integrationen für die Datenintegration, obwohl einige Broker bidirektionale Integrationen unterstützen.

Anwendungsfälle

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

Standardbasierte Datenerfassung 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. Geräte, die eine Verbindung zu Pub/Sub herstellen, müssen dagegen die Pub/Sub API implementieren oder das Pub/Sub SDK verwenden. Die Ausführung eines standardkonformen MQTT-Brokers aufGoogle Cloud bietet somit 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-Dienste 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. Ein Fabrikbetreiber kann beispielsweise mehrere MQTT-Broker in der lokalen Umgebung bereitstellen, um eine Verbindung zu Sensoren, Maschinen, Gateways und anderen Geräten herzustellen, die sich hinter der Firewall befinden. 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