Passage à l'échelle d'une application web

Un système d'auto-scaling a besoin d'un système de monitoring fournissant des informations sur la demande utilisateurs et l'état/statut de l'application.

• Les infrastructures du cloud fournissent via une API, l'accès à des informations au fournisseur (par exemple, vérifier le bon fonctionnement de l'infrastructure).
• Un système d'auto-scaling s'appuie sur la mise à jour des indicateurs de performance. En effet, la performance de l'auto-scaler dépendra de la qualités des mesures/informations disponibles et des coûts de l'obtention de ces mesures.

Pour analyser l'état du système, le moniteur observe au niveau :

• de l'équilibreur de charge (répartiteur) le nombre, de sessions utilisateurs actuelles, de demandes refusées, d'erreurs ;
• des serveurs web, l'utilisation du processeur par machine virtuelle, le nombre de threads totaux, de threads actifs, de sessions, la mémoire utilisée, les demandes traitées, en attente, abandonnées, le temps de réponse ;
• des serveurs de bases de données, le nombre de threads actifs, de transactions dans un état particulier (écrire, rollback) ;
• de la communication (file d'attente), le nombre moyen de demandes dans la file d'attente, le temps d'attente.

La phase d'analyse consiste à traiter les données rassemblées lors de l'étape de Monitoring. Il existe deux types d'auto-scaler :

• réactif : ce système renvoie juste l'état du système à un instant donné. Il réagit aux variations de la charge de travail seulement lorsque ces changements ont été détectés, en utilisant les dernières valeurs obtenues à partir de l'ensemble des informations récoltées lors de l'étape de "Monitor".
• proactif : ce système effectue de la prédiction sur de futures demandes afin d'organiser suffisamment tôt les ressources. L'anticipation est très importante car il y a toujours un délai entre le moment où le système décide de se mettre à l'échelle et celui où celle-ci prendra effet.

Une fois l'état de l'application connu, l'auto-scaler est chargé de planifier la mise à l'échelle des ressources.

Cette étape passe en exécution le passage à l'échelle des ressources trouvées dans l'étape précédente. L'exécution du passage à l'échelle des serveurs peut prendre un certain temps non négligeable (démarrage des serveurs, installations des logiciels, modifications réseaux).

Ainsi, les auto-scaler proactifs ont pour objectif d'anticiper ce temps de mise en place pour répondre au mieux à la demande. Cette étape est réalisée par une API du fournisseur du cloud.

application distribuée avec stockage statique

Les applications web contiennent souvent du contenu statique, par exemple des images, des vidéos, des fichiers javascript, des documents pdf. Pour pouvoir réduire au maximum la charge des serveurs d'application exécutant du code dynamique, les applications de cloud utilisent un serveur dédié à stocker des fichiers statiques volumineux. Sur ce serveur, les données sont organisées dans une hiérarchie de dossiers similaires à un système de fichiers ordinaire. Chaque fichier statique reçoit un identificateur unique composé de son emplacement dans la hiérarchie du dossier et le nom du fichier[6].

La mise à l'échelle d'une base de données est caractérisée par la scalabilité en écriture, en lecture et en stockage données. Plusieurs techniques permettent de mettre à l'échelle les différents types de base de données :

• la réplication
• la duplication

fonctionnement des réplications

La réplication est une technique permettant de dupliquer une instance de base de données en plusieurs instances identiques (possédant les mêmes données). Elle est utilisée pour la mise à l'échelle en lecture des données. Cette technique améliore la disponibilité d'une application. En effet, si l'une des répliques est indisponible, il est toujours possible pour les autres instances de répondre à une demande de lecture. Toutes les répliques étant capable de répondre, les requêtes de lecture peuvent être distribuées entre chacune d'elles. Ainsi la charge de travail de chaque serveur et par conséquent la latence d'une réponse diminue[7].

Cette solution possède plusieurs inconvénients :

• Chaque instance de la base de données contient les mêmes valeurs. Ainsi, si la base de données est très volumineuse, tous les serveurs de base de données devront posséder une capacité de stockage suffisante.
• Lorsqu'une écriture a lieu sur une instance, elle doit être répliquée sur chaque instance pour que chaque serveur possède les mêmes données à tout moment.
• Les réplications de la base de données permettent de mettre à l'échelle la capacité de lecture des données car chaque réplication peut répondre à une demande de lecture, mais ne permettent pas de mettre à l'échelle la capacité en écriture des données.

Il existe deux types principaux de réplication[8] :

1. la réplication maître-esclave : Un nœud est désigné comme "maître". Les autres sont appelés "esclave". Seul le nœud maître peut traiter et diriger des requêtes d'écriture. Les changements de données se propagent du nœud maître aux esclaves. On utilise cette réplication lorsque l'on souhaite faire de la scalabilité en lecture car cela permet aux nœuds esclaves d'accepter les requêtes en lecture. Par contre il est impossible de réaliser de la scalabilité en écriture car seul le nœud maître s'occupe des requêtes en écriture.
2. la réplication multi-maître : Plusieurs nœuds peuvent traiter et diriger des requêtes d'écriture. La propagation des données peut se faire dans plusieurs directions. On peut se servir de cette réplication pour la scalabilité en lecture et écriture puisque chaque nœud est capable de gérer les deux types de requêtes en lecture et en écriture.

Le partitionnement permet de mettre à l'échelle la capacité en écriture d'une base de données en séparant les données en partitions (ou shards). Le partitionnement permet de séparer les données dans différents serveurs indépendants[9]. Il existe deux types de partitionnement :

• Le partitionnement vertical dont les données sont partagées en ensembles de colonnes.
• Le partitionnement horizontal (appelé Database Sharding), qui est le partitionnement le mieux adapté pour distribuer les bases de données. Les données sont divisées en ensembles de lignes.

Cette méthode permet d’améliorer les performances des bases de données et de simplifier la gestion de bases de données de très grande ampleur. Le partitionnement augmente les performances des requêtes puisque les ensembles de données sont plus petits comparés à une table unique de grande taille (scalabilité en lecture, écriture et stockage)[10].

Les bases de données relationnelles respectent plusieurs caractéristiques principales regroupées sous l'acronyme ACID. Les bases de données relationnelles sont facilement réplicables. Cependant, partitionner ce type de base de données s'avère complexe. De plus, garantir la consistance des données est souvent incompatible avec les performances. Ainsi, le passage à l'échelle horizontal est délicat pour ce type de base de données. Comme le modèle relationnel ne semble pas adapté aux environnements nécessitants de grosses architectures distribuées et que les propriétés ACID des bases de données ne permettent généralement pas de passer à l'échelle de manière horizontale et optimale[11], les concepteurs du cloud computing et de grands sites communautaires ont proposé un nouveau modèle de base de données : NoSQL[12].

Les bases de données NoSQL se basent sur le théorème CAP, mieux adapté aux données massivement partagées, qui déclare qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps les trois contraintes suivantes[13] :

• la cohérence (Consistency) : Tous les serveurs de base de données du système possèdent exactement les mêmes données au même moment.
• la disponibilité (Availability) : Une réponse sera forcément renvoyée pour chaque requête reçue, même s'il y a une défaillance d'un serveur.
• la tolérance au partitionnement (Partition Tolerence) : Même si le système fait face à une défaillance d'un composant, il doit être capable de répondre correctement à toutes les requêtes qu'il aura reçues.

La première propriété (la cohérence) du théorème CAP est parfois intéressante à supprimer car elle permet d'augmenter les performances de manière non négligeable[11]. Ainsi, certains sites préfèrent optimiser la disponibilité et la latence de l'application au détriment de ne pas fournir une réponse identique pour une même requête. Le fait d'accepter des données inconsistantes est connu sous le nom de BASE (Basically Available, Soft-state, Eventually consistent) en opposition aux propriétés ACID. Si la cohérence est importante pour certaines données du système, il est d'usage d'isoler ces données dans des bases relationnelles et de placer les autres données dans des bases NoSQL.

Les bases de données NoSQL facilitent le passage à l'échelle en utilisant plusieurs systèmes qui mettent en œuvre les propriétés citées par le théorème CAP. Les voici :

• Le passage à l'échelle horizontal avec ce type de base de données est très simple à réaliser. Ainsi, elles permettent de répartir la charge de travail et par conséquent d'assurer une grande disponibilité.
• Elles possèdent en général un système de réplication et de partitionnement qui assurent la disponibilité et la tolérance au partitionnement.
• Elles utilisent en général, simultanément l'indexation et la RAM afin de trouver les données recherchées. Grâce à l'indexation, on connaît rapidement le serveur sur lequel est présent la RAM qui stocke les données que l'on souhaite quérir. De plus, les données sont conservées en RAM, permettant ainsi de les récupérer très rapidement puisque le temps d'accès à la RAM est très performant. Ainsi on peut dire que la disponibilité et la tolérance au partitionnement sont garanties par ces deux points.

Ce type de base de données est considérée comme la plus élémentaire et la plus simple à utiliser. On y trouve un ensemble de couples clé-valeur représentant chacun une donnée. Chacune des valeurs stockées dans la base de données peut avoir un type différent. Mais ce type est opaque, sa nature est donc masquée. Il est alors impossible de connaître et de modifier le contenu de la valeur. On peut simplement la stocker et la transmettre dans une base de données. Afin d'identifier chaque valeur sans ambiguïté, celle-ci est alors associée à une clé unique. C'est grâce à cette clé que l'on pourra connaître et modifier le contenu de la valeur. Les clés et les valeurs ne sont pas obligatoirement du même type.

Ces bases de données sont très efficaces dans le stockage de données distribuées. Elles sont ainsi performantes pour :

• synchroniser les données sur chacune des bases de données à un moment donné;
• répliquer les données mises à jour, modifiées, supprimées dans une base de données sur les autres bases de données lorsque plusieurs utilisateurs souhaitent accéder à la même donnée.

Par contre, le type opaque des valeurs empêche de manier les requêtes au niveau données et de faciliter l'accès aux données à l'aide de l'indexation sur les données puisqu'il est impossible de récupérer ou de changer le contenu d'une valeur. Ces bases de données sont seulement capables de lancer des requêtes sur les clés. De plus elles sont dans l'obligation d'utiliser des applications clientes car elles n'ont pas la possibilité de gérer les relations entre les différentes données[14].

Tout comme les bases de données clé-valeur, le système de stockage d'une base de données orientée document se fait toujours sous forme d'un couple clé-valeur. Par contre, la valeur est représentée à l'aide d'un document dont le format n'est pas imposé. Le plus souvent, ils seront de type JSON. Il n'est pas obligatoire que tous les documents d'une base de données orientée document possèdent la même structure.

Les bases de données orientées document peuvent grâce à la clé primaire, générer des requêtes et indexer les documents. Elles peuvent également le faire à l'aide de la valeur puisque son type est connu, il n'est pas opaque.

Mais elles n'ont pas la capacité à sauvegarder des relations entre les données, les obligeant ainsi à faire appel à des applications clientes[15].

Contrairement aux bases de données relationnelles qui stockent les données par ligne, celles-ci le font par colonne. L'ensemble des données est enregistré dans un ensemble de lignes. Chacune d'entre elles corresponde à une clé primaire. Les bases de données orientées colonne sont constituées d'un ensemble de famille de colonnes qui contiennent toutes les valeurs.

Grâce aux ensembles de famille de colonnes, ce type de base de données offre de puissantes capacités de génération de requêtes et d'indexation des données. Mais elles ne possèdent pas l'aptitude à stocker les différentes relations entre les données[15].

Une base de données orientée graphe s'appuie sur la théorie des graphes. Les données sont décrites par des nœuds. Quant aux relations entre les différentes données, celles-ci sont symbolisées via les arcs du graphe.

Contrairement aux autres bases de données, elles peuvent stocker efficacement les relations entre les différentes données. Elles sont également spécialisées dans le traitement des données interconnectées[16].

• [Burtica et al. 2012] (en) Ruxandra Burtica, Eleonora Maria Mocanu, Mugurel Ionuţ Andreica et Nicolae Ţăpuş, « Practical application and evaluation of no-SQL databases in Cloud Computing », dans IEEE International'12 on Systems Conference (SysCon), Vancouver, BC, IEEE Computer Society Washington, DC, USA, mars 2012 (ISBN 978-1-4673-0748-2, DOI 10.1109/SysCon.2012.6189510).
• [Cattell 2010] (en) Rick Cattell, « Scalable SQL and NoSQL Data Stores », ACM SIGMOD Record, vol. 39, n^o 4,‎ décembre 2010 (DOI 10.1145/1978915.1978919, lire en ligne [PDF]).
• [Fehling, Leymann, Mietzner et Schupeck 2011] (en) Christoph Fehling, Frank Leymann, Ralph Mietzner et Walter Schupeck, « A Collection of Patterns for Cloud Types, Cloud Service Models, and Cloud-based Application Architectures », iaas,‎ 2011 (lire en ligne).
• [Fehling, Leymann, Retter et Schumm 2011] (en) Christoph Fehling, Frank Leymann, Ralph Retter, David Schumm et Walter Schupeck, « An Architectural Pattern Language of Cloud-based Applications », dans PLoP '11 Proceedings of the 18th Conference on Pattern Languages of Programs Article No. 2, ACM New York, NY, USA, 2011 (ISBN 978-1-4503-1283-7, DOI 10.1145/2578903.2579140).
• [Grolinger et al. 2013] (en) Katarina Grolinger, Wilson A. Higashino, Abhinav Tiwari et AM Miriam Capretz, « Data management in cloud environments: NoSQL and NewSQL data stores », Journal of Cloud Computing: Advances, Systems and Applications 2013, 2:22,‎ 2013, p. 1-24 (lire en ligne).
• [Homer et al. 2014] (en) Alex Homer, John Sharp, Larry Brader, Masashi Narumoto et Trent Swanson, « Cloud Design Patterns », msdn.microsoft.com,‎ 2014 (lire en ligne).
• [Li et al. 2014] (en) Feng Li, Beng Chin ooi, M. Tamer Özsu et Sai Wu, « Distributed data management using MapReduce », ACM Computing Surveys (CSUR), ACM New York, NY, USA, vol. 46, n^o 31,‎ janvier 2014, p. 1-41 (DOI 10.1145/2503009).
• [Lorido-Botran, Miguel-Alonso et Lozano 2014] (en) Tania Lorido-Botran, Jose Miguel-Alonso et Jose A. Lozano, « A Review of Auto-scaling Techniques for Elastic Applications in Cloud Environments », Journal of Grid Computing, vol. 12,‎ janvier 2014, p. 559-592 (DOI 10.1007/s10723-014-9314-7, lire en ligne [PDF]).
• [Maheshwari, Tang et Liang 2004] (en) Piyush Maheshwari, Hua Tang et Roger Liang, « Enhancing Web Services with Message-Oriented Middleware », dans IEEE International Conference on Web Services., IEEE, juillet 2004 (ISBN 0-7695-2167-3, DOI 10.1109/ICWS.2004.1314778, lire en ligne), p. 524-531.
• [Nagendra 2014] (en) Rupesh Nagendra, « Performance Evaluation in Web Architectures », Oriental Journal of Computer Science & Technology, Oriental Scientific Publishing Co., India, vol. 7, n^o 1,‎ avril 2014, p. 83-90 (ISSN 0974-6471, lire en ligne).
• [Pokorny 2011] (en) Jaroslav Pokorny, « NoSQL Databases: a step to database scalability in Web environment », dans iiWAS '11 Proceedings of the 13th International Conference on Information Integration and Web-based Applications and Services, ACM New York, NY, USA, 2011, 278-283 p. (ISBN 978-1-4503-0784-0, DOI 10.1145/2095536.2095583).
• [Thandar Thant et Naing 2013] (en) Phyo Thandar Thant et Thinn Thu Naing, « Improving the Availability of NoSQL Databases for Cloud Storage », academia,‎ 2013 (lire en ligne).
• [Vaquero, Rodero-Merino et Buyya 2011] (en) Luis Miguel Vaquero, Luis Rodero-Merino et Rajkumar Buyya, « Dynamically Scaling Applications in the Cloud », Newsletter ACM SIGCOMM Computer Communication Review, ACM New York, NY, USA, vol. 41, n^o 1,‎ janvier 2011, p. 45-52 (DOI 10.1145/1925861.1925869).

• Cloud computing
• Scalability