View a markdown version of this page

Présentation de l’architecture - Tests de charge distribués sur AWS
Diagramme d’architecture

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.

Présentation de l’architecture

Diagramme d’architecture

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

Tests de charge distribués sur l'architecture AWS

Tests de charge distribués sur l'architecture AWS
Note

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

Le flux de processus de haut niveau pour les composants de la 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 dessert l'application AWS Amplify hébergée dans un compartiment Amazon Simple Storage Service (Amazon S3).

  2. (Option de déploiement de l'hébergement ALB + ECS Fargate) L'utilisateur de la console accède à la console Web via un équilibreur de charge d'application, qui achemine le trafic vers l'application AWS Amplify exécutée sur Amazon Elastic Container Service (Amazon ECS) sur AWS Fargate au sein d'un Amazon Virtual Private Cloud (Amazon VPC).

  3. (Option de déploiement sans interface) 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 permettant de gérer les données de test et d'exécuter les tests.

  6. Les microservices interagissent avec Amazon S3, Amazon DynamoDB et Amazon EventBridge pour stocker les détails des scénarios de test et gérer les calendriers de test. Lorsque vous planifiez l'exécution d'un test à une date ultérieure ou à un intervalle récurrent, les microservices créent un calendrier EventBridge Scheduler 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 de défaillance d'Amazon ECS Task et 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 dans un Amazon Virtual Private Cloud (Amazon VPC) dans la région sélectionnée.

  11. Les conteneurs de test de charge utilisent une image de base Amazon Linux 2023, et l'image utilisée par une tâche dépend du mode de forme du trafic du test. En mode Standard, le framework d'automatisation des tests Taurus est installé sur l'image. Taurus exécute votre test JMeter, k6, Locust ou Simple HTTP Endpoint en utilisant les paramètres de charge que vous avez définis dans la console. En mode natif, une image dédiée pour chaque framework exécute ce framework directement sur votre script, sans Taurus ni paramètres de chargement provenant de la solution. Pour plus de détails sur les modes, reportez-vous à la section Modes de forme du trafic. Pour voir comment chaque framework de test est provisionné, reportez-vous à la section Provisionnement du framework de test. L'option ALB + ECS utilisera le conteneur d'hôte Web. Les images de conteneurs 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 dans Amazon S3 et transmet des journaux à Amazon. CloudWatch Lorsque toutes les régions sont complètes, les microservices regroupent les résultats dans DynamoDB.

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

  14. La fonction Lambda publie les journaux relatifs à 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 mesures 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ée via le protocole Model Context. AgentCore Gateway valide le jeton d'authentification Amazon Cognito de l'utilisateur pour vérifier l'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.

  18. La fonction Lambda appelle l'API REST DLT existante pour récupérer les données de test de charge demandées. Il renvoie ensuite les données structurées à AgentCore Gateway, qui les renvoie au client MCP pour AI-assisted analyse et informations.