Connessione del dispositivo a Pub/Sub a Google Cloud

Anziché implementare un'architettura specifica per connettere i dispositivi alle applicazioni di analisi, alcune organizzazioni potrebbero trarre vantaggio dalla connessione diretta a Pub/Sub dai dispositivi edge. Consigliamo questo approccio alle organizzazioni con un numero ridotto di dispositivi connessi che aggregano i dati da 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 descrive le considerazioni architetturali 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:

Architettura

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

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

Il flusso di eventi nel diagramma precedente è il seguente:

  • Utilizzi 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 dati da 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 architettoniche

Poiché Pub/Sub è un servizio di streaming di dati serverless, puoi utilizzarlo per creare sistemi bidirezionali composti da produttori e consumer di eventi (noti come publisher e sottoscrittori). In alcuni scenari di dispositivi connessi, è necessario solo un servizio di pubblicazione e sottoscrizione scalabile per creare un'architettura dei 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 hanno il supporto integrato per le API REST, quindi la connessione con l'API REST Pub/Sub è spesso la soluzione più semplice. In alcuni casi d'uso, 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 alle applicazioni a bassa larghezza di banda che si trovano comunemente nei casi d'uso dei dispositivi connessi. Le connessioni API gRPC sono anche 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 diversi 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 temporanei per i dispositivi connessi. Puoi anche concedere ruoli IAM ai tuoi dispositivi connessi, senza il sovraccarico di gestione e sicurezza dell'utilizzo delle chiavi deaccount di serviziont.

Nei casi in cui un provider di identità esterno non è disponibile, le chiavi account di servizio sono l'unica opzione per l'autenticazione. Le chiavi dei service account possono diventare un rischio per la sicurezza se non vengono gestite correttamente, pertanto ti consigliamo di seguire le best practice per la sicurezza per il deployment delle chiavi deaccount di serviziont sui dispositivi connessi. Per saperne di più, consulta Best practice per la gestione delle chiavi degli account di servizio. I service account sono anche una risorsa limitata e qualsiasi progetto cloud ha una quota limitata di service account gestiti dall'utente. Di conseguenza, questo approccio è un'opzione solo per implementazioni con un numero ridotto di dispositivi da connettere.

Applicazioni di backend

Una volta inseriti in un argomento Pub/Sub, i dati sono disponibili per qualsiasi applicazione in esecuzione su Google Cloud che disponga 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 resi disponibili a più applicazioni nell'infrastruttura di backend per l'elaborazione o gli avvisi paralleli, nonché per l'archiviazione dei dati ad accesso sporadico e altre analisi.

Casi d'uso

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

Importazione collettiva di dati da un data historian on-premise

Una connessione da dispositivo a Pub/Sub è più adatta alle applicazioni che hanno un numero ridotto di endpoint che trasmettono grandi volumi di dati. Un historian dei dati operativi è un buon esempio di un 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 rientra nei parametri tipici per l'autenticazione dell'account di servizio. Questi sistemi hanno in genere anche architetture modulari, che ti consentono di implementare la connessione API Pub/Sub 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 a una connessione Pub/Sub diretta. In questo caso, un sistema locale di gestione e aggregazione dei dati viene implementato su un dispositivo gateway in fabbrica. Questo sistema è in genere un prodotto software che si connette a un'ampia varietà di sensori e macchine locali. Il prodotto raccoglie i dati e li trasforma spesso in una rappresentazione standardizzata prima di passarli all'applicazione cloud.

In questo scenario è possibile connettere molti dispositivi. Tuttavia, questi dispositivi sono in genere connessi solo al gateway locale e vengono gestiti dal software sul dispositivo, quindi non è necessaria un'applicazione di gestione basata sul 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, esegue l'autenticazione con Pub/Sub tramite una chiave delaccount di serviziot. La chiave invia i dati aggregati e trasformati all'applicazione cloud per un'ulteriore elaborazione. Il numero di gateway connessi è in genere compreso tra decine e centinaia di dispositivi, che rientra nell'intervallo tipico per l'autenticazione del account di servizio.

Passaggi successivi