Analisi e Benchmark dei Broker

In questa sottosezione viene presentata l’analisi svolta per la scelta di un Message Broker.

Nello specifico si ha la necessita di gestire una gran varietà di sensori diversi tra loro, che inviano grandi quantità di dati con una frequenza di 100-200 Hz al Middleware. Si vuole riu-scire a gestire il maggior numero di dispositivi collegati al Broker possibile garantendo buone prestazioni. Inoltre, non si vuole trascurare la compatibilità del Broker scelto con vari tipi di linguaggi di programmazione. Il Broker dovrebbe avere una memorizzazione persistente dei dati ed essere in grado di sopportare un alto volume di traffico e set di dati massicci.

Dovrebbe avere la capacità di dividere il traffico in parti separate e logiche, per esempio, i topic. Infine, il Broker dovrebbe avere un’affidabilità molto alta e una deliverability degli eventi.

Per una consultazione approfondita delle analisi svolte in merito ai vari Broker si rimanda ad documento integrale "Analisi_broker", presente negli allegati. Di seguito viene riportata una panoramica del Broker scelto: Eclipse Mosquitto.

Mosquitto è una soluzione molto popolare tra gli sviluppatori. È un protocollo leggero creato per progetti IoT. Si basa sul modello di publish/subscribe. Il Broker di messaggi è indipen-dente da altre applicazioni o librerie. È concesso in licenza con EPL/END, il che significa che è open source, inoltre fa parte della Fondazione Eclipse, è un fattore importante per molti progetti. Mosquitto ha più librerie in molte lingue, quindi è abbastanza versatile, il che significa che può essere facilmente adattato dagli sviluppatori a un progetto. Eclipse Mo-squitto fornisce un’implementazione server leggera del protocollo MQTT che è adatta a tutte le situazioni, dalle macchine a piena potenza alle macchine embedded e a bassa potenza.

I sensori e gli attuatori, che sono spesso le sorgenti e le destinazioni dei messaggi MQTT, possono essere molto piccoli e privi di potenza. Questo vale anche per le macchine em-bedded a cui sono collegati, che è dove Mosquitto potrebbe essere eseguito. Tipicamente, l’attuale implementazione di Mosquitto ha un eseguibile dell’ordine di 120kB che consuma circa 3MB di RAM con 1000 client connessi. Sono stati segnalati test di successo con 100.000 client connessi a velocità di messaggi modeste. Oltre ad accettare connessioni da applicazioni client MQTT, Mosquitto dispone di un bridge che gli consente di connettersi ad altri server MQTT, incluse altre istanze di Mosquitto. Ciò consente di costruire reti di server MQTT, passando messaggi MQTT da qualsiasi posizione della rete a qualsiasi altra, a se-conda della configurazione dei bridge. Attualmente Mosquitto non è multi thread. [10]

Il Benchmark prende in considerazione la maggior parte dei broker presentati e selezionati nella fase di analisi, in particolare quelli MQTT. Sono stati esclusi quelli per i quali non è sta-to possibile realizzare un’implementazione adeguata. Lo scopo di quessta-to lavoro è quello di identificare quale Broker si adatti in modo migliore alle esigenze che caratterizzano il proget-to, considerando soprattutto l’efficienza e le performance, nonché la facilità implementativa e di utilizzo.

I Broker selezionati per l’analisi nella prima fase sono:

• Apache Kafka

• HiveMQ

• EMQ

Degli 8 Broker selezionati in fase di analisi sopra riportati, il benchmark considera solo 6 di questi. Come precedentemente menzionato per quelli restanti non è stato possibile trovare un client Java adeguato e di conseguenza realizzarne un’implementazione. Oltre ad Apa-che Kafka (Apa-che per comunicare con MQTT deve appoggiarsi ad un broker a parte, come Mosquitto) e Orion Context Broker (per il quale l’unica possibilità di integrazione con Java è l’utilizzo di un framework client REST), sono stati presi in considerazione anche Mosca e JoramMQ, dei broker particolarmente validati dalla letteratura ma per i quali non è disponibi-le un client Java. I broker restanti, Mosquitto, Redis, RabbitMQ, ZeroMQ, HiveMQ ed EMQ, sono quelli che sono stati effettivamente implementati e comparati, come viene descritto nella sezione successiva.

