Une des raisons de passer sur le cloud (Azure ou autre), est notamment de s’affranchir des contraintes matérielles et de pouvoir par conséquent adapter la consommation d’une application ou d’un service « à la volée ». Aussi, comprendre et maîtriser le service Azure Autoscale peut être très utile afin d’optimiser vos coûts tout en répondant à vos besoins de charge !
Table des matières
À quelles problématiques répond Azure Autoscale?
S’adapter aux pics utilisateurs
Quelle startup, quelle PME n’a jamais connu son site ou son service ralentir à cause d’un pic de trafic plus ou moins imprévu ? Voici quelques cas que j’ai pu rencontrés plus ou moins directement :
- Les e-commerces, à chaque solde (ou évènement du même genre). En général on a droit à une augmentation du trafic habituel assez violente (x10, x100 …), ce qui est souvent anticipé avec appréhension
- À peu près n’importe quel site après un spot de pub TV un peu trop efficace
- Ou simplement si vous êtes sujets aux saisons, aux horaires…
Si certains de ces cas peuvent être anticipés, ce n’est pas forcement toujours le cas. Et surtout, l’important est de savoir dans quelle proportion il va falloir s’adapter ! Si vous évaluez un pic à x100 et que vous avez besoin que de 2 fois plus de « puissance », alors vous allez perdre de l’argent. A l’inverse, si vous estimez trop à la baisse et que votre application est dégradée, voir tombe, c’est votre image qui en pâti !
Le premier point important d’Azure Autoscale est donc de répondre aux pics de charges dans les proportions adaptées !
Éviter la gestion manuelle des performances
S’adapter aux pics de charge, c’est bien. Le faire automatiquement, c’est mieux ! Et c’est évidemment le rôle de ce service.
Plus besoin de surveiller constamment vos métriques de charge afin de voir quand ajuster la puissance. Ici, l’idée est que cet ajustement se fasse seul, en respectant les règles d’automatisation que vous avez décidées !
Ainsi, vous déciderez :
- Sur quels critères vous souhaitez voir un ajustement de puissance (CPU, mémoire, heure de la journée…)
- dans quelles proportions vous souhaitez voir l’augmentation se faire (afin de garder un contrôle sur les coûts)
Étant donné sur les règles que vous allez construire se base sur des métriques continuellement observées par Azure Autoscale, l’ajustement se fera rapidement et automatiquement. Plus besoin de stresser en restant les yeux rivés sur les métriques de vos machines !
Optimiser votre facture avec Azure Autoscale
Voilà un sujet FinOps fort intéressant : l’optimisation des coûts. En soi, ce point est couvert par les deux précédents. En effet :
- L’ajustement adapté de la puissance en fonction de vos besoins fait que, par défaut, vous ne consommez que ce dont vous avez besoin ! Plus besoin de réserver à l’année un serveur surpuissant en prévision des soldes du mois prochain.
- Vous pouvez faire des économies importantes sur les moments où vos machines peuvent être peu utilisées. Par exemple, en pleine nuit, ou à certains moments de la journée
- C’est vous qui déterminez les limites basses et hautes de l’ajustement de puissance. Ainsi, même si la consommation (et donc la facturation) s’adapte, vous conservez la maîtrise en connaissance d’avance la fourchette possible
Qu’est-ce que le scaling d’une application ?
Le scaling vertical (ou scale up)
Le scaling vertical est probablement le plus connu, car c’est le modèle « legacy ». Il s’agit d’augmenter ou de réduire la puissance même du service que l’on consomme.
On travaille surtout aujourd’hui sur des environnements virtualisés, mais si on devait faire le parallèle avec une machine physique, cela consisterait à augmenter la mémoire et/ou le processeur d’un serveur par exemple.
Ce scaling est simple à mettre en place, car on garde un seul service, ce qui facilite beaucoup les choses en termes de gestion d’application et d’infrastructure réseau. Cependant, c’est aussi le moins efficace, car chaque service possède une limite en termes de puissance proposée. Typiquement, ce type de scaling est uniquement proposé en gestion manuelle.
Cet ajustement de puissance va cependant service au second type : le scaling horizontal !
Le scaling horizontal (ou scale out)
Le scaling horizontal, à l’opposé donc du vertical, va consister à ajouter des copies de la machine de base qui a été sélectionnée. On va ainsi faire tourner l’application sur plusieurs serveurs, ce qui permet de partager la charge, et donc de répondre au besoin de disponibilité du service.
Ce type de scaling à plusieurs avantages :
- Il est très facile à mettre en place : il suffit souvent de pousser un curseur ou d’écrire une règle de paramétrage pour déployer autant de copie que l’on souhaite
- On maîtrise le nombre de copies déployées
- Les copies sont basées sur la puissance choisie au départ dans le cadre des services type Azure App Service, Azure SQL Hyperscale ou Azure PostgreSQL Hyperscale
- On peut atteindre une puissance cumulée bien plus grande que part le scaling vertical, car nous ne sommes pas contraints aux limitations physiques d’une machine
- Si on peut recréer ce type de service nous-mêmes (en déployant plusieurs VM et avec du load balancing ou du reverse proxy), c’est quand même nettement plus aisé de le déployer et le maintenir. En fait, typiquement, on laisse Azure gérer justement toute l’infrastructure de répartition de charge pour nous. Et c’est très bien !
Par contre, il faut garder en tête que son application risque de tourner sur plusieurs serveurs séparés. En fonction de votre application, une réflexion d’architecture peut être indispensable. L’utilisation de services externes tels qu’un service de cache partagé ou encore un serveur SignalR peut être important à envisager dans ce cas.
Quels sont les services concernés ?
Il existe principalement deux services sur lesquels vous pouvez appliquer Azure Autoscale :
- Les VM (notamment avec les scale set)
- Les App Services Plan
Personnellement, je trouve que ce service est particulièrement efficace pour les App Service Plan et le serverless en général (voir 🔎 Qu’est-ce que le serverless ?), notamment car on est sur du PAAS et non du IAAS. Du coup, on allège d’autant la gestion de l’infrastructure en s’occupant du minimum de configuration nécessaire pour la gestion de l’application et de son environnement.
Si vous êtes sur une consommation « App Service Plan » pour vos Azure Function, il est aussi possible de profiter du Azure Autoscale pour ce service, ce qui peut être là encore très pratique (NdlA : voir ⚡ Que sont les Azure Functions ?).
Enfin, même si ce n’est pas directement le service Azure Autoscale, sachez que le ‘scaling out’ est aussi disponible sur d’autres services, comme par exemple Azure SQL Hyperscale et Azure PostgreSQL Hyperscale.
Comment paramétrer Azure Autoscale ?
Le paramétrage d’Azure Autoscale se décompose en trois parties :
- Les règles de ‘Scale out’, déterminant quand vous souhaitez augmenter le nombre d’instances
- Les règles de ‘Scale in’, qui à l’inverse réduiront le nombre d’instances pour économiser quand c’est possible
- Et les limites d’instances. Ces limites vont permettre
- d’éviter de trop réduire la charge pour éviter que sur un afflux massif, votre application se retrouve à ne pas pouvoir répondre le temps que le ‘Scale out’ se mette en place
- d’éviter d’avoir un ‘Scale out’ qui déploie un nombre de machines non maitrisé, faisant ainsi exploser votre facturation
Les différents types de conditions
Comme on peut voir dans l’écran ci-dessus, il existe deux types de conditions, dans lesquelles nous allons ajouter nos règles :
- La condition par défaut, qui comme son nom l’indique, sera celle qui sera toujours appliquée. Vous allez ajouter ici vos règles principales
- Les conditions basées sur des plages de dates spécifiques. Elles peuvent vous servir à prévoir des scénarios plus ou moins exceptionnels, comme par exemple :
- une plage de date sur une saison particulière (soldes, vacances, etc.)
- certains créneaux horaires spécifiques (gestion de la nuit, du week-end…)
Les règles Azure Autoscale
La partie importante d’Azure Autoscale sont les règles de ‘Scale in’ et ‘Scale out’.
Ces règles se basent sur les métriques Azure Monitor. Elles sont assez nombreuses, et vous pouvez donc vous baser sur :
- le % de CPU
- le % de mémoire
- des informations réseau (nombre de connexions, datas reçues, etc.)
Sur cette métrique de base, on va pouvoir jouer avec les méthodes d’agrégation et les opérateurs pour obtenir une règle qui fonctionne comme on le souhaite. L’observation d’Azure Monitor va aussi être programmée sur une certaine plage de temps, afin d’éviter de prendre une décision sur un pic de charge momentané.
La partie la plus intéressante (à mon sens) sur l’établissement de la règle, c’est la visualisation de cette dernière justement. Un graphique est proposé qui correspond à votre règle. Sur l’exemple ci-dessus, on voit l’utilisation du CPU (~20%), et en pointillé la règle proposée qui s’active si le CPU dépasse 90%. Le % moyen est aussi directement affiché, permettant d’avoir la valeur concrète de comparaison avec la règle (ici, 19.49%).
Vérifier le bon fonctionnement des règles
Comme nous l’avions vu un peu plus haut, il est possible de suivre l’évolution via l’écran de monitoring proposé à cet effet dans l’onglet « Run History ». Il est alors possible de vérifier que les règles s’activent bien comme et quand on le souhaite, et de faire les ajustements nécessaires.
Combien ça coûte ?
Ce service se base sur la surveillance des métriques de vos machines. Donc ça dépend surtout de combien de métriques et de machines vous surveillez. D’expérience, Azure Autoscale ne va vous consommer que quelques centimes par mois pour l’ajustement d’une machine. Autant dire que ça coûtera moins cher que 5mn du temps d’une personne chargée de surveiller tout ça.
Azure Autoscale : Conclusion
Azure Autoscale est un petit service qui se met rapidement en place, notamment si vous utilisez déjà les App Service Plans pour l’hébergement de vos applications et Azure Function. Il permet d’ajuster la puissance de votre Plan en fonction du besoin, en montant comme en descendant, permettant ainsi de maximiser la disponibilité de votre application en même temps que le coût ! Le service en lui-même ne coûtant quasiment rien, il serait dommage de s’en priver 😁.
Plutôt que de penser uniquement au Scale Up, une bonne stratégie peut être le Scale Out, qui sera probablement plus économe.
Et si vous n’utilisez pas de service disponible via Azure Autoscale, pensez qu’il peut être possible et intéressant de mettre en place une stratégie de Scale Up / Scale Down automatique via des services tels que Azure Logic App et une ou deux commandes Powershell 😉