Connessione del dispositivo a Pub/Sub a Google Cloud

Last reviewed 2024-08-09 UTC

Anziché implementare un'architettura specifica per collegare i dispositivi alle applicazioni di analisi, alcune organizzazioni potrebbero trarre vantaggio dal collegamento diretto a Pub/Sub dai dispositivi edge. Consigliamo questo approccio per le organizzazioni con un numero limitato di dispositivi connessi che aggregano i dati di un numero maggiore di dispositivi e sensori in una rete locale o on-premise. Questo approccio è consigliato anche quando la tua organizzazione dispone di dispositivi connessi che si trovano in un ambiente più sicuro, ad esempio una fabbrica. Questo documento illustra le considerazioni di architettura di alto livello che devi fare per utilizzare questo approccio per connettere i dispositivi ai Google Cloud prodotti.

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 quanto segue:

Architettura

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

Dispositivo di aggregazione o architettura gateway collegata a Pub/Sub (il flusso di eventi è spiegato nel testo che segue).

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 memorizzarla nel dispositivo gateway in modo che possa essere utilizzata per l'autenticazione.
  • Il dispositivo di aggregazione raccoglie i dati di più dispositivi e sensori remoti situati all'interno di una rete locale sicura. I dispositivi remoti comunicano con il gateway utilizzando un protocollo edge 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 del account di servizio memorizzata sul dispositivo di aggregazione.

Considerazioni e scelte sull'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). In alcuni scenari di dispositivi connessi a internet, è sufficiente un servizio di pubblicazione e sottoscrizione scalabile per creare un'architettura di dati efficace. Le sezioni seguenti descrivono le considerazioni e le scelte che devi fare quando implementi un dispositivo nell'architettura Pub/Sub su Google Cloud.

Endpoint di importazione

Pub/Sub fornisce librerie client predefinite in più lingue che implementano le API REST e gRPC. Supporta due protocolli per l'importazione dei messaggi: REST (HTTP) e gRPC. Affinché un dispositivo connesso possa inviare e ricevere dati tramite Pub/Sub, deve essere in grado di interagire con uno di questi endpoint.

Molte applicazioni software supportano 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 una serie di metodi di autenticazione per l'accesso dall'esterno 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 ruoli IAM ai tuoi dispositivi connessi, senza il sovraccarico di gestione e sicurezza derivante dall'utilizzo delle chiavi degli account di servizio.

Se non è disponibile un provider di identità esterno, le chiavi dell'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 scoprire di più, consulta le best practice per la gestione delle chiavi degli account di servizio. Gli account di servizio sono anche una risorsa limitata e qualsiasi progetto cloud ha una quota limitata 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 l'importazione in un argomento Pub/Sub, i dati sono disponibili per qualsiasi applicazione in esecuzione su Google Cloud che dispone delle credenziali e dei privilegi di accesso appropriati. Non sono necessari connettori aggiuntivi oltre 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 archiviazione dei dati ad accesso sporadico e altri dati.

Casi d'uso

Le sezioni seguenti descrivono scenari di esempio in cui una connessione diretta dai dispositivi a Pub/Sub è adatta per i casi d'uso dei dispositivi connessi.

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 analisi 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 autenticare un numero ridotto di endpoint, in genere da uno a pochi dispositivi connessi, che rientrano nei parametri tipici per l'autenticazione dell'account di servizio. Inoltre, questi sistemi hanno spesso architetture modulari, che ti consentono di implementare la connessione all'API Pub/Sub di cui hai bisogno per comunicare 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. In genere, questo sistema è un prodotto software che si connette a una vasta gamma 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. A differenza di un'architettura di broker MQTT, in questo caso d'uso il gateway svolge un ruolo attivo nell'aggregazione e nella trasformazione dei dati.

Quando il gateway si connette a Google Cloud, si autentica con Pub/Sub tramite una chiave dell'account di servizio. La chiave invia i dati aggregati e trasformati all'applicazione cloud per ulteriori elaborazioni. Anche il numero di gateway connessi in genere varia da decine a centinaia di dispositivi, che rientra nell'intervallo tipico per l'autenticazione dei service account.

Passaggi successivi