Impact de l’utilisation de REDIS par rapport à MySQL

Pénalités en termes de temps de réponse

Les changements faits au code source du service Nova pour permettre le support des bases de données NoSQL, sont susceptibles de modifier sa réactivité. La première raison est qu’un système clé/valeur n’offre pas nativement le support d’opérations telles que les jointures et que le code que nous avons écrit pour ajouter de telles opérations entraine un surcoût de calculs. La seconde raison est liée aux aspects réseau. Contrairement à une base de données localisée sur un nœud unique, une base REDIS peut fonctionner native- ment sur plusieurs nœuds, ce qui peut aboutir à ce qu’une seule requête soit à l’origine d’échanges réseau impliquant plusieurs nœuds de bases de données. Enfin, REDIS pro- pose une stratégie de réplication, permettant entre autres de répondre au problème de la tolérance aux pannes, qui est aussi à l’origine d’un surcoût en matière de calcul, car né- cessitant des opérations de synchronisation entre les nœuds contenant la base de données REDIS.

6.4. Validation sur Grid’5000 93

FIGURE 6.10 : Illustration du déploiement fait avec une base de données REDIS distri- buée.

TABLE6.1 : Temps de réponse moyens aux requêtes API pour des déploiements monosite (en ms).

Configuration REDIS MySQL

1 nœud 83 37

4 nœuds 82 -

4 nœuds + réplication 91 -

La Table 6.1compare les temps de réponse moyens pour satisfaire les requêtes API qui sont lancées pendant la création de 500 machines virtuelles sur une infrastructure OpenStack (contenant 1 nœud contrôleur et 6 nœuds de calcul) où Nova stocke ses états dans des bases de données plus ou moins distribuées utilisant REDIS ou MySQL. Alors que la distribution de REDIS sur plusieurs nœuds et l’utilisation de ses mécanismes de réplication ne semblent pas augmenter considérablement le temps de réponse (première colonne), notre version de Nova semble moins réactive que celle de base, car le temps de réponse moyen est plus important à première vue (124% d’augmentation). Cependant, l’importance de ce résultat doit être mise dans la perspective de la figure6.12et de la Table

TABLE6.2 : Temps utilisés pour créer 500 VMs pour des déploiements monosite (en sec.).

Configuration REDIS MySQL

1 nœud 322 298

4 nœuds 327 -

94 Chapitre 6. Support des bases clé/valeur dans Nova

FIGURE6.11 : Illustration du déploiement fait avec une base de données MySQL distri- buée avec Galera.

6.2. La figure6.12montre la distribution statistique des temps de réponse de chaque appel à l’API de Nova durant la création de 500 machines virtuelles. D’une part, on observe que pour une grande partie de ces appels (environ 80%), le temps de réponse moyen de notre version de Nova reposant Rome+REDIS est inférieur à la version par défaut de Nova utilisant SQLAlchemy+MySQL. En ce qui concerne les 10% les plus lentes, leurs temps de résolution moyen est supérieur à 222ms avec notre prototype, tandis qu’il est supérieur à 86ms avec la version de base. Cette différence concernant les requêtes les plus lentes explique pourquoi les moyennes enregistrées dans la Table6.2sont plus élevées avec notre solution et met en évidence le besoin de pousser plus loin les analyses afin d’identifier ces requêtes et accélérer leur traitement pour qu’il soit plus efficace, ce qui n’a pu être réalisé faute de temps. De manière générale, nous pouvons voir que malgré un traitement plus lent de certaines requêtes, les temps nécessaires pour créer 500 machines virtuelles avec notre version de Nova sont très comparables à ceux par défaut, comme le montre la Table 6.2. En d’autres termes, seules quelques méthodes API semblent être décisives sur le temps de création des machines virtuelles, et elles ne semblent être pas trop pénalisées par nos modifications.

Pénalités en termes de réseau

Nos modifications du service Nova ayant pour but de pouvoir exploiter un réseau de mi- cros centres de données impliquant un grand nombre de sites géographiques, la quantité de données échangées sur le réseau est un critère important qu’il faut prendre en compte dans le cadre de l’évaluation de notre approche. La principale raison est que les données que nous stockons avec Rome dans le système clé/valeur utilisent un format objet qui né-

6.4. Validation sur Grid’5000 95

FIGURE6.12 : Distribution statistique des temps de réponse à l’API de Nova (en ms.).

cessite une phase de sérialisation/désérialisation lors de l’accès et du stockage des valeurs. Pour permettre cette désérialisation, il a été nécessaire d’ajouter des métadonnées, ce qui augmente l’empreinte en matière de stockage et donc augmente la quantité de données échangées entre les nœuds de base de données et les nœuds hébergeant le service Nova.

TABLE6.3 : Quantité de données échangées sur le réseau (en Méga-octets).

Configuration REDIS MySQL

1 nœud 2190 1794

4 nœuds 2382 -

4 nœuds + réplication 4186 -

Pour déterminer si le surcoût réseau est à un niveau acceptable, nous avons collecté des métriques réseau au cours des expériences précédentes. La Table 6.3 compare les quantités de données échangées sur le réseau en fonction des configurations de bases de données utilisées. Comme MySQL ne stocke pas des objets sérialisés, ceux-ci sont séria- lisés par l’ORM au niveau du client, et donc seules des données brutes sont échangées sur le réseau. Pour cette raison nous considérons la configuration à base d’un nœud MySQL unique comme étant la solution optimale, avec 1764 Mo échangés. Notre solution dé- ployée avec un simple nœud REDIS consomme 2190 Mo, ce qui signifie que le surcoût lié à l’utilisation de Rome et REDIS peut être estimé à 22%. En faisant la même expérience utilisant cette fois un cluster comprenant 4 nœuds REDIS sans avoir activé la réplication des données, nous mettons en évidence que la distribution de REDIS entraine un surcoût de 33% comparé à l’expérience à base d’un unique nœud MySQL. Enfin, quand la ré- plication des données est activée sur la base d’un facteur de réplication de 1, la quantité de données échangées est supérieure de 76% à celle mesurée sans réplication, ce qui est intuitivement raisonnable.

96 Chapitre 6. Support des bases clé/valeur dans Nova Cependant, les infrastructures qui ont été déployées contenant différents types de nœuds (contrôleurs, nœuds de calcul, nœuds de base de données, . . . ), les quantités de données précédemment évoquées prennent en compte tous les échanges sans distinction d’origine et donc ne permettent pas de comprendre l’origine du surcoût réseau.

FIGURE 6.13 : Quantité de données échangées en fonction du type de nœuds dans une configuration avec un unique nœud MySQL.

En utilisant l’outil iftop2_{, il a été possible de rassembler des informations sur l’ori-} gine et la destination des messages TCP/IP échangés pendant la création des 500 machines virtuelles, et ainsi avoir ainsi une idée précise de l’origine du surcoût réseau. Les figures 6.13, 6.14 et 6.15 illustrent les échanges de données en fonction de l’origine (axe ho- rizontal), de la destination (barres verticales) et de la configuration de base de données utilisée par Nova. On observe qu’il n’y a pas de différence significative au niveau des flux de données entre les types de nœuds, quel que soit le type du nœud de départ et quelle que soit la configuration de base de données (que ce soit REDIS ou MySQL). Nous pou- vons cependant remarquer une légère différence en ce qui concerne les nœuds de base de données, car une comparaison des figures6.13et6.15confirme que le surcoût réseau vient des nœuds de base de données. Enfin, la figure 6.15confirme qu’une grande partie du surcoût réseau observé quand on active la réplication des données vient des données additionnelles échangées entre les nœuds de bases de données.