Rally, du benchmarking à l’amélioration continue

Temps de lecture estimé : 7 minute(s)

Maintenir un niveau de qualité élevé tout en améliorant en continu nos offres exige que nous soyons capables de définir et mesurer cette qualité, d’en détecter les variations et d’enquêter en cas de dégradation.

Pour y parvenir, nous avons identifié sur OpenStack (la solution sur laquelle est bâtie l’offre Public Cloud) deux points majeurs qui nous semblent essentiels dans le ressenti client :

  • l’utilisation de l’API OpenStack via les clients OpenStack, les librairies ou l’API v6 d’OVH ;
  • la garantie des performances sur les instances (processeur, RAM, disque, réseau).

Cet article se focalise sur le premier point : comment, chez OVH, nous mesurons la performance des API Public Cloud. Je vais vous présenter la solution que nous avons mise en place et la manière dont elle s’intègre dans l’écosystème d’OVH. Je finirai par un cas concret, qui montre comment nous avons pu améliorer le temps de réponse de certains appels API jusqu’à 75 %.

Rally : l’outil de benchmark d’OpenStack orienté client

Rally est une brique du projet OpenStack qui se définit comme une solution de « Benchmarking as a Service ». Son rôle est de tester une plateforme OpenStack d’un point de vue client et d’en extraire des mesures de temps d’exécution.

Le projet, développé en Python, a été initié en 2013. La version 1.0.0 vient tout juste de sortir en juillet 2018. Le choix d’utiliser ce projet chez OVH s’est fait relativement facilement, dans la mesure où il fait partie de l’écosystème OpenStack et qu’il fournit des fonctionnalités qui répondaient à nos besoins.

Rally propose d’exécuter des scénarios, ceux-ci étant des ensembles de tests séquentiels paramétrables de plus ou moins grande complexité. Ainsi, il est par exemple possible de tester simplement la création d’un token d’authentification et d’en valider le fonctionnement. D’autres manipulations plus complexes sont réalisables : tester en un seul scénario l’authentification et la création de plusieurs instances en y attachant des volumes. Cette souplesse nous permet d’imaginer assez facilement et sans limite des tests très spécifiques. Rally fournit nativement un lot très complet de scénarios classés par briques fonctionnelles (Nova, Neutron, Keystone, Glance par exemple).

Rally mesure les temps de réponse à chaque étape du scénario et dans sa globalité. Les données sont sauvegardées en bases et peuvent être exportées sous forme de rapports en HTML ou en JSON. L’outil est capable d’itérer un certain nombre de fois sur un même scénario et de calculer les valeurs moyennes, ainsi que d’autres statistiques (médian, 90e centile, 95e centile, minimum, maximum) par itération et sur l’ensemble de celles-ci.

Rapport de test Rally généré en HTML

Rally supporte également la notion de Service Level Agreement (SLA), c’est-à-dire la possibilité de définir un taux d’erreur acceptable sur le nombre d’itérations pour considérer que le test global est un succès.

Un autre point qui nous a séduits dans ce projet est la possibilité d’exécuter les tests en tant que client final, sans rôle d’administrateur. Nous pouvons donc de nous mettre complètement à la place de nos clients Public Cloud.

Nos cas d’usage

Mesure de performance

Notre besoin initial est de qualifier l’API d’une plateforme existante. Nous exécutons donc, plusieurs fois par heure, un certain nombre d’itérations des tests Rally pour chaque brique fonctionnelle d’OpenStack, sur toutes les régions.

Qualification logicielle

Une autre utilisation est envisagée lorsque nous sommes amenés à réaliser des patchs de code ou à effectuer des mises à jour de sécurité ou software. Dans chacun de ces cas, il est difficile, sans outil, de mesurer les impacts de ces changements. Nous pouvons prendre comme exemple les mises à jour kernel relatives aux dernières failles de sécurité (Spectre et Meldwon) annoncées comme induisant une baisse des performances. Rally nous permet maintenant d’évaluer facilement les éventuels impacts.

Qualification hardware

