Architettura del broker MQTT autonomo su Google Cloud

MQTT è un protocollo standard OASIS per applicazioni di dispositivi connessi che fornisce messaggistica bidirezionale utilizzando un'architettura di broker di pubblicazione e sottoscrizione. Il protocollo MQTT è leggero per ridurre l'overhead di rete e i client MQTT sono molto piccoli per ridurre al minimo l'utilizzo delle risorse sui dispositivi con limitazioni. Una soluzione per le organizzazioni che vogliono supportare applicazioni per dispositivi connessi su Google Cloud è eseguire un broker MQTT autonomo su Compute Engine o GKE. Per implementare un broker MQTT nella tua organizzazione, devi prendere diverse decisioni chiave che influiscono sull'architettura complessiva, in particolare sul bilanciamento del carico e sull'ambiente di deployment. Questo documento descrive un'architettura per il deployment di un broker MQTT, l'applicazione principale in un deployment MQTT, su Google Cloud. Descrive inoltre le decisioni che devi prendere quando esegui il deployment di questo broker e il loro impatto sull'architettura.

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:

Il seguente diagramma mostra un'architettura di broker MQTT in esecuzione su Google Cloud.

Diagramma dell'architettura del broker MQTT (spiegato nel testo seguente).

L'architettura nell'immagine precedente è composta come segue:

  • Il broker MQTT viene implementato come cluster di tre istanze connesse al servizio Cloud Load Balancing. Per il bilanciatore del carico cloud, puoi scegliere tra diversi prodotti di bilanciamento del carico, descritti più avanti in questo documento.
  • Il cluster broker include un archivio delle credenziali del dispositivo e un servizio di autenticazione e autorizzazione del dispositivo. Il cluster si connette ai workload di backend tramite Dataflow o Pub/Sub.
  • Sul lato client, gli edge gateway forniscono una comunicazione bidirezionale tra i dispositivi edge e il cluster di broker MQTT tramite MQTT su TLS.

In genere, consigliamo di implementare l'applicazione broker MQTT per questa architettura in un cluster per la scalabilità. Fattori come la funzionalità di clustering, la gestione dei cluster di scalabilità verticale e orizzontale, la sincronizzazione dei dati e la gestione delle partizioni di rete sono gestiti dalle implementazioni specifiche dei broker.

Considerazioni e scelte architettoniche

Le sezioni seguenti descrivono le diverse scelte e considerazioni architetturali che devi fare per un'architettura di broker MQTT autonomo e l'impatto che queste scelte hanno sull'architettura.

Dispositivi connessi

I dispositivi edge connessi a internet pubblicano i propri eventi di telemetria e altre informazioni nel broker MQTT. Per implementare l'architettura del broker MQTT autonomo descritta in questo documento, il dispositivo deve disporre di un client MQTT, della chiave pubblica del certificato del server per l'autenticazione TLS e delle credenziali necessarie per l'autenticazione con il broker MQTT.

Inoltre, i dispositivi edge in genere dispongono di connettori per sensori locali, per sistemi di dati on-premise e per altri dispositivi che non hanno accesso a internet o connettività IP. Ad esempio, il dispositivo edge può fungere da gateway per altri dispositivi locali con limitazioni connessi al gateway tramite BLE, a una connessione cablata o a un altro protocollo near-field. Una specifica dettagliata dell'architettura del dispositivo connesso non rientra nell'ambito di questa guida.

Bilanciamento del carico

Nell'architettura, un servizio di bilanciamento del carico esterno è configurato tra la rete pubblica e il cluster di broker MQTT. Questo servizio fornisce diverse funzioni di networking importanti, tra cui la distribuzione delle connessioni in entrata tra i nodi di backend, la crittografia della sessione e l'autenticazione.

