Rally, dal benchmarking al miglioramento continuo

Mantenere un alto livello di qualità migliorando costantemente le offerte proposte richiede la capacità di definire e misurare questa qualità, individuarne le variazioni e condurre indagini in caso di degradazione.

Per raggiungere questo obiettivo abbiamo individuato in OpenStack (la soluzione su cui si basa il nostro servizio Public Cloud) due aspetti che ci sembrano fondamentali per la user experience:

  • l’utilizzo dell’API OpenStack con i client OpenStack, le librerie o l’API v6 di OVH
  • la garanzia delle performance sulle istanze (processore, RAM, disco, rete)

Questo articolo si concentra sul primo punto: come, in OVH, viene misurata l’efficienza delle API Public Cloud. Presentiamo la soluzione sviluppata e il modo in cui si integra nell’ecosistema di OVH, per concludere con un esempio concreto che dimostra il miglioramento fino al 75% dei tempi di risposta delle API.

Rally, lo strumento di benchmark di OpenStack orientato al cliente

Rally è un modulo del progetto OpenStack che può essere definito come una soluzione di Benchmarking as a Service. Permette di testare una piattaforma OpenStack dal punto di vista dell’utente e di estrarre le misurazioni dei tempi di esecuzione.

Il progetto, sviluppato in Python, è iniziato nel 2013. La versione 1.0.0 è stata rilasciata proprio lo scorso luglio. La decisione di utilizzarlo in OVH è stata relativamente semplice: da un lato, infatti, fa parte dell’ecosistema OpenStack e, dall’altro, include funzionalità che rispondono alle nostre esigenze.

Rally permette di eseguire scenari, un insieme di test sequenziali configurabili più o meno complessi. In questo modo è possibile, ad esempio, testare facilmente la creazione di un token di autenticazione e confermarne il corretto funzionamento. È inoltre possibile realizzare operazioni più complesse, come testare in un unico scenario l’autenticazione e la creazione di diverse istanze associandovi volumi. Questa flessibilità ci permette di concepire facilmente e senza limiti test molto specifici. Rally include nativamente una serie completa di scenari classificati per moduli funzionali (es. Nova, Neutron, Keystone e Glance) e misura i tempi di risposta per ogni step dello scenario e nella sua totalità. I dati raccolti vengono salvati su database e i report possono essere esportati in formato HTML o JSON. Lo strumento è in grado di replicare lo stesso scenario per diverse volte e calcolare i valori medi e altre statistiche (media, 90° percentile, 95° percentile, minimo, massimo) per iterazione e sul totale.

Report di un test Rally generato in HTML

Report di un test Rally generato in HTML

Rally supporta anche la nozione di Service Level Agreement (SLA), ovvero la possibilità di definire un margine di errore accettabile sul numero di iterazioni per considerare il test globale concluso correttamente.

Un altro elemento di questo progetto che ci ha conquistato è la possibilità di eseguire i test come utenti finali invece che come amministratori. In questo modo possiamo letteralmente metterci nei panni dei nostri clienti Public Cloud.

Casi d’uso

Misura delle prestazioni

Per qualificare l’API di una piattaforma esistente, ogni ora eseguiamo più volte un certo numero di iterazioni di test Rally per ciascun modulo funzionale di OpenStack, su tutte le localizzazioni.

Qualificazione software

Quando abbiamo necessità di realizzare patch del codice o effettuare aggiornamenti di sicurezza o software, senza strumenti diventa difficile quantificare gli effetti delle modifiche apportate. Prendiamo come esempio gli aggiornamenti kernel relativi agli ultimi bug di sicurezza Spectre e Meltdown, accusati di provocare un calo delle prestazioni: Rally consente di valutarne facilmente il possibile impatto.

Qualificazione hardware

Questa situazione può presentarsi anche quando vogliamo testare una nuova gamma di server fisici da utilizzare sul “Control Plane” di OpenStack. Rally permette in questo caso di verificare se si presenta una variazione delle prestazioni.

Misurare va bene, ma...

