Ceci est le troisième épisode d’une série d’articles décrivant des solutions simples que le cloud apporte à des problèmes compliqués auxquels j’ai été confronté dans ma carrière.
“La nouvelle version de l’appli ralentit tout ! Faut vite trouver le problème et patcher avant le pic de charge, on ne tiendra pas !” (MJ, stressé à l’idée de devoir sacrifier son week end encore une fois)
On a beau faire des tests de performance avant les versions majeures, ça arrive qu’un changement applicatif qu’on croyait mineur, ou que la réalité de la charge par rapport à ce qu’on a prévu, sature le système. Il y a aussi le cas (que toute DSI a déjà rencontré, ceux qui prétendent le contraire, j’ai du mal à les croire) où on est un peu contraint par le délai et que les tests de performances ne sont pas vraiment exhaustifs.
Et là, quand on fait tourner l’appli sur son infra maison, on n’a pas beaucoup de solutions. On peut essayer de couper des fonctions non critiques, des scripts, des batches, … mais il n’y a pas de magie, si l’appli est plus gourmande que prévu, les infras ne suivent pas forcément.
Sur AWS, on peut “scaler”, de 2 façons. Soit mettre plus de machines en parallèle (scaling “horizontal”), soit remplacer des machines trop petites par des plus grosses (scaling “vertical”). Les 2 sont plutôt simples.
Le “scaling horizontal” est typiquement mis en oeuvre pour des frontaux web, ou pour des microservices. Quand la charge augmente, on ajoute des machines. Comment on fait ? Et bien c’est simple, on crée un groupe d’auto-scaling, on met les frontaux web dedans, on définit une règle (du genre quand le taux d’utilisation du processeur est supérieur à 75% deux minutes de suite) qui déclenche l’ajout d’une machine dans le groupe, on met une règle à la baisse aussi, et on met un équilibreur de charge devant. C’est tout. On peut aussi faire ça avec des containers pour des microservices…
Le “scaling vertical”, c’est pareil, ce n’est pas très compliqué. Je vais prendre pour exemple un blog wordpress hébergé sur cette architecture de référence wordpress. Si je veux basculer sur une instance de base de données de plus grosse taille (en imaginant que le blog ait un succès important…), je n’ai rien d’autre à faire que de… changer d’instance et le système se charge du reste qui est compliqué (basculer vers la secours - arrêter la première, changer d’instance, redémarrer la base, synchroniser les données, rebasculer vers le principal, puis changer l’instance de secours aussi).
Du coup, si on revient au problème de départ : une mise à jour un peu gourmande en ressource ? Pas grave, on augmente les capacités quelques jours, le temps de trouver la cause, et on revient à la dimension initiale ensuite. Coût : quelques jours d’une infra plus grosse, c’est à dire très faible. Temps d’arrêt du système : zéro. Impact sur les utilisateurs : aucun. Retard de mise en production : aucun. A nouveau, si on regarde les problèmes de retard des grands projets de l’Etat, l’échec des tests de performance, alors que le projet est largement avancé, est un sujet récurrent : c’est un moyen de surpasser cette difficulté.
Du mal à y croire ? Testez donc, par exemple sur une architecture de référence Wordpress : créez un compte AWS, montez l’architecture, jouez à augmenter et diminuer la taille des machines, et vérifiez !
J’ai bien sûr pris des exemples plutôt simples, et comme pour tous les sujets en matière d’informatique, la performance d’un système repose d’abord sur une conception initiale de l’architecture adaptée à ce que l’on veut faire, et ensuite sur un travail d’optimisation progressive, et enfin, pour des besoins très pointus (calcul intensif, temps réel critique, …), sur du travail de spécialistes. Si la question de la performance dans le cloud vous intéresse, je vous encourage à regarder cette vidéo, qui explique les différentes stratégies envisageables depuis 1 utilisateur jusqu’à 10 millions d’utilisateurs pour votre application dans le cloud.