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.
Consideraciones sobre el diseño
En esta sección se describen las decisiones de diseño y las opciones de configuración importantes para la solución Distributed Load Testing on AWS, incluidas las aplicaciones compatibles, los tipos de pruebas, las opciones de programación y las consideraciones de implementación.
Aplicaciones compatibles
Esta solución permite probar aplicaciones basadas en la nube y aplicaciones locales siempre que tenga conectividad de red desde su cuenta de AWS a su aplicación. La solución es compatible con las API que utilizan los protocolos HTTP o HTTPS.
Tipos de pruebas
Las pruebas de carga distribuidas en AWS admiten varios tipos de pruebas: pruebas de punto final HTTP simples, JMeter, k6 y Locust. Cada tipo de prueba, excepto el punto final HTTP simple, puede ejecutarse en cualquier modo de forma de tráfico. Para obtener más información, consulte los modos de configuración del tráfico.
nota
La solución distribuye JMeter, k6 y Locust como componentes de terceros sin modificaciones. Para conocer las consideraciones de seguridad, las opciones de parches y la información sobre las licencias, consulte los marcos de prueba. Third-party
Pruebas sencillas de terminales HTTP
La consola web proporciona una interfaz de configuración de puntos finales HTTP que permite probar cualquier punto final HTTP o HTTPS sin necesidad de escribir scripts personalizados. Defina la URL del punto de enlace, seleccione el método HTTP (GET, POST, PUT, DELETE, etc.) en un menú desplegable y, si lo desea, añada encabezados y cuerpos de solicitud personalizados. Esta configuración te permite probar las API con tokens de autorización personalizados, tipos de contenido o cualquier otro encabezado HTTP y cuerpo de solicitud que necesite tu aplicación.
Al configurar un punto final HTTP, la solución convierte la configuración en un plan de pruebas que ejecuta el binario Apache JMeter incluido a través del marco Taurus. Las pruebas simples de terminales HTTP no aceptan un archivo de prueba, por lo que no pueden anular el binario o los complementos de JMeter incluidos. Si necesitas ejecutar pruebas de punto final HTTP con un JMeter parcheado, usa el tipo de prueba JMeter en su lugar. Pruebas de JMeter Para cuestiones de seguridad, consulte Apache JMeter.
Como la solución genera el plan de pruebas para este tipo de prueba, las pruebas de terminales HTTP simples se ejecutan únicamente en modo estándar. El modo nativo requiere que subas un script. Para obtener más información, consulta los modos Traffic Shape.
Pruebas de JMeter
Al crear un escenario de prueba con la consola web, puede cargar un script de prueba de JMeter. La solución carga el script al bucket S3 del escenario. Cuando se ejecutan las tareas de Amazon ECS, descargan el script JMeter de S3 y ejecutan la prueba.
importante
En el modo estándar, su script de JMeter puede definir la concurrencia (usuarios virtuales), las tasas de transacción (TPS), los tiempos de aceleración y otros parámetros de carga. La solución los anula todos con los valores que especifique en la pantalla Traffic Shape durante la creación de la prueba. Esa configuración controla el recuento de tareas, la simultaneidad (usuarios virtuales por tarea), la duración de la aceleración y la duración de la espera de la ejecución de la prueba.
En el modo nativo, la solución se ejecuta jmeter -n -t en el script y no pasa ningún parámetro de carga. Los temporizadores y grupos de subprocesos se ejecutan exactamente como se crearon. Para obtener más información, consulta los modos de configuración del tráfico.
Si tiene archivos de entrada de JMeter, puede comprimirlos junto con el script de JMeter. Puede elegir el archivo zip al crear un escenario de prueba.
Si quieres incluir complementos, todos los archivos.jar que estén incluidos en un subdirectorio /plugins del archivo zip incluido se copiarán al directorio de extensiones de JMeter y estarán disponibles para realizar pruebas de carga.
nota
Si incluye archivos de entrada de JMeter en su archivo de script de JMeter, debe incluir la ruta relativa de los archivos de entrada en su archivo de script de JMeter. Además, los archivos de entrada deben estar en la ruta relativa. Por ejemplo, si los archivos de entrada y el archivo de script de JMeter están en el home/user directorio/y hace referencia a los archivos de entrada en el archivo de script de JMeter, la ruta de los archivos de entrada debe estar. /INPUT_FILES. Si usa/home/user/INPUT_FILES en su lugar, la prueba fallará porque no podrá encontrar los archivos de entrada.
Si incluyes los complementos de JMeter, los archivos.jar deben estar empaquetados en un subdirectorio llamado /plugins dentro de la raíz del archivo zip. En relación con la raíz del archivo zip, la ruta a los archivos jar debe ser. /plugins/BUNDLED_PLUGIN.jar.
Para obtener más información sobre cómo usar los scripts de JMeter, consulte el Manual del usuario de JMeter.
pruebas k6
La solución admite las pruebas basadas en el marco k6. Puede cargar el archivo de prueba k6 junto con los archivos de entrada necesarios en un archivo de almacenamiento. La consola web muestra un mensaje de confirmación de licencia al crear una nueva prueba de k6. Para obtener información sobre la licencia y la seguridad, consulte Grafana k6.
importante
En el modo estándar, su script k6 puede definir la concurrencia (usuarios virtuales), las etapas, los umbrales y otros parámetros de carga. La solución los anula todos con los valores que especifique en la pantalla Traffic Shape durante la creación de la prueba. Esa configuración controla el recuento de tareas, la simultaneidad (usuarios virtuales por tarea), la duración de la aceleración y la duración de la espera de la ejecución de la prueba.
En el modo nativo, la solución se ejecuta k6 run en el script y no pasa ningún parámetro de carga. k6 aplica los bloques de opciones, los escenarios, las etapas y los umbrales tal y como están escritos. Para obtener más información, consulte los modos de configuración del tráfico.
Pruebas contra langostas
La solución admite las pruebas basadas en el marco Locust. Puede cargar el archivo de prueba de Locust junto con los archivos de entrada necesarios en un archivo de almacenamiento.
importante
En el modo Estándar, tu script de Locust puede definir la concurrencia (número de usuarios), la velocidad de generación y otros parámetros de carga. La solución los anula todos con los valores que especifiques en la pantalla Traffic Shape durante la creación de la prueba. Esa configuración controla el recuento de tareas, la simultaneidad (usuarios virtuales por tarea), la duración de la aceleración y la duración de la espera de la ejecución de la prueba.
En el modo nativo, la solución se ejecuta locust --headless en el script y no pasa ningún parámetro de carga. Locust aplica LoadTestShape las clases y los conjuntos de tareas ponderados exactamente como están escritos. El script no debe configurarseprocesses, ya que la solución solo cuenta las solicitudes cuando Locust se ejecuta como un solo proceso. Para obtener más información, consulte Modos de configuración del tráfico.
Nombre del script de prueba
Cuando subes un único .py archivo, la solución lo almacena bajo el ID de prueba y hace referencia a él directamente, por lo que el archivo puede tener cualquier nombre. Cuando subes un .zip archivo, la solución busca en el archivo un archivo con el nombrelocustfile.py. Si el archivo contiene una secuencia de comandos de Python con otro nombre, la prueba falla al iniciar el contenedor y muestra el mensajeNo test script (.py) in zip file.
Dependencias personalizadas de Python
El contenedor de pruebas de carga incluye Locust y sus dependencias. No incluye paquetes de Python de terceros. Si tu script de Locust importa un paquete que no está presente en el contenedor, la prueba fallará conModuleNotFoundError. Para que haya paquetes adicionales disponibles, incluye un requirements.txt archivo en la raíz del .zip archivo. El contenedor instala los paquetes listados requirements.txt antes de que comience la prueba.
Puede proporcionar dependencias de dos maneras:
- Instala desde PyPI
-
Incluya solo un archivo
requirements.txt. El contenedor instala los paquetes listados enrequirements.txtPyPI al iniciar la tarea. Esto requiere acceso saliente a Internet desde las subredes en las que se ejecutan las tareas de prueba de carga. - Realice la instalación desde las ruedas incluidas (sin conexión)
-
Incluye un
requirements.txtarchivo y unpackagessubdirectorio que contengan los archivos wheel (.whl) de Python. El contenedor se instala únicamente desde las ruedas incluidas y no entra en contacto con PyPI. Esta opción funciona en entornos sin acceso saliente a Internet. Bundling Wheels también incluye las versiones exactas del paquete, por lo que una nueva versión de PyPI no puede cambiar tu entorno de prueba entre ejecuciones.
El siguiente ejemplo muestra el diseño del archivo:
my-test.zip ├── locustfile.py # Required — must use this name ├── requirements.txt # Optional — packages to install └── packages/ # Optional — wheels, for offline install only └── *.whl
requirements.txtTanto el packages subdirectorio como el subdirectorio deben estar en la raíz del archivo, al ladolocustfile.py. Omita ambos si su script solo importa los paquetes que el contenedor ya proporciona. El packages subdirectorio solo tiene efecto junto con un requirements.txt archivo; por sí solo, se ignora y no se instala ningún paquete.
Dependencias transitivas
Cuando agrupes ruedas, requirements.txt debes enumerar todos los paquetes que requieran tus dependencias, no solo los paquetes que importes directamente. La instalación sin conexión no establece contacto con PyPI. La falta de una dependencia transitiva provoca un error en la instalación y la tarea se detiene antes de que comience la prueba.
Preparando las ruedas para el contenedor
El contenedor de pruebas de carga ejecuta Linux en la arquitectura x86_64 con Python 3.11. Las ruedas compiladas para otro sistema operativo, arquitectura o versión de Python no se instalan. Los paquetes escritos en Python puro se distribuyen como ruedas independientes de la plataforma y funcionan en cualquier lugar, pero los paquetes que contienen extensiones compiladas requieren una rueda diseñada para la plataforma del contenedor. Como el contenedor no incluye un compilador, no puede crear una distribución de código fuente al iniciar la tarea.
Ejecuta el siguiente comando para descargar las ruedas compatibles con la plataforma del contenedor. Puedes ejecutar este comando desde cualquier sistema operativo, incluidos macOS y Windows. A continuación, incluye el packages directorio resultante en tu archivo:
pip download -r requirements.txt \ --dest packages \ --platform manylinux2014_x86_64 \ --python-version 3.11 \ --only-binary=:all:
--python-versionLas opciones --platform y se dirigen al contenedor, no a la máquina en la que se ejecuta el comando. La --only-binary=:all: opción hace que el comando falle en lugar de recurrir silenciosamente a una distribución de origen que el contenedor no puede crear. La manylinux2014 etiqueta especifica una rueda compatible con la glibc 2.17 y versiones posteriores, que incluye la versión del contenedor.
Para empaquetar un paquete que tú mismo mantengas, crea una rueda desde el directorio fuente de tu paquete con y, a continuaciónpip wheel . --wheel-dir packages, añade el nombre del paquete a. requirements.txt
Modos de forma de tráfico
Cada prueba se ejecuta en uno de los dos modos de configuración del tráfico: estándar o nativo. El modo determina tres cosas: qué lado controla la carga, qué imagen de contenedor utilizan las tareas de Fargate y qué parámetros de carga envía la solución al marco de pruebas. Para obtener información sobre cómo elegir un modo al crear una prueba, consulte los modos de configuración del tráfico en la sección Usar la solución.
Modo estándar
Las tareas de Fargate utilizan la imagen con Taurus instalado. Taurus recibe de la solución el recuento de tareas, la simultaneidad, el aumento y la duración de espera. Traduce estos valores en los propios controles de carga del marco subyacente. Taurus tiene prioridad sobre la carga que declara tu script. Reescribe o ignora un bloque de opciones de k6, un grupo de hilos de Locust o LoadTestShape JMeter. Los usuarios virtuales que genera una región son el recuento de tareas multiplicado por la concurrencia de cada tarea. Esa forma es la misma para todos los marcos. Así es como la solución ejecutaba todas las pruebas anteriores a la versión 4.3.0.
Modo nativo
Las tareas de Fargate utilizan la imagen dedicada para el marco de la prueba, que no incluye Taurus. En lugar de escribir una configuración de Taurus, la solución invoca el marco directamente:jmeter -n -t,k6 run, o. locust --headless No pasa ningún parámetro de carga. Su script es la única autoridad sobre el tráfico que genera.
De ese diseño se derivan dos consecuencias, y ambas afectan a la forma de dimensionar una prueba:
-
Las tareas multiplican la carga. Cada tarea ejecuta un proceso marco independiente sin coordinación entre las tareas. Como resultado, una región genera una copia completa de la carga declarada del script para cada tarea. Por ejemplo, un script k6 que contiene 200 usuarios virtuales y se ejecuta en cinco tareas sitúa a 1000 usuarios virtuales en el objetivo. El recuento de tareas es el único control de carga que ofrece la solución en este modo. Se mueve en múltiplos enteros de lo que declara el script.
-
Una duración de seguridad limita la carrera. Como el script decide cuándo finaliza la prueba, la solución requiere una duración de seguridad de hasta 24 horas. Si la prueba sigue ejecutándose cuando transcurra la duración, la solución detiene el marco. Recopila los resultados de la parte que se ejecutó y registra la ejecución como completada y no como fallida.
Programación de pruebas
La solución proporciona tres opciones de tiempo de ejecución para ejecutar las pruebas de carga:
-
Ejecutar ahora: ejecuta la prueba de carga inmediatamente después de la creación
-
Ejecutar una vez: ejecuta la prueba en una fecha y hora específicas en el futuro
-
Ejecute según un cronograma: cree pruebas recurrentes utilizando expresiones cron para definir el cronograma
Cuando seleccionas Ejecutar una vez, especificas la hora de ejecución en formato de 24 horas y la fecha de ejecución en la que debería empezar a ejecutarse la prueba de carga.
Al seleccionar Ejecutar según una programación, puede introducir manualmente una expresión de cron o seleccionar uno de los patrones de cron más comunes (por ejemplo, cada hora, todos los días a una hora específica, de lunes a viernes o mensualmente). La expresión cron utiliza un formato de programación detallado con campos para los minutos, las horas, el día del mes, el mes, el día de la semana y el año. También debe especificar una fecha de caducidad, que define cuándo debe dejar de ejecutarse la prueba programada. Para obtener más información sobre la programación de las reglas de validación, consulte la sección Restricciones de programación de esta guía.
nota
-
Duración de las pruebas: tenga en cuenta la duración total de las pruebas al programar. Por ejemplo, una prueba con un tiempo de preparación de 10 minutos y un tiempo de espera de 40 minutos tardará aproximadamente 80 minutos en completarse.
-
Intervalo mínimo: asegúrese de que el intervalo entre las pruebas programadas sea superior a la duración estimada de la prueba. Por ejemplo, si la prueba dura unos 80 minutos, prográmala para que no se ejecute con más frecuencia que cada 3 horas.
-
Limitación horaria: el sistema no permite programar las pruebas con solo una diferencia de una hora, incluso si la duración estimada de la prueba es inferior a una hora.
Pruebas simultáneas
Cada vez que se ejecuta una prueba de carga, la función AWS Lambda, que ejecuta tareas, crea un CloudWatch panel de Amazon con el nombre de cada región EcsLoadTesting-<testId>-<region>
en la que se ejecuta la prueba. El CloudWatch panel muestra el resultado combinado de todas las tareas que se ejecutan en el clúster de Amazon ECS en tiempo real: tiempo medio de respuesta, número de usuarios simultáneos, número de solicitudes satisfactorias y número de solicitudes fallidas. La solución agrega cada métrica por segundo y actualiza el panel cada minuto.
Las ejecuciones posteriores del mismo escenario de prueba actualizan el mismo panel, por lo que su cuenta contiene un panel para cada escenario de prueba en cada región. Estos paneles permanecen en su cuenta una vez finalizadas las pruebas. Tienen un coste mensual hasta que los elimines. La solución elimina los paneles de un escenario al eliminar el escenario de prueba (por ejemplo, a través de la consola web). Los paneles no se eliminan al eliminar las pilas de la solución. CloudFormation Para obtener más información, consulte la sección Costo y la sección Eliminación manual de los recursos retenidos de esta guía.
Administración de usuarios
Durante la configuración inicial, proporciona un nombre de usuario y una dirección de correo electrónico que Amazon Cognito utiliza para concederle acceso a la consola web de la solución. La consola no proporciona la administración de usuarios. Para agregar usuarios adicionales, debe usar la consola de Amazon Cognito. Para obtener más información, consulte Administración de usuarios en grupos de usuarios en la Guía para desarrolladores de Amazon Cognito.
Para migrar los usuarios existentes a los grupos de usuarios de Amazon Cognito, consulte el blog de AWS Approaches for migrating users to Amazon Cognito.
Federación de proveedores de identidades
El grupo de usuarios de Amazon Cognito de la solución admite la federación con proveedores de identidad externos (IdPs) mediante los protocolos SAML 2.0 u OpenID Connect (OIDC). La federación permite a los usuarios iniciar sesión en la consola web con sus credenciales corporativas u organizativas existentes en lugar de las credenciales. Cognito-native Los usuarios federados reciben los mismos permisos de acceso que los usuarios creados directamente en el grupo de usuarios de Cognito.
La solución ya implementa el grupo de usuarios, el dominio, el cliente de aplicaciones y la interfaz de usuario alojada de Cognito. Para habilitar la federación, solo necesita registrar su proveedor de identidad y habilitarlo en el cliente de la aplicación existente.
Si implementa la integración opcional del servidor MCP, los usuarios federados también pueden acceder al servidor MCP con las mismas credenciales del grupo de usuarios de Cognito.
Requisitos previos
Antes de configurar la federación, necesita lo siguiente:
-
Un proveedor de identidades externo que admita SAML 2.0 u OIDC
-
Acceso de administrador para configurar el IdP externo (para establecer los URI de redireccionamiento o las URL de ACS)
-
El ID del grupo de usuarios de Cognito de la solución (disponible en los recursos de la CloudFormation pila o en la consola de Amazon Cognito)
-
El prefijo de dominio Cognito de la solución (disponible en los resultados de la CloudFormation pila o en la consola de Cognito, en Integración de aplicaciones > Dominio)
Paso 1: Configura tu proveedor de identidad
Configure su proveedor de identidad externo con los siguientes valores para que pueda comunicarse con el grupo de usuarios de Cognito de la solución.
Para los proveedores de identidades SAML:
-
ID de entidad SP:
urn:amazon:cognito:sp:_<UserPoolId>_ -
URL DE ACS:
\https://<cognito-domain>.auth.<region>.amazoncognito.com/saml2/idpresponse
Para los proveedores de identidad OIDC:
-
URI de redireccionamiento:
\https://<cognito-domain>.auth.<region>.amazoncognito.com/oauth2/idpresponse
Para obtener más información sobre lo que necesita su IdP, consulte Agregar proveedores de identidades SAML a un grupo de usuarios o Agregar proveedores de identidades OIDC a un grupo de usuarios en la Guía para desarrolladores de Amazon Cognito.
Paso 2: Registrar el proveedor de identidad en Cognito
Agregue su proveedor de identidad externo al grupo de usuarios de Cognito existente de la solución mediante la consola de Amazon Cognito.
Para obtener instrucciones paso a paso, consulte Cómo agregar el inicio de sesión a un grupo de usuarios a través de un tercero en la Guía para desarrolladores de Amazon Cognito.
Paso 3: configurar las asignaciones de atributos
Configure las asignaciones de atributos entre las afirmaciones de su proveedor de identidad y los atributos del grupo de usuarios de Cognito. Como mínimo, asigna la notificación de correo electrónico del usuario procedente del proveedor externo al atributo Cognito. email Considera también la posibilidad de mapear name o de nickname que tu proveedor de identidad los suministre.
Para obtener instrucciones, consulte Especificar las asignaciones de atributos de los proveedores de identidad para su grupo de usuarios en la Guía para desarrolladores de Amazon Cognito.
Paso 4: Habilite el proveedor de identidades en el cliente de la aplicación
En la consola de Amazon Cognito, busque el cliente de la aplicación creado por la solución y habilite su nuevo proveedor de identidades en la configuración de la interfaz de usuario alojada.
Para obtener instrucciones, consulte Configuración de un cliente de aplicaciones de grupo de usuarios en la Guía para desarrolladores de Amazon Cognito.
nota
La solución ya configura las URL de devolución de llamada y cierre de sesión del cliente de la aplicación, los ámbitos de OAuth y el dominio de la interfaz de usuario alojada. No necesitas modificar esta configuración, solo habilita tu proveedor de identidad en el cliente de la aplicación existente.
importante
La solución omite intencionadamente la SupportedIdentityProviders propiedad de la configuración del cliente de la CloudFormation aplicación. Esto le permite agregar proveedores de identidad después de la implementación sin activar la detección de desviaciones. CloudFormation Si se configurara esta propiedad en la plantilla, cualquier cambio manual de IdP realizado mediante la consola o la CLI se sobrescribiría en la siguiente actualización de la pila, con lo que el cliente de la aplicación pasaría a depender únicamente de los proveedores que figuran en la plantilla.
Como se omite esta propiedad, CloudFormation no rastrea ni administra qué proveedores de identidad están habilitados en el cliente de la aplicación. Tras configurar la federación, usted es responsable de administrar el contenido del cliente SupportedIdentityProviders de la aplicación. Para supervisar los cambios no autorizados, habilite el CloudTrail registro de AWS y cree EventBridge reglas de Amazon para alertar sobre CreateIdentityProvider las llamadas a la UpdateUserPoolClient API dirigidas al grupo de usuarios de Cognito de la solución.
nota
-
La adición de un proveedor de identidad externo no elimina la posibilidad de que Cognito-native los usuarios actuales inicien sesión con sus credenciales actuales.
-
Los usuarios federados están sujetos a las mismas restricciones de disponibilidad regional que el grupo de usuarios de Cognito. Para obtener más información, consulte Implementación regional.
-
Prueba el inicio de sesión federado con un grupo reducido de usuarios antes de implementarlo en tu organización.
Inhabilitar o eliminar el usuario predeterminado de Cognito
Tras configurar la federación, es posible que desee deshabilitar o eliminar el usuario predeterminado que se creó durante la implementación de la pila. Esto es opcional: el usuario predeterminado sigue funcionando junto con el inicio de sesión federado.
Para inhabilitar a un usuario, navegue hasta el grupo de usuarios de Cognito de la solución en la consola de Amazon Cognito
Para obtener más información, consulte Administración y búsqueda de cuentas de usuario en la Guía para desarrolladores de Amazon Cognito.
Implementación regional
Esta solución utiliza Amazon Cognito, que solo está disponible en regiones específicas de AWS. Por lo tanto, debe implementar esta solución en una región en la que Amazon Cognito esté disponible. Para conocer la disponibilidad de servicios más actualizada por región, consulte la lista de servicios regionales de
