L'élasticité du cloud : une notion dont la transparence est relative

A lire sur: http://www.zdnet.fr/actualites/l-elasticite-du-cloud-une-notion-dont-la-transparence-est-relative-39796071.htm

Cloud Computing : Les prestataires de services cloud vantent la possibilité d’augmenter à volonté les ressources allouées à une application. Horizontale ou verticale, cette élasticité est réelle mais plus ou moins transparente selon le type de cloud.

Par Thierry Lévy-Abégnoli | Mercredi 04 Décembre 2013

Le cloud computing permet en principe une élasticité virtuellement sans limite. Dans l'idéal, on aimerait bénéficier d’une fonction presse-bouton, pour allouer davantage de ressources aux applications en production. Instantanément, les performances seraient alors améliorées ou le nombre d'utilisateurs supportés augmenterait.

Cette promesse n'est tenue que dans une certaine mesure. Car, quel que soit le type de cloud - PaaS ou IaaS -, l'infrastructure sous-jacente est constituée de serveurs bel et bien physiques dont le nombre de processeurs et la puissance unitaire trouvent vite leurs limites.

Elasticité horizontale et verticale

On distingue deux types d'élasticité. Avec l'élasticité verticale, on augmente la puissance ou la mémoire des serveurs sans en augmenter le nombre. « Cela permet typiquement de réduire le temps de traitement de chaque requête », explique Gilles Mergoil, PDG de Neoxia. Mais cette méthode est contrainte par les capacités des serveurs les plus puissants, en termes de nombre de cœurs et de taille mémoire. D’autant que les prestataires ont souvent tendance à baser leurs infrastructures sur des grandes fermes de serveurs de puissance moyenne ou modeste.

« C'est pourquoi nous cherchons systématiquement une élasticité horizontale, par augmentation du nombre de serveurs », explique Christophe Tricard, directeur technique branche production chez GFI Informatique. Cela ne pose généralement pas de problème pour les infrastructures Web.

La difficulté se concentre davantage sur le code applicatif. « Il est possible d'allouer un process Java à un thread que l’on peut exécuter sur un cœur virtuel, mais pour répartir vraiment l'exécution d'une application complète sur plusieurs serveurs virtuels, cela reste compliqué », constate Christophe Tricard, avant de conclure que c’est pourtant la tendance.

Plutôt adaptée à l’augmentation des volumétries et du nombre d’utilisateurs, l’élasticité horizontale trouve des limites encore plus fortes au niveau des serveurs de données. La solution consiste à opter pour les moteurs noSQL, en rupture avec le traditionnel modèle relationnel. « Le noSQL permet une élasticité horizontale presque infinie mais le passage n'est pas indolore. Il faut en effet coder soi-même certaines logiques applicatives qu'on avait l'habitude de ne plus gérer. L'avantage, c'est que les temps d'accès restent constants quels que soient les volumes », explique Gilles Mergoil.

IaaS : l’élasticité doit être gérée de bout en bout

Les cloud de type IaaS offrent pour la plupart un vaste choix de serveurs virtuels – on parle d’instances. Dans l’offre Amazon EC2 par exemple, cela va de Small (un seul cœur et 2 Go de mémoire) jusqu'à double extra large (26 cœurs et 30 Go). A cela s’ajoutent des instances spécifiques, par exemple avec beaucoup de mémoire ou des processeurs graphiques (GPU).

Même principe avec l’offre IaaS de Microsoft. Les instances sont répertoriées de A0 (un cœur partagé par plusieurs clients et 768 Mo de Ram) à A7 (8 cœurs et 56 Go). Pour autant, l’élasticité verticale doit être gérée explicitement. « Chez Amazon par exemple, il est possible de passer d’un serveur Small à un serveur Extra large mais il faut arrêter la machine virtuelle, donc l’application », prévient Gilles Mergoil. En pratique, on prépare d’abord la nouvelle instance, on l’accroche au serveur d’équilibrage de charge, puis on débranche l’ancienne instance. Lors de l’opération, on doit accepter quelques dizaines de secondes d'interruption de service.

De plus, des problèmes de gestion des sessions des utilisateurs peuvent survenir. Il est toutefois possible de déléguer au prestataire de cloud, l’élasticité du moteur de base de données, via des services de stockage comme Amazon DynamoDB, Microsoft Azure SQL Database ou Google Datastore. « Des serveurs seront alors automatiquement ajoutés selon la volumétrie et le nombre de requêtes », détaille Gilles Mergoil.

PaaS : transparence relative

Les offres PaaS mettent en œuvre les mêmes mécanismes d’élasticité que les IaaS mais ils sont partiellement ou totalement masqués. « Le prestataire industrialise et automatise l’ajout de serveurs, l’augmentation de leur puissance unitaire et l’équilibrage de charge », résume Gilles Mergoil. Ce processus est totalement transparent chez SalesForce. Mais chez Microsoft par exemple, même en mode PaaS, il subsiste une notion d’instance dont il est même possible de suivre la consommation de puissance ou de mémoire.

Sur les PaaS, la prise en charge partielle ou totale de l’élasticité est liée à la gestion des couches basses du cloud, par le prestataire, qui peut par exemple redémarrer un serveur sans en avertir ses clients. C’est pourquoi les applications déployées sur un PaaS doivent être adaptées en conséquence, notamment au niveau de la gestion des sessions. « Toutefois, certains frameworks comme Spring ou Symphony sont dotés de plug-in qui gèrent cette problématique », explique Gilles Mergoil.