Scalabilité et estimation des coûts dans le cloud, quels outils aujourd’hui ?

Le développement ou le portage d’applications dans le Cloud ne devrait plus susciter de craintes majeures concernant les problématiques de scalabilité et de coûts d’exploitation. Les outils pour valider en amont l’aptitude à supporter la charge et de calculer les coûts sont abordables et matures.

La faculté d’élasticité du Cloud-computing est très souvent mise en avant pour vanter un des principaux avantages du Cloud :
Etre capable, en temps réel, d’adapter les capacités hardware à la charge générée par les utilisateurs et ne payer que les ressources utilisées, cela avec une garantie de disponibilité, voilà le rêve de tout éditeur de logiciel qui souhaite vendre son produit sous forme de service… 
Mais cela reste aujourd’hui malheureusement encore de la théorie !

Pourquoi ?

Ajouter ou supprimer des ressources est effectivement extrêmement simple dans une architecture Cloud… Seulement cette élasticité est essentiellement manuelle ou éventuellement programmée (suivant un calendrier prédéfini). Le rêve de l’adaptation automatique à la charge n’est pas encore devenu réalité… car c’est éminemment complexe, même si les premiers systèmes d’auto-scalabilités intelligents prometteurs commencent à arriver… (Exemple : AzureWatch dans le Cloud Azure)

Le problème principal est de déterminer le comportement des ressources lors de la montée en charge dans le Cloud.

La scalabilité :
C’est l’aptitude d’une application à maintenir son niveau de performance face à une augmentation de la charge (ou de la volumétrie de données), ceci par augmentation de la capacité des ressources hardware sans modification de l’application elle-même.

Prenons un exemple d’un service SaaS qui se compose de 4 composants :
  • un site web (sur des serveurs frontaux)
  • une couche Business (BLL, sur des serveurs Middleware)
  • un service A Asynchrone (sur des serveurs dédiés)
  • une base de données (Serveur BDD)
Lorsqu’un seul internaute consomme le service, une unique instance de chaque composant est nécessaire.











Mais là où cela se complique… comment connaitre le nombre d’instances nécessaire de chaque serveur pour répondre à une charge données ? (100, 1000, 10 000 utilisateurs ?)











Autrement dit, comment déterminer la courbe de scalabilité dans le Cloud ?

Comment doit-on multiplier les instances en fonction de la charge ? (scalabilité horizontale)
Doit-on augmenter  unitairement la capacité d’une ressource ? (scalabilité verticale, instance de type small, medium, large, x-large ?)

De la réponse à ces questions découlera la réponse principale : quel coût pour mon service dans le Cloud ?

La seule façon de répondre aujourd’hui à cette problématique est d’utiliser des systèmes qui vont simuler différents niveaux de charge et de mesurer en même temps l’utilisation des ressources correspondantes. 
Ceci permettra de déterminer la configuration optimale de vos instances à différents niveaux de solicitations. Et donc de déduire avec précision le coût de votre application dans le Cloud.

Et c’est ici que les outils de CloudTesting prennent tout leur intérêt. Ils permettent en effet de simuler une charge d’utilisateurs virtuels à partir d’un Cloud. 
Ils sont très simples à prendre en main, bon marchés et simulent parfaitement le comportement des utilisateurs via des scénarios de navigation.  
Les outils les plus fiables sont ceux qui pilotent de réels navigateurs web et supportent, de fait,  intégralement les interfaces riches des applications Web modernes (AJAX, Flash, Silverlight, …). En outre le comportement d’un navigateur peut être très différent en fonction de la charge du serveur - timeouts internes du navigateur si des requêtes http sont trop lentes, exécution différente des scripts javascript , reflow … - et les systèmes qui se contentent de reproduire les requêtes http d’un unique navigateur et de les multiplier ne sont pas capable de prendre en compte ces comportements.

Ce marché, comme celui du Cloud en général est très dynamique, et les principaux outils existants à ce jour sont aux Etats-unit d’abord : Soasta (Requêtes http uniquement), Loadstorm (Requêtes http uniquement), Browsermob (Véritables navigateurs), en Suède : Loadimpact (Requêtes http uniquement), enfin en France : CloudNetCare (Véritables navigateurs). 

Ces outils permettent de gérer graphiquement et en quelques minutes des tests qui auparavant prenaient des jours à mettre en place. Cette simplicité d’utilisation offre donc une nouvelle opportunité à ceux qui hésitent à passer dans le Cloud… par peur de ne pas maitriser les coûts !







Validation, via un test de charge, de la taille d’un déploiement dans le Cloud

Ceux qui vendent déjà un applicatif en mode SaaS hébergé sur une infrastructure dédiée et veulent migrer dans un Cloud PaaS peuvent donc facilement simuler la charge réelle qui correspond à leurs utilisateurs actuels (mesurée dans leurs analytics) et en déduire le coût dans le Cloud.

Conclusion
Dès aujourd’hui, le développement ou le portage d’applications dans le Cloud ne devrait plus susciter de craintes majeures concernant les coûts d’exploitations. En effet les outils pour valider en amont l’aptitude à supporter la charge et par extension de calculer les coûts existent, ils sont très abordables et véritablement matures !

Autour du même sujet