Architettura del broker MQTT autonomo su Google Cloud

Last reviewed 2024-08-09 UTC

MQTT è un protocollo standard OASIS per le applicazioni per dispositivi connessi che fornisce la messaggistica bidirezionale utilizzando un'architettura di broker di pubblicazione e sottoscrizione. Il protocollo MQTT è leggero per ridurre il sovraccarico della 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 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 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 di base in un deployment MQTT, su Google Cloud. Inoltre, descrive le decisioni che devi prendere durante 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 quanto segue:

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

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

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

  • Il broker MQTT viene distribuito come cluster di tre istanze collegate al servizio Cloud Load Balancing. Per il bilanciatore del carico cloud, puoi scegliere tra uno dei diversi prodotti di bilanciamento del carico descritti più avanti in questo documento.
  • Il cluster del 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, i gateway di edge forniscono la comunicazione bidirezionale tra i dispositivi di edge e il cluster del broker MQTT tramite MQTT su TLS.

In genere, consigliamo di implementare l'applicazione di broker MQTT per questa architettura in un cluster per la scalabilità. 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 vengono affrontati dalle implementazioni specifiche del broker.

Considerazioni e scelte sull'architettura

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

Dispositivi connessi

I dispositivi edge connessi a internet pubblicano i propri eventi di telemetria e altre informazioni al broker MQTT. Per implementare l'architettura del broker MQTT autonomo 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 edge in genere hanno connettori per sensori locali, sistemi di dati on-premise e altri dispositivi che non dispongono di accesso a internet o connettività IP. Ad esempio, il dispositivo edge può fungere da gateway per altri dispositivi con limitazioni locali collegati al gateway tramite BLE, una connessione con cavo o un altro protocollo a corto raggio. 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 del broker MQTT. Questo servizio fornisce diverse importanti funzioni di networking, tra cui la distribuzione delle connessioni in arrivo tra i 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, tieni presente quanto segue:

  • mTLS. mTLS gestisce sia la crittografia sia i metodi 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 Google Cloud bilanciatori del carico.

Strategia di bilanciamento del carico

Qualsiasi servizio di bilanciamento del carico distribuisce le connessioni dai dispositivi edge ai nodi del cluster in base a uno di diversi algoritmi o modalità di bilanciamento. Per MQTT, una strategia di bilanciamento del carico basata sull'affinità sessione è migliore del 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 scollega e poi si ricollega a un altro nodo, 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'affinità di sessione è migliore per MQTT. L'affinità delle sessioni è disponibile in tutti i prodotti Cloud Load Balancing.

Autenticazione del dispositivo e gestione delle credenziali

Le applicazioni di broker MQTT gestiscono l'autenticazione e il controllo di accesso dei dispositivi distintamente da Google Cloud. Un'applicazione broker fornisce anche il proprio armadietto delle credenziali e la propria interfaccia di gestione. Il protocollo MQTT supporta l'autenticazione di base con nome utente e password nel pacchetto di connessione iniziale e questi campi vengono spesso utilizzati 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 metodi di autenticazione avanzati che utilizzano l'autenticazione con 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 gestisce un archivio delle credenziali del dispositivo. Questo archivio può trovarsi in un database SQL locale o in un file piatto. Alcuni broker supportano anche l'utilizzo di un servizio di database gestito come Cloud SQL. È necessario un servizio distinto per gestire il repository delle credenziali del dispositivo e gestire eventuali integrazioni con altri servizi di autenticazione come IAM. Lo sviluppo di questo servizio esula dall'ambito di questa guida.

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

Carichi di lavoro di backend

Qualsiasi caso d'uso relativo ai 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 di 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 degli argomenti del broker per distinguere i dati dai comandi.

I dati e i comandi possono essere inviati tra il broker e le applicazioni di backend in uno di diversi modi. Se l'applicazione stessa supporta MQTT o se può essere modificata per supportarlo, 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, 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 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 per i casi d'uso dei dispositivi descritti nelle sezioni seguenti.

Importazione di dati basata su standard da dispositivi eterogenei

Quando vuoi raccogliere e analizzare i dati di un parco di dispositivi eterogenei di grandi dimensioni, un broker MQTT è spesso una buona soluzione. Poiché MQTT è uno standard ampiamente adottato e implementato, molti dispositivi perimetrali ne supportano la funzionalità integrata e sono disponibili client MQTT leggeri per aggiungere il supporto MQTT ai dispositivi che non lo supportano. Il paradigma publish-and-subscribe fa parte anche dello standard MQTT, pertanto i dispositivi compatibili con MQTT possono sfruttare questa architettura senza ulteriori interventi di implementazione. I dispositivi che si connettono a Pub/Sub, invece, devono implementare l'API Pub/Sub o utilizzare l'SDK Pub/Sub. L'esecuzione di un broker MQTT conforme agli standard suGoogle Cloud fornisce quindi una soluzione semplice per raccogliere i dati da una vasta gamma di dispositivi.

Quando 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 stesso sarebbe 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 dal dispositivo al cloud.

Comunicazione bidirezionale per l'integrazione di applicazioni multiparti

La funzionalità di messaggistica bidirezionale di MQTT lo rende molto adatto per un caso d'uso di applicazioni mobile multiparti come la consegna di cibo on demand o un'applicazione di chat web su larga scala. MQTT ha un overhead del protocollo ridotto e i client MQTT hanno richieste di risorse ridotte. MQTT offre anche il routing Pubblichi e Abbonati, più livelli di qualità del servizio (QoS), conservazione dei messaggi integrata e un ampio supporto del protocollo. 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 da bordo a cloud

Grazie alla standardizzazione e al basso overhead offerti da MQTT, può essere anche una buona soluzione per integrare applicazioni di messaggistica on-premise e basate su cloud. Ad esempio, un operatore di una fabbrica può implementare più broker MQTT nell'ambiente on-premise per connettersi a sensori, macchine, gateway e altri dispositivi dietro il firewall. Il broker MQTT locale può gestire tutti i messaggi di telemetria e di controllo e comando bidirezionali per l'infrastruttura on-premise. Il broker locale può anche essere collegato tramite abbonamento 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