Auto-scaling ?

Dans un contexte croissant d’ouverture des systèmes d’information, le dimensionnement au plus juste des infrastructures techniques est un enjeu de taille. Comment faire pour estimer la charge que vont devoir supporter les serveurs de la nouvelle application web à mettre en ligne prochainement ? Comment va-t-on faire pour assumer le pic de charge soudain engendré par la dernière campagne marketing ?

Historiquement, pour dimensionner une infrastructure, on calcule à très grosse maille le nombre maximum d’utilisateurs accédant simultanément au système lors d’un pic de charge. Par sécurité, pour que l’infrastructure reste disponible, les équipes techniques appliquent un facteur de sécurité qui dépend de la criticité de l’application et du degré d’incertitude sur le pic de charge. Ce facteur est communément de l’ordre de 3 à 4 pour les applications sensibles. Avec ce mode de conception, nous aboutissons bien souvent à des ressources fortement sous-utilisées, ce qui est économiquement discutable… Et ne parlons pas de l’impact écologique !

C’est dans cette situation que le cloud public arrive à la rescousse avec sa capacité d’auto-scaling…

Architecture de référence pour l’auto-scaling

L’auto-scaling désigne un mécanisme qui permet à une infrastructure de se redimensionner de manière totalement autonome en fonction de la charge qu’elle absorbe. Pour illustrer la fonctionnalité d’auto-scaling d’une application web ou d’une API exposée sur Internet, voici une architecture de référence simplifiée.

 

Résultat de recherche d'images pour "auto scaling group"

Architecture de référence pour une application en auto-scaling

 

Le schéma ci-dessus représente un client qui se connecte au site dont le nom de domaine est ici géré par le service DNS Route53 d’AWS. L’URL du site est configurée pour orienter le flux vers un distributeur de charge (ou load balancer); le distributeur de charge va faire suivre à tour de rôle les requêtes des utilisateurs vers le serveur du datacenter A et celui du datacenter B : la charge est donc répartie uniformément entre ces deux serveurs. Lorsque la charge globale sur l’ensemble des serveurs dépasse un certain seuil, la magie de l’auto-scaling opère : un nouveau serveur est automatiquement créé pour augmenter la capacité de traitement et pour réduire la charge moyenne absorbée par chacun des serveurs.

 

Exemple d’implémentation de l’auto-scaling sur AWS

Configuration du modèle de serveur

Pour pouvoir bénéficier d’une infrastructure élastique, il faut au préalable construire une architecture qui s’appuie sur un modèle de serveurs. Ce modèle permet de provisionner un nouveau serveur hébergeant l’application avec des caractéristiques spécifiques : nombre et puissance des CPU, espace mémoire, espace disque…

C’est également dans la définition de ce modèle de serveurs que nous décrivons le type d’instances AWS que nous souhaitons utiliser. Il existe principalement trois types d’instances :

  • Les instances dites « à la demande » qui offrent la plus grande flexibilité, elles peuvent être créées immédiatement et sans engagement, la facturation cesse dès que l’instance est arrêtée.
  • Les instances dites « réservées » qui sont pertinentes lorsque l’on souhaite s’engager sur la durée sur un modèle de serveur bien précis. Cet engagement permet d’obtenir un rabais du provider cloud de l’ordre de 30% par rapport aux instances à la demande.
  • Les instances dites « spot » qui s’appuient sur un mécanisme disruptif de mise aux enchères ! Cette fonctionnalité spécifique au provider cloud public lui permet d’optimiser le taux d’utilisation de son parc avec un mécanisme de marché qui permet aux clients d’économiser jusqu’à 90% par rapport à des instances à la demande. En contrepartie, si un autre acquéreur place une enchère plus élevée que vous sur le même type de serveur, votre serveur sera arrêté pour être ré-attribué au plus offrant ! Idéales pour mettre en place des grilles de calcul distribué, ces instances sont donc à éviter pour les applications coeur de votre business avec un haut niveau de disponibilité.

Modèle de serveurs

 

En complément des caractéristiques hardware de la machine à instancier, ce modèle de serveur permet également de définir les instructions à exécuter au démarrage de la machine virtuelle. Dans notre cas, l’application web est démarrée et le serveur s’enregistre auprès du distributeur de charges, il devient donc éligible pour répondre aux demandes des utilisateurs.

Instructions de lancement pour démarrer l’application et s’enregistrer auprès du distributeur de charge

 

Création de l’auto-scaling group