Google Cloud supporta diversi tipi di bilanciatori del carico. Per scegliere il bilanciatore del carico migliore per la tua architettura, considera quanto segue:

  • mTLS. mTLS gestisce sia i metodi di crittografia sia quelli di autenticazione del dispositivo, mentre TLS standard gestisce solo la crittografia e richiede un metodo di autenticazione del dispositivo separato:

  • Endpoint HTTP(S). Se devi esporre endpoint HTTP(S), ti consigliamo di configurare un bilanciatore del carico delle applicazioni esterno separato per questi endpoint.

Per saperne di più sui tipi di bilanciatori del carico supportati da Cloud Load Balancing, consulta Riepilogo dei bilanciatori del carico. Google Cloud

Strategia di bilanciamento del carico

Qualsiasi servizio di bilanciamento del carico distribuisce le connessioni dai dispositivi perimetrali tra i nodi del cluster in base a uno dei diversi algoritmi o modalità di bilanciamento. Per MQTT, una strategia di bilanciamento del carico con affinità sessione è migliore del bilanciamento del carico casuale. Poiché le connessioni client-server MQTT sono sessioni bidirezionali persistenti, lo stato viene mantenuto sul nodo broker che interrompe la connessione. In una configurazione in cluster, se un client si disconnette e poi si riconnette a un nodo diverso, lo stato della sessione viene spostato nel nuovo nodo, il che aumenta il carico sul cluster. Questo problema può essere evitato in gran parte utilizzando il bilanciamento del carico con affinità sessione. Se i client cambiano spesso i propri indirizzi IP, la connessione può interrompersi, ma nella maggior parte dei casi l&#39affinità sessionee è migliore per MQTT. L'affinità di sessione è disponibile in tutti i prodotti Cloud Load Balancing.

Autenticazione del dispositivo e gestione delle credenziali

Le applicazioni broker MQTT gestiscono l'autenticazione dei dispositivi e il controllo dell'accesso separatamente da Google Cloud. Un'applicazione broker fornisce anche un proprio archivio delle credenziali e un'interfaccia di gestione. Il protocollo MQTT supporta l'autenticazione di base con nome utente e password nel pacchetto Connect iniziale e questi campi vengono spesso utilizzati anche dalle implementazioni del broker per supportare altre forme di autenticazione, come l'autenticazione JWT o con certificato X.509. MQTT 5.0 aggiunge anche il supporto per metodi di autenticazione avanzati che utilizzano l'autenticazione in stile richiesta e risposta. Il metodo di autenticazione utilizzato dipende dalla scelta dell'applicazione broker MQTT e dal caso d'uso del dispositivo connesso.

Indipendentemente dal metodo di autenticazione utilizzato, il broker gestisce un archivio delle credenziali del dispositivo. Questo archivio può trovarsi in un database SQL locale o in un file flat. Alcuni broker supportano anche l'utilizzo di un servizio di database gestito come Cloud SQL. Per gestire l'archivio delle credenziali del dispositivo e gestire le integrazioni con altri servizi di autenticazione come IAM, è necessario un servizio separato. Lo sviluppo di questo servizio non rientra nell'ambito di questa guida.

Per saperne di più sull'autenticazione e sulla gestione delle credenziali, consulta Best practice per l'esecuzione di un backend IoT su Google Cloud.

Workload di backend

Qualsiasi caso d'uso di dispositivi connessi include una o più applicazioni di backend che utilizzano i dati importati dai dispositivi connessi. A volte, queste applicazioni devono anche inviare comandi e aggiornamenti della configurazione ai dispositivi. Nell'architettura del broker MQTT autonomo descritta in questo documento, i dati in entrata e i comandi in uscita vengono entrambi instradati tramite il broker MQTT. Esistono diversi argomenti all'interno della gerarchia di argomenti del broker per distinguere tra dati e comandi.

