Architettura autonoma del broker MQTT su Google Cloud

MQTT è un protocollo standard OASIS per le applicazioni dei dispositivi connessi che fornisce messaggistica bidirezionale utilizzando un'architettura di broker "publish-and-subscribe". Il protocollo MQTT è leggero per ridurre il sovraccarico di rete, mentre i client MQTT sono molto piccoli per ridurre al minimo l'uso di risorse su dispositivi vincolati. Una soluzione per le organizzazioni che vogliono supportare le applicazioni per dispositivi connessi su Google Cloud è eseguire un broker MQTT autonomo su Compute Engine o GKE. Per eseguire il deployment di un broker MQTT nella tua organizzazione, devi prendere diverse decisioni chiave che influenzano l'architettura complessiva, in particolare il bilanciamento del carico e l'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 e sulla migrazione da IoT Core. 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 che segue).

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

  • Il deployment del broker MQTT viene eseguito come cluster di tre istanze connesse al servizio Cloud Load Balancing. Per il bilanciatore del carico cloud, puoi scegliere da uno dei diversi prodotti di bilanciamento del carico descritti più avanti in questo documento.
  • Il cluster dell'intermediario include un archivio di credenziali del dispositivo e un servizio di autenticazione e autorizzazione del dispositivo. Il cluster si connette ai carichi di lavoro di backend tramite Dataflow o Pub/Sub.
  • Sul lato client, i gateway perimetrali forniscono una comunicazione bidirezionale tra dispositivi periferici e il cluster di broker MQTT tramite MQTT su TLS.

In genere, per la scalabilità, si consiglia di eseguire il deployment dell'applicazione broker MQTT per questa architettura in un cluster. Fattori come la funzionalità di clustering, la gestione dei cluster di scale up e scale down, la sincronizzazione dei dati e la gestione delle partizioni di rete sono gestiti dalle implementazioni del broker specifiche (come HiveMQ, EMQX, VerneMQ, zanzara e altre).

Considerazioni e scelte sull'architettura

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

Dispositivi connessi

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

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

Bilanciamento del carico

Nell'architettura viene configurato un servizio di bilanciamento del carico esterno 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 nei nodi di backend, la crittografia delle sessioni 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 la crittografia sia i metodi di autenticazione dei dispositivi, mentre il protocollo TLS standard gestisce solo la crittografia e richiede un metodo di autenticazione del dispositivo separato:

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

Per ulteriori informazioni sui tipi di bilanciatori del carico supportati da Cloud Load Balancing, vedi Riepilogo dei bilanciatori del carico Google Cloud.

Strategia di bilanciamento del carico

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

Autenticazione del dispositivo e gestione delle credenziali

Le applicazioni di broker MQTT gestiscono l'autenticazione dei dispositivi e controllo dell'accesso separatamente da Google Cloud. Un'applicazione broker fornisce anche il proprio archivio credenziale e la propria interfaccia di gestione. Il protocollo MQTT supporta l'autenticazione tramite nome utente e password di base nel pacchetto Connect iniziale e questi campi vengono utilizzati spesso anche dalle implementazioni del broker per supportare altre forme di autenticazione come il certificato X.509 o l'autenticazione JWT. MQTT 5.0 aggiunge inoltre il supporto per i metodi di autenticazione avanzati che utilizzano l'autenticazione di tipo verifica 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 mantiene un archivio di credenziali del dispositivo. Può trovarsi in un database SQL locale o in un file flat. Anche alcuni broker, tra cui HiveMQ e VerneMQ, supportano l'utilizzo di un servizio di database gestito come Cloud SQL. È necessario un servizio separato per gestire l'archivio delle credenziali del dispositivo e gestire eventuali integrazioni con altri servizi di autenticazione, ad esempio IAM. Lo sviluppo di questo servizio non rientra nell'ambito di questa guida.

Per ulteriori informazioni sull'autenticazione e sulla gestione delle credenziali, consulta le best practice per l'esecuzione di un backend IoT su Google Cloud.

Carichi di lavoro di backend

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

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

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

Casi d'uso

L'architettura di un broker MQTT è particolarmente adatta per i casi d'uso dei dispositivi descritti nelle sezioni seguenti.

Importazione dati basata su standard da dispositivi eterogenei

Un broker MQTT rappresenta spesso una buona soluzione quando vuoi raccogliere e analizzare dati da un ampio parco dispositivi eterogenei. MQTT è uno standard ampiamente adottato e implementato, pertanto molti dispositivi periferici lo supportano integrato e sono disponibili client MQTT leggeri per aggiungere il supporto MQTT ai dispositivi che non lo supportano. Anche il paradigma di pubblicazione e sottoscrizione fa parte dello standard MQTT, pertanto i dispositivi abilitati per MQTT possono sfruttare questa architettura senza ulteriori operazioni 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 offre quindi una soluzione semplice per la raccolta di dati da un'ampia gamma di dispositivi.

Se i 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 stessa sarebbe di responsabilità dell'altra parte. In questo caso, ti consigliamo di eseguire un broker MQTT e di fornire le credenziali di autenticazione alla terza parte per configurare il canale di comunicazione tra dispositivi.

Comunicazione bidirezionale per l'integrazione di applicazioni multi-parti

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

Messaggistica integrata edge-to-cloud

A causa della standardizzazione e del basso overhead offerto da MQTT, può anche rappresentare una buona soluzione per integrare 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 protetti dal firewall. Il broker MQTT locale può gestire tutti i messaggi bidirezionali di comando e controllo e di telemetria per l'infrastruttura on-premise. Il broker locale può anche essere connesso tramite abbonamento bidirezionale a un cluster di broker MQTT parallelo nel cloud, consentendo la comunicazione tra il cloud e l'ambiente perimetrale senza esporre i dispositivi e i sistemi on-premise alla rete internet pubblica.

Passaggi successivi