EC2 ou Elastic Compute Cloud, est l’un des services les plus utilisés chez AWS. Il représente l'offre IAAS d'AWS, en offrant des serveurs virtuelles et physiques avec beaucoup de configurations possibles (CPU, RAM, Réseau, Disque, OS …). Plusieurs entreprises et particuliers (dont je fais partie) utilisent passivement les ressources EC2 grâce à la flexibilité du service et la facilité de s’approprier et personnaliser son infrastructure. Cependant, EC2 reste tout de même un service d’infrastructure, ce qui implique qu’il faut la gérer et la maintenir contrairement aux services managés ou encore les services serverless. Heureusement, AWS propose plusieurs possibilités pour faciliter la tâche et anticiper, dès la phase d’architecture, l’automatisation de certaines tâches récurrentes. Une de ces possibilités est l’utilisation d’Auto Scaling.  

Cas d’utilisation

AWS Auto Scaling peut être utilisé pour répondre à plusieurs besoins, je cite entre autres :

• La résilience de l’infrastructure : en garantissant par exemple qu’un nombre minimum de nœuds d’un cluster soient toujours en activité, en bon état de fonctionnement et répartis dans plusieurs zones de disponibilité (Datacenters)
• La performance d’application : en ajustant le dimensionnement des instances ou en ajoutant de nouvelles instances au besoin, pour répondre aux pics de charge.
• La réduction des coûts : Inversement à l’objectif précédant, on peut viser à réduire les coûts en optant pour une configuration minimaliste pendant les heures creuses ; on peut aussi utiliser les instances SPOT (jusqu’à 70% moins chères) pour renforcer un cluster à moindre coût.

 

Principe de fonctionnement

AWS Auto Scaling a pour objet la gestion du cycle de vie d’une configuration d’infrastructure d’instances. Cela peut avoir la forme la plus simple comme le maintien en permanence de deux instances d’un cluster, ou bien des stratégies plus sophistiquées comme opter pour une scaling policy.

Configuration de scaling base

Une configuration de base consiste à paramétrer un ASG avec une capacité minimale, une capacité maximale et une capacité désirée. ASG, dans ce cas, va essayer de maintenir un cluster avec la capacité désirée tout en respectant les deux seuils minimal et maximal.

Predictive Scaling

Comme son nom l’indique, on peut utiliser le prédictive scaling pour anticiper des charges qu’on peut prédire, par exemple ajouter deux instances chaque matin entre 9h du 10h pour absorber un pic journalier récurrent, et réduire de deux entre 18h et 7h et rester sur une configuration minimaliste pendant les heures non travaillées.

Dynamic Scaling

Parfois, on ne peut pas prédire les pics de charge et les périodes à basse activité, et pourtant, on aimerait bien que notre infrastructure assure un bon niveau de performance et de disponibilité, et ce, tout en maitrisant les coûts. Dynamic Scaling répond à ce besoin, en associant l’augmentation et la réduction du nombre d’instances par exemple au taux d’utilisation du CPU des serveurs du cluster. On peut aussi utiliser des métriques plus évoluées comme le nombre d’utilisateurs ou de transactions sollicitant un load balancer.   Si vous souhaitez en savoir plus et vous former sur Amazon Web Services, découvrez notre offre de formations officielles AWS.