Connessione del dispositivo a Pub/Sub a Google Cloud

Last reviewed 2024-08-09 UTC

Anziché implementare un'architettura specifica per connettere i dispositivi all'analisi applicazioni, alcune organizzazioni potrebbero trarre vantaggio dalla connessione diretta in Pub/Sub dai dispositivi periferici. Consigliamo questo approccio organizzazioni con un numero limitato di dispositivi connessi che aggregano dati da un numero maggiore di dispositivi e sensori in una rete locale o on-premise. Questo approccio è consigliato anche quando la tua organizzazione ha dispositivi connessi in un ambiente più sicuro, come una fabbrica. Questo documento illustra le considerazioni di architettura di alto livello che devi fare per utilizzare questo approccio per connettere i dispositivi ai prodotti Google Cloud.

Questo documento fa parte di una serie di documenti che forniscono informazioni sulle architetture IoT su Google Cloud. Gli altri documenti di questa serie includono seguenti:

Architettura

Il seguente diagramma mostra un gateway o un dispositivo di aggregazione connesso che si connette direttamente a Pub/Sub.

Architettura gateway o dispositivo di aggregazione connesso a Pub/Sub (flusso di eventi spiegato nel testo seguente).

Il flusso di eventi nel diagramma precedente è il seguente:

  • Utilizza l'API Identity and Access Management per creare una nuova coppia di chiavi per un account di servizio. La chiave pubblica è archiviata in IAM. Tuttavia, devi scaricare la chiave privata in modo sicuro e la archivi nel dispositivo gateway in modo che possa per l'autenticazione.
  • Il dispositivo di aggregazione raccoglie i dati da diversi altri dispositivi remoti e sensori situati all'interno di una rete locale protetta. I dispositivi remoti comunicare con il gateway utilizzando un protocollo perimetrale locale come MODBUS, BACNET, OPC-UA o un altro protocollo locale.
  • Il dispositivo di aggregazione invia i dati a Pub/Sub tramite HTTPS o gRPC. Queste chiamate API vengono firmate utilizzando la chiave privata dell'account di servizio memorizzata sul dispositivo di aggregazione.

Considerazioni e scelte dell'architettura

Poiché Pub/Sub è un servizio di streaming di dati serverless, puoi usarlo per creare sistemi bidirezionali composti da produttori e consumer di eventi (noti come publisher e sottoscrittori). Su un dispositivo connesso è sufficiente un servizio di pubblicazione e sottoscrizione scalabile per creare un'efficace architettura dei dati. Nelle sezioni seguenti vengono descritte le considerazioni e le scelte che devi fare quando implementi un dispositivo dell'architettura Pub/Sub su Google Cloud.

Endpoint di importazione

Pub/Sub offre modelli di ML librerie client in più linguaggi che implementano le API REST e gRPC. Supporta due protocolli per l'importazione dei messaggi: REST (HTTP) e gRPC. Per consentire a un dispositivo connesso di inviare e ricevere dati tramite Pub/Sub, il dispositivo deve essere in grado di interagire con uno di questi endpoint.

Molte applicazioni software hanno il supporto integrato per le API REST, quindi la connessione con l'API REST Pub/Sub è spesso la soluzione più semplice. In alcuni scenari di utilizzo, tuttavia, gRPC può essere un'alternativa più efficiente e veloce. Poiché utilizza buffer di protocollo serializzati per il payload del messaggio anziché JSON, XML o un altro formato basato su testo, gRPC è più adatto per le applicazioni a bassa larghezza di banda che si trovano comunemente nei casi d'uso dei dispositivi connessi a internet. Le connessioni API gRPC sono inoltre più veloci di REST per la trasmissione dei dati e gRPC supporta la comunicazione bidirezionale simultanea. Uno studio ha rilevato che gRPC è fino a sette volte più veloce di REST. Di conseguenza, per molti scenari di dispositivi connessi, gRPC è un'opzione migliore se è disponibile o può essere implementato un connettore gRPC per l'applicazione del dispositivo connesso.

Autenticazione del dispositivo e gestione delle credenziali