Une fois la configuration du modèle de serveur terminée, il suffit de créer un groupe d’auto-scaling qui va se charger de contrôler notre ensemble de serveurs construits selon le même modèle. Dans ce groupe, nous allons spécifier certains paramètres structurants : le nombre d’instances initiales, le minimum d’instances à préserver, quelle que soit la charge, et le maximum d’instances afin de garder le contrôle sur la taille de l’infrastructure. Potentiellement, si l’infrastructure grossit d’elle-même de manière incontrôlée, nous pouvons être confrontés à une attaque externe de type DDoS, ou parfois plus simplement à un défaut d’implémentation dans le code de l’application… Rien n’est à exclure ! Le fait de limiter le nombre de serveurs permet dans tous les cas de contrôler la facturation du service !

Configuration de l’auto-scaling group

 

Élasticité du groupe d’auto-scaling

La vraie plus-value de ce mécanisme repose sur les « scaling policies ». Ce sont les règles qui permettent de déclencher la mise en route de nouvelles machines ou leur extinction en fonction de l’augmentation ou la diminution de la charge utilisateur. C’est cette intelligence, qui exploite les mécanismes de supervision du provider cloud, qui permet de bénéficier d’une infrastructure flexible capable de s’adapter en continu.

Dans l’exemple ci-dessous, nous définissons deux règles de mise à l’échelle. Une règle de « scale-up » qui permet de rajouter deux serveurs supplémentaires dans le groupe lorsque le système détecte que la charge moyenne par serveur est supérieure à 65% sur les 60 dernières secondes. Et une règle symétrique de « scale-down » qui retire deux instances du groupe lorsque le système détecte que la charge moyenne est descendue sous les 15% depuis plus d’une minute.

Scaling policies pour redimensionner notre infrastructure automatiquement

 

Démonstration réalisée par CACD2 lors du séminaire Cloud du 22 février 2019

Dans le cadre du séminaire Cloud tenu auprès des membres du comité des DSIs du Groupe, l’équipe d’architecture CACD2 a réalisé une démonstration « live » illustrant cette capacité d’auto-scaling sur une API fictive simulant un agrégateur bancaire. En utilisant un injecteur de requêtes ad-hoc, nous avons chargé notre API afin de saturer les serveurs et ainsi forcer l’auto-scaling group à provisionner automatiquement de nouveaux serveurs. Les écrans de suivi ci-dessous montrent l’augmentation puis la diminution du nombre de serveurs durant la démonstration.

Au démarrage de la démonstration, deux serveurs uniquement sont présents pour garantir la disponibilité de l’API

 

Une fois l’injecteur lancé, après quelques minutes, quatre serveurs deviennent actifs

Grâce à un tableau de bord graphique, nous avons pu suivre en temps réel l’adaptation de l’infrastructure sur les quinze minutes de la démonstration.

Nous constatons que l’augmentation du nombre de requêtes traitées par l’API provoque bien un usage élevé du CPU des serveurs. Rapidement, le taux d’utilisation des CPU dépasse le seuil défini dans la scaling policy. En réponse, deux serveurs sont ajoutés dans le groupe. Nous pouvons observer que cet ajout permet de répartir la charge sur davantage de serveurs et ainsi diminuer l’utilisation moyenne des ressources. Cependant, l’utilisation moyenne des serveurs restant au dessus du seuil fixé, deux instances supplémentaires sont ajoutées après quelques minutes. Ces deux nouveaux serveurs permettent de faire descendre l’utilisation moyenne du CPU en dessous du seuil critique : l’infrastructure s’est donc dimensionnée d’elle-même, au plus juste, sans aucune intervention humaine.

Une fois l’injecteur de requêtes arrêté, la charge CPU redescend soudainement. Après quelques minutes, les instances sont automatiquement détruites, seuls deux serveurs sont conservés pour préserver la haute disponibilité du système.

Conclusion

Le mécanisme d’auto-scaling permet de bénéficier d’une infrastructure capable de se redimensionner de manière autonome. Couplée au mécanisme de facturation à l’usage du cloud public, cette solution offre un avantage compétitif non négligeable sur le plan économique par rapport aux approches de dimensionnement traditionnelles. Cependant, ce principe ne permet pas d’assurer complètement la disponibilité d’une application en cas de pic de charge très brutal. En effet, le système nécessite souvent quelques minutes pour se redimensionner, le temps de constater que la charge subie dépasse les seuils critiques et le temps de démarrer les nouveaux serveurs. Dans ces situations, si le pic de charge brutal est prévisible, il est fortement recommandé de demander au système d’augmenter le nombre de serveurs quelques minutes avant l’arrivée du pic, afin de lui laisser le temps d’être pleinement opérationnel pour absorber la charge. L’auto-scaling est en revanche parfaitement adapté pour gérer un redimensionnement automatique de l’infrastructure pour une augmentation relativement lisse de la charge, comme pour gérer le classique pic de charge au cours du premier mardi du mois sur un site web bancaire.

Si ces problématiques vous intéressent, l’équipe d’architecture CACD2 se fera un plaisir d’échanger avec vous sur ces nouveaux usages.