Autoscaling : Scaler automatiquement votre application sur la base de ses métriques !

Bonne nouvelle ! La fonctionnalité Autoscaling est maintenant disponible sur Scalingo !

Cette fonctionnalité était disponible sur demande depuis 18 mois, et nous sommes ravis d'annoncer que vous pouvez maintenant profiter de la fonctionnalité directement sur notre dashboard.

Dans cet article, nous allons expliquer à quoi sert l'autoscaling et comment vous pouvez en bénéficier sur Scalingo.

A quoi sert l'autoscaling ? (et pourquoi cela peut simplifier votre vie de développeur)

Vous le savez : Scalingo permet de faire évoluer votre application en quelques minutes. En un seul clic, vous pouvez faire passer votre application de un à des centaines de conteneurs !

La fonctionnalité que beaucoup d'entre vous attendaient est la mise à l'échelle automatique basée sur les métriques de l'application.

Vous l'avez compris : c'est ce que l'on nomme l'autoscaling.

Pour faire simple, voici un cas d'usage typique de la fonctionnalité d'autoscaling :

Vous avez développé une application que vous avez judicieusement choisi d'héberger sur Scalingo.

Au début, votre application n'est pas très utilisée et vous la mettez à l'échelle sur 2 conteneurs.

Sans vous avertir au préalable, quelqu'un publie votre application à la une de Hacker News et votre application est soudainement surchargée par les demandes des utilisateurs.

Votre application se plante car vous n'aviez pas prévu de recevoir autant de demandes. Tous ces clients potentiels ne seront jamais en mesure d'accéder à votre application. Le temps que vous mettiez manuellement votre application à l'échelle, le pic de trafic est passé et votre consommation de ressources est revenue à la normale.

Grâce à la fonction de mise à l'échelle automatique (autoscaling), vous pouvez définir un objectif pour l'une des métriques de votre application de sorte que l'autoscaler augmente et diminue automatiquement la charge de l'application.

Comment configurer un autoscaler pour votre application ?

L'autoscaler est configurable par type de conteneur via le tableau de bord Scalingo, dans la section Ressources. Il vous suffit de cliquer sur la flèche vers le bas près du bouton Scale, et configurez l'autoscaler pour le type de conteneur que vous souhaitez :

L'autoscaler peut utiliser les métriques suivantes :

• CPU, RAM et swap : pourcentage de la consommation de cette ressource.
• Temps de réponse : 95ème percentile du temps de réponse des requêtes
• RPM et RPM par conteneur : demandes par minute (RPM) reçues par votre application. La métrique RPM par conteneur divise le RPM de l'application par le nombre de conteneurs.

Notez que les conteneurs non-web peuvent uniquement utiliser le CPU, la RAM et le swap pour définir un autoscaler.

Nous vous fournissons également une valeur recommandée que vous pouvez utiliser comme cible. Elle correspond à 90 % du maximum alloué à votre application pour le CPU et la RAM, à 10 % du maximum alloué à votre application pour le swap, et à la médiane des 24 dernières heures pour les autres métriques.

L'autoscaler ne fait monter ou descendre l'application que d'un seul conteneur. Après un événement de mise à l'échelle, l'autoscaler ne mettra pas l'application à l'échelle à nouveau avant au moins une minute. La réduction d'échelle est un peu moins agressive avec un refroidissement de trois minutes. Ces valeurs de refroidissement empêchent l'autoscaler de mettre à l'échelle l'application de manière frénétique.

Événements liés à l'autoscaling

Un événement est généré sur Scalingo lorsqu'un autoscaler est créé ou mis à jour :

Chaque fois qu'une décision d'autoscaling est prise, un événement est également créé. Cet événement apparaît sur la chronologie de l'application.

L'utilisateur responsable de l'opération est étiqueté scalingo-platform-autoscaler :

Comment fonctionne l'autoscaling ?

Afin de maintenir la métrique aussi proche de la cible que possible, nous avons conçu un algorithme basé sur un seuil.

