Cómo funcionan las pruebas de carga distribuidas en AWS - 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.

Cómo funcionan las pruebas de carga distribuidas en AWS

En el siguiente desglose detallado se muestran los pasos necesarios para ejecutar un escenario de prueba.

Flujo de trabajo de prueba

image3

  1. Utiliza la consola web para enviar un escenario de prueba que incluye los detalles de configuración a la API de la solución.

  2. La configuración del escenario de prueba se carga en el Amazon Simple Storage Service (Amazon S3) como un archivo s3://<bucket-name>/test-scenarios/<$TEST_ID>/<$TEST_ID>.json JSON ().

  3. Una máquina de estados de AWS Step Functions se ejecuta con el ID de prueba, el recuento de tareas, el tipo de prueba y el tipo de archivo como entrada de la máquina de estados de AWS Step Functions. Si la prueba está programada, primero se creará una regla de CloudWatch eventos, que activará AWS Step Functions en la fecha especificada. Para obtener más información sobre el flujo de trabajo de programación, consulte la sección Flujo de trabajo de programación de pruebas de esta guía.

  4. Los detalles de configuración se almacenan en la tabla Amazon DynamoDB de escenarios.

  5. En el flujo de trabajo del ejecutor de tareas de AWS Step Functions, la función task-status-checker AWS Lambda comprueba si las tareas de Amazon Elastic Container Service (Amazon ECS) ya se están ejecutando para el mismo ID de prueba. Si se encuentran en ejecución tareas con el mismo ID de prueba, se produce un error. Si no hay ninguna tarea de Amazon ECS en ejecución en el clúster de AWS Fargate, la función devuelve el ID de la prueba, el recuento de tareas y el tipo de prueba.

  6. La función AWS Lambda ejecutora de tareas obtiene los detalles de la tarea del paso anterior y ejecuta las tareas de trabajo de Amazon ECS en el clúster de AWS Fargate. La API de Amazon ECS utiliza la RunTask acción para ejecutar las tareas de los trabajadores. Estas tareas de trabajo se lanzan y, a continuación, esperan un mensaje de inicio de la tarea principal para comenzar la prueba. La RunTask acción está limitada a 10 tareas por definición. Si el número de tareas es superior a 10, la definición de la tarea se ejecutará varias veces hasta que se hayan iniciado todas las tareas de los trabajadores. La función también genera un prefijo para distinguir la prueba actual en la función AWS Lambda de análisis de resultados.

  7. La función task-status-checker AWS Lambda comprueba si todas las tareas de trabajo de Amazon ECS se ejecutan con el mismo ID de prueba. Si las tareas aún se están aprovisionando, espera un minuto y vuelve a comprobarlo. Una vez ejecutadas todas las tareas de Amazon ECS, devuelve el identificador de la prueba, el recuento de tareas, el tipo de prueba, todas las tareas IDs y el prefijo y los pasa a la función de ejecución de tareas.

  8. La función AWS Lambda ejecutora de tareas se vuelve a ejecutar y, esta vez, lanza una única tarea de Amazon ECS para que actúe como nodo líder. Esta tarea de ECS envía un mensaje de inicio de la prueba a cada una de las tareas del trabajador para iniciar las pruebas simultáneamente.

  9. La función task-status-checker AWS Lambda vuelve a comprobar si las tareas de Amazon ECS se ejecutan con el mismo ID de prueba. Si las tareas siguen ejecutándose, espera un minuto y vuelve a comprobarlas. Cuando no hay tareas de Amazon ECS en ejecución, devuelve el ID de la prueba, el recuento de tareas, el tipo de prueba y el prefijo.

  10. Cuando la función AWS Lambda ejecutora de tareas ejecuta las tareas de Amazon ECS en el clúster de AWS Fargate, cada tarea descarga la configuración de prueba de Amazon S3 e inicia la prueba.

  11. Una vez ejecutadas las pruebas, el tiempo medio de respuesta, el número de usuarios simultáneos, el número de solicitudes satisfactorias y el número de solicitudes fallidas de cada tarea se registran en Amazon CloudWatch y se pueden ver en un CloudWatch panel de control.

  12. Si incluiste datos en tiempo real en la prueba, la solución filtra los resultados de las pruebas en tiempo real CloudWatch mediante un filtro de suscripción. A continuación, la solución pasa los datos a una función Lambda.

  13. A continuación, la función Lambda estructura los datos recibidos y los publica en un tema de AWS IoT Core.

  14. La consola web se suscribe al tema AWS IoT Core de la prueba y recibe los datos publicados en el tema para representar gráficamente los datos en tiempo real mientras se ejecuta la prueba.

  15. Una vez finalizada la prueba, las imágenes del contenedor exportan un informe detallado como un archivo XML a Amazon S3. A cada archivo se le asigna un UUID para el nombre del archivo. Por ejemplo, s3://dlte-bucket/test-scenarios/ <$TEST_ID> /results/ <$UUID> .json.

  16. Cuando los archivos XML se cargan en Amazon S3, la función AWS Lambda del analizador de resultados lee los resultados de los archivos XML empezando por el prefijo y los analiza y agrega todos los resultados en un resultado resumido.

  17. La función AWS Lambda del analizador de resultados escribe el resultado agregado en una tabla de Amazon DynamoDB.

Flujo de trabajo del servidor MCP (opcional)

Si implementa la integración opcional del servidor MCP, los agentes de IA pueden acceder a los datos de las pruebas de carga y analizarlos mediante el siguiente flujo de trabajo:

Arquitectura de servidor MCP

La arquitectura del servidor MCP muestra la integración con los componentes DLT
  1. Interacción con el cliente: el cliente interactúa con el MCP de DLT a través del punto de conexión MCP alojado en AWS Gateway. AgentCore Los agentes de IA se conectan a este punto final para solicitar acceso a los datos de las pruebas de carga.

  2. Autorización: AgentCore Gateway gestiona la autorización contra el cliente de la aplicación del grupo de usuarios de Solution Cognito. La puerta de enlace valida el token de Cognito del usuario para garantizar que tiene permiso para acceder al servidor DLT MCP. Se concede el acceso a los usuarios autorizados y el acceso a las herramientas del agente se limita a las operaciones de solo lectura.

  3. Especificación de la herramienta: la AgentCore puerta de enlace se conecta a la función Lambda del servidor MCP de DLT. Una especificación de herramienta define las herramientas disponibles que los agentes de IA pueden utilizar para interactuar con los datos de las pruebas de carga.

  4. Acceso a la API de solo lectura: la función Lambda se limita al acceso a la API de solo lectura a través de los puntos finales de DLT API Gateway existentes. La función proporciona cuatro operaciones principales:

    • Listar escenarios: recupera una lista de escenarios de prueba de la tabla de escenarios de DynamoDB

    • Obtenga los resultados de las pruebas de escenarios: acceda a los resultados detallados de las pruebas para escenarios específicos de DynamoDB y S3

    • Obtenga ejecutores de pruebas de carga de Fargate: consulte información sobre la ejecución de tareas de Fargate en el clúster de ECS

    • Obtenga las pilas regionales disponibles: recupere información sobre la infraestructura regional implementada en CloudFormation

La integración del servidor MCP aprovecha la infraestructura DLT existente (API Gateway, Cognito, DynamoDB, S3) para proporcionar un acceso seguro y de solo lectura a los datos de prueba para análisis e información basados en inteligencia artificial.