Di questi solo alcuni sono dei Broker MQTT: Mosquitto, RabbitMQ, ZeroMQ, HiveMQ, EMQ;

mentre Redis è un database distribuito NoSQL in memoria con archiviazione chiave-valore, funziona bene con i server MQTT perché può fungere da Broker di messaggi. Il carico del server MQTT può essere spostato in gran parte su un cluster Redis in modo da ottenere una maggiore concorrenza.

L’idea alla base del programma è quella di realizzare l’implementazione di ogni singolo Bro-ker e di un modulo principale dal quale è possibile impostare quale broBro-ker utilizzare, ap-poggiandosi agli appositi connettori. L’implementazione dello specifico Broker è realizzata in un package dedicato, che comprende un gestore dei publisher e dei subscriber. Inoltre, per Mosquitto e per EMQ è stata realizzata una callback esterna, che viene implementata dal subscriber. Oltre che dal package principale i vari publisher e subscriber possono es-sere eseguiti anche indipendentemente, direttamente nella classe stessa. Nel file pom.xml sono state inserite le dipendenze per ogni client che sono state importate tramite Maven e utilizzate nei vari package. Per ogni Broker è stato utilizzato un server già esistente, senza realizzarne uno ad hoc. Dove possibile si è optato per un’implementazione asicrona, uti-lizzando a dipendenza del Broker la versione 3 o 5 di MQTT. Per i Broker MQTT (tranne che per ZeroMQ) è stata impostata anche la Quality of Service, come verrà illustrato nella prossima sezione. Per quanto concerne autenticazione e sicurezza, la maggior parte dei Broker permettono di impostare diverse opzioni, ma all’interno di questo lavoro si è deciso di omettere questi fattori.

All’interno del package principale sono presenti anche le interfacce che definiscono i metodi che publisher e subscriber devono implementare, unitamente ad una classe astratta che definisce la struttura dei vari gestori. Nello specifico i manager si occupano di istanziare e

gestire delle liste di publisher e subscriber, chiamando i metodi delle rispettive classi. Questi gestori sono istanziati all’interno del package principale rispettivamente per publisher e sub-scriber, sulla base del Broker che si intende usare. È qui che è possibile specificare anche quanti elementi istanziare, assieme ai topic e messaggi da inviare. Inoltre, per garantire il corretto funzionamento del programma, bisogna installare e avviare sulla macchina i client di Mosquitto, RabbitMQ e Redis; oltre che importare le dipendenze specificate nel pom. Per ZeroMQ è stato utilizzato il paradigma publish-subscribe.

Una volta implementato il programma sono stati svolti dei test di esecuzione, considerando la durata di quest’ultima e il numero di messaggi correttamente consegnati. I valori mostrati nelle tabelle seguenti sono una media di varie esecuzioni. Tranne che in Redis e ZeroMQ, sono stati cambiati nelle varie esecuzioni i parametri di Quality of Service, oltre che dei messaggi e del numero di publisher e subscriber coinvolti, per vedere come questi fattori influenzano l’esecuzione. Nei casi in cui non è stato possibile impostare la QoS i risultati sono stati riportati nella colonna QoS=0, mentre le celle inutilizzate sono indicate con uno sfondo grigio. Per semplicità è stato misurato il tempo di esecuzione del publisher principale con l’implementazione dei vari Broker, questo perché il subscriber principale rimane sempre in attesa. Non sarebbe stato semplice verificare il termine della ricezione, mentre il publi-sher, quando ha finito di pubblicare i messaggi, termina la sua esecuzione. Inoltre, i tempi non prendono in considerazione l’inizializzazione dei vari client, ma solo i tempi di invio. Gli stessi test sono stati svolti su gruppi di rispettivamente 10 publisher/subscriber, un nume-ro ristretto di test è stato effettuato anche con gruppi di 100 publisher/subscriber; i risultati sono riportati nelle tabelle seguenti. Per semplicità tutti i test sono stati svolti pubblicando e leggendo da un unico topic, ma dalle prove effettuate è emerso che anche coinvolgendo molteplici topic i risultati sono molto simili.