Pour détecter qu'une augmentation ou une diminution de l'échelle est nécessaire, nous prenons une moyenne de la métrique sur les 5 dernières minutes et la comparons à deux limites.

La valeur associée à ces limites dépend de la métrique que vous avez choisie pour votre autoscaler et de l'objectif défini.

RPM par conteneur

La métrique RPM par conteneur est bien adaptée si vous connaissez votre application depuis longtemps et que vous savez qu'elle fonctionne bien si elle reçoit un nombre élevé de minutes de trafic. qu'elle fonctionne bien si elle reçoit un certain nombre de demandes par conteneur. La limite au-delà de laquelle l'application sera mise à l'échelle est :

La limite en dessous de laquelle l'application sera réduite est :

Voici le scénario typique qui explique ce choix.

Disons qu'un utilisateur définit la cible à 100 RPM par conteneur. L'application a 5 conteneurs et reçoit 500 RPM. La limite de montée en charge est de 120 et la limite de descente en charge est de 80.

Soudain, l'application reçoit 1000 RPM. Le RPM par conteneur est de 200 (au-dessus de la limite de mise à l'échelle de 120). Nous faisons passer l'application à 6 conteneurs. La limite de mise à l'échelle devient 117. Nous continuons à faire évoluer l'application jusqu'à 9 conteneurs. Le RPM par conteneur est maintenant de 111 et la limite de montée en charge est de 111. La limite de réduction d'échelle est de 89.

Puis le RPM tombe à 500. Le RPM par conteneur est de 56. Nous réduisons l'application à 8 conteneurs. Le RPM par conteneur est de 63 et la limite de réduction d'échelle est de 87,5.

Nous continuons à réduire l'application à 6 conteneurs où la limite de réduction et le RPM par conteneur sont égaux à 83.

Avec cet algorithme, nous sommes en mesure de maintenir le RPM réel par conteneur aussi proche de la cible que possible, sans avoir à augmenter ou à diminuer l'application.

Nous pensons que cette métrique et cet algorithme répondent à la plupart des besoins d'une application web classique.

Consommation de ressources

Un autre type de métrique dont vous pouvez avoir besoin est basé sur la consommation de ressources de votre application (c'est-à-dire CPU, RAM ou swap). Par exemple, vous ne voulez pas que votre application soit affamée par l'épuisement de la RAM.

Vous pouvez définir l'objectif à 80 %. La limite d'augmentation de l'application est égale à l'objectif. Ainsi, dès que votre application consomme plus de 80 % de la RAM, elle est mise à l'échelle pour répartir la charge entre plusieurs conteneurs. La limite pour faire évoluer l'application vers le bas est :

Autres métriques

Pour les autres métriques, les formules de limites sont :

Limites de l'autoscaling

L'autoscaler n'est pas une solution magique qui résout tous les problèmes de mise à l'échelle. Afin d'empêcher l'autoscaler de sur-réagir, nous avons ajouté des délais et des cooldowns qui induisent un temps de réaction plus faible. Il peut prendre un peu de temps pour se mettre en marche et il n'absorbera pas un pic soudain et élevé.

En outre, l'augmentation du temps de réponse ou de la consommation de ressources d'une application peut avoir différentes causes et une mise à l'échelle horizontale ne résoudra pas forcément le problème. Ces causes peuvent être :

• Une fuite de mémoire dans votre application.
• La base de données utilise toutes ses ressources.

Dans de tels cas, la configuration d'un autoscaler n'améliorera pas la réactivité de l'application. Il faut donc étudier ces problèmes avant d'activer un autoscaler.

Conclusion

Vous avez été nombreux à demander la fonctionnalité d'autoscaling et nous sommes très fiers de la rendre disponible aujourd'hui. N'hésitez pas à l'ajouter à votre application pour lui donner un filet de sécurité supplémentaire.

Image de bannière par Dan Meyers sur Unsplash