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

Last reviewed 2024-08-09 UTC

Anstatt eine bestimmte Architektur zum Verbinden von Geräten mit Analyseanwendungen zu implementieren, können einige Organisationen davon profitieren, eine direkte Verbindung zu Pub/Sub von Edge-Geräten herzustellen. 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 in einer sichereren Umgebung hat, z. B. in einer Fabrik. 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 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:

  • Mit der Identity and Access Management API erstellen Sie ein neues Schlüsselpaar für ein Dienstkonto. Der öffentliche Schlüssel wird in IAM gespeichert. Sie müssen den privaten Schlüssel jedoch sicher herunterladen und auf dem Gateway-Gerä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 mit dem Gateway über ein lokales Edge-Protokoll wie MODBUS, BACNET, OPC-UA oder ein anderes lokales Protokoll.
  • Das Aggregationsgerät sendet Daten entweder über HTTPS oder gRPC an Pub/Sub. Diese API-Aufrufe werden mit dem privaten Schlüssel des Dienstkontos signiert, der sich auf dem Aggregationsgerät befindet.

Ü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 bestehen (Publisher und Abonnenten genannt). In einigen Szenarien mit verbundenen Geräten benötigen Sie lediglich einen skalierbaren Publish-and-Subscribe-Dienst, um eine effektive Datenarchitektur zu erstellen. In den folgenden Abschnitten werden die Überlegungen und Entscheidungen beschrieben, die Sie bei der Implementierung einer Gerät-zu-Pub/Sub-Architektur in Google Cloud treffen müssen.

Aufnahmeendpunkte

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

Viele Softwareanwendungen unterstützen 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 Szenarien mit verbundenen Geräten die bessere Option, wenn ein gRPC-Connector verfügbar ist oder für die Anwendung des verbundenen Geräts 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 Identitätsföderation von Arbeitslasten verwenden, um den Zugriff auf Pub/Sub zu verwalten. So 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 ebenfalls eine begrenzte Ressource und jedes Cloud-Projekt hat ein begrenztes Kontingent an nutzerverwalteten Dienstkonten. Daher ist dieser Ansatz nur für Bereitstellungen mit einer kleinen Anzahl von Geräten geeignet, die verbunden werden müssen.

Backend-Anwendungen

Nachdem Daten in ein Pub/Sub-Thema aufgenommen wurden, sind sie für alle Anwendungen verfügbar, die in Google Cloud ausgeführt werden und die entsprechenden Anmeldedaten und Zugriffsberechtigungen haben. Außer der Pub/Sub API sind in Ihrer Anwendung keine zusätzlichen Connectors erforderlich. Sie können Nachrichten für mehrere Anwendungen in Ihrer Back-End-Infrastruktur zur parallelen Verarbeitung oder für Benachrichtigungen sowie für die Archivierung und andere Analysen zur Verfügung stellen.

Anwendungsfälle

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

Bulk-Datenaufnahme aus einem lokalen Data Historian

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 Data Historian 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 lokaler 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 sein. Diese Geräte sind jedoch in der Regel 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, authentifiziert es sich über einen Dienstkontoschlüssel bei Pub/Sub. Der Schlüssel sendet die aggregierten und transformierten Daten zur weiteren Verarbeitung an die Cloud-Anwendung. Die Anzahl der verbundenen Gateways liegt in der Regel auch im Bereich von Dutzenden bis Hunderten von Geräten. Dies liegt innerhalb des typischen Bereichs für die Dienstkontoauthentifizierung.

Nächste Schritte