Tutti i test sono stati svolti sulla stessa macchina: un Asus Vivobook Pro con processore Intel Core i7-7700HQ 2.80GHz, 16 GB di RAM e sistema operativo Windows 10 Home. La versione di Java è la 11.0.2 LTS.

Un’importante premessa è che la colonna “Inviati” indica il numero totale di messaggi inviati (numero di messaggi per client*numero publisher), mentre le colonne “Ricevuti” indicano il numero totale di messaggi ricevuti, che sarà ulteriormente moltiplicato per il numero di subscriber, essendo tutti registrati allo stesso topic. Esempio: 10 messaggi per publisher, 10 publisher, 10 subscriber. In un caso ottimale, Inviati=100, Ricevuti=1000. I tempi di esecuzione estremamente lunghi (oltre i 10 minuti) sono in arancione.

Figura 3.3: Test con 10 publisher/subscriber

Figura 3.4: Test con 100 publisher/subscriber

* L’implementazione del Broker è bloccante, pertanto i messaggi ricevuti si riferiscono ad un unico subscriber. Si può stimare il numero totale moltiplicando per i subscriber.

Ciò che emerge dai risultati del benchmark, visibili nelle Figure 3.3 e 3.4, è che i migliori Broker MQTT sono, in ordine, Mosquitto e RabbitMQ. Redis invece è la soluzione migliore in assoluto, pur non essendo MQTT.

• EMQ: pur essendo semplice a livello implementativo, le performance non sono delle migliori, e fatica molto specie con tanti publisher/subscriber.

• HiveMQ: uno dei Broker più complessi a livello implementativo, questo perché è possi-bile sviluppare diversi tipi di client (sincroni, asincroni, bloccanti, paralleli). Nonostante sia molto completo, le performance non sono ottimali, seppur migliori di quelle di EMQ.

• Mosquitto: si è dimostrato essere il migliore come performance fra i Broker MQTT ed è caratterizzato da un’implementazione abbastanza semplice.

• RabbitMQ: è la seconda scelta fra i Broker MQTT, ed ha un’implementazione un po’

più complessa di quella di Mosquitto.

• Redis: pur non essendo prettamente un message Broker ma bensì un database di-stribuito NoSQL in memoria con archiviazione chiave-valore, sì è dimostrato essere il migliore come performance, ed è una valida alternativa ad un Broker MQTT. L’unico problema potrebbe essere che, trattandosi di un database in memoria, potrebbe non inserirsi correttamente all’interno dell’architettura del progetto.

• ZeroMQ: potrebbe avere molto potenziale, ma adottando il paradigma publish sub-scribe non risulta particolarmente ottimale nell’utilizzo, sia come implementazione che come performance in ricezione, mentre quelle di invio sono estremamente buone. Un altro punto a suo sfavore è che solo un publisher può essere bindato ad uno specifico indirizzo, e non esiste il concetto di topic, che rimane implicito all’interno del messag-gio (la categoria di appartenenza di un messagmessag-gio viene stabilita dalla prima parola di quest’ultimo).

Non c’è da escludere che le performance dei vari Broker siano state influenzate dall’imple-mentazione specifica adottata in questo Benchmark e che questi ultimi potrebbero perfor-mare in maniera migliore, nonostante siano state seguite diverse guide e documentazioni per ogni soluzione, cercando di realizzare quella più valida e consolidata. La grossa utilità del benchmark realizzato è che, oltre ad aver permesso di selezionare i Broker migliori, ha permesso di comprenderne anche l’implementazione, facilitando il compito di integrazione del Broker all’interno dell’architettura più avanti nel progetto.

Per ulteriori informazioni in merito al Benchmark si rimanda al documento "Benchmark_broker"

presente negli allegati.