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

Anstatt eine bestimmte Architektur zum Verbinden von Geräten mit Analyseanwendungen zu implementieren, kann es für einige Organisationen von Vorteil sein, eine direkte Verbindung zu Pub/Sub von Edge-Geräten aus 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 wie einer Fabrik hat. 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 auf Google Cloudenthalten. 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 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, die sich in einem sicheren lokalen Netzwerk befinden. 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 ü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 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 Cloudtreffen müssen.

Aufnahmeendpunkte

Pub/Sub bietet vorgefertigte 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. Laut einer Studie ist gRPC bis zu siebenmal schneller als REST. Daher ist gRPC in vielen Szenarien mit verbundenen Geräten eine bessere Option, wenn ein gRPC-Connector verfügbar ist oder für die Anwendung mit verbundenen Geräten 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 auch eine begrenzte Ressource und für jedes Cloud-Projekt gilt ein begrenztes Kontingent für vom Nutzer verwaltete Dienstkonten. Daher ist dieser Ansatz nur für Bereitstellungen mit einer geringen Anzahl von Geräten geeignet, die verbunden werden müssen.

Back-End-Anwendungen

Nachdem Daten in ein Pub/Sub-Thema aufgenommen wurden, sind sie für jede Anwendung verfügbar, die auf Google Cloud ausgeführt wird und die entsprechenden Anmeldedaten und Zugriffsberechtigungen hat. Außer der Pub/Sub API in Ihrer Anwendung sind keine zusätzlichen Connectors erforderlich. Nachrichten können mehreren Anwendungen in Ihrer Backend-Infrastruktur zur parallelen Verarbeitung oder Benachrichtigung sowie zur Archivierung und für 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 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 anGoogle 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 Cloudzu 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 mit einer Vielzahl von lokalen Sensoren und Maschinen verbunden ist. 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 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 Cloudherstellt, authentifiziert es sich mit Pub/Sub über einen Dienstkontoschlüssel. Über den Schlüssel werden die aggregierten und transformierten Daten zur weiteren Verarbeitung an die Cloudanwendung gesendet. Die Anzahl der verbundenen Gateways liegt in der Regel auch im Bereich von zehn bis hundert Geräten, was innerhalb des typischen Bereichs für die Dienstkontoauthentifizierung liegt.

Nächste Schritte