Gerät in Pub/Sub-Verbindung zu Google Cloud

Last reviewed 2023-01-26 UTC

Anstatt eine bestimmte Architektur zu implementieren, um Geräte mit Analyseanwendungen zu verbinden, können einige Organisationen von einer direkten Verbindung zu Pub/Sub von Edge-Geräten profitieren. Wir empfehlen diesen Ansatz für Organisationen, die eine kleine Anzahl verbundener Geräte haben, die Daten von einer größeren Anzahl von Geräten und Sensoren in einem lokalen Netzwerk aggregieren. Dieser Ansatz wird auch empfohlen, wenn Ihre Organisation verbundene Geräte hat, die sich in einer sichereren Umgebung wie einer Fabrik befinden. In diesem Dokument werden die allgemeinen Architekturaspekte beschrieben, die Sie berücksichtigen müssen, um Geräte mit Google Cloud-Produkten zu verbinden.

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:

Architektur

Das folgende Diagramm zeigt ein verbundenes Aggregationsgerät oder Gateway, das direkt mit Pub/Sub verbunden ist.

Mit Pub/Sub verbundene Aggregationsgerät- oder Gateway-Architektur (Ablauf der Ereignisse wird im folgenden Text erläutert).

Der Ablauf der Ereignisse im vorherigen Diagramm sieht so aus:

  • Sie verwenden die Identity and Access Management API, um ein neues Schlüsselpaar für ein Dienstkonto zu erstellen. Der öffentliche Schlüssel wird in IAM gespeichert. Sie müssen den privaten Schlüssel jedoch sicher herunterladen und im Gatewaygerät speichern, damit er für die Authentifizierung verwendet werden kann.
  • Das Aggregationsgerät erfasst Daten von mehreren anderen Remote-Geräten und Sensoren in einem sicheren lokalen Netzwerk. Die Remote-Geräte kommunizieren über ein lokales Edge-Protokoll wie MODBUS, BACNET, OPC-UA oder ein anderes lokales Protokoll mit dem Gateway.
  • Das Aggregationsgerät sendet Daten über HTTPS oder gRPC an Pub/Sub. Diese API-Aufrufe werden mit dem privaten Schlüssel des Dienstkontos signiert, der auf dem Aggregationsgerät gespeichert ist.

Überlegungen und Auswahlmöglichkeiten zu Architekturen

Da Pub/Sub ein serverloser Datenstreamingdienst ist, können Sie damit bidirektionale Systeme erstellen, die aus Ereigniserstellern und Nutzern (Publishern und Abonnenten) bestehen. In einigen Szenarien für verbundene Geräte benötigen Sie nur einen skalierbaren Dienst zum Veröffentlichen und Abonnieren, um eine effektive Datenarchitektur zu erstellen. In den folgenden Abschnitten werden die Überlegungen und Entscheidungen beschrieben, die Sie treffen müssen, wenn Sie ein Gerät in der Pub/Sub-Architektur in Google Cloud implementieren.

Aufnahmeendpunkte

Pub/Sub bietet vordefinierte Clientbibliotheken in mehreren Sprachen, die die REST API und die gRPC API implementieren. Es unterstützt zwei Protokolle zur Nachrichtenaufnahme: REST (HTTP) und gRPC. Damit ein verbundenes Gerät Daten über Pub/Sub senden und empfangen kann, muss das Gerät mit einem dieser Endpunkte interagieren können.

Viele Softwareanwendungen bieten integrierte Unterstützung für REST APIs. Daher ist die Verbindung mit der Pub/Sub REST API oft die einfachste Lösung. In einigen Anwendungsfällen kann gRPC jedoch eine effizientere und schnellere Alternative sein. Da für die Nachrichtennutzlast serialisierte Protokollpuffer anstelle von JSON, XML oder einem anderen textbasierten Format verwendet werden, ist gRPC besser für Anwendungen mit geringer Bandbreite geeignet, die häufig in Anwendungsfällen von verbundenen Geräten verwendet werden. gRPC API-Verbindungen sind außerdem schneller als REST bei der Datenübertragung und gRPC unterstützt die gleichzeitige bidirektionale Kommunikation. Eine Studie hat ergeben, dass gRPC bis zu siebenmal schneller als REST ist. Daher ist gRPC für viele verbundene Geräteszenarien eine bessere Option, wenn ein gRPC-Connector verfügbar ist oder für die verbundene Geräteanwendung implementiert werden kann.

Verwaltung der Geräteauthentifizierung und -anmeldedaten

Pub/Sub unterstützt eine Reihe von Authentifizierungsmethoden für den Zugriff von außerhalb von Google Cloud.