I dati e i comandi possono essere inviati tra il broker e le applicazioni di backend in uno dei diversi modi. Se l'applicazione stessa supporta MQTT o se può essere modificata per supportare MQTT, l'applicazione può abbonarsi direttamente al broker come client. Questo approccio ti consente di utilizzare la funzionalità di messaggistica bidirezionale MQTT Pub/Sub direttamente utilizzando la tua applicazione per ricevere dati e inviare comandi ai dispositivi connessi.

Se la tua applicazione non supporta MQTT, esistono diverse altre opzioni. Nell'architettura descritta in questo documento, Apache Beam fornisce un driver MQTT, che consente l'integrazione bidirezionale con Dataflow e altre implementazioni di Beam. Molti broker dispongono anche di funzionalità di plug-in che supportano l'integrazione con servizi come Google Pub/Sub. In genere si tratta di integrazioni unidirezionali per l'integrazione dei dati, anche se alcuni broker supportano l'integrazione bidirezionale.

Casi d'uso

Un'architettura di broker MQTT è particolarmente adatta ai casi d'uso dei dispositivi descritti nelle sezioni seguenti.

Importazione dati basata su standard da dispositivi eterogenei

Quando vuoi raccogliere e analizzare i dati di una vasta flotta di dispositivi eterogenei, un broker MQTT è spesso una buona soluzione. Poiché MQTT è uno standard ampiamente adottato e implementato, molti dispositivi perimetrali lo supportano in modo integrato e sono disponibili client MQTT leggeri per aggiungere il supporto MQTT ai dispositivi che non lo supportano. Il paradigma di pubblicazione e iscrizione fa parte anche dello standard MQTT, quindi i dispositivi abilitati a MQTT possono sfruttare questa architettura senza ulteriori interventi di implementazione. Al contrario, i dispositivi che si connettono a Pub/Sub devono implementare l'API Pub/Sub o utilizzare l'SDK Pub/Sub. L'esecuzione di un broker MQTT conforme agli standard su Google Cloud fornisce quindi una soluzione semplice per la raccolta di dati da una vasta gamma di dispositivi.

Quando i tuoi dispositivi connessi non sono controllati dalla tua applicazione, ma da una terza parte, potresti non avere accesso al software di sistema del dispositivo e la gestione del dispositivo stesso sarebbe responsabilità dell'altra parte. In questo caso, ti consigliamo di eseguire un broker MQTT e fornire le credenziali di autenticazione alla terza parte per configurare il canale di comunicazione da dispositivo a cloud.

Comunicazione bidirezionale per l'integrazione di applicazioni di più parti

La funzionalità di messaggistica bidirezionale di MQTT lo rende molto adatto a un caso d'uso di applicazioni mobile multiparte, come la consegna di cibo on demand o un'applicazione di chat web su larga scala. MQTT ha un basso overhead del protocollo e i client MQTT hanno basse richieste di risorse. MQTT offre anche routing di pubblicazione e iscrizione, più livelli di qualità del servizio (QoS), conservazione dei messaggi integrata e un ampio supporto dei protocolli. Un broker MQTT può essere il componente principale di una piattaforma di messaggistica scalabile per applicazioni di servizi on demand e casi d'uso simili.

Messaggistica integrata edge-to-cloud

Grazie alla standardizzazione e al basso overhead offerti da MQTT, può anche essere una buona soluzione per l'integrazione di applicazioni di messaggistica on-premise e basate su cloud. Ad esempio, un operatore di fabbrica può eseguire il deployment di più broker MQTT nell'ambiente on-premise per connettersi a sensori, macchine, gateway e altri dispositivi che si trovano dietro il firewall. Il broker MQTT locale può gestire tutti i messaggi di comando e controllo bidirezionali e di telemetria per l'infrastruttura on-premise. Il broker locale può anche essere connesso tramite sottoscrizione bidirezionale a un cluster di broker MQTT parallelo nel cloud, consentendo la comunicazione tra il cloud e l'ambiente edge senza esporre i dispositivi e i sistemi on-premise alla rete internet pubblica.

Passaggi successivi