Non dimentichiamoci che vogliamo vedere l’evoluzione dei tempi di risposta nel lungo termine. Rally può fornire un report HTML sull’esecuzione di uno scenario, quindi un periodo di tempo molto breve, ma non è in grado di raccogliere i report di tutte le operazioni che ha eseguito.

Dovevamo quindi trovare il modo di estrarre i dati dei report di esecuzione e aggregarli sotto forma di grafico. Proprio qui entra in gioco la nostra piattaforma di metriche interna, basata su Warp10 per lo storage e Grafana per le dashboard.

Abbiamo infatti utilizzato l’export JSON implementato in Rally per estrarre i valori raccolti durante i test e importarli sulla piattaforma di metriche e poi creato una dashboard per visualizzare i tempi di risposta a lungo termine, per ciascun test e per ogni Region. In questo modo siamo in grado di visualizzare facilmente la loro evoluzione nel tempo e comparare i tempi di riposta per localizzazione. Per Region limitrofe (es. GRA, RBX e SBG in Francia) i tempi di risposta devono essere simili tra loro. In caso contrario è necessario cercare l’origine della discrepanza per risolvere il problema.

Dashboard interna che aggrega i risultati dei test Rally

Dashboard interna che aggrega i risultati dei test Rally

Caso pratico

Dopo aver implementato tutti i moduli, abbiamo confrontato l’evoluzione dei tempi di risposta tra le varie Region. Abbiamo notato che, nel tempo e in determinate localizzazioni, le performance peggioravano durante alcuni test. Ad esempio, per il test eseguito per generare l’elenco di tutte le istanze del progetto Rally. Il tempo medio calcolato era pari a 600 ms, ma in alcune localizzazioni raggiungeva i 3 secondi.

Per prima cosa abbiamo verificato che il malfunzionamento interessasse solo il nostro progetto e non tutti i clienti.

Grazie a una ricerca più approfondita, ci siamo poi accorti che il collo di bottiglia era situato nel database della versione Juno di OpenStack. Come mai? Perché OpenStack effettua il soft delete quando elimina dei dati. Questo significa che marca il dato come eliminato, ma in realtà non lo cancella dalla tabella. Nel nostro caso, la tabella “istances” include, tra l’altro, una colonna “project_id” e “deleted”. Quando Rally genera la lista dei server del progetto, la query è di questo tipo:

SELECT * FROM instances WHERE project_id=’xxx’ AND deleted = 0 ;

Purtroppo, a differenza della versione Newton di OpenStack, nella versione Juno non esistono gli indici (“project_id”,”deleted”) su questa tabella. Sul progetto Rally di ogni Region i test avviano circa 3.000 nuove istanze al giorno. Dopo 3 mesi avevamo raggiunto 270.000 istanze in soft delete nei nostri database. Questa elevata quantità di dati associata all’assenza di indici sulla tabella spiega le latenze constatate in alcuni siti (esclusivamente quelli con versione Juno).

La misura correttiva che abbiamo implementato nei nostri progetti interni è stata la realizzazione di un meccanismo di rimozione definitiva dei dati segnati come soft delete. Il risultato è stato subito evidente: i tempi di risposta sul test per generare i server del progetto Rally si sono ridotti di quattro volte.

Miglioramento significativo del tempo di risposta su una Region Juno per il progetto Rally

Miglioramento significativo del tempo di risposta su una Region Juno per il progetto Rally

Per i clienti che potrebbero essere colpiti dalla stessa problematica, implementeremo un archivio automatico dei dati soft deleted nelle tabelle shadow di OpenStack previste per tale scopo.

Grazie a questo tool di benchmarking, abbiamo ormai i mezzi per identificare le anomalie che possono presentarsi tra le Region e che si traducono in user experience differenti per gli utenti. Questo ci permette di lavorare alle soluzioni necessarie all’eliminazione di queste disparità ed entrare così in un processo di miglioramento continuo volto a mantenere e accrescere la qualità di utilizzo delle nostre API OpenStack.