Pub/Sub supporta diverse metodi di autenticazione per l'accesso dall'esterno di Google Cloud.

Se la tua architettura include un provider di identità esterno come Active Directory o un cluster Kubernetes locale, puoi utilizzare la federazione delle identità per i carichi di lavoro per gestire l'accesso a Pub/Sub. Questo approccio ti consente di creare token di accesso di breve durata per i dispositivi connessi. Puoi anche concedere i ruoli IAM per i dispositivi connessi, senza le funzionalità di gestione dell'overhead per la sicurezza dovuto all'uso delle chiavi degli account di servizio.

Nei casi in cui non è disponibile un provider di identità esterno, l'account di servizio sono l'unica opzione per l'autenticazione. Le chiavi degli account di servizio possono rappresentare un rischio per la sicurezza se non vengono gestite correttamente, pertanto ti consigliamo di seguire le migliori pratiche di sicurezza per il deployment delle chiavi degli account di servizio sui dispositivi connessi. Per apprendere vedi altro Best practice per la gestione delle chiavi degli account di servizio. Anche gli account di servizio sono una risorsa limitata e qualsiasi progetto cloud ha un limite quota di account di servizio gestiti dall'utente. Di conseguenza, questo approccio è un'opzione solo per le implementazioni con un numero ridotto di dispositivi da collegare.

Applicazioni di backend

Dopo essere stati importati in un argomento Pub/Sub, i dati sono disponibili a qualsiasi applicazione eseguita su Google Cloud che abbia i le credenziali e i privilegi di accesso. Non sono necessari connettori aggiuntivi rispetto all'API Pub/Sub nella tua applicazione. I messaggi possono essere messi a disposizione di più applicazioni nell'infrastruttura di backend per l'elaborazione parallela o l'invio di avvisi, nonché per lo spazio di archiviazione di archivi e altri dati.

Casi d'uso

Le seguenti sezioni descrivono scenari di esempio in cui una connessione diretta dai dispositivi a Pub/Sub è ideale per l'uso di dispositivi connessi d'uso diversi.

Importazione collettiva dei dati da un Data Historian on-premise

Una connessione di un dispositivo a Pub/Sub è più adatta per le applicazioni con un numero ridotto di endpoint che trasmettono grandi volumi di dati. Un strumento di monitoraggio dei dati operativi è un buon esempio di sistema on-premise che archivia molti dati che devono essere trasmessi a Google Cloud. Per questo caso d’uso, è necessario un numero ridotto di endpoint autenticati, generalmente uno o pochi dispositivi connessi, che si trovano all'interno parametri tipici per l'autenticazione dell'account di servizio. Inoltre, questi sistemi hanno architetture modulari che consentono di implementare Connessione API necessaria per comunicare con Google Cloud.

Aggregazione dei dati del gateway locale per una fabbrica

L'aggregazione dei dati dei sensori di fabbrica in un gateway locale è un altro caso d'uso adatto per una connessione Pub/Sub diretta. In questo caso, un sistema di gestione e aggregazione dei dati locali viene implementato su un dispositivo gateway in fabbrica. Questo sistema è in genere un prodotto software che si collega una varietà di sensori e macchine locali. Il prodotto raccoglie i dati e spesso li trasforma in una rappresentazione standardizzata prima di trasmetterli all'applicazione cloud.

In questo scenario possono essere connessi molti dispositivi. Tuttavia, questi dispositivi sono solitamente collegati solo al gateway locale e sono gestiti dal software su quel dispositivo, quindi non è necessaria un'applicazione di gestione basata su cloud. Non mi piace in un'architettura di broker MQTT, in questo caso d'uso il gateway di aggregazione e trasformazione dei dati.

Quando il gateway si connette a Google Cloud, esegue l'autenticazione tramite una chiave dell'account di servizio. La chiave invia i dati aggregati e trasformati all'applicazione cloud per l'ulteriore elaborazione. La di gateway connessi è generalmente compreso tra decine e centinaia di dispositivi, che rientra nell'intervallo tipico per l'account di servizio autenticazione.

Passaggi successivi