Le cas peut se présenter aussi lorsque nous voulons tester une nouvelle gamme de serveurs physiques à utiliser sur le « Control Plane » d’OpenStack. Rally nous permet alors de vérifier s’il y a une variation de performance.

Mesurer c’est bien, mais…

N’oublions pas que nous voulons visualiser l’évolution des temps de réponse dans la durée. Rally peut fournir un rapport HTML sur l’exécution d’un scénario, donc sur une période de temps très courte. Il s’avère cependant incapable d’agréger les rapports de toutes ses exécutions.

Il nous fallait donc un moyen d’extraire les données des rapports d’exécution et de les résumer sous forme de graphique. C’est là qu’entre en jeu notre plateforme de métriques interne, basée sur Warp10 pour le stockage et Grafana pour les tableaux de bord.

Nous avons utilisé l’export JSON, implémenté dans Rally, pour extraire les valeurs mesurées lors des tests et les pousser sur la plateforme de métriques. Nous avons ensuite créé un tableau de bord qui nous permet de visualiser ces temps de réponse dans la durée pour chaque test et par région. Nous pouvons ainsi visualiser facilement leur évolution dans le temps et comparer les délais de réponse par région. Sur des régions proches (en France par exemple : GRA, RBX et SBG), nous devons obtenir sensiblement les mêmes temps de réponse. Si ce n’est pas le cas, nous recherchons l’origine de la différence pour corriger le problème.

Tableau de bord interne agrégeant les résultats des tests Rally

Cas concret

Après avoir mis en place l’ensemble des briques, nous avons comparé l’évolution des temps de réponse entre les différentes régions. Nous nous sommes aperçus que, dans la durée et sur certaines régions, les performances se dégradaient pour des tests spécifiques de notre projet. À titre d’exemple, il existe un test qui consiste à lister l’ensemble des instances du projet Rally : le temps moyen constaté est de 600 ms alors que sur certaines régions, nous avons atteint 3 secondes.

Nous avons commencé par vérifier que le dysfonctionnement était lié uniquement à notre projet et non pas à tous les clients, ce qui était bien le cas.

Après une recherche plus approfondie, nous nous sommes aperçus que le goulot d’étranglement était situé au niveau de la base de données pour la version Juno d’OpenStack. En effet, OpenStack pratique le soft delete lorsqu’il supprime des données. Cela signifie qu’il marque la donnée comme supprimée, mais ne l’efface pas réellement de la table. Dans notre cas, la table « instances » est composée entre autres d’une colonne « project_id » et « deleted ». Lorsque Rally liste les serveurs du projet, la requête est du type :

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

Malheureusement, sur les versions de Juno d’OpenStack, il n’existe pas d’index (« project_ id », « deleted ») sur cette table, contrairement à la version Newton d’OpenStack. Sur le projet Rally de chaque région, les tests démarrent environ 3 000 nouvelles instances tous les jours. Au bout de 3 mois, nous étions à 270 000 instances en soft delete dans nos bases. Cette importante quantité de données en bases associée au manque d’index sur la table explique les latences que nous avons constaté sur certaines régions (celles en version Juno uniquement).

L’action corrective que nous avons déployée a donc été de mettre en place sur nos projets internes une mécanique de suppression définitive des données marquées soft delete. Le résultat s’est fait sentir immédiatement, en divisant par quatre le temps de réponse sur le test qui consiste à lister les serveurs du projet Rally.

Amélioration significative du temps de réponse sur une région Juno pour le projet Rally

Dans ce cas précis, nous allons mettre en place, pour nos clients qui pourraient être affectés par les mêmes problématiques, un archivage automatique des données soft deleted dans les tables shadow d’OpenStack prévues à cet effet.

Grâce à cet outil de benchmark, nous avons désormais les moyens de mettre en évidence des anomalies pouvant exister entre régions et qui entraînent une différence d’expérience pour l’utilisateur. Nous mettons en œuvre les solutions nécessaires au gommage de ces disparités, de manière à obtenir le meilleur ressenti possible pour des régions proches. Avec cet outil, nous entrons naturellement dans un processus d’amélioration continue pour maintenir et accroître la qualité d’utilisation de nos API OpenStack.