Présentation de l’architecture

Diagramme d’architecture

Le déploiement de cette solution avec les paramètres par défaut déploie les composants suivants dans votre compte AWS.

Tests de charge distribués sur l'architecture AWS

Note

Les CloudFormation ressources AWS sont créées à partir des constructions du kit AWS Cloud Development Kit (AWS CDK).

Le flux de processus de haut niveau pour les composants de solution déployés avec le CloudFormation modèle AWS est le suivant :

1. (CloudFront + option de déploiement de l'hébergement S3) L'utilisateur de la console accède à la console Web via Amazon CloudFront, qui gère l'application AWS Amplify hébergée dans un compartiment Amazon Simple Storage Service (Amazon S3).

2. (option de déploiement d'hébergement ALB + ECS Fargate) L'utilisateur de la console accède à la console Web via un Application Load Balancer, qui achemine le trafic vers l'application AWS Amplify exécutée sur Amazon ElasticContainer Service (Amazon ECS) sur AWS Fargate au sein d'un AmazonVirtual Private Cloud (Amazon VPC).

3. (Option de déploiement sans tête) Aucune interface publique n'est déployée. La solution fournit la console Web sous forme de fichier ZIP téléchargeable dans un compartiment Amazon S3 privé. L'utilisateur de la console peut accéder à la console à partir d'un serveur Web auto-hébergé.

4. Lors de la configuration initiale, la solution crée un utilisateur administrateur par défaut dans le groupe d'utilisateurs Amazon Cognito et envoie un e-mail de création de compte à l'adresse e-mail que vous avez fournie. Le groupe d'utilisateurs Cognito gère l'accès des utilisateurs à la console Web, à l'API REST, à la CLI et au serveur MCP.

5. Amazon API Gateway invoque les microservices AWS Lambda qui fournissent la logique métier nécessaire à la gestion des données de test et à l'exécution des tests.

6. Les microservices interagissent avec Amazon S3, Amazon DynamoDB EventBridge et Amazon pour stocker les détails des scénarios de test et gérer les calendriers de test. Lorsque vous planifiez un test pour qu'il soit exécuté à une date future ou à un intervalle récurrent, les microservices créent un EventBridge calendrier de planification qui appelle le microservice à l'heure planifiée.

7. Pour exécuter un test, les microservices invoquent AWS Step Functions, qui orchestre l'exécution du test.

8. EventBridge les règles acheminent les événements d'échec de la tâche Amazon ECS et de Step Functions vers une fonction Lambda du gestionnaire de défaillances.

9. Step Functions lance les tâches Amazon Elastic Container Service (Amazon ECS) sur AWS Fargate dans chaque région AWS que vous avez sélectionnée.

10. Chaque tâche s'exécute au sein d'un Amazon Virtual Private Cloud (Amazon VPC) dans la région sélectionnée.

11. Le conteneur de test de charge utilise une image de base Amazon Linux 2023 sur laquelle le framework d'automatisation des tests Taurus est installé. Taurus exécute votre test JMeter, K6, Locust ou Single HTTP Endpoint. Pour plus de détails sur le mode de provisionnement de chaque infrastructure de test, reportez-vous à la section Provisionnement de la structure de test. L'option ALB + ECS utilisera le conteneur d'hôte Web. Les images de conteneur sont hébergées par AWS dans un référentiel public Amazon Elastic Container Registry (Amazon ECR).

12. Chaque tâche Fargate écrit les résultats de ses tests par région sur Amazon S3 et envoie des journaux à Amazon. CloudWatch Lorsque toutes les régions sont terminées, les microservices agrégent les résultats dans DynamoDB.

13. Si vous activez l'option Live Data, une fonction Lambda reçoit les CloudWatch journaux des tâches Fargate pendant le test.

14. La fonction Lambda publie les journaux dans une rubrique d'AWS IoT Core dans la région où la pile principale est déployée. La console Web s'abonne à la rubrique pour afficher des métriques en temps réel pendant l'exécution du test.

15. (Accès CLI facultatif) Les utilisateurs peuvent installer l'interface de ligne de commande (CLI) DLT localement pour interagir avec la solution depuis leur terminal. La CLI s'authentifie via Cognito et appelle directement l'API REST, ce qui permet une automatisation et une intégration par script. CI/CD

    Note

    Les étapes suivantes décrivent l'intégration optionnelle du serveur MCP pour l'analyse des tests de AI-assisted charge. Ce composant n'est déployé que si vous sélectionnez l'option Serveur MCP lors du déploiement de la solution.

16. Un client MCP (outil de développement d'IA) se connecte au point de terminaison Amazon Bedrock AgentCore Gateway pour accéder aux données de la solution de test de charge distribué via le protocole Model Context. AgentCore Gateway valide le jeton d'authentification Cognito de l'utilisateur pour garantir un accès autorisé au serveur MCP.

17. Une fois l'authentification réussie, AgentCore Gateway transmet la demande d'outil MCP à la fonction Lambda du serveur DLT MCP. La fonction Lambda renvoie les données structurées à AgentCore Gateway, qui les renvoie au client MCP pour AI-assisted analyse et analyse.

18. La fonction Lambda traite la demande et interroge les ressources AWS appropriées (tables DynamoDB, compartiments S3 ou CloudWatch journaux) pour récupérer les données de test de charge demandées.