Comparaison de la mise à l'échelle automatique : Azure, GCP et AWS

Chez Mindee, nous sommes multicloud. La création et la maintenance de dizaines d'API utilisées des millions de fois par mois nous ont permis de faire appel aux « trois grands » fournisseurs de cloud, en particulier pour leurs capacités de dimensionnement automatique.

Dans cet article, nous partagerons nos résultats et comparerons les services de dimensionnement automatique d'AWS, d'Azure et de GCP.

Fonctionnalités de mise à l'échelle automatique

La mise à l'échelle automatique permet de gérer un pool de machines virtuelles et de les ajouter ou de les supprimer automatiquement en fonction des besoins.

Les clusters de dimensionnement automatique sont appelés « groupes de dimensionnement automatique » dans AWS, « ensembles de mise à l'échelle de machines virtuelles » dans Azure et « groupes d'instances gérés » dans GCP.

Avant de comparer les différences, résumons quelques caractéristiques communes aux trois nuages :

• les trois fournisseurs vous permettent de répartir votre cluster dans plusieurs zones de disponibilité
• ces clusters de dimensionnement automatique peuvent être associés à des services d'équilibrage de charge, tels qu'AWS ALB, Azure Application Gateway ou Google Load Balancer
• la configuration de ces clusters est similaire : les nouvelles instances sont basées sur une image de machine virtuelle (créée manuellement ou à l'aide d'outils tels que Packer) et sur un script d'initialisation fourni par l'utilisateur.

Enfin, même si certains clouds proposent des fonctionnalités pour les clusters avec état, nous nous concentrerons uniquement sur les groupes sans état, ce qui signifie qu'une instance du groupe peut être supprimée à tout moment sans aucune perte de données.

Examinons maintenant trois caractéristiques clés :

• définition des politiques de mise à l'échelle automatique
• possibilité d'utiliser des instances ponctuelles dans le cluster
• possibilité d'utiliser une combinaison d'instances dans le cluster

Politiques de dimensionnement

Ce que nous attendons de cette fonctionnalité, c'est de pouvoir ajouter ou supprimer automatiquement des machines virtuelles de nos clusters de dimensionnement automatique, en fonction de divers indicateurs tels que l'utilisation du processeur, le nombre de requêtes ou simplement l'heure de la journée.

Les politiques de dimensionnement peuvent être séparées en trois groupes : mise à l'échelle simple, suivi des cibles et mise à l'échelle planifiée.

La mise à l'échelle simple vous permet de définir manuellement une action qui doit être exécutée en réponse à un changement de métrique. Voici un exemple de traduction de cette fonctionnalité : »si l'utilisation moyenne du processeur par machine virtuelle atteint 40 %, ajoutez 10 % de machines virtuelles supplémentaires au groupe ». Vous pouvez généralement déclencher des actions pour ajouter ou supprimer un nombre fixe d'instances, ou un pourcentage.

Le suivi des cibles est une méthode de mise à l'échelle plus automatique. Au lieu d'effectuer les modifications manuellement, comme une simple mise à l'échelle, nous laissons le fournisseur de cloud évoluer ou augmenter la taille pour maintenir une certaine métrique au même niveau. Par exemple, »maintenir l'utilisation du processeur à 40 % » serait une bonne traduction de l'exemple ci-dessus. Sous le capot, le même comportement que la simple mise à l'échelle se produit ; toutefois, il est géré en interne par le fournisseur de cloud et l'utilisateur n'a pas à le définir.

Le dernier type de mise à l'échelle, et le plus simple, est le dimensionnement planifié. Il vous permet de déclencher une modification de la taille du cluster en fonction de l'heure de la journée, de la semaine ou de l'année, généralement à l'aide d'expressions cron. Un cas d'utilisation courant consiste à ajouter plus de machines virtuelles aux heures de pointe de la journée, ou pendant une certaine période de l'année, lorsque nous savons à l'avance que le trafic augmentera.

Voyons maintenant quel type de mise à l'échelle est pris en charge par chaque cloud.

Politiques de dimensionnement d'AWS

Amazon propose trois types de mise à l'échelle : la mise à l'échelle simple, la mise à l'échelle avec suivi des cibles et la mise à l'échelle planifiée.

Il est intéressant de noter qu'AWS propose un autre type de mise à l'échelle appelé « dimensionnement par étapes ». Il s'agit essentiellement d'un type spécial de mise à l'échelle simple, où les règles peuvent varier en fonction de l'ampleur de la violation de l'alarme.

Une autre chose à noter est que les actions planifiées dans AWS peuvent modifier tous les paramètres des groupes de mise à l'échelle automatique, c'est-à-dire les capacités minimale, maximale et souhaitée du groupe de dimensionnement automatique. Les capacités minimale et maximale définissent les limites inférieure et supérieure du groupe de mise à l'échelle automatique, tandis que la capacité souhaitée est le nombre réel d'instances du groupe et est également modifiée par d'autres politiques de dimensionnement en place.

Politiques de dimensionnement d'Azure

Le service Azure Autoscale ne fournit qu'une mise à l'échelle simple et planifiée.

Il est possible de définir des règles pour de nombreuses métriques différentes et d'augmenter ou de diminuer le nombre d'instances, ou le pourcentage.

En outre, le nombre d'instances peut être modifié en fonction d'un calendrier spécifique.

