L'élasticité des bases de données sur le cloud computing - CoDE

4.2 Problèmes liés à la mesure de l’élasticité
Avant de décrire de manière détaillée une nouvelle méthodologie, prenons le temps d’analyser
les problèmes intrinsèques à une telle démarche : le premier est la difficulté de chiffrer,
d’apposer une métrique sur l’ajout d’une instance. Jugera-t-on l’apport en CPU, en RAM ou
en mémoire disque ? Effectivement ceci dépendra du type de SGBD : un SGBD stockant les
données en mémoire tirera nettement plus profit de l’ajout d’une instance avec une grande
capacité en RAM qu’un système les stockant en mémoire disque.
Pour ne pas être confrontés à de telles considérations, nous proposons que toutes les
instances composant notre cloud soient similaires 2 . Chiffrer, fixer une métrique devient donc
assez simple 3 :
Définition 10.
Soit ni, le nombre initial d’instances d’un service, nf le nombre d’instances du service
après un passage à l’échelle, son apport terme de ressources se définit comme
∆n = nf −ni
ni
Le second problème est de prendre en considération le rôle de l’instance. Une instance
de calcul est dite sans état (stateless en anglais) lorsqu’elle traite chaque requête indépendamment
(sans relation avec la précédente). Les instances de BDs stocke des données dont
la persistance doit être assurée. On voit ici assez vite arriver le problème de la descente à
l’échelle : lorsqu’on désire diminuer le nombre d’instances de stockage d’un service, il va falloir
déplacer les données qu’il stockait vers d’autres instances. Ceci va nécessiter un certain
temps d’adaptation qui se reflétera sur une augmentation certaine des temps de latence du
service de stockage. On le comprend donc, le rôle d’une instance détermine son influence sur
l’élasticité.
Comme nous l’avons vu au chapitre 3, un nœud peut se voir attribuer un ensemble de
fonctions bien différentes. Par exemple, dans le cas de MongoDB , l’ajout un processus mongos
aura un effet, théoriquement, très différent de l’ajout d’un shard. Lorsqu’on parle d’ajouter
un nœud sur un cluster Hbase/HDFS, ajout-t-on ce nœud au cluster Hbase ou au cluster
HDFS. Traiter ces rôles comme une dimension de notre étude semble très complexe (voire
impossible). Toutefois, il ne serait pas judicieux de faire abstraction de ces rôles. Il s’agit donc
de les considérer lors de l’analyse des résultats.
4.3 Notre solution
Si on peut comprendre facilement l’élasticité, définir des paramètres qui permettront de
la mesurer est une tâche moins aisée. Dans cette section, nous étudierons le comportement
théorique d’un système face à l’ajout ou au retrait d’instances et proposerons un scénario de
test permettant de son élasticité.
2. Cette abstraction peut facilement se justifier par l’aspect virtuel des instances composant le cloud : vu
qu’elle font abstraction de la couche physique, il n’y a pas de raison de vouloir s’en tenir à des instances émulant
des composantes physiques différentes
3. Notons toutefois que, même si nous en faisons abstraction (pour des raisons de clarté), étudier ces aspects
“physiques” de l’instance garde tout son intérêt.
41