Site icon A DevOps journey

Adaptez la consommation de votre app avec Azure Autoscale

Logo Azure Autoscale

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 !

À 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 :

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 :

É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 :

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.

Les différents types de plans proposés pour le scaling vertical des Azure App Services Plan

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.

Schéma scale in vs scale out. Source

Ce type de scaling à plusieurs avantages :

Exemple d’ajustement du nombre d’instances de l’application en fonction de la charge, sur une journée

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 :

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 :

Exemple de paramétrage d’Azure Autoscale. La règle par défaut permet d’avoir jusqu’à 3 instances au maximum, en déployant une nouvelle chaque fois que la puissance utilisée est supérieure à 90% du CPU. Dès qu’elle redescend en dessous de 70%, une instance est de nouveau détruite. La seconde règle est spécifique pour la période de solde par exemple

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 :

Exemple de condition Azure Autoscale qui détermine que, le week-end, seule 1 instance sera en place

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 :

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é.

Exemple d’une règle Azure Autoscale

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.

Exemple d’historique Azure Autoscale sur l’évolution de l’instance

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 😉

Quitter la version mobile