Wenn Ihre Architektur einen externen Identitätsanbieter wie Active Directory oder einen lokalen Kubernetes-Cluster enthält, können Sie die Workload Identity-Föderation verwenden um den Zugriff auf Pub/Sub zu verwalten. Mit diesem Ansatz können Sie kurzlebige Zugriffstokens für verbundene Geräte erstellen. Sie können Ihren verbundenen Geräten auch IAM-Rollen zuweisen, ohne dass ein Verwaltungs- und Sicherheitsaufwand für die Verwendung von Dienstkontoschlüsseln anfallen.

Wenn kein externer Identitätsanbieter verfügbar ist, sind Dienstkontoschlüssel die einzige Option für die Authentifizierung. Dienstkontoschlüssel können zu einem Sicherheitsrisiko werden, wenn sie nicht ordnungsgemäß verwaltet werden. Daher empfehlen wir, die Best Practices für die Bereitstellung von Dienstkontoschlüsseln für verbundene Geräte zu befolgen. Weitere Informationen finden Sie unter Best Practices für die Verwaltung von Dienstkontoschlüsseln. Dienstkonten sind außerdem eine begrenzte Ressource und jedes Cloud-Projekt hat ein begrenztes Kontingent für nutzerverwaltete Dienstkonten. Dieser Ansatz ist daher nur eine Option für Bereitstellungen, die eine kleine Anzahl von Geräten haben, die verbunden werden müssen.

Backend-Anwendungen

Nachdem Daten in ein Pub/Sub-Thema aufgenommen wurden, sind sie für jede Anwendung in Google Cloud verfügbar, die die entsprechenden Anmeldedaten und Zugriffsberechtigungen hat. Außer der Pub/Sub API in Ihrer Anwendung sind keine weiteren Connectors erforderlich. Nachrichten können mehreren Anwendungen in Ihrer Backend-Infrastruktur für parallele Verarbeitung oder Benachrichtigungen sowie für Archivspeicherung und andere Analysen zur Verfügung gestellt werden.

Anwendungsfälle

In den folgenden Abschnitten werden Beispielszenarien beschrieben, in denen eine direkte Verbindung von Geräten zu Pub/Sub gut für Anwendungsfälle mit verbundenen Geräten geeignet ist.

Bulk-Datenaufnahme aus einem lokalen Datenverlauf

Ein Gerät-zu-Pub/Sub-Verbindung eignet sich am besten für Anwendungen, die eine kleine Anzahl von Endpunkten haben, welche große Datenmengen übertragen. Ein operativer Datenverlauf ist ein gutes Beispiel für ein lokales System, in dem viele Daten gespeichert werden, die an Google Cloud übertragen werden müssen. Für diesen Anwendungsfall muss eine kleine Anzahl von Endpunkten authentifiziert werden, normalerweise eines bis zu einigen wenigen verbundenen Geräten. Dies liegt innerhalb der typischen Parameter für die Dienstkontoauthentifizierung. Diese Systeme haben in der Regel auch modulare Architekturen, mit denen Sie die Pub/Sub API-Verbindung implementieren können, die Sie benötigen, um mit Google Cloud zu kommunizieren.

Datenaggregation eines lokalen Gateways für eine Fabrik

Eine Aggregation von Fabrik-Sensordaten in einem lokalen Gateway ist ein weiterer Anwendungsfall, der sich für eine direkte Pub/Sub-Verbindung eignet. In diesem Fall werden ein lokales Datenverwaltungs- und Aggregationssystem auf einem Gatewaygerät in der Fabrik bereitgestellt. Dieses System ist in der Regel ein Softwareprodukt, das eine Verbindung zu einer Vielzahl von lokalen Sensoren und Maschinen herstellt. Das Produkt erfasst die Daten und transformiert sie häufig in eine standardisierte Darstellung, bevor sie an die Cloud-Anwendung übergeben werden.

In diesem Szenario können viele Geräte verbunden werden. Diese Geräte sind jedoch normalerweise nur mit dem lokalen Gateway verbunden und werden von der Software auf diesem Gerät verwaltet. Daher ist keine cloudbasierte Verwaltungsanwendung erforderlich. Im Gegensatz zu einer MQTT-Broker-Architektur spielt das Gateway in diesem Anwendungsfall eine aktive Rolle bei der Aggregation und Transformation der Daten.

Wenn das Gateway eine Verbindung zu Google Cloud herstellt, wird es über einen Dienstkontoschlüssel bei Pub/Sub authentifiziert. Der Schlüssel sendet die aggregierten und transformierten Daten zur weiteren Verarbeitung an die Cloudanwendung. Die Anzahl der verbundenen Gateways liegt normalerweise auch im Bereich von zehn bis Hunderten von Geräten, was innerhalb des typischen Bereichs für die Dienstkontoauthentifizierung liegt.

Nächste Schritte