Tests de montée en charge sur Google Kubernetes Engine : ce qu’il faut savoir avant de se lancer

Le passage à l’échelle d’une application n’est pas toujours évident. Des systèmes qui se montrent prévisibles et fiables à petite échelle peuvent avoir un comportement chaotique et incontrôlable lorsqu’ils sont passés à l’échelle, mettant ainsi en évidence les limites de leur conception logicielle ou exhibant un fonctionnement avec des performances dégradées, voire pas de fonctionnement du tout.

Pour éviter ces désagréments, il est essentiel de pouvoir tester leur déploiement à grande échelle avant de les passer en production. 

Pouvoir prédire les performances et la fiabilité d’une application lors de son passage à l’échelle demeure toutefois une opération complexe qui suppose une attention particulière. En général, la quantité de ressources informatiques attribuées à un système permet de prédire son fonctionnement lors du passage à l’échelle. Mais il arrive que d’autres facteurs doivent également être pris en compte, comme le nombre de connexions simultanées et le nombre de clients (tenants) ou encore les règles de sécurité à appliquer. 

En outre, la façon d’effectuer les tests de montée en charge dépend de la nature même de l’application : nouveau produit, migration en provenance d’un autre fournisseur de cloud, redimensionnement d’un existant… En nous basant sur notre expérience des grands clusters Google Kubernetes Engine (GKE), nous partageons ici les meilleures pratiques ainsi que les conseils que nous donnons aux clients GKE lorsqu’ils cherchent à monter en charge sur leurs workloads.

Avantages des tests de montée en charge

Le principal avantage des tests de montée en charge est de permettre d’identifier les goulets d'étranglement et les optimisations à réaliser qui n’apparaissent pas forcément à une échelle inférieure, de sorte que l’application fonctionne bien et de façon fiable une fois passée à l’échelle. 

Mais ces tests présentent également d’autres avantages :

• Gagner en confiance. Si vous avez réussi à faire passer votre application au double de sa taille actuelle, vous devriez vous sentir tranquille à l'idée de la faire fonctionner à son échelle normale. 

• Anticiper les problèmes potentiels. Les tests peuvent vous inciter à améliorer vos procédures d'observabilité. Par exemple, de nombreux clients ne supervisent pas la latence de l'API GKE. Mais lorsqu'ils remarquent à quel point le suivi de la latence de l'API Kubernetes permet de détecter les premiers signes d’un problème sur le « Control Plane », ils décident de l'ajouter à Cloud Operations, la suite d'observabilité de Google Cloud. 

• Vérifier le coût d’exploitation de l’application passée à l’échelle. Typiquement, rapporté au nombre de sessions, d'utilisateurs ou de traitements exécutés, le coût d'exploitation d’une application passée à l’échelle peut être moins élevé, ce qui surprend parfois les clients.

Définir les objectifs des tests de montée en charge

Définir des objectifs pertinents pour ses tests de montée en charge est essentiel. Tester des hypothèses erronées peut coûter cher. De plus, aux coûts réels des tests, s’ajoute le risque de créer un faux sentiment de confiance dans le fonctionnement de l’application : Mal définir ses objectifs peut engendrer de graves incidents lors de la mise à l’échelle en production.

De façon générale, vos objectifs doivent être exprimés sous la forme d'une valeur orientée métier. Ils doivent aussi être mesurables. Exemples : doubler le nombre de tâches traitées simultanément, tripler le nombre de requêtes d'utilisateurs par seconde ou être en mesure de gérer une panne dans une région. Prenez cet objectif et affichez-le bien en vue sur votre tableau de bord des tests.

Vous devez également faire correspondre ces objectifs avec des quantités de ressources identifiées. Par exemple, si vous redimensionnez le système existant, la méthode la plus courante consiste à supposer une croissance linéaire de l'utilisation des ressources et à ajouter une marge de sécurité. Ainsi, si un système fonctionne de manière fiable avec 100 000 CPU et que vous souhaitez doubler les performances, vous pouvez passer à 250 000 CPU.
Ces hypothèses brutes effectuées pour redimensionner le système testé ne sont bien sûr qu’une estimation, mais elles permettent de se faire une idée de la marge de manœuvre dont on dispose avant d’atteindre les limites matérielles du système. Il faut bien entendu profiter des tests pour confirmer ces estimations.

Voici une liste de ressources à vérifier lors du passage à l’échelle :

• Nombre de nœuds/Pods/containers

• Nombre de services

• Nombre de namespaces

• Quantité de CPU/GPU/mémoire

• Nombre de secrets/ConfigMaps/CRDs

Assurez-vous d’en provisionner suffisamment pour le passage à l’échelle.

