Cloud 2.0 : Diviser ses coûts d’infrastructure Cloud par deux

17 novembre 2014 Par Posté dans Expertise

Cloud 2.0 : Diviser ses coûts d’infrastructure Cloud par 2 grâce à un ajustement automatique des instances en fonction de la QoE et la QoS.

Dès 2011, une idée nous trottait dans la tête concernant le futur de la gestion des ressources Cloud. En effet, nos intuitions, dictées par les projets de recherche sur les architectures réseaux autogérées des opérateurs (réseaux autonomiques), nous amenaient à penser que ces techniques devaient être adaptées pour les plateformes de Cloud et ainsi, permettre la mise au point d’une nouvelle génération de plateforme, le « Cloud 2.0».

 

Déjà dans notre livre blanc « Pour une gestion durable du Cloud computing », nous évoquions une gestion automatique de l’élasticité des instances : l’auto-scaling. Cette gestion, qui consiste à adapter finement l’offre à la demande, ne pouvait être optimum que grâce à un mécanisme de gestion, prenant en compte des paramètres de QoS de la plateforme (qualité de service) et de QoE (expérience utilisateur).
Depuis, nous avons assisté à la naissance de mécanismes ou de services de gestion automatiques des ressources (Auto-scaling d’Amazon, Metrics Hub racheté par Microsoft dernièrement, RightScale,…). Cependant, les règles de décision, basées sur des indicateurs de qualité de service (QoS), ne permettent pas d’optimiser la prise de décision. Par exemple, un taux d’utilisation CPU de 100% indique que la machine virtuelle travaille mais cela ne signifie pas pour autant que le service est ralenti vu de l’utilisateur. Si l’auto-scaling utilise cette métrique, il augmentera peut-être le nombre d’instances, ce qui conduira à un surcoût inutile.

En tant qu’éditeur d’une offre de service SaaS et devant la nécessité d’adapter notre infrastructure en fonction de l’audience de nos clients (gestion des périodes de soldes, des pics de trafic non prévus, etc…), nous avons donc porté une partie de nos serveurs sur deux plateformes de Cloud public (IaaS et PaaS). Une fois ce travail achevé, nous nous sommes attaqués à l’implémentation d’une politique de gestion automatique des frontaux web afin de s’adapter au plus juste à la demande.

 

Cette demande est matérialisée par le graphique suivant (nous avons ventilé par tranche de 5 minutes, le nombre de requêtes accueillies sur nos frontaux web).

 

Cloud Computing Autoscaling

 

Il nous est paru évident que l’utilisation de cette information pouvait nous aider à construire un module d’arbitrage automatique sur le nombre d’instances réellement nécessaires. Nous avons donc décidé de développer ce module en utilisant les API des plateformes de Cloud afin de gérer le dimensionnement. Ce module a ainsi été porté en production pour la gestion de la plateforme. Des « garde fous » ont été implémentés comme le nombre minimum et maximum d’instances afin de prévenir tout dysfonctionnement. De plus, les modèles économiques des plateformes ont été pris en compte, par exemple, la facturation horaire pour une plateforme, la facturation à la minute pour une autre et ainsi ajuster les décisions en conséquence. Nous avons été surpris des résultats obtenus.

En effet :

  • le nombre d’instances allouées par défaut était surdimensionné par rapport aux périodes de trafic que nous rencontrons actuellement,
  • le mécanisme d’auto-adaptation réagit très précisément à la demande,
  •  l’économie réalisée est très importante.

 

Cloud Computing VM Autoscaling

 

Ainsi, les pics de charge sont gérés de manière automatique, sans aucune intervention manuelle, ce qui permet de gérer des évènements non prévus et ainsi améliorer la qualité perçue du service.

De plus, l’économie réalisée est très importante, même à l’échelle d’une petite infrastructure, et peut se calculer comme suit :

  • Nombre d’instances avant ajout du module 7
  • Nombre moyen d’instances après ajout du module 3,57
  • Economie de capacité 51%

 

Cloud

 

Nous avons d’ores et déjà prévu des évolutions comme la gestion automatique d’autres types d’instances, comme des bases de données pour diminuer les coûts tout en conservant une qualité de service optimale.

 

William Rang, CTO

Laisser un commentaire

Votre adresse email ne sera pas publié