View a markdown version of this page

Comment fonctionnent les tests de charge distribués sur AWS - Tests de charge distribués sur AWS

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

image3

  1. Vous utilisez la console Web pour soumettre un scénario de test incluant les détails de configuration à l'API de la solution.

  2. 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>.json JSON ().

  3. 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 de ce guide.

  4. Les détails de configuration sont stockés dans le tableau des scénarios Amazon DynamoDB.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. La fonction Lambda structure ensuite les données reçues et les publie dans une rubrique AWS IoT Core.

  14. 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.

  15. 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.

  16. 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é.

  17. 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
  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.

  2. 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.

  3. 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.

  4. 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.