View a markdown version of this page

GAMEOPS05-BP01 Choisissez le stage, l'architecture et le framework de test de charge adaptés à vos objectifs - Objectif de l'industrie du jeu

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

GAMEOPS05-BP01 Choisissez le stage, l'architecture et le framework de test de charge adaptés à vos objectifs

L'approche utilisée pour tester la charge d'un jeu peut varier considérablement en fonction de nombreux facteurs, notamment le stade du processus de développement dans lequel il est réalisé, l'architecture du système de génération de charge lui-même et le choix du framework de test de charge. Le moment où il est effectué, que ce soit dans les premières phases, pendant les sprints itératifs, avant le déploiement en production ou après le déploiement, déterminera les objectifs et l'orientation des efforts de test. Les différentes conceptions d'infrastructure génératrice de charge ont leurs avantages et leurs inconvénients, et le choix du framework de test de charge influence considérablement les capacités, la facilité d'utilisation et les intégrations disponibles pour le processus de test. En alignant judicieusement ces éléments, les équipes de développement peuvent adapter l'approche des tests de charge aux caractéristiques uniques du jeu, extraire les informations les plus précieuses sur les performances et offrir une expérience fluide à leurs joueurs.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé

Directives d’implémentation

Tests de charge à différents stades de développement

La réalisation de tests de charge exploratoires au début des phases de développement permet de valider l'architecture du système sous-jacent. Cela permet aux développeurs de prendre des décisions éclairées concernant l'infrastructure du jeu, la conception de la base de données et la topologie du réseau avant d'effectuer un travail de mise en œuvre approfondi. Les tests de charge identifient les risques et créent une référence de performance, ce qui permet de minimiser le besoin de retouches coûteuses et de dettes techniques plus tard dans le cycle de développement. Ils peuvent également favoriser une compréhension partagée des exigences de performance du jeu au sein de l'équipe, ce qui se traduit par une meilleure collaboration et une meilleure prise de décision. En fin de compte, les tests de charge effectués au cours des phases initiales constituent une base solide pour un jeu performant, évolutif et résilient, contribuant ainsi à améliorer l'expérience globale des joueurs.

À la fin de chaque sprint ou itération, les tests de charge permettent d'évaluer l'impact sur les performances des nouvelles fonctionnalités, des corrections de bogues et des autres modifications introduites au cours du dernier cycle. Cette approche ciblée permet aux équipes de développement d'identifier rapidement les régressions ou les dégradations de performances introduites par les dernières mises à jour, ce qui leur permet de résoudre ces problèmes avant qu'ils ne se propagent plus loin dans le pipeline et de maintenir un niveau constant de qualité et de performance.

Avant le déploiement en production, des tests de charge robustes aident les équipes à valider la capacité du système à gérer les conditions de trafic et de charge réelles prévues. Ils peuvent identifier les goulots d'étranglement liés à l'évolutivité ou les contraintes de ressources au sein de l'infrastructure de production et offrir la possibilité d'optimiser les performances du jeu, en créant une expérience utilisateur fluide et réactive dès le premier jour. Les informations recueillies lors des tests de charge effectués avant le lancement peuvent atténuer les risques liés au lancement et éclairer la planification continue des capacités, qui jette les bases de la durabilité et de l'évolutivité à long terme du jeu.

Les tests de charge d'un jeu déjà en production permettent aux équipes de surveiller les performances du jeu et d'identifier les régressions ou les dégradations de performances susceptibles de se produire au fil du temps. Cela leur permet de résoudre les problèmes de manière proactive avant qu'ils n'affectent l'expérience des joueurs et n'affectent négativement la fidélisation des utilisateurs. En outre, les tests de charge en production valident l'efficacité des efforts d'optimisation des performances ou de mise à l'échelle de l'infrastructure mis en œuvre. Ce processus fournit aux joueurs une expérience de jeu de haute qualité, réactive et évolutive, même au fur et à mesure que le jeu évolue et mûrit.

Architectures génératrices de charge

La conception de l'architecture de génération de charge pour les tests de chargement des jeux peut prendre différentes formes, chacune présentant ses propres avantages et considérations. 

Au niveau le plus élémentaire, les EC2 instances Amazon autogérées peuvent être mises en service et configurées pour agir comme des générateurs de charge. Grâce à l'approche des nœuds de contrôle et des nœuds de travail, vous pouvez configurer plusieurs instances génératrices de charge, chacune exécutant son propre script de test et étant globalement gérée par une seule instance de contrôle. L'architecture peut évoluer et générer plus de charge sans augmenter la complexité en installant des nœuds de travail supplémentaires, mais cette approche pratique oblige les équipes à gérer le provisionnement, la configuration et la gestion de l'infrastructure sous-jacente.

Pour une approche plus évolutive et orchestrée, vous pouvez utiliser les clusters Amazon EKS Kubernetes pour gérer et répartir la charge de travail des tests de charge sur un parc d'agents de charge basés sur des conteneurs. Les fonctionnalités de dimensionnement automatique de Kubernetes peuvent être utilisées pour gérer le dimensionnement des pods générateurs de charge, tandis que les équipes configurent et gèrent elles-mêmes les EC2 instances sous-jacentes du cluster hébergeant les pods. 

La nature sans serveur de AWS Fargatepeut également accélérer et simplifier la configuration des tests de charge en supprimant la gestion de l'infrastructure tout en offrant l'évolutivité et la flexibilité nécessaires. Pour les solutions hybrides dans lesquelles un cluster Kubernetes sur site générateur de charge existe déjà mais qu'une capacité supplémentaire peut être nécessaire, EKS Anywhere peut gérer les deux clusters comme s'il s'agissait d'un seul cluster à partir du. Console de gestion AWS

Vous pouvez également utiliser des AWS Lambdafonctions en fonction de vos besoins et de vos objectifs. Les fonctions Lambda sont relativement simples à configurer et à faire évoluer sans qu'il soit nécessaire de fournir et de gérer des ressources supplémentaires. Ils permettent également de créer des scénarios de test plus complexes et dynamiques grâce à une intégration approfondie avec d'autres AWS services. Cependant, les fonctions Lambda sont soumises à des limites quant aux fonctions simultanées et à leur durée d'exécution (15 minutes), ce qui peut limiter l'échelle et la durée des tests de charge pouvant être réalisés. Les latences de démarrage à froid peuvent également avoir un impact sur la précision des résultats, et les limites de ressources de Lambda peuvent ne pas être adaptées aux charges de travail de test de charge très exigeantes.

Les studios qui souhaitent utiliser une solution prédéfinie peuvent utiliser les tests de charge distribués sur AWS. Cette solution utilise Amazon ECS AWS Fargate pour déployer des conteneurs capables d'exécuter des simulations de dizaines de milliers d'utilisateurs connectés. Vous pouvez l'utiliser pour démarrer rapidement votre infrastructure de test de charge à la manière IAC en utilisant AWS CloudFormation.

Cadres de test de charge

Il n'existe pas deux frameworks de test de charge conçus de la même manière. Certains disposent d'interfaces graphiques intuitives pour la création de tests, tandis que d'autres sont entièrement basés sur la ligne de commande. Un outil peut être flexible et performant, mais sa configuration et sa gestion nécessitent du temps et des efforts, tandis qu'un autre peut être sans serveur mais limité dans les tests qu'il peut créer et exécuter. Certains bénéficient de vastes communautés et de nombreux tutoriels alors qu'ils n'ont pas encore fait leurs preuves sur le terrain, ce qui contraste nettement avec d'autres qui peuvent avoir fait leurs preuves en production mais qui manquent de soutien ou de documentation de la part de la communauté. Choisissez le cadre qui offre le bon équilibre pour vous et votre équipe. Voici quelques options populaires :

  • Apache JMeter : framework de test de charge open source populaire basé sur Java en raison de ses fonctionnalités robustes et de sa facilité d'utilisation. Sa capacité à simuler des scénarios utilisateur complexes, son large éventail de protocoles pris en charge, ses rapports complets et ses antécédents éprouvés en font JMeter un choix fiable pour les tests de charge.

  • Locust : Framework de test de charge moderne et distribué basé sur une architecture axée sur les événements, ce qui le rend performant tout en économisant les ressources. Les tests sont écrits en Python, ce qui permet des scénarios de test flexibles qui tirent parti de milliers de puissantes bibliothèques tierces, tout en restant conviviaux et simples à lire.

  • Grafana K6 : puissant framework de test de charge alliant facilité d'utilisation et fonctionnalités avancées. Sa prise en charge de la génération de charge distribuée, ses scripts flexibles et son intégration parfaite avec Grafana pour la visualisation des données font de Grafana K6 un choix intéressant.

  • Gatling : framework de test de charge open source connu pour ses performances et son évolutivité. Son langage spécifique au domaine (DSL) basé sur Scala permet aux développeurs de créer des scripts de test de charge concis et faciles à gérer, et ses fonctionnalités robustes de reporting et d'analyse fournissent des informations détaillées sur le système testé.

Étapes d’implémentation

  • Étapes de test de charge : effectuez des tests de charge à différentes étapes de développement (développement initial, sprints, pré-production et post-déploiement) pour valider les performances du système et identifier les problèmes.

  • Architectures génératrices de charge : choisissez les architectures de génération de charge appropriées (EC2EKS, Fargate ou Lambda) en fonction des besoins d'évolutivité, des préférences de gestion et des exigences de test spécifiques.

  • Frameworks de test de charge : sélectionnez un framework de test de charge (comme JMeter Locust, Grafana K6 ou Gatling) qui concilie facilité d'utilisation, performance, flexibilité et soutien communautaire pour répondre aux besoins de votre équipe.