Microscope : an agent for latency monitoring and topology inference in microservice deployments

In recent years, cloud services have started undergoing a significant shift in the design of user-facing applications, transitioning from monolithic architectures to an approach based on hundreds of loosely-coupled components, commonly referred to as microservices. Although these architectures allow companies to scale their application with more flexibility and to distribute the development across different teams, they also introduce complexity in the deployment and operations of production systems. Decomposing a monolithic architecture into a network of microservices brings in the intrinsic complexity of a distributed system. Tracking the evolution of the application topology over time becomes more difficult, and we might lose sight of the dependencies between the deployed microservices. At the same time, an invocation performed on a single microservice can trigger the execution of other microservices, complicating the identification of bottlenecks. Latency, in particular, is one of the most critical metrics to keep monitored in web-facing applications because it is used to measure the responsiveness perceived by users, which has a direct impact on the level of engagement with the application. Distributed tracing and service meshes are current solutions to these problems, but they either require modifications of the application source code or of the deployment infrastructure, which is not always feasible. Monitoring agents can be considered as an alternative solution, but they are not able to provide the same level of detail. In this thesis work we propose microscope, a monitoring platform that measures the latency distribution of HTTP calls in a microservice-based application and generates its topology graph at runtime. Both operations are performed without any previous knowledge about the application, and they are agnostic to the programming languages or application frameworks used to develop the microservices. microscope leverages an in-kernel HTTP tracer that analyzes the network traffic, correlates HTTP requests and responses, measures the latencies, and aggregates them in latency histograms. A user- space application then reads the histograms, exposes the latency metrics to external monitoring systems, and computes the topology graph. We evaluated our approach on different microservice-based applications in order to verify the accuracy of the measurements and the overhead imposed on the monitored application. Our tests showed that microscope was able to trace more than 92% of the requests sent by the microservice providing a misclassification error of the latency distribution that was below the 2%. Furthermore, our measurements provided a higher level of detail compared to the current monitoring agents available in the state of the art, without imposing a higher overhead on the monitored application.

Negli ultimi anni si è potuto osservare un cambiamento significativo nel design delle applicazioni cloud su larga scala, passando dalla tradizionale architettura monolitica a un approccio basato su centinaia di componenti disaccoppiati, comunemente chiamati microservizi. Da un lato, con l’approccio monolitico, gli sviluppatori organizzano l’applicazione come un unico elemento indivisibile, includendo tutte le funzionalità esposte in un’unica entità. Dall’altro, i microservizi permettono di dividere l’applicazione monolitica in molteplici servizi che possono essere sviluppati e rilasciati in modo indipendente. Le applicazioni sviluppate seguendo il paradigma a microservizi offrono maggiore flessibilità nel far scalare orizzontalmente le applicazioni quando si rivela necessario. Inoltre, permettono di distribuire su diversi gruppi di lavoro all’interno dell’azienda lo sviluppo, il rilascio e la manutenzione dei diversi componenti dell’applicativo. Un fattore che ha favorito il passaggio dal modello monolitico a quello basato su microservizi è stato lo sviluppo e la diffusione di tecnologie come Docker e Kubernetes, che permettono di creare e orchestrare applicazioni containerizzate. I container consentono agli sviluppatori di pacchettizzare in un unico ambiente indipendente l’applicativo e tutte le sue dipendenze, così che possano essere facilmente distribuiti e rilasciati sui diversi nodi fisici di un cluster. In aggiunta, gli orchestratori di container forniscono ulteriori funzionalità avanzate come la gestione dei segreti, il supporto alla scalabilità orizzontale, la possibilità di fare service discovery e la gestione del rilascio di nuove versioni dell’applicativo senza downtime. Un aspetto che sta diventando sempre più rilevante per le moderne applicazioni cloud native, è l’impatto che hanno i tempi di risposta nel determinare il livello di qualità dell’applicativo percepito dagli utenti. Sistemi con tempi di riposta più brevi risultano più fluidi da utilizzare per gli utenti e questo determina un vantaggio competitivo del prodotto cloud rispetto ai suoi concorrenti. Prove di questa affermazione possono essere trovate in alcune analisi fatte dal gruppo di ingegneri di Google che si occupa del servizio di ricerca web. Essi hanno verificato l’impatto dato da un maggiore tempo di risposta nelle ricerche, sul livello di utilizzo da parte degli utenti. I risultati dimostrano come il livello di interazione degli utenti con la piattaforma web diminuiva in modo proporzionale al ritardo nella risposta che veniva simulato. Dal test risultò anche che gli utenti che venivano esposti per più tempo all’esperimento, effettuavano via via sempre meno ricerche. Un altro elemento che ben rappresenta il fatto che la latenza sia percepita come una metrica chiave dalle aziende che offrono servizi web, è l’esistenza dell’indice APDEX. Questo indice è uno standard aperto, sviluppato da un consorzio di aziende, il cui scopo è la XIconversione di metriche applicative in un punteggio che valuta il livello di soddisfazione di un utente. Secondo i promulgatori di questo indice, la latenza è la metrica più importante per poter valutare il livello di performance dell’applicativo osservato dagli utenti. Quando le applicazioni venivano sviluppate seguendo l’approccio monolitico, la latenza poteva essere considerata più semplice da misurare perché veniva monitorata in un unico punto: l’istanza dell’applicativo che serviva la richiesta dell’utente. Con l’adozione dei microservizi, nonostante i numerosi benefici offerti da questo tipo di architettura, ci troviamo in una posizione più sfavorevole rispetto alla misurazione della latenza. L’applicazione in questo caso può essere considerata a tutti gli effetti come un sistema distribuito, dove una singola funzionalità logica, dal punto di vista dell’interazione di un utente, genera in realtà numerose richieste che vengono scambiate fra diversi microservizi. Non è più possibile quindi misurare la latenza in un unico punto ma piuttosto, dobbiamo misurare la latenza di tutte le richieste generate dalla singola interazione dell’utente. Un’altra caratteristica delle applicazioni a microservizi, è che sono formate da numerosi componenti eterogenei e fortemente disaccoppiati, il che complica notevolmente la topologia della rete. In un’applicazione a microservizi, è difficile determinare a priori la struttura che avrà l’intero sistema a regime. Il sistema sarà composto da molteplici tipi di servizi differenti, ognuno dei quali avrà soltanto una visione parziale dell’intero sistema, la cui topologia può cambiare nel corso dell’evoluzione dell’applicazione. Questi fattori portano alla nascita di un problema che si sta rivelando essere comune nelle architetture a microservizi più complesse utilizzate dai servizi cloud che operano su larga scala, e che viene chiamato il problema dell’architettura "Death Star". Durante la fase iniziale dello sviluppo di un applicativo a microservizi, la topologia è composta da un numero limitato di servizi, in cui sono chiare le dipendenze che si vengono a creare tra essi. Con il procedere dello sviluppo però, il numero di microservizi e delle interconnessioni fra essi aumenta esponenzialmente, dando origine a un’architettura sempre più complessa. La causa dell’insorgenza di questo problema risiede nel fatto che in un’applicazione a microservizi, ogni servizio dovrebbe servire a un unico scopo ed esporre un insieme limitato di funzionalità. Come conseguenza, quando vogliamo aggiungere nuove funzionalità all’applicazione, il più delle volte dobbiamo sviluppare e rilasciare nuovi microservizi. Inoltre, questi nuovi microservizi si baseranno sull’interazione con i microservizi esistenti, per fornire le funzionalità che esulano dallo scopo per cui sono stati creati. Tenere traccia delle catene di dipendenze che si vengono a creare in questo scenario diventa quindi un’operazione complessa, che richiede l’utilizzo di strumenti specializzati che permettano operazioni di analisi e drill-down di queste informazioni. Negli ultimi anni sono state presentate diverse soluzioni che affrontano il problema di monitorare i tempi di risposta dei microservizi, tenendo traccia al contempo delle dipendenze fra essi. Queste soluzioni possono essere classificate in due sottoinsiemi: i sistemi di tracing distribuito e le service mesh. Il tracing distribuito si basa sulla modifica del codice delle applicazioni affinché vengano inviate delle "tracce" durante la normale esecuzione, che descrivono come una transazione distribuita si sta muovendotra i vari componenti del sistema. Queste "tracce" vengono raccolte da un sistema centralizzato che permette di aggregarle e analizzarle. Le service mesh invece seguono un approccio diverso, basato sul dispiego di cosiddetti sidecar proxy che vengono eseguiti insieme ai microservizi. Questi proxy intercettano il traffico di rete scambiato fra i microservizi e lo utilizzano per generare delle metriche che, anche in questo caso, vengono raccolte da un sistema centralizzato per l’analisi. Lo svantaggio che osserviamo in queste soluzioni è che esse, per poter funzionare, richiedono che venga modificato il codice originale dell’applicativo o che vengano installati numerosi sidecar proxy, tanti quanti i microservizi che compongono l’applicazione. A causa di queste limitazioni, il loro utilizzo non è sempre possibile, specialmente per applicazioni che sono già operative in produzione. In questi contesti sarebbe utile poter disporre di uno strumento che riesca a misurare i tempi di risposta e ad inferire la topologia dei microservizi, senza richiedere alcuna modifica dell’applicativo o l’utilizzo di un elevato numero di componenti aggiuntivi. Inoltre, una volta ricreata la topologia dell’applicazione, essa potrebbe essere usata come strumento per visualizzare le dipendenze e al tempo stesso mostrare informazioni sui tempi di risposta dei singoli servizi. In questo modo, trovandosi di fronte a un problema di degradazione delle performance, si potrebbe individuare più rapidamente la causa scatenante del problema. In questo lavoro di tesi proponiamo microscope, una piattaforma per il monitoraggio progettata specificatamente per applicazioni a microservizi, che permette di misurare la distribuzione della latenza di ogni microservizio e di generare il grafo topologico dell’intera applicazione. La metodologia proposta permette di derivare queste informazioni da un’applicazione esistente senza nessun tipo di conoscenza pregressa circa l’architettura dell’applicazione e senza doverne modificare il codice. L’analisi viene effettuata a basso livello e si basa soltanto sul controllo del traffico di rete che viene generato dai microservizi nella loro normale operatività. La metodologia si basa su due componenti principali: un tracer HTTP che viene eseguito lato kernel e un programma eseguito in user-space. Il tracer HTTP è costituito da un programma eBPF gira in kernel-space e che si occupa di analizzare i pacchetti di rete, al fine di correlare le richieste HTTP ricevute da un microservizio, con le risposte che esso emette. Il risultato di questa correlazione permette di misurare la latenza di ogni chiamata HTTP. In seguito, queste informazioni vengono aggregate utilizzando degli istogrammi rappresentanti la distribuzione delle latenze, che vengono a loro volta condivisi con i componenti in user-space. L’applicazione lato user-space raccoglie le metriche di latenza calcolate del tracer e utilizza i loro metadati per generare la topologia dell’applicazione, esponendo sia essa, sia le metriche, a dei consumatori esterni. In aggiunta a questi due componenti vengono anche sfruttate le Application Programing Interface (API) messe a disposizione dall’orchestratore di container per decorare le informazioni di rete estratte dal tracer con metadati di più alto livello. Le metriche sulle latenze vengono salvate in un database a serie temporali per poter essere ispezionate e utilizzate per la generazione di dashboard. Infine, un database a grafo viene utilizzato per salvare la topologia e permetterne la visualizzazione e le successive operazioni di drill-down. Abbiamo valutato la metodologia proposta su diverse applicazioni a microservizi, messe in funzione utilizzando i container Docker e l’orchestratore Kubernetes, misurando sia l’accuratezza di microscope che il suo impatto sulle performance dell’applicazione monitorata. I risultati sperimentali mostrano che microscope è in grado di tracciare più del 92% delle chiamate HTTP effettuate dai microservizi, nelle diverse topologie che abbiamo simulato. Utilizzando un simulatore di latenze che rispondeva con dei tempi di risposta predicibili, abbiamo valutato l’accuratezza con cui microscope calcola la distribuzione della latenza, confrontato la distribuzione calcolata con quella attesa e misurandone l’errore di classificazione. I risultati mostrano che l’errore della nostra soluzione non supera generalmente il 2% e, in molti casi, si attesta a un livello molto inferiore allo 0.5%. Per misurare l’accuratezza nella generazione della topologia, abbiamo osservato quanto la topologia generata da microscope ben rappresentasse l’architettura, nota a priori, delle applicazioni a microservizi in esecuzione. Infine, abbiamo misurato l’overhead apportato da microscope sull’applicazione monitorata, confrontandolo con quello apportato dalle soluzioni presenti nello stato dell’arte. I risultati mostrano che l’overhead può essere considerato trascurabile essendo visibile solo oltre il 99-esimo percentile in una misura nell’ordine del singolo millisecondo. Il lavoro presentato nella nostra tesi verrà sviluppato come segue: • Il Capitolo 1 fornisce un’introduzione generale al lavoro; • Capitolo 2 dà una visione d’insieme sulla tendenza attuale a sviluppare applicazioni basate su microservizi, fornisce un’introduzione a eBPF, la tecnologia utilizzata per sviluppare la soluzione proposta e definisce il problema affrontato dal lavoro di tesi; • Capitolo 3 descrive lo stato dell’arte nel campo delle soluzioni per il monitoraggio dei microservizi; • Capitolo 4 descrive la metodologia di questo lavoro di tesi; • Capitolo 5 dettaglia l’implementazione di microscope; • Capitolo 6 presenta e discute i risultati sperimentali ottenuti; • Infine, Capitolo 7 riporta le conclusioni del lavoro, sottolineando i contributi e possibili lavori futuri.