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.
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
-
Vous utilisez la console Web pour soumettre un scénario de test incluant les détails de configuration à l'API de la solution.
-
La configuration du scénario de test est téléchargée sur Amazon Simple Storage Service (Amazon S3) sous forme de fichier
s3://<bucket-name>/test-scenarios/<$TEST_ID>/<$TEST_ID>.jsonJSON (). -
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 un calendrier Amazon EventBridge Scheduler, 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 de ce guide.
-
Les détails de configuration sont stockés dans le tableau des scénarios Amazon DynamoDB.
-
Dans le flux de travail du lanceur de tâches AWS Step Functions, la fonction 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.
-
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.
-
La fonction AWS Lambda du vérificateur de statut des tâches vérifie si toutes les tâches de travail Amazon ECS sont exécutées avec le même identifiant 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, tous les ID de tâche et le préfixe et les transmet à la fonction de lancement de tâches.
-
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.
-
La fonction AWS Lambda du vérificateur de statut des tâches 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.
-
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.
-
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.
-
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.
-
La fonction Lambda structure ensuite les données reçues et les publie dans une rubrique AWS IoT Core.
-
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.
-
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/ <$TEST_ID> /results/ <$UUID> .json.
-
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é.
-
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 :
Flux de travail du serveur MCP
-
Interaction avec le client - Le client interagit avec la solution de test de charge distribué par le biais d'un agent d'intelligence artificielle. L'agent se connecte au point de terminaison MCP pour demander l'accès aux données de test de charge.
-
Autorisation : AgentCore Gateway valide le jeton d'authentification Amazon Cognito de l'utilisateur pour s'assurer que celui-ci est autorisé à accéder au serveur DLT MCP. Les utilisateurs autorisés bénéficient d'un accès en lecture seule pour charger les données de test via les outils d'agent disponibles.
-
Invocation d'outil : la AgentCore passerelle transmet les demandes d'outils MCP autorisées à la fonction Lambda de DLT MCP Tools. La fonction Lambda implémente les outils utilisés par les agents d'intelligence artificielle pour récupérer les informations relatives aux tests de charge.
-
Read-only Accès à l'API : la fonction Lambda de DLT MCP Tools appelle les points de terminaison DLT API Gateway existants pour récupérer des données de test à partir de DynamoDB, S3 et de piles régionales. CloudFormation La fonction Lambda 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 à des fins d'analyse et d'analyse. AI-powered