Eigenständige MQTT-Broker-Architektur in Google Cloud

Last reviewed 2024-08-09 UTC

MQTT ist ein OASIS-Standardprotokoll für Anwendungen auf verbundenen Geräten, das bidirektionales Messaging mit einer Publish-and-Subscribe-Broker-Architektur 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 Anwendungen für verbundene Geräte in Google Cloud unterstützen möchten, besteht darin, einen eigenständigen MQTT-Broker in der Compute Engine oder GKE auszuführen. Wenn Sie einen MQTT-Broker in Ihrem Unternehmen bereitstellen möchten, müssen Sie mehrere wichtige Entscheidungen treffen, die sich auf die Gesamtarchitektur auswirken, insbesondere auf 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 enthalten. Die anderen Dokumente in dieser Reihe umfassen die folgenden Punkte:

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

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

Die Architektur im vorherigen Bild ist so aufgebaut:

  • Der MQTT-Broker wird als Cluster aus drei Instanzen bereitgestellt, die mit dem Cloud Load Balancing-Dienst verbunden sind. Für den Cloud-Load-Balancer können Sie zwischen 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äteanmeldedaten und einen Dienst zur 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 (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 in der Regel Anschlüsse für lokale Sensoren, lokale Datensysteme und andere Geräte, die keinen Internetzugriff 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 der verbundenen Geräte 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, darunter die Verteilung eingehender Verbindungen auf Back-End-Knoten, die Sitzungsverschlüsselung und die 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 Sie die Verbindungsinformationen des Clients 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 Verbindungsinformationen des Clients 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 über die Knoten im Cluster gemäß einem der verschiedenen Algorithmen oder Balancing-Modi. Bei MQTT ist eine Load-Balancing-Strategie für eine Sitzungsaffinität besser als das zufällige Load-Balancing. Da MQTT-Client-Server-Verbindungen persistente bidirektionale Sitzungen sind, wird der Status auf dem Broker-Knoten verwaltet, der die Verbindung beendet. Wenn ein Client in einer Clusterkonfiguration die Verbindung trennt und dann wieder mit einem anderen Knoten verbindet, wird der Sitzungsstatus auf den neuen Knoten verschoben, was die Auslastung 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 für MQTT jedoch besser. 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 unabhängig von Google Cloud. Eine Brokeranwendung stellt auch einen eigenen Anmeldedatenspeicher und eine eigene Verwaltungsoberfläche bereit. 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 Anmeldedatenverwaltung finden Sie unter Best Practices zum Ausführen eines IoT-Back-Ends in Google Cloud.

Backend-Arbeitslasten

Jeder Anwendungsfall für verbundene Geräte umfasst eine oder mehrere Back-End-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 sie den Broker direkt als Client abonnieren. Mit diesem Ansatz können Sie die bidirektionale MQTT Pub/Sub-Messaging-Funktion direkt verwenden, indem Sie mit Ihrer Anwendung Daten von den verbundenen Geräten empfangen und Befehle an sie senden.

Wenn Ihre Anwendung MQTT nicht unterstützt, gibt es mehrere andere Möglichkeiten. In der in diesem Dokument beschriebenen Architektur bietet Apache Beam einen MQTT-Treiber, der die bidirektionale Integration mit Dataflow und anderen Beam-Deployments ermöglicht. Viele Broker bieten auch Plug-in-Funktionen, die die Einbindung in Dienste wie Google Pub/Sub unterstützen. Dies sind in der Regel unidirektionale Integrationen für die Datenintegration, obwohl einige Broker die bidirektionale Integration unterstützen.

Anwendungsfälle

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

Standardbasierte Datenaufnahme aus 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 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-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 Betriebsleiter 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