View a markdown version of this page

Información general de la arquitectura - Pruebas de carga distribuidas en AWS

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Información general de la arquitectura

Diagrama de arquitectura

Al implementar esta solución con los parámetros predeterminados, se implementan los siguientes componentes en su cuenta de AWS.

Pruebas de carga distribuidas en la arquitectura de AWS

Pruebas de carga distribuidas en la arquitectura de AWS
nota

Los CloudFormation recursos de AWS se crean a partir de componentes del AWS Cloud Development Kit (AWS CDK).

El flujo de proceso de alto nivel para los componentes de la solución implementados con la CloudFormation plantilla de AWS es el siguiente:

  1. (CloudFront + opción de implementación de alojamiento S3) El usuario de la consola accede a la consola web a través de Amazon CloudFront, que sirve a la aplicación AWS Amplify alojada en un bucket de Amazon Simple Storage Service (Amazon S3).

  2. (opción de implementación de alojamiento ALB + ECS Fargate) El usuario de la consola accede a la consola web a través de un Application Load Balancer, que dirige el tráfico a la aplicación AWS Amplify que se ejecuta en Amazon Elastic Container Service (Amazon ECS) en AWS Fargate dentro de una nube privada virtual de Amazon (Amazon VPC).

  3. (Opción de implementación centralizada) No se implementa ninguna interfaz pública. La solución proporciona la consola web como un ZIP descargable en un bucket privado de Amazon S3. El usuario de la consola puede acceder a la consola desde un servidor web autohospedado.

  4. Durante la configuración inicial, la solución crea un usuario administrador predeterminado en el grupo de usuarios de Amazon Cognito y envía un correo electrónico de creación de cuenta a la dirección de correo electrónico que usted proporcione. El grupo de usuarios de Cognito administra el acceso de los usuarios a la consola web, la API REST, la CLI y el servidor MCP.

  5. Amazon API Gateway invoca los microservicios de AWS Lambda que proporcionan la lógica empresarial necesaria para gestionar los datos de las pruebas y ejecutarlas.

  6. Los microservicios interactúan con Amazon S3, Amazon DynamoDB EventBridge y Amazon para almacenar los detalles del escenario de las pruebas y gestionar los programas de las pruebas. Cuando programa una prueba para que se ejecute en un futuro o en un intervalo periódico, los microservicios crean una EventBridge programación del programador que invoca el microservicio a la hora programada.

  7. Para ejecutar una prueba, los microservicios invocan AWS Step Functions, que organiza la ejecución de la prueba.

  8. EventBridge las reglas direccionan las tareas de Amazon ECS y los eventos de error de Step Functions a una función Lambda del controlador de errores.

  9. Step Functions lanza las tareas de Amazon Elastic Container Service (Amazon ECS) en AWS Fargate en cada región de AWS que haya seleccionado.

  10. Cada tarea se ejecuta en una Amazon Virtual Private Cloud (Amazon VPC) en la región seleccionada.

  11. El contenedor de pruebas de carga utiliza una imagen base de Amazon Linux 2023 con el marco de automatización de pruebas Taurus instalado. Taurus ejecuta su prueba de punto final JMeter, K6, Locust o Single HTTP. Para obtener más información sobre cómo se aprovisiona cada marco de prueba, consulte Probar el aprovisionamiento del marco de prueba. La opción ALB + ECS utilizará el contenedor de alojamiento web. AWS aloja las imágenes del contenedor en un repositorio público de Amazon Elastic Container Registry (Amazon ECR).

  12. Cada tarea de Fargate escribe los resultados de sus pruebas por región en Amazon S3 y emite registros a Amazon. CloudWatch Cuando se completan todas las regiones, los microservicios agregan los resultados en DynamoDB.

  13. Si habilita la opción de datos en tiempo real, una función de Lambda recibirá CloudWatch los registros de las tareas de Fargate durante la prueba.

  14. La función Lambda publica los registros de un tema de AWS IoT Core en la región en la que se implementa la pila principal. La consola web se suscribe al tema para mostrar métricas en tiempo real mientras se ejecuta la prueba.

  15. (Acceso CLI opcional) Los usuarios pueden instalar la interfaz de línea de comandos (CLI) de DLT de forma local para interactuar con la solución desde su terminal. La CLI se autentica mediante Cognito y llama directamente a la API REST, lo que permite la automatización e integración mediante scripts. CI/CD

    nota

    Los siguientes pasos describen la integración opcional del servidor MCP para AI-assisted el análisis de las pruebas de carga. Este componente solo se implementa si selecciona la opción de servidor MCP durante la implementación de la solución.

  16. Un cliente MCP (herramienta de desarrollo de IA) se conecta al punto final de Amazon Bedrock AgentCore Gateway para acceder a los datos de la solución de pruebas de carga distribuidas a través del protocolo Model Context. AgentCore Gateway valida el token de autenticación de Cognito del usuario para garantizar el acceso autorizado al servidor MCP.

  17. Tras la autenticación correcta, AgentCore Gateway reenvía la solicitud de la herramienta MCP a la función Lambda del servidor MCP de DLT. La función Lambda devuelve los datos estructurados a AgentCore Gateway, que los envía de vuelta al cliente MCP para que los analice y obtenga AI-assisted información.

  18. La función Lambda procesa la solicitud y consulta los recursos de AWS correspondientes (tablas de DynamoDB, buckets de S3 o CloudWatch registros) para recuperar los datos de las pruebas de carga solicitados.