De plus, vérifiez l’utilisation typique des ressources de Google Cloud, comme le nombre de VPC, leurs instances et alias, ou le nombre total de clusters ou de nodepools (pools de nœuds) dans le projet.

Les grands systèmes peuvent être très fiables tant que les choses sont stables. C'est souvent à l’occasion de changements que les choses commencent à mal tourner. Pour construire un scénario de test approprié, vérifiez les points de friction les plus courants pendant le test. On peut notamment citer la mise à niveau de clusters, les pannes de zone ou des préemptions importantes de PVM (Preempible Virtual Machine, des VM à bas coûts qui peuvent être interrompues à tout moment par le fournisseur Cloud). Assurez-vous que toutes les métriques et tous les logs sont correctement collectés pendant la procédure de test.

Quantifier le coût des tests de montée en charge

Les tests de montée en charge peuvent être très coûteux, c’est certain. Dans les cas extrêmes, ils peuvent coûter jusqu’à des centaines de milliers d’euros ! Nous sommes bien placés pour en parler : nous testons les versions de GKE chez Google Cloud avec parfois jusqu’à 20 configurations de tests différentes sur 15 000 nœuds, et ceci au moins deux fois par semaine. Nous vérifions également la montée en charge des versions open source de Kubernetes, en effectuant 5 000 tests de nœuds par jour.

Même si vous effectuez vos tests de montée en charge sur une configuration minimale, vous devez toujours optimiser vos coûts. Le moyen le plus simple d’y parvenir est d’effectuer des tests aussi courts que possible. Nos tests internes en sont un bon exemple : nous avons optimisé une procédure de test qui prenait 15 heures et l’avons ainsi réduit à moins de trois heures, tout en conservant le périmètre du test inchangé.

Voici quelques méthodes d’optimisation que vous pouvez utiliser :

• Effectuez vos tests avec des ressources informatiques moins coûteuses. Si possible, exécutez vos tests sur des machines virtuelles Spot, qui sont jusqu'à 91 % moins chères que les instances ordinaires.

• Simplifiez la couche de stockage. Tant que vous ne testez pas la couche de stockage elle-même, vous pouvez remplacer les cibles par défaut (Cloud Storage, LocalSSD) par des disques persistants standard (plus économiques).

• Lorsque c’est possible, optimisez les workloads de test en restreignant les ressources mémoire et CPU des containers par rapport à ce que vous utiliserez en production.

Par ailleurs, lorsque vous estimez le coût de vos tests, n’oubliez pas d’inclure tous les postes de coûts (compute, réseau, stockage) en les estimant à leur valeur maximale attendue. Pour évaluer la durée du test, pensez à inclure le temps nécessaire pour une montée à l’échelle puis pour une réduction des capacités. D'après notre expérience, vous aurez besoin d'au moins deux ou trois tests complets pour atteindre votre objectif.

Enfin, sachez qu’il n’existe pas de recette miracle : vous devrez trouver le meilleur équilibre entre l’optimisation des coûts et l’obtention de résultats sur un système aussi proche que possible de l’environnement de production.

Préparation de l'infrastructure

Lorsque vous exécutez des tests de montée en charge de grande envergure, nous vous conseillons de le faire au sein d’un projet Google Cloud distinct, avec un compte dédié en termes de facturation. En procédant ainsi, vous pouvez gérer les quotas (ressources Google Cloud) de vos différents projets de manière indépendante. Autrement dit, vous pourrez attribuer un quota spécifique à votre projet de test en fonction des ressources que vous envisagez d’utiliser. Aidez-vous des bonnes pratiques listées dans la documentation GKE Plan for large workloads | Google Kubernetes Engine (GKE) afin d’ajuster au mieux vos quotas. Prenez le temps de bien configurer le réseau. Définissez l'adressage CIDR ou les équilibreurs de charge (Load Balancers) afin de monter à l’échelle dans différentes dimensions à commencer par les plus communes telles que le nombre de nœuds, de pods ou de services. Pour optimiser votre démarche, nous vous conseillons également de vous inspirer de la documentation GKE address management: Introduction and overview | Cloud Architecture Center.  

Bien qu’il soit techniquement possible d’effectuer vos tests de montée en charge sans l’aide de l’équipe Google Cloud en charge de votre compte, nous vous conseillons néanmoins de l’impliquer dans votre démarche dès le début du projet. Ainsi, elle pourra vous aider à comprendre les limites de la plateforme et vous mettre en contact avec des experts sur le sujet. Vous pourrez même avoir accès aux meilleures pratiques et aux solutions provisoires de contournement d’un problème avant même qu’elles ne soient rendues publiques.

Nous vous conseillons également d’informer l’équipe Google chargée de la gestion des ressources et de l’inclure également à votre projet dès la phase de préparation. Certaines périodes de l'année se prêtent moins bien que d'autres à l'exécution de volumineux tests de montée en charge. Typiquement, nous vous déconseillons les périodes du Black Friday, Cyber Monday ou encore autour du réveillon du Nouvel An. De fait, le premier trimestre de l'année constitue le moment idéal pour préparer vos tests et le second trimestre pour les exécuter. 

Une fois le calendrier des tests fixé, prévoyez un essai rapide quelques jours avant la réalisation du test en situation réelle : vous pourrez ainsi vérifier que tous les « tuyaux » sont correctement connectés. Dernière étape avant de vous lancer, assurez-vous d’avoir bien rédigé tous les scénarios de tests et prouvé qu’ils fonctionnent, d’avoir enregistré la configuration de vos tests dans des « repositories » et d’avoir prévu des tableaux de bord pour afficher les résultats de vos tests.

Exécution des tests

Chaque exécution de test est différente. Toutefois, on constate de nombreux points communs entre les tests réussis. Exécuter le test avec la bonne équipe est sans doute la règle la plus basique à respecter. Votre équipe peut être constituée de DevOps, d’architectes ou de développeurs. Certains de nos clients prévoient une journée dans l’agenda de leur équipe pour organiser une « war-room » (réunion de crise). Réunir tous les architectes et développeurs au même endroit peut aussi être une excellente idée pour trouver des solutions plus rapidement en cas de problème.

Attendez-vous à ce que certains composants du système testé soient instables pendant la phase d’exécution. L'objectif d'un programme de test est de collecter autant de données que possible afin d’identifier les comportements problématiques et les résoudre. Dans cette perspective, nous avons tendance chez Google Cloud à enregistrer tous les échanges et toutes les investigations menées pendant les phases de tests : combinés aux logs et métriques collectés, ces enregistrements peuvent être très utiles au débogage par la suite. 

Le compte-rendu du test doit non seulement inclure des métriques techniques mais aussi une ventilation des coûts par ressource. Elle vous sera très utile pour estimer le coût du fonctionnement de votre application à grande échelle.  

Ayant effectué de nombreux tests de montée en charge, nos ingénieurs sont des experts dans ce domaine. Malgré tout, ils détectent généralement plusieurs problèmes lors du premier essai et il est rare qu'un seul essai suffise pour atteindre les objectifs du test. En fonction de l'ampleur des ajustements nécessaires, vous devrez généralement procéder à une nouvelle exécution du test dans un délai d'environ un mois. Parfois, vous devrez procéder à une refonte plus approfondie ou exécuter une nouvelle série de tests. Mais n’oubliez pas que sans les tests, vous n'auriez jamais pu anticiper ces questions avant qu’elles ne deviennent un problème en production !

En résumé…

Le redéploiement vers le cloud vous donne l'occasion de reconsidérer les machines que vous utilisez pour vos workloads sous un angle nouveau et intéressant. Un des grands avantages du cloud est d’être piloté par le logiciel. Un logiciel qui devient dès lors la principale interface pour interagir avec le réseau, le stockage, les workloads et les systèmes sous-jacents qui les gèrent. Cette approche ouvre la voie à une infinité de façons d’intégrer, imaginer et utiliser le cloud.

Tester les modifications apportées à votre code fait partie intégrante de la culture moderne du cycle de vie du développement logiciel. Dès lors que l’on considère les systèmes cloud sous cet angle logiciel, il devient évident que chaque changement apporté au système se traduit par une évolution de l’environnement qui doit être traitée comme une nouvelle version. Ceci est vrai que ce changement est une nouvelle version de Kubernetes, un nouveau composant comme une base de données en mémoire, un système de cache ou encore une évolution de l’architecture telle qu’un passage d’un déploiement mono-cluster à un multi-clusters.

Bien que le coût des tests de montée en charge puisse être considérable, c'est souvent le moyen le plus efficace et le plus rapide pour préparer son système à fonctionner à plus grande échelle. Nous sommes convaincus que GKE est la meilleure plateforme pour exécuter des workloads conséquents et complexes. S’aligner sur les meilleures pratiques que nous avons nous-mêmes développées et expérimentées au fil des années en développant et testant Kubernetes et GKE peut simplifier votre démarche. Nous sommes ravis de partager notre expérience afin de vous aider à construire le système le plus avancé possible en vous appuyant sur notre plateforme. Suivez ce lien pour en savoir plus sur les meilleures pratiques dans le domaine de la scalabilité avec GKE, ou contactez le responsable technique de votre compte si vous souhaitez en parler davantage.