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.
# Détails de l'architecture
Cette section décrit les composants et les [services AWS qui constituent cette solution](#aws-services-in-this-solution) ainsi que les détails de l'architecture sur la manière dont ces composants fonctionnent ensemble.
La solution de test de charge distribué sur AWS comprend trois composants de haut niveau : un [front-end](front-end.md), un [backend](back-end.md) et un serveur [MCP](MCP-Server.md) en option.
# Extrémité avant
Le front-end fournit les interfaces permettant d'interagir avec la solution et inclut :
+ Une API de test de charge pour un accès programmatique
+ Une console Web pour créer, planifier et exécuter des tests de performance
+ Un serveur MCP en option pour l'analyse assistée par l'IA des résultats de test et des erreurs
## API de test de charge
Les tests de charge distribués sur AWS configurent Amazon API Gateway pour héberger l' RESTful API de la solution. Les utilisateurs peuvent interagir avec le système de test de charge en toute sécurité via la console Web, RESTful l'API et le serveur MCP en option inclus. L'API fait office de « porte d'entrée » pour accéder aux données de test stockées dans Amazon DynamoDB. Vous pouvez également utiliser le APIs pour accéder à toutes les fonctionnalités étendues que vous intégrez à la solution.
Cette solution tire parti des fonctionnalités d'authentification des utilisateurs des groupes d'utilisateurs Amazon Cognito. Après avoir authentifié un utilisateur avec succès, Amazon Cognito émet un jeton Web JSON qui est utilisé pour permettre à la console d'envoyer des demandes aux solutions (points APIs de terminaison Amazon API Gateway). Les requêtes HTTPS sont envoyées par la console au APIs avec l'en-tête d'autorisation qui inclut le jeton.
Sur la base de la demande, API Gateway invoque la fonction AWS Lambda appropriée pour effectuer les tâches nécessaires sur les données stockées dans les tables DynamoDB, stocker les scénarios de test sous forme d'objets JSON dans Amazon S3, récupérer les images des métriques CloudWatch Amazon et soumettre des scénarios de test à la machine d'état AWS Step Functions.
Pour plus d'informations sur l'API de la solution, reportez-vous à la section [API de test de charge distribuée](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/distributed-load-testing-api.html) de ce guide.
## console Web
Cette solution inclut une console Web que vous pouvez utiliser pour configurer et exécuter des tests, surveiller les tests en cours et afficher les résultats détaillés des tests. La console est une application ReactJS construite avec [Cloudscape](https://cloudscape.design/), un système de conception open source permettant de créer des applications Web intuitives. La console est hébergée dans Amazon S3 et accessible via Amazon CloudFront. L'application utilise AWS Amplify pour s'intégrer à Amazon Cognito afin d'authentifier les utilisateurs. La console Web contient également une option permettant d'afficher les données en temps réel pour un test en cours, dans laquelle elle s'abonne à la rubrique correspondante dans AWS IoT Core.
L'URL de la console Web est le nom de domaine de CloudFront distribution qui se trouve dans les CloudFormation sorties sous forme de **console**. Après avoir lancé le CloudFormation modèle, vous recevrez également un e-mail contenant l'URL de la console Web et le mot de passe à usage unique pour vous y connecter.
## Serveur MCP (facultatif)
Le serveur MCP (Model Context Protocol) en option fournit une interface supplémentaire permettant aux outils de développement d'IA d'accéder aux données de test de charge et de les analyser par le biais d'interactions en langage naturel. Ce composant n'est déployé que si vous sélectionnez l'option Serveur MCP lors du déploiement de la solution.
Le serveur MCP permet aux agents d'intelligence artificielle de consulter les résultats des tests, d'analyser les indicateurs de performance et d'obtenir des informations sur vos données de test de charge à l'aide d'outils tels qu'Amazon Q, Claude et d'autres assistants d'IA compatibles avec MCP. Pour des informations détaillées sur l'architecture et la configuration du serveur MCP, reportez-vous à la section [Serveur MCP](MCP-Server.md) dans cette section.
# Backend
Le backend se compose d'un pipeline d'images de conteneur et d'un moteur de test de charge que vous utilisez pour générer de la charge pour les tests. Vous interagissez avec le backend par le biais du front-end. En outre, les tâches Amazon ECS on AWS Fargate lancées pour chaque test sont associées à un identifiant de test (ID) unique. Ces étiquettes d'identification de test peuvent être utilisées pour vous aider à contrôler les coûts de cette solution. Pour plus d'informations, reportez-vous aux [balises de répartition des coûts définies par](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) l'utilisateur dans le *guide de l'utilisateur d'AWS Billing and Cost Management*.
## Pipeline d'images de conteneurs
Cette solution utilise une image de conteneur créée avec [Amazon Linux 2023](https://aws.amazon.com/linux/amazon-linux-2023/) comme image de base avec le framework de test de charge [Taurus](https://gettaurus.org/) installé. Taurus est un framework d'automatisation des tests open source qui prend en charge K6 JMeter, Locust et d'autres outils de test. AWS héberge cette image dans un référentiel public Amazon Elastic Container Registry (Amazon ECR). La solution utilise cette image pour exécuter des tâches dans le cluster Amazon ECS on AWS Fargate.
Pour plus d'informations, reportez-vous à la section [Personnalisation des images du conteneur](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/container-image.html) de ce guide.
## Infrastructure de test
Outre le CloudFormation modèle principal, la solution fournit un modèle régional pour lancer les ressources nécessaires à l'exécution de tests dans plusieurs régions. La solution stocke ce modèle dans Amazon S3 et fournit un lien vers celui-ci dans la console Web. Chaque stack régional inclut un VPC, un cluster AWS Fargate et une fonction Lambda pour le traitement des données en temps réel.
Pour plus d'informations sur le déploiement d'une infrastructure de test dans des régions supplémentaires, reportez-vous à la section [Déploiement multirégional](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/multi-region-deployment.html) de ce guide.
## Moteur d'essai de charge
La solution de test de charge distribué utilise Amazon Elastic Container Service (Amazon ECS) et AWS Fargate pour simuler des milliers d'utilisateurs simultanés dans plusieurs régions, générant des requêtes HTTP à un rythme soutenu.
Vous définissez les paramètres de test à l'aide de la console Web incluse. La solution utilise ces paramètres pour générer un scénario de test JSON et le stocker dans Amazon S3. Pour plus d'informations sur les scripts de test et les paramètres de [test, reportez-vous à la section Types de tests](design-considerations.md#test-types) de cette section.
Une machine d'état AWS Step Functions exécute et surveille les tâches Amazon ECS dans un cluster AWS Fargate. La machine d'état AWS Step Functions inclut une fonction AWS Lambda ecr-checker, une fonction AWS Lambda, une fonction AWS Lambda de task-status-checker lancement de tâches, une fonction d'annulation de tâches AWS Lambda et une fonction AWS Lambda d'analyseur de résultats. Pour plus d'informations sur le flux de travail, reportez-vous à la section [Test du flux](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-workflow.html) de travail de ce guide. Pour plus d'informations sur les résultats des tests, reportez-vous à la section [Résultats des tests](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-results.html) de ce guide. Pour plus d'informations sur le flux de travail d'annulation des tests, reportez-vous à la section sur le [flux de travail d'annulation des tests](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-cancel-workflow.html) de ce guide.
Si vous sélectionnez des données en temps réel, la solution lance une fonction real-time-data-publisher Lambda dans chaque région à partir CloudWatch des journaux correspondant aux tâches Fargate de cette région. La solution traite et publie ensuite les données dans une rubrique d'AWS IoT Core dans la région où vous avez lancé le stack principal. Pour plus d'informations, reportez-vous à la section [Données en temps réel](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/live-data.html) de ce guide.
# Serveur MCP
L'intégration optionnelle du serveur MCP (Model Context Protocol) permet aux agents d'intelligence artificielle d'accéder à vos données de test de charge et de les analyser par le biais d'interactions en langage naturel. Ce composant n'est déployé que si vous sélectionnez l'option Serveur MCP lors du déploiement de la solution.
Le serveur MCP fait office de pont entre les outils de développement d'IA et votre déploiement DLT, fournissant une interface standardisée pour une analyse intelligente des résultats des tests de performance. L'architecture intègre plusieurs services AWS afin de créer une interface sécurisée et évolutive pour les interactions avec les agents d'intelligence artificielle :
## AgentCore Passerelle AWS
AWS AgentCore Gateway est un service entièrement géré qui fournit un hébergement standardisé et une gestion des protocoles pour les serveurs MCP. Dans cette solution, AgentCore Gateway sert de point de terminaison public auquel les agents d'IA se connectent lorsqu'ils demandent l'accès à vos données de test de charge.
Le service gère toutes les communications du protocole MCP, y compris la découverte d'outils, la validation des jetons d'authentification et le routage des demandes. AgentCore Gateway fonctionne comme un service mutualisé doté de protections de sécurité intégrées contre les menaces courantes qui pèsent sur les terminaux publics, tout en validant les signatures et les revendications des jetons Cognito pour chaque demande.
## Serveur DLT MCP Lambda
La fonction Lambda du serveur DLT MCP est un composant sans serveur personnalisé qui traite les demandes MCP des agents d'intelligence artificielle et les traduit en requêtes relatives à vos ressources DLT.
Cette fonction Lambda agit comme la couche intelligente de l'intégration MCP, en récupérant les résultats des tests à partir des tables DynamoDB, en accédant aux artefacts de performance stockés dans des compartiments S3 et en interrogeant les journaux pour obtenir des informations d'exécution détaillées. CloudWatch La fonction Lambda implémente des modèles d'accès en lecture seule et transforme les données DLT brutes en formats structurés et adaptés à l'IA que les agents peuvent facilement interpréter et analyser.
## Intégration de l'authentification
Le système d'authentification tire parti de l'infrastructure existante de votre pool d'utilisateurs Cognito pour maintenir des contrôles d'accès cohérents à la fois sur la console Web et sur les interfaces du serveur MCP.
Cette intégration utilise une authentification basée sur des jetons OAuth 2.0. Les utilisateurs s'authentifient une fois via le processus de connexion Cognito et reçoivent des jetons qui fonctionnent à la fois pour les interactions avec l'interface utilisateur et pour l'accès au serveur MCP. Le système maintient les mêmes limites d'autorisation et les mêmes contrôles d'accès que l'interface Web, garantissant que les utilisateurs ne peuvent accéder que par le biais d'agents d'intelligence artificielle aux mêmes données de test de charge auxquelles ils peuvent accéder via la console.
## Services AWS inclus dans cette solution
Les services AWS suivants sont inclus dans cette solution :
| Service AWS | Description |
| --- | --- |
| [Amazon API Gateway](https://aws.amazon.com/api-gateway/) | **Noyau.** Héberge les points de terminaison de l'API REST dans la solution. |
| [AWS CloudFormation](https://aws.amazon.com/cloudformation/) | **Noyau.** Gère les déploiements de l'infrastructure de la solution. |
| [Amazon CloudFront](https://aws.amazon.com/cloudfront/) | **Noyau.** Diffuse le contenu Web hébergé dans Amazon S3. |
| [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) | **Noyau.** Stocke les journaux et les indicateurs de la solution. |
| [Amazon Cognito](https://aws.amazon.com/cognito/) | **Noyau.** Gère la gestion des utilisateurs et l'authentification pour l'API. |
| [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) | **Noyau.** Stocke les informations de déploiement et teste les détails et les résultats des scénarios. |
| [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) | **Noyau.** Déploie et gère des tâches Amazon ECS indépendantes sur des conteneurs AWS Fargate. |
| [AWS Fargate](https://aws.amazon.com/fargate/) | **Noyau.** Héberge les conteneurs Amazon ECS de la solution |
| [AWS Identity and Access Management](https://aws.amazon.com/iam/) | **Noyau.** Gère la gestion des rôles et des autorisations des utilisateurs. |
| [AWS Lambda](https://aws.amazon.com/lambda/) | **Noyau.** Fournit une logique pour la APIs mise en œuvre, l'analyse des résultats des tests et le lancement de workers/leader tâches. |
| [AWS Step Functions](https://aws.amazon.com/step-functions/) | **Noyau.** Orchestre le provisionnement des conteneurs Amazon ECS sur les tâches AWS Fargate dans les régions spécifiées |
| [AWS Amplify](https://aws.amazon.com/amplify/) | **Soutenir.** Fournit une console Web alimentée par [AWS Amplify](https://aws.amazon.com/amplify). |
| [ CloudWatch Événements Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) | **Soutenir**. Planifie les tests pour qu'ils commencent automatiquement à une date spécifiée ou à des dates récurrentes. |
| [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) | **Soutenir**. Héberge l'image du conteneur dans un référentiel ECR public. |
| [Noyau d'AWS IoT](https://aws.amazon.com/iot-core/) | **Soutenir.** Permet de visualiser les données en temps réel pour un test en cours en vous abonnant à la rubrique correspondante dans AWS IoT Core. |
| [AWS Systems Manager](https://aws.amazon.com/systems-manager/) | **Soutenir.** Assure la surveillance des ressources au niveau de l'application et la visualisation des opérations sur les ressources et des données de coûts. |
| [Amazon S3](https://aws.amazon.com/s3/) | **Soutenir.** Héberge le contenu Web statique, les journaux, les métriques et les données de test. |
| [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) | **Soutenir.** Contient les conteneurs Amazon ECS de la solution exécutés sur AWS Fargate. |
| [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) | **Support, facultatif.** Héberge le serveur MCP (Remote Model Context Protocol) optionnel de la solution pour l'intégration de l'agent AI à l'API. |
# Comment fonctionnent les tests de charge distribués sur AWS
La répartition détaillée suivante montre les étapes nécessaires à l'exécution d'un scénario de test.
**Flux de travail de test**
![\[image3\]](http://docs.aws.amazon.com/fr_fr/solutions/latest/distributed-load-testing-on-aws/images/image3.png)
1. Vous utilisez la console Web pour soumettre un scénario de test incluant les détails de configuration à l'API de la solution.
1. La configuration du scénario de test est téléchargée sur Amazon Simple Storage Service (Amazon S3) sous forme de fichier `s3:///test-scenarios/<$TEST_ID>/<$TEST_ID>.json` JSON ().
1. Une machine d'état AWS Step Functions s'exécute en utilisant l'ID de test, le nombre de tâches, le type de test et le type de fichier comme entrée de la machine d'état AWS Step Functions. Si le test est planifié, il créera d'abord une règle d' CloudWatch événements, qui déclenchera AWS Step Functions à la date spécifiée. Pour plus de détails sur le flux de travail de planification, reportez-vous à la section [Processus de planification des tests](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-scheduling-workflow.html) de ce guide.
1. Les détails de configuration sont stockés dans le tableau des scénarios Amazon DynamoDB.
1. Dans le flux de travail du lanceur de tâches AWS Step Functions, la fonction task-status-checker AWS Lambda vérifie si les tâches Amazon Elastic Container Service (Amazon ECS) sont déjà en cours d'exécution pour le même ID de test. Si des tâches portant le même ID de test sont détectées en cours d'exécution, cela provoque une erreur. Si aucune tâche Amazon ECS n'est exécutée dans le cluster AWS Fargate, la fonction renvoie l'ID de test, le nombre de tâches et le type de test.
1. La fonction AWS Lambda d'exécution de tâches obtient les détails des tâches de l'étape précédente et exécute les tâches de travail Amazon ECS dans le cluster AWS Fargate. L'API Amazon ECS utilise l' RunTask action pour exécuter les tâches de travail. Ces tâches de travail sont lancées, puis attendent un message de démarrage de la tâche principale pour commencer le test. L' RunTask action est limitée à 10 tâches par définition. Si le nombre de tâches est supérieur à 10, la définition des tâches sera exécutée plusieurs fois jusqu'à ce que toutes les tâches de travail aient été démarrées. La fonction génère également un préfixe pour distinguer le test en cours dans la fonction AWS Lambda d'analyse des résultats.
1. La fonction task-status-checker AWS Lambda vérifie si toutes les tâches de travail Amazon ECS sont exécutées avec le même ID de test. Si les tâches sont toujours en cours de provisionnement, il attend une minute et vérifie à nouveau. Une fois que toutes les tâches Amazon ECS sont exécutées, il renvoie l'ID de test, le nombre de tâches, le type de test, toutes les tâches IDs et le préfixe et les transmet à la fonction de lancement de tâches.
1. La fonction de lancement de tâches AWS Lambda s'exécute à nouveau, en lançant cette fois une seule tâche Amazon ECS qui servira de nœud principal. Cette tâche ECS envoie un message de test de démarrage à chacune des tâches de travail afin de démarrer les tests simultanément.
1. La fonction task-status-checker AWS Lambda vérifie à nouveau si les tâches Amazon ECS sont exécutées avec le même ID de test. Si les tâches sont toujours en cours d'exécution, il attend une minute et vérifie à nouveau. Lorsqu'aucune tâche Amazon ECS n'est en cours d'exécution, il renvoie l'ID de test, le nombre de tâches, le type de test et le préfixe.
1. Lorsque la fonction de lancement de tâches AWS Lambda exécute les tâches Amazon ECS dans le cluster AWS Fargate, chaque tâche télécharge la configuration de test depuis Amazon S3 et lance le test.
1. Une fois les tests exécutés, le temps de réponse moyen, le nombre d'utilisateurs simultanés, le nombre de demandes réussies et le nombre de demandes ayant échoué pour chaque tâche sont enregistrés sur Amazon CloudWatch et peuvent être consultés dans un CloudWatch tableau de bord.
1. Si vous avez inclus des données en temps réel dans le test, la solution filtre les résultats du test en temps réel à CloudWatch l'aide d'un filtre d'abonnement. La solution transmet ensuite les données à une fonction Lambda.
1. La fonction Lambda structure ensuite les données reçues et les publie dans une rubrique AWS IoT Core.
1. La console Web s'abonne à la rubrique AWS IoT Core du test et reçoit les données publiées dans cette rubrique pour représenter graphiquement les données en temps réel pendant l'exécution du test.
1. Lorsque le test est terminé, les images du conteneur exportent un rapport détaillé sous forme de fichier XML vers Amazon S3. Un UUID est attribué à chaque fichier pour son nom de fichier. *Par exemple, s3://dlte-bucket/test-scenarios/ *<\$1TEST\$1ID> /results/ <\$1UUID>* .json.*
1. Lorsque les fichiers XML sont chargés sur Amazon S3, la fonction AWS Lambda de l'analyseur de résultats lit les résultats dans les fichiers XML en commençant par le préfixe, puis analyse et agrège tous les résultats en un seul résultat résumé.
1. La fonction AWS Lambda de l'analyseur de résultats écrit le résultat agrégé dans une table Amazon DynamoDB.
## Flux de travail du serveur MCP (facultatif)
Si vous déployez l'intégration optionnelle du serveur MCP, les agents AI peuvent accéder à vos données de test de charge et les analyser via le flux de travail suivant :
**Architecture du serveur MCP**
![\[Architecture du serveur MCP montrant l'intégration avec les composants DLT\]](http://docs.aws.amazon.com/fr_fr/solutions/latest/distributed-load-testing-on-aws/images/mcp-server-architecture.png)
1. **Interaction avec le client** : le client interagit avec le MCP de DLT via le point de terminaison MCP hébergé par AWS Gateway. AgentCore Les agents d'IA se connectent à ce point de terminaison pour demander l'accès aux données de test de charge.
1. **Autorisation** : AgentCore Gateway gère les autorisations relatives au client d'application Solution Cognito du pool d'utilisateurs. La passerelle valide le jeton Cognito de l'utilisateur pour s'assurer qu'il est autorisé à accéder au serveur DLT MCP. L'accès est accordé aux utilisateurs autorisés, l'accès à l'outil agent étant limité aux opérations en lecture seule.
1. **Spécification de l'outil** : la AgentCore passerelle se connecte à la fonction Lambda du serveur DLT MCP. Une spécification d'outil définit les outils disponibles que les agents d'IA peuvent utiliser pour interagir avec vos données de test de charge.
1. **Accès aux API en lecture seule** : la fonction Lambda est limitée à l'accès aux API en lecture seule via les points de terminaison DLT API Gateway existants. La fonction fournit quatre opérations principales :
+ **Répertorier les scénarios** - Récupérez une liste de scénarios de test dans le tableau des scénarios DynamoDB
+ **Obtenez les résultats des tests de scénarios** - Accédez aux résultats de test détaillés pour des scénarios spécifiques à partir de DynamoDB et S3
+ **Get Fargate Load Test** Runners : recherchez des informations sur l'exécution de tâches Fargate dans le cluster ECS
+ **Obtenez des piles régionales disponibles** - Récupérez des informations sur l'infrastructure régionale déployée auprès de CloudFormation
L'intégration du serveur MCP tire parti de l'infrastructure DLT existante (API Gateway, Cognito, DynamoDB, S3) pour fournir un accès sécurisé en lecture seule aux données de test pour des analyses et des informations basées sur l'IA.
# Considérations relatives à la conception
Cette section décrit les décisions de conception et les options de configuration importantes pour la solution de test de charge distribué sur AWS, y compris les applications prises en charge, les types de tests, les options de planification et les considérations relatives au déploiement.
## Applications prises en charge
Cette solution permet de tester des applications basées sur le cloud et des applications sur site, à condition que vous disposiez d'une connectivité réseau entre votre compte AWS et votre application. La solution prend en APIs charge l'utilisation des protocoles HTTP ou HTTPS.
## Types de tests
Les tests de charge distribués sur AWS prennent en charge plusieurs types de tests : tests de point de terminaison HTTP simples JMeter, K6 et Locust.
### Tests de point de terminaison HTTP simples
La console Web fournit une interface de configuration de point de terminaison HTTP qui vous permet de tester n'importe quel point de terminaison HTTP ou HTTPS sans écrire de scripts personnalisés. Vous définissez l'URL du point de terminaison, sélectionnez la méthode HTTP (GET, POST, PUT, DELETE, etc.) dans un menu déroulant et ajoutez éventuellement des en-têtes de requête et des charges utiles personnalisés. Cette configuration vous permet de tester APIs avec des jetons d'autorisation personnalisés, des types de contenu ou tout autre en-tête HTTP et corps de requête requis par votre application.
### JMeter tests
Lorsque vous créez un scénario de test à l'aide de la console Web, vous pouvez télécharger un script de JMeter test. La solution télécharge le script dans le compartiment S3 des scénarios. Lorsque les tâches Amazon ECS sont exécutées, elles téléchargent le JMeter script depuis S3 et exécutent le test.
**Important**
Bien que votre JMeter script puisse définir la simultanéité (utilisateurs virtuels), les taux de transaction (TPS), les temps de montée en puissance et d'autres paramètres de chargement, la solution remplacera ces configurations par les valeurs que vous spécifiez sur l'écran Traffic Shape lors de la création du test. La configuration Traffic Shape contrôle le nombre de tâches, la simultanéité (utilisateurs virtuels par tâche), la durée de montée en puissance et la durée de suspension pour l'exécution du test.
Si vous avez des fichiers JMeter d'entrée, vous pouvez les compresser avec le JMeter script. Vous pouvez choisir le fichier zip lorsque vous créez un scénario de test.
Si vous souhaitez inclure des plugins, tous les fichiers .jar inclus dans un sous-répertoire /plugins du fichier zip fourni seront copiés dans le répertoire des JMeter extensions et seront disponibles pour les tests de charge.
**Note**
Si vous incluez des fichiers JMeter d'entrée dans votre fichier de JMeter script, vous devez inclure le chemin relatif des fichiers d'entrée dans votre fichier de JMeter script. En outre, les fichiers d'entrée doivent se trouver dans le chemin relatif. Par exemple, si vos fichiers JMeter d'entrée et votre fichier de script se trouvent plutôt dans le home/user directory and you refer to the input files in the JMeter script file, the path of input files must be ./INPUT\$1FILES. If you use /home/user/INPUT répertoire/\$1FILES, le test échouera car il ne sera pas en mesure de trouver les fichiers d'entrée.
Si vous incluez JMeter des plug-ins, les fichiers .jar doivent être regroupés dans un sous-répertoire nommé /plugins à la racine du fichier zip. Par rapport à la racine du fichier zip, le chemin d'accès aux fichiers jar doit être. /Plugins/bundled\$1plugin.jar.
Pour plus d'informations sur l'utilisation JMeter des scripts, reportez-vous au [manuel de JMeter l'utilisateur](https://jmeter.apache.org/usermanual/index.html).
### Tests K6
La solution prend en charge les tests basés sur le framework K6. K6 est publié sous licence [AGPL-3.0](https://github.com/grafana/k6/blob/master/LICENSE.md). La solution affiche un message d'accusé de réception de licence lors de la création d'un nouveau test K6. Vous pouvez télécharger le fichier de test K6 ainsi que tous les fichiers d'entrée nécessaires dans un fichier d'archive.
**Important**
Bien que votre script K6 puisse définir la simultanéité (utilisateurs virtuels), les étapes, les seuils et d'autres paramètres de charge, la solution remplacera ces configurations par les valeurs que vous spécifiez sur l'écran Traffic Shape lors de la création du test. La configuration Traffic Shape contrôle le nombre de tâches, la simultanéité (utilisateurs virtuels par tâche), la durée de montée en puissance et la durée de suspension pour l'exécution du test.
### Tests acridiens
La solution prend en charge les tests basés sur le framework Locust. Vous pouvez télécharger le fichier de test Locust ainsi que tous les fichiers d'entrée nécessaires dans un fichier d'archive.
**Important**
Bien que votre script Locust puisse définir la simultanéité (nombre d'utilisateurs), le taux d'apparition et d'autres paramètres de charge, la solution remplacera ces configurations par les valeurs que vous spécifiez sur l'écran Traffic Shape lors de la création du test. La configuration Traffic Shape contrôle le nombre de tâches, la simultanéité (utilisateurs virtuels par tâche), la durée de montée en puissance et la durée de suspension pour l'exécution du test.
## Planification des tests
La solution propose trois options de synchronisation d'exécution pour exécuter des tests de charge :
+ **Exécuter maintenant** - Exécute le test de charge immédiatement après la création
+ **Exécuter une fois** : exécute le test à une date et à une heure spécifiques dans le futur
+ **Exécuter selon un calendrier** : créez des tests récurrents à l'aide d'expressions cron pour définir le calendrier
Lorsque vous sélectionnez **Exécuter une fois**, vous spécifiez la durée d'exécution au format 24 heures et la date d'exécution à laquelle le test de charge doit commencer.
Lorsque vous sélectionnez **Exécuter selon un calendrier**, vous pouvez soit saisir manuellement une expression cron, soit sélectionner l'un des modèles cron courants (par exemple toutes les heures, tous les jours à une heure précise, en semaine ou tous les mois). L'expression cron utilise un format de planification précis avec des champs pour les minutes, les heures, le jour du mois, le mois, le jour de la semaine et l'année. Vous devez également spécifier une date d'expiration, qui définit le moment où le test planifié doit cesser de fonctionner. Pour plus d'informations sur le fonctionnement de la planification, reportez-vous à la section [Workflow de planification des tests](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-scheduling-workflow.html) de ce guide.
**Note**
Durée des tests : tenez compte de la durée totale des tests lors de la planification. Par exemple, un test avec un temps de démarrage de 10 minutes et un temps d'attente de 40 minutes prendra environ 80 minutes.
Intervalle minimum : assurez-vous que l'intervalle entre les tests planifiés est supérieur à la durée estimée du test. Par exemple, si le test dure environ 80 minutes, programmez-le pour qu'il ne soit pas exécuté plus fréquemment que toutes les 3 heures.
Limite horaire : le système ne permet pas de planifier les tests avec une différence d'une heure seulement, même si la durée estimée du test est inférieure à une heure.
## Tests simultanés
Cette solution crée un CloudWatch tableau de bord Amazon pour chaque test qui affiche le résultat combiné de toutes les tâches exécutées dans le cluster Amazon ECS en temps réel. Le CloudWatch tableau de bord indique le temps de réponse moyen, le nombre d'utilisateurs simultanés, le nombre de demandes réussies et le nombre de demandes ayant échoué. La solution agrège chaque métrique par seconde et met à jour le tableau de bord toutes les minutes.
## Gestion des utilisateurs
Lors de la configuration initiale, vous fournissez un nom d'utilisateur et une adresse e-mail qu'Amazon Cognito utilise pour vous donner accès à la console Web de la solution. La console n'assure pas l'administration des utilisateurs. Pour ajouter des utilisateurs supplémentaires, vous devez utiliser la console Amazon Cognito. Pour plus d'informations, reportez-vous à [la section Gestion des utilisateurs dans les groupes d'](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users.html)utilisateurs du manuel *Amazon Cognito Developer Guide*.
Pour la migration d'utilisateurs existants vers des groupes d'utilisateurs Amazon Cognito, consultez le [blog AWS Approaches for migration des utilisateurs vers des groupes d'utilisateurs Amazon Cognito](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools).
## Déploiement régional
Cette solution utilise Amazon Cognito, disponible uniquement dans certaines régions AWS. Par conséquent, vous devez déployer cette solution dans une région où Amazon Cognito est disponible. Pour connaître la disponibilité des services la plus récente par région, consultez la [liste des services régionaux AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).