Uno de los problemas que enfrentan con frecuencia los proveedores de software multicanal es la duplicación de competencias de ingenieros —desarrolladores, testers y administradores de infraestructura— en casi cada equipo. Esto también se refiere a ingenieros costosos —especialistas en pruebas de carga.
En lugar de centrarse en sus tareas directas y utilizar su experiencia única para establecer el proceso de pruebas de carga, elegir metodologías, valores óptimos de métricas y escribir pruebas automatizadas de acuerdo con los perfiles de carga, los ingenieros a menudo tienen que desplegar desde cero la infraestructura de prueba, configurar herramientas de carga, integrarlas en sistemas de CI, configurar monitoreo y publicar informes.
Las soluciones a algunos problemas organizativos en las pruebas que aplicamos en Positive Technologies se pueden encontrar en . En este artículo, hablaré sobre la posibilidad de integrar pruebas de carga en un canal general de CI utilizando el concepto de "pruebas de carga como servicio" (load testing as a service). Aprenderá cómo y qué imágenes de Docker de fuentes de carga se pueden utilizar en el canal de CI; cómo conectar fuentes de carga a su proyecto de CI mediante una plantilla de compilación; cómo es un pipeline demo para ejecutar pruebas de carga y publicar resultados. Este artículo puede ser útil para ingenieros de pruebas de software e ingenieros de automatización en CI que están considerando la arquitectura de su sistema de carga.
La esencia del concepto
El concepto de pruebas de carga como servicio implica la posibilidad de integrar herramientas de carga como Apache JMeter, Yandex.Tank y frameworks propios en cualquier sistema de integración continua. El ejemplo demostrativo será para GitLab CI, pero los principios son aplicables a todos los sistemas de CI.
Las pruebas de carga como servicio son un servicio centralizado para realizar pruebas de carga. Las pruebas se ejecutan en grupos dedicados de agentes, y la publicación de resultados ocurre automáticamente en GitLab Pages, Influx DB y Grafana o en sistemas de informes de pruebas (TestRail, ReportPortal, etc.). La automatización y escalado se implementan de manera sencilla —a través de la adición y parametrización en el proyecto de GitLab CI de una plantilla gitlab-ci.yml estándar.
La ventaja de este enfoque radica en que toda la infraestructura CI, los agentes de carga, las imágenes de Docker de las fuentes de carga, los pipelines de prueba y la publicación de informes son gestionados por un departamento centralizado de automatización (ingenieros DevOps), lo que permite a los ingenieros de pruebas de carga concentrarse en el desarrollo de pruebas y el análisis de sus resultados, sin encargarse de cuestiones de infraestructura.
Para simplificar la descripción, consideraremos que la aplicación o servidor de destino ya están desplegados y configurados con antelación (para esto se pueden utilizar scripts automatizados en Python, SaltStack, Ansible, etc.). Así, toda la concepción de las pruebas de carga como servicio se distribuye en tres etapas: preparación, prueba, publicación de informes. Más detalles en el esquema (todas las imágenes son clicables):
Conceptos y definiciones clave en pruebas de carga
Al llevar a cabo pruebas de carga, tratamos de adherirnos a , utilizando la terminología adecuada y las métricas recomendadas. A continuación, presento un breve listado de conceptos y definiciones clave en pruebas de carga.
Agente de carga (load agent) — una máquina virtual en la que se ejecutará la aplicación origen de carga (Apache JMeter, Yandex.Tank o un módulo de carga personalizado).
Objetivo de la prueba (target) — el servidor o la aplicación instalada en el servidor que será sometido a carga.
Escenario de prueba (test case) — un conjunto de pasos parametrizados: acciones de los usuarios y las reacciones esperadas a estas acciones, con solicitudes y respuestas de red registradas según los parámetros especificados.
Perfil o plan de carga (profile) — en (p. 4.2.4, pág. 43) los perfiles de carga determinan métricas críticas para la prueba específica y opciones para modificar los parámetros de carga a lo largo de la prueba. Ejemplos de perfiles pueden verse en la imagen.
Prueba (test) — un escenario con un conjunto de parámetros previamente definidos.
Plan de prueba (test-plan) — un conjunto de pruebas y un perfil de carga.
Ejecución de prueba (testrun) — una iteración de la ejecución de una prueba con un escenario de carga completamente realizado y un informe obtenido.
Solicitud de red (request) — una solicitud HTTP enviada desde el agente al objetivo.
Respuesta de red (response) — Respuesta HTTP enviada del objetivo al agente.
El código de respuesta HTTP (código de estado de respuestas HTTP) es el código estándar de respuesta del servidor de aplicaciones.
Transacción (transaction) — ciclo completo de "solicitud — respuesta". Una transacción se considera desde el inicio del envío de la solicitud (request) hasta la finalización de la recepción de la respuesta (response).
Estado de la transacción (transactions status) — si se logró completar con éxito el ciclo "solicitud – respuesta". Si hubo algún error en este ciclo, toda la transacción se considera fallida.
Tiempo de respuesta (latency) — el tiempo desde que se finaliza el envío de la solicitud (request) hasta que comienza la recepción de la respuesta (response).
Métricas de carga (metrics) — características del servicio y el agente de carga definidas durante el proceso de prueba de carga.
Métricas principales para medir los parámetros de carga
Algunas métricas de uso común y recomendadas en la metodología (pág. 36, 52) se presentan en la tabla a continuación. Métricas similares para el agente y el objetivo se indican en una misma fila.
Métricas para el agente de carga
Métricas del sistema o aplicación objetivo, probados bajo carga
Cantidad vCPU y memoria RAM,
Disco — características "hardware" del agente de carga
CPU, Memoria, Uso del disco — dinámica de carga del procesador, memoria y disco
durante la prueba. Se mide generalmente en porcentajes de
valores máximamente disponibles
Ancho de banda de la red (Network throughput) (en el agente de carga) — capacidad de transmisión
del interfaz de red en el servidor,
donde está instalado el agente de carga.
Generalmente se mide en bytes por segundo (bps)
Ancho de banda de la red (Network throughput)(en destino) — capacidad de transmisión del interfaz de red
en el servidor objetivo. Se mide generalmente en bytes por segundo (bps)
Usuarios virtuales (Virtual users)— número de usuarios virtuales,
que implementan escenarios de carga e
imitan las acciones reales de los usuarios.
Estado de usuarios virtuales (Virtual users status), Aprobados/Fallidos/Total — número de estados exitosos y
fallidos del funcionamiento de los usuarios virtuales
para los escenarios de carga, así como su número total.
Se espera generalmente que todos los usuarios hayan podido realizar
todas sus tareas indicadas en el perfil de carga.
Cualquier error significará que un usuario real tampoco podrá
resolver su tarea al trabajar con el sistema.
Solicitudes por segundo (minuto)— número de solicitudes de red por segundo (o minuto).
Característica importante del agente de carga: cuántas puede generar.
De hecho, esto es una simulación de la interacción con la aplicación por parte de usuarios virtuales
Respuestas por segundo (minuto)
— el número de respuestas de red por segundo (o minuto).
Una característica importante del servicio objetivo: cuántas respuestas se lograron
generar y enviar a las solicitudes de
el agente de carga
Estado de las respuestas HTTP— la cantidad de distintos códigos de respuesta
del servidor de la aplicación que fueron recibidos por el agente de carga.
Por ejemplo, 200 OK significa una solicitud exitosa,
y 404 indica que el recurso no fue encontrado
Latencia (tiempo de respuesta) — el tiempo desde que se termina
el envío de la solicitud (request) hasta que comienza a recibirse la respuesta (response).
Normalmente se mide en milisegundos (ms)
Tiempo de respuesta de la transacción— el tiempo de una transacción completa,
el cierre del ciclo "solicitud — respuesta".
Este es el tiempo desde que se inicia el envío de la solicitud (request)
hasta que se termina de recibir la respuesta (response).
El tiempo de la transacción se puede medir de varias maneras: se consideran los mínimos,
máximos, promedio y, por ejemplo, el percentil 90.
Las lecturas mínimas y máximas son los extremos
de la capacidad de rendimiento del sistema.
El percentil 90 se usa con mayor frecuencia
porque muestra la mayoría de los usuarios,
que trabajan cómodamente en el umbral de rendimiento del sistema
Transacciones por segundo (minuto)
— la cantidad de transacciones completas por segundo (minuto), es decir, cuántas solicitudes pudo recibir y
procesar la aplicación y emitir respuestas.
De hecho, esto es el rendimiento del sistema
Estado de las transacciones
, Pasado / Fallido / Total — la cantidad
de transacciones exitosas, fallidas y el número total de transacciones. Para los usuarios reales, una transacción fallida
significará en realidad
la imposibilidad de trabajar con el sistema bajo carga
El esquema fundamental de las pruebas de carga
El esquema fundamental de las pruebas de carga es muy simple y consta de tres etapas principales, de las que ya he hablado:
Preparar — Probar — Informar
, es decir, preparar los objetivos de prueba y establecer parámetros para las fuentes de carga, luego realizar las pruebas de carga y, al final, generar y publicar el informe de pruebas. Notas sobre el esquema:QA.Tester — experto en pruebas de carga,
Objetivo — la aplicación objetivo, para la cual es necesario conocer su comportamiento bajo carga.
- Clasificador de entidades, etapas y pasos en el esquema
- Etapas y pasos
¿Qué ocurre?
Этапы и шаги
Что происходит
Qué hay de entrada
Qué hay de salida
Prepare: etapa de preparación para las pruebas
LoadParameters
Asignación e inicialización
por el usuario
de los parámetros de carga,
elección de métricas y
preparación del plan de pruebas
(perfil de carga)
Parámetros personalizados para
la inicialización del agente de carga
Plan de pruebas
Objetivo de la prueba
VM
Despliegue en la nube
de máquina virtual con
características requeridas
Parámetros de VM para el agente de carga
Scripts de automatización para
la creación de VM
VM configurada en
la nube
Env
Configuración del sistema operativo y preparación
del entorno para
el funcionamiento del agente de carga
Parámetros del entorno para
el agente de carga
Scripts de automatización para
configuración del entorno
Entorno preparado:
Sistema operativo, servicios y aplicaciones,
necesarios para el funcionamiento
el agente de carga
LoadAgents
Instalación, configuración y parametrización
del agente de carga.
O descarga de la imagen de Docker con
fuente de carga preconfigurada
Imagen de Docker de fuente de carga
(JMeter, JM o marco de trabajo personalizado)
Parámetros de configuración
el agente de carga
Agente de carga configurado y listo
para trabajar
Test: etapa de ejecución de pruebas de carga. Las fuentes son agentes de carga, desplegados en grupos dedicados de agentes para GitLab CI
Cargar
Inicio del agente de carga
con el plan de pruebas seleccionado
y parámetros de carga
Parámetros personalizados
para la inicialización
el agente de carga
Plan de pruebas
Objetivo de la prueba
Registros de ejecución
de pruebas de carga
Registros del sistema
Dinámica de cambios en las métricas del objetivo y del agente de carga
RunAgents
Ejecución por parte del
agente de carga de escenarios de prueba
de acuerdo con
perfil de carga
Interacción del agente de carga
con el objetivo de prueba
Plan de pruebas
Objetivo de la prueba
Registros
Recolección de registros 'en crudo'
durante las pruebas de carga:
registros de las acciones del agente de carga,
estado del objetivo de prueba
y de la máquina virtual en la que se ejecuta el agente
Registros de ejecución
de pruebas de carga
Registros del sistema
Métricas
Recolección de métricas 'en crudo' durante las pruebas
Dinámica de cambios en las métricas del objetivo
y del agente de carga
Report: etapa de preparación del informe de pruebas
Generator
Procesamiento de las métricas y registros 'en crudo' recolectados por
el sistema de carga y
el sistema de monitoreo
Formación del informe en
un formato legible,
posiblemente con elementos
de análisis
Dinámica de cambios en las métricas
Registros de ejecución
de pruebas de carga
Registros del sistema
del objetivo y del agente de carga
Registros 'en crudo' procesados
en un formato adecuado para
exportación a almacenes externos
Informe estático de carga,
adecuado para el análisis humano
Publicación del informe
Publicar
sobre la prueba de carga
en un servicio externo
Registros 'en crudo' procesados
сервисе
Обработанные «сырые»
registros en un formato utilizable
para exportación a sistemas externos
almacén
Informes almacenados en un
almacenamiento externo sobre
carga, adecuados
para análisis humano
Conexión de fuentes de carga en la plantilla de CI
Pasemos a la parte práctica. Quiero mostrar cómo en algunos proyectos de la empresa hemos implementado el concepto de pruebas de carga como servicio.
Primero, nuestros ingenieros de DevOps crearon en GitLab CI un grupo dedicado de agentes para ejecutar pruebas de carga. Para no confundirlos en las plantillas con otros, como los de compilación, añadimos etiquetas a estos agentes, : load. Se pueden utilizar cualquier otra etiqueta comprensible. Se definen de los ejecutores de GitLab CI.
¿Cómo determinar la potencia requerida de «hardware»? Las características de los agentes de carga — suficiente cantidad de vCPU, RAM y Disco — se pueden calcular en base a que en el agente deben estar en ejecución Docker, Python (para Yandex.Tank), el agente de GitLab CI, Java (para Apache JMeter). Para Java bajo JMeter también se recomienda usar un mínimo de 512 MB de RAM y, como límite superior, .
Así, basándonos en nuestra experiencia, recomendamos usar para los agentes de carga al menos: 4 vCPU, 4 GB de RAM, 60 GB de SSD. El ancho de banda del adaptador de red se determina en función de los requisitos del perfil de carga.
Principalmente utilizamos dos fuentes de carga: imágenes de Docker de Apache JMeter y Yandex.Tank.
es una herramienta de código abierto de la empresa Yandex para realizar pruebas de carga. Su arquitectura modular se basa en un generador HTTP de solicitudes asíncronas de alta rendimiento llamado Phantom. Tank tiene monitoreo incorporado de los recursos del servidor de prueba a través del protocolo SSH, puede detener automáticamente las pruebas bajo ciertas condiciones, puede mostrar resultados tanto en consola como en forma de gráficos, y se le pueden conectar módulos propios para extender su funcionalidad. Por cierto, utilizamos Tank cuando eso aún no era una tendencia general. En el artículo «se puede leer la historia de cómo en 2013 realizamos pruebas de carga con su ayuda uno de los productos de nuestra empresa.
JMeter es una herramienta de código abierto para realizar pruebas de carga de la empresa Apache. Se puede utilizar con la misma eficacia tanto para probar aplicaciones web estáticas como dinámicas. JMeter admite una gran cantidad de protocolos y métodos de interacción con aplicaciones: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), servicios web SOAP / REST, FTP, TCP, LDAP, SMTP(S), POP3(S) e IMAP(S), bases de datos a través de JDBC, puede ejecutar comandos de shell y trabajar con objetos Java. JMeter tiene un IDE para crear, depurar y ejecutar planes de prueba. También cuenta con una CLI para trabajar desde la línea de comandos en cualquier sistema operativo compatible con Java (Linux, Windows, Mac OS X). La herramienta puede generar dinámicamente un informe HTML sobre las pruebas.
Para facilitar su uso dentro de nuestra empresa, y permitir que los testers modifiquen y añadan entornos, hemos creado imágenes de Docker de las fuentes de carga en GitLab CI con publicación en nuestro . Esto hace que sea más rápido y fácil conectarlas en los pipelines para pruebas de carga. Cómo hacer un docker push en el registro a través de GitLab CI — consulte en .
El archivo Docker básico para Yandex.Tank que utilizamos es este:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Y para Apache JMeter este:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Cómo está organizada nuestra sistema de integración continua, puede leerlo en el artículo “».
Plantilla y pipeline
Un ejemplo de plantilla para realizar pruebas de carga está disponible en el proyecto . Hay se puede leer la instrucción sobre cómo usar la plantilla. En la propia plantilla (archivo ) hay anotaciones sobre a qué corresponde cada paso.
La plantilla es muy simple y demuestra tres etapas de pruebas de carga, como se describió anteriormente en el esquema: preparación, prueba y publicación de informes. Esto corresponde a las : Prepare, Test y Report.
- Etapa debe usarse para la configuración preliminar de los objetivos de prueba o para verificar su disponibilidad. No es necesario configurar el entorno para las fuentes de carga, ya que se han creado previamente como imágenes de Docker y se han subido al registro de Docker: basta con indicar la versión requerida en la etapa Test. Pero se pueden reconstruir y crear sus propias imágenes modificadas.
- Etapa se utiliza para especificar la fuente de carga, iniciar pruebas y guardar artefactos de prueba. Se puede elegir cualquier fuente de carga: Yandex.Tank, Apache JMeter, la propia o todas juntas. Para desactivar fuentes no deseadas, basta con comentar o eliminar la tarea. Puntos de entrada para las fuentes de carga:
- los parámetros de inicio de Yandex.Tank se especifican en el archivo.,
- los parámetros de inicio de Apache JMeter se especifican en el archivo .
Nota: la plantilla de configuración de compilación se utiliza para configurar la interacción con el sistema CI y no se supone que contenga la lógica de las pruebas. Para las pruebas, se especifica el punto de entrada, donde se encuentra el script bash controlador. La forma de ejecutar las pruebas, la generación de informes y los propios escenarios de prueba deben ser implementados por los ingenieros de QA. En el ejemplo de demostración, para ambas fuentes de carga, se utiliza una prueba simple que pide la página principal de Yandex. Los escenarios y parámetros de las pruebas se encuentran en el directorio .
- En la etapa se deben describir las formas de publicar los resultados de las pruebas obtenidos en la etapa de Prueba, en almacenes externos, por ejemplo, en GitLab Pages o sistemas de informes especiales. Para GitLab Pages, se requiere que, al finalizar las pruebas, el directorio .\/public no esté vacío y contenga al menos el archivo index.html. Sobre las peculiaridades del servicio GitLab Pages se puede leer .
Ejemplos de cómo exportar datos:
- de JMeter a ,
- de Yandex.Tank a .
Instrucciones para configurar la publicación:
- HTML-estáticos en ,
- en InfluxDB y luego en .
En el ejemplo de demostración, el pipeline con pruebas de carga y dos fuentes de carga (se puede desactivar la no deseada) se ve así:
Apache JMeter puede generar el informe HTML por sí mismo, por lo que es más beneficioso conservarlo en GitLab Pages utilizando los medios estándar. Así es como se ve el informe de Apache JMeter:
En el ejemplo de demostración para Yandex.Tank, solo verás un en la sección para GitLab Pages. Durante las pruebas, Tank puede guardar los resultados en la base de datos InfluxDB, y desde allí se pueden mostrar, por ejemplo, en Grafana (la configuración se realiza en el archivo ). Así es como se ve el informe del tanque en Grafana:
Currículum
En este artículo, hablo sobre el concepto de "pruebas de carga como servicio" (load testing as a service). La idea principal es utilizar la infraestructura de grupos preconfigurados de agentes de carga, imágenes de Docker para las fuentes de carga, sistemas de informes y un pipeline que los integre en GitLab CI basado en una plantilla simple .gitlab-ci.yml (ejemplo ). Todo esto es sostenido por un pequeño equipo de ingenieros automatizadores y se reproduce a solicitud de los equipos de producto. Espero que esto les ayude en la preparación e implementación de un esquema similar en su empresa. ¡Gracias por su atención!
P. S. Quiero dar un gran agradecimiento a mis colegas, Sergey Kurbanov y Nikolay Yusev, por su ayuda técnica en la implementación del concepto de pruebas de carga como servicio en nuestra empresa.
Autor: — Subdirector del departamento de tecnologías y procesos de desarrollo (DevOps) de Positive Technologies
Fuente: habr.com