Cependant, le dimensionnement planifié est un peu moins flexible que les actions planifiées d'Amazon, car il ne permet pas de modifier la capacité minimale et maximale du groupe de dimensionnement automatique.

Politiques de dimensionnement de GCP

Contrairement à Azure, les groupes d'instances gérés dans Google Cloud peuvent être redimensionnés à l'aide du suivi des cibles et de calendriers de dimensionnement automatique.

Notez que vous avez la possibilité de choisir un « mode de mise à l'échelle automatique » entre deux options : « Activé » et « Scale-out ». Ce dernier ne fera qu'ajouter des instances au groupe et empêchera la réduction des effectifs.

Instances ponctuelles

Il s'agit d'une fonctionnalité cruciale dans les groupes de mise à l'échelle automatique, car elle permet de réduire considérablement les coûts.

Les instances Spot sont des instances inactives qui sont disponibles avec une réduction importante (généralement entre 60 et 90 % du prix normal). L'inconvénient est que ces machines ne sont pas toujours disponibles et peuvent être préemptées par le fournisseur de cloud si la capacité de calcul est nécessaire, à tout moment. Ces types d'instances sont donc adaptés aux charges de travail sans état et tolérantes aux pannes.

Bien que les trois fournisseurs de cloud prennent en charge les instances Spot pour des machines virtuelles uniques, nous aimerions comparer les éléments suivants :

• Pouvons-nous utiliser des spots dans des groupes d'instances avec mise à l'échelle automatique ?
• Est-il possible de mélanger des types d'instances à la demande (c'est-à-dire réguliers) avec des instances ponctuelles dans un groupe ?

Instances AWS Spot

Les instances AWS Spot sont utilisables au sein de groupes de dimensionnement automatique, et il est possible de mélanger des instances ponctuelles à la demande au sein d'un groupe. Lors de la création d'un groupe, vous pouvez définir une « capacité de base à la demande », c'est-à-dire le nombre minimum d'instances à la demande dans le groupe et un pourcentage au-dessus de la capacité de base.

Par exemple, si vous avez 10 instances dans le groupe et que vous configurez une capacité de base de 2 et un pourcentage à la demande de 20 %, il y aura 2 + 20 % de 8 = 4 instances à la demande, et le reste sera constitué d'instances ponctuelles.

Instances Azure Spot

Depuis octobre 2022, Azure permet de mélanger des instances ponctuelles et régulières au sein d'un ensemble d'échelles de machines virtuelles. Pour ce faire, vous devez choisir un ensemble de balances « flexible ». La configuration est identique à celle d'Amazon, avec une base et un pourcentage d'instances régulières dans le groupe.

Instances GCP Spot

GCP autorise l'utilisation d'instances ponctuelles (et auparavant « préemptives ») au sein d'un groupe d'instances géré, mais contrairement à Azure et AWS, il n'est pas encore possible de mélanger des instances ponctuelles et à la demande.

Lorsque vous définissez un groupe d'instances géré dans Google Cloud, vous devez définir un « modèle d'instance » contenant la taille de la machine virtuelle et son type (spot ou à la demande). Ce modèle d'instance peut être modifié au fil du temps, mais il n'est pas possible d'utiliser les deux simultanément.

Différentes tailles de machines virtuelles (VM) : uniquement dans AWS

Selon votre cas d'utilisation, vous pouvez vous rendre compte que plusieurs types d'instances sont adaptés pour faire partie de votre cluster de dimensionnement automatique. Par exemple, si votre charge de travail ne nécessite que 16 processeurs, vous trouverez plusieurs types de machines virtuelles pour cette tâche : par exemple, AWS m5.4xlarge et c5.4xlarge, Azure F16 et D16, ou Google c2-standard-16 et n2-standard-16, répondent tous à cette simple exigence.

C'est pourquoi il serait intéressant de tirer parti de cette puissance lors de l'utilisation d'instances Spot dans un cluster. N'oubliez pas que la disponibilité des instances Spot n'est pas garantie à un moment donné, ce qui signifie que la fin d'un événement de scale-up n'est pas garantie.

AWS permet de spécifier plusieurs types d'instance, en utilisant des politiques d'instances mixtes.

Par exemple, vous pouvez spécifier à la fois c5.4xlarge et m5.4xlarge dans cette configuration. La prochaine instance spot lancée sera choisie parmi les deux en fonction des critères que vous définissez : elle peut être la plus disponible des deux types, ou la moins chère.

En outre, Amazon a mis en place une stratégie de « pondération », qui vous permet d'attribuer encore plus de types d'instances et de leur attribuer des pondérations. Par exemple, vous pouvez ajouter c5,8xlarge au cluster, avec un poids de 2 : ce qui signifie que 1 c5,8xlarge sera équivalent à 2 c5,4xlarge (le poids par défaut est 1).

Conclusion

Bien qu'AWS soit sans aucun doute le gagnant de cette comparaison concernant ce service spécifique, certaines choses sont remarquables.

Tout d'abord, Azure réalise (à ce jour, fin 2022) des progrès significatifs en matière d'ensembles d'échelles flexibles, et a récemment introduit la possibilité de mélanger des instances ponctuelles et régulières. Deuxièmement, de nouveaux progrès ont été réalisés dans d'autres domaines, comme la possibilité d'utiliser un autre type de mise à l'échelle, connu sous le nom de mise à l'échelle prédictive, qui est désormais pris en charge par les trois clouds.