Un dos problemas aos que adoitan enfrontarse os provedores de software multiproduto é a duplicación das competencias dos enxeñeiros (desenvolvedores, probadores e administradores de infraestruturas) en case todos os equipos. Isto tamén se aplica aos enxeñeiros caros, especialistas no campo das probas de carga.
En lugar de realizar as súas tarefas directas e utilizar a súa experiencia única para construír un proceso de proba de carga, escoller unha metodoloxía, métricas óptimas e escribir autotests de acordo cos perfís de carga, os enxeñeiros adoitan ter que implementar a infraestrutura de proba desde cero, configurar ferramentas de carga e incorporalas. propios en sistemas CI, configuren informes de supervisión y publiquen.
Podes atopar solucións a algúns problemas organizativos nas probas que usamos en Positive Technologies en . E neste, falarei sobre a posibilidade de integrar as probas de carga nunha canalización de CI común utilizando o concepto de "proba de carga como servizo" (proba de carga como servizo). Aprenderá como e que imaxes docker das fontes de carga se poden usar na canalización de CI; como conectar fontes de carga ao teu proxecto CI usando un modelo de compilación; como é o pipeline de demostración para realizar probas de carga e publicar os resultados. O artigo pode ser útil para enxeñeiros de probas de software e enxeñeiros de automatización en CI que estean pensando na arquitectura do seu sistema de carga.
A esencia do concepto
O concepto de proba de carga como servizo implica a capacidade de integrar ferramentas de carga Apache JMeter, Yandex.Tank e os seus propios cadros nun sistema de integración continua arbitrario. A demostración será para GitLab CI, pero os principios son comúns a todos os sistemas CI.
A proba de carga como servizo é un servizo centralizado para probas de carga. As probas de carga realízanse en grupos de axentes dedicados, os resultados publícanse automaticamente en GitLab Pages, Influx DB e Grafana ou en sistemas de informes de probas (TestRail, ReportPortal, etc.). A automatización e a escala implícanse o máis sinxelo posible, engadindo e parametrizando o modelo habitual gitlab-ci.yml no proxecto GitLab CI.
A vantaxe do enfoque é que toda a infraestrutura de CI, os axentes de carga, as imaxes do acoplador das fontes de carga, os condutos de proba e a publicación de informes son mantidos por un departamento de automatización centralizado (enxeñeiros DevOps) e os enxeñeiros de probas de carga poden centrar os seus esforzos no desenvolvemento de probas e análise dos seus resultados, sen tratar problemas de infraestruturas.
Para simplificar a descrición, asumiremos que a aplicación ou o servidor de destino en proba xa foi despregado e configurado previamente (pódense usar scripts automatizados en Python, SaltStack, Ansible, etc. para iso). Entón, todo o concepto de proba de carga como servizo encádrase en tres etapas: elaboración, proba, publicación de informes. Máis detalles sobre o diagrama (todas as imaxes pódense facer clic):
Conceptos básicos e definicións en probas de carga
Ao realizar probas de carga, intentamos cumprir , use a terminoloxía adecuada e as métricas recomendadas. Darei unha pequena lista dos principais conceptos e definicións nas probas de carga.
Axente de carga - unha máquina virtual na que se iniciará a aplicación - a fonte de carga (Apache JMeter, Yandex.Tank ou un módulo de carga autoescrito).
Obxectivo da proba (obxectivo) - servidor ou aplicación instalada no servidor que será obxecto de carga.
Escenario de proba (caso de proba) - un conxunto de pasos parametrizados: accións do usuario e reaccións esperadas a estas accións, con solicitudes e respostas de rede fixas, dependendo dos parámetros especificados.
Perfil ou plano de carga (perfil) - dentro (Sección 4.2.4, p. 43) os perfís de carga definen métricas que son críticas para unha proba particular e opcións para cambiar os parámetros de carga durante a proba. Podes ver exemplos de perfís na figura.
Proba — un script cun conxunto predeterminado de parámetros.
Plan de proba (plan de proba) - un conxunto de probas e un perfil de carga.
Testran (testrán) - unha iteración de realizar unha proba cun escenario de carga totalmente executado e o informe recibido.
Solicitude de rede (solicitude) — Unha solicitude HTTP enviada desde un axente a un destino.
Resposta da rede (resposta) — Unha resposta HTTP enviada desde o destino ao axente.
Código de resposta HTTP (estado das respostas HTTP): código de resposta estándar do servidor de aplicacións.
Unha transacción é un ciclo completo de solicitude-resposta. Unha transacción cóntase desde o inicio do envío dunha solicitude (solicitude) ata a finalización da recepción dunha resposta (resposta).
Estado da transacción - se foi posible completar con éxito o ciclo solicitude-resposta. Se houbo algún erro neste ciclo, a transacción enteira considérase sen éxito.
Tempo de resposta (latencia) - o tempo desde o final do envío dunha solicitude (solicitude) ata o inicio da recepción dunha resposta (resposta).
Cargar métricas — as características do servizo cargado e do axente de carga determinados no proceso de proba de carga.
Métricas básicas para medir parámetros de carga
Algunhas das máis utilizadas e recomendadas na metodoloxía (páx. 36, 52) as métricas móstranse na seguinte táboa. Na mesma liña móstranse métricas similares para o axente e o destino.
Métricas para o axente de carga
Métricas do sistema ou aplicación de destino que se está a probar baixo carga
Número vCPU e memoria RAM,
Disco - Características "ferro" do axente de carga
CPU, Memoria, uso do disco - dinámica da CPU, memoria e carga do disco
en proceso de proba. Adoita medirse como unha porcentaxe de
valores máximos dispoñibles
rendemento da rede (no axente de carga) - rendemento
interface de rede no servidor,
onde está instalado o axente de carga.
Normalmente se mide en bytes por segundo (bps)
rendemento da rede(no destino) - ancho de banda da interface de rede
no servidor de destino. Normalmente se mide en bytes por segundo (bps)
Usuarios virtuais- o número de usuarios virtuais,
implementación de escenarios de carga e
imitando accións reais do usuario
Estado dos usuarios virtuais, Aprobado/Fallo/Total — número de éxitos e
estados non exitosos dos usuarios virtuais
para escenarios de carga, así como o seu número total.
En xeral, espérase que todos os usuarios puidesen completar
todas as súas tarefas especificadas no perfil de carga.
Calquera erro significará que un usuario real non poderá facelo
resolver o seu problema ao traballar co sistema
Solicitudes por segundo (minuto)- o número de solicitudes de rede por segundo (ou minuto).
Unha característica importante dun axente de carga é cantas solicitudes pode xerar.
De feito, trátase dunha imitación do acceso á aplicación por parte dos usuarios virtuais
Respostas por segundo (minuto)
- o número de respostas de rede por segundo (ou minuto).
Unha característica importante do servizo obxectivo: canto
xerar e enviar respostas a consultas con
axente de carga
Estado da resposta HTTP— Número de códigos de resposta diferentes
do servidor de aplicacións recibido polo axente de carga.
Por exemplo, 200 OK significa unha chamada exitosa,
e 404 - que non se atopou o recurso
Latencia (tempo de resposta) - tempo dende o final
enviar unha solicitude (solicitude) antes de comezar a recibir unha resposta (resposta).
Normalmente mídese en milisegundos (ms)
Tempo de resposta das transaccións- tempo dunha transacción completa,
finalización do ciclo solicitude-resposta.
Este é o tempo desde o inicio do envío da solicitude (solicitude)
ata completar a recepción dunha resposta (resposta).
O tempo de transacción pódese medir en segundos (ou minutos)
de varias maneiras: considerar o mínimo,
máximo, medio e, por exemplo, o percentil 90.
As lecturas mínimas e máximas son extremas
estado de rendemento do sistema.
O percentil noventa é o máis utilizado,
como mostra a maioría dos usuarios,
operando comodamente no limiar do rendemento do sistema
Transaccións por segundo (minuto) - o número de completos
transaccións por segundo (minuto),
é dicir, canto puido aceptar a solicitude e
procesar solicitudes e emitir respostas.
De feito, este é o rendemento do sistema
Estado da transacción , Aprobado / Fallado / Total - número
exitoso, non exitoso e o número total de transaccións.
Para usuarios reais sen éxito
a transacción significará realmente
incapacidade para traballar co sistema baixo carga
Diagrama esquemático de proba de carga
O concepto de proba de carga é moi sinxelo e consta de tres etapas principais, que xa mencionei: Preparar-Proba-Informe, é dicir, preparar obxectivos de proba e establecer parámetros para as fontes de carga, executar despois probas de carga e, ao final, xerar e publicar un informe de proba.
Notas esquemáticas:
- QA.Tester é un experto en probas de carga,
- Target é a aplicación de destino para a que quere coñecer o seu comportamento baixo carga.
Clasificador de entidades, etapas e pasos do diagrama
Etapas e pasos
Que pasa
Que hai na entrada
Cal é a saída
Preparación: fase de preparación para a proba
Cargar parámetros
Configuración e inicialización
usuario
parámetros de carga,
elección de métricas e
preparación do plan de proba
(cargar perfil)
Opcións personalizadas para
inicialización do axente de carga
Plan de proba
Finalidade da proba
VM
Implantación na nube
máquina virtual con
características requiridas
Configuración da máquina virtual para o axente de carga
Scripts de automatización para
Creación de VM
VM configurada en
nube
Enviar
Configuración e preparación do SO
ambiente para
traballo do axente de carga
Configuración do entorno para
axente de carga
Scripts de automatización para
configuración do entorno
Ambiente preparado:
OS, servizos e aplicacións,
necesarios para o traballo
axente de carga
Axentes de carga
Instalación, configuración e parametrización
axente de carga.
Ou descargando unha imaxe de docker desde
fonte de carga preconfigurada
Cargar imaxe docker fonte
(YAT, JM ou marco autoescrito)
Configuración
axente de carga
Configura e listo
para traballar axente de carga
Proba: fase de execución das probas de carga. As fontes son axentes de carga despregados en grupos de axentes dedicados para GitLab CI
Carga
Iniciando o axente de carga
co plan de proba seleccionado
e parámetros de carga
Opcións de usuario
para inicialización
axente de carga
Plan de proba
Finalidade da proba
Rexistros de execución
probas de carga
Rexistros do sistema
Dinámica de cambios nas métricas dos obxectivos e no axente de carga
Executar axentes
Axente de execución
un montón de scripts de proba
dacordo con
perfil de carga
Interacción do axente de carga
coa finalidade da proba
Plan de proba
Finalidade da proba
Rexistros
Recollida de rexistros "crus".
durante a proba de carga:
cargar rexistros de actividade do axente,
estado do obxectivo da proba
e a máquina virtual que executa o axente
Rexistros de execución
probas de carga
Rexistros do sistema
Métrica
Recopilación de métricas "en bruto" durante as probas
Dinámica de cambios nas métricas dos obxectivos
e axente de carga
Informe: fase de elaboración do informe de proba
Xerador
Procesamento recollido
sistema de carga e
sistema de monitorización "raw"
métricas e rexistros
Elaboración dun informe en
forma lexible humana
posible con elementos
analistas
Rexistros de execución
probas de carga
Rexistros do sistema
Dinámica de cambios nas métricas
destino e axente de carga
Rexistros "en bruto" procesados
nun formato axeitado para
cargas en almacenamento externo
Informe de carga estática,
lexible polo home
Publicar
Publicación do informe
sobre a carga
probas en externo
servizo
Procesado "en bruto"
rexistros nun formato axeitado
para descarga a exterior
repositorios
Gardado en externo
informes de almacenamento
carga, adecuado
para análise humana
Conectando fontes de carga nun modelo de CI
Pasemos á parte práctica. Quero mostrar como nalgúns proxectos na empresa implementamos o concepto de proba de carga como servizo.
En primeiro lugar, coa axuda dos nosos enxeñeiros de DevOps, creamos un grupo dedicado de axentes en GitLab CI para realizar probas de carga. Para non confundilos en modelos con outros, como grupos de conxuntos, engadimos etiquetas a estes axentes, : carga. Podes usar calquera outra etiqueta comprensible. preguntan Corredores de GitLab CI.
Como descubrir a potencia necesaria polo hardware? As características dos axentes de carga -un número suficiente de vCPU, RAM e disco- pódense calcular en función do feito de que Docker, Python (para Yandex.Tank), o axente GitLab CI, Java (para Apache JMeter) deberían executarse no axente. . Para Java baixo JMeter, tamén se recomenda utilizar un mínimo de 512 MB de RAM e, como límite superior, .
Así, segundo a nosa experiencia, recomendamos utilizar polo menos 4 vCPU, 4 GB de RAM, 60 GB SSD para axentes de carga. O rendemento da tarxeta de rede determínase en función dos requisitos do perfil de carga.
Usamos principalmente dúas fontes de carga: Apache JMeter e imaxes docker Yandex.Tank.
é unha ferramenta de código aberto de Yandex para probas de carga. A súa arquitectura modular baséase no xerador de solicitudes HTTP asíncrono de alto rendemento de Phantom. O tanque ten un seguimento integrado dos recursos do servidor en proba a través do protocolo SSH, pode deter automaticamente a proba en condicións especificadas, pode mostrar os resultados tanto na consola como en forma de gráficos, pode conectar os seus módulos para ampliar a súa funcionalidade. Por certo, usamos o Tanque cando aínda non era mainstream. No artigo "» podes ler a historia de como realizamos as probas de carga con el en 2013 é un dos produtos da nosa empresa.
é unha ferramenta de proba de carga de código aberto de Apache. Pódese usar igualmente ben para probar aplicacións web tanto estáticas como dinámicas. JMeter admite un gran número de protocolos e formas de interactuar con aplicacións: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), Servizos web SOAP/REST, FTP, TCP, LDAP, SMTP(S), POP3( S) ) e IMAP(S), bases de datos a través de JDBC, poden executar comandos de shell e traballar con obxectos Java. JMeter ten un IDE para crear, depurar e executar plans de proba. Tamén hai unha CLI para o funcionamento da liña de comandos en calquera sistema operativo compatible con Java (Linux, Windows, Mac OS X). A ferramenta pode xerar dinámicamente un informe de proba HTML.
Para facilitar o seu uso dentro da nosa empresa, para a capacidade dos propios probadores de cambiar e engadir o ambiente, fixemos compilacións de imaxes docker de fontes de carga en GitLab CI con publicación no sistema interno. . Isto fai que sexa máis rápido e sinxelo conectalos en canalizacións para probas de carga. Como facer docker push para o rexistro a través de GitLab CI - ver .
Tomamos este ficheiro docker básico para Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]E para Apache JMeter este:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Podes ler como funciona o noso sistema de integración continua no artigo "».
Modelo e canalización
No proxecto está dispoñible un exemplo de modelo para realizar probas de carga . En Podes ler as instrucións para usar o modelo. No propio modelo (arquivo ) hai notas sobre o que é responsable de cada paso.
O modelo é moi sinxelo e demostra as tres etapas da proba de carga descritas no diagrama anterior: preparación, proba e publicación de informes. Responsable disto : Preparar, probar e informar.
- Etapa debe utilizarse para preconfigurar obxectivos de proba ou comprobar a súa dispoñibilidade. Non é necesario configurar o ambiente para as fontes de carga, xa que están preconstruídas como imaxes do docker e publicadas no rexistro docker: só tes que especificar a versión desexada na fase de proba. Pero podes reconstruílos e crear as túas propias imaxes modificadas.
- Etapa usado para especificar a fonte de carga, executar probas e almacenar artefactos de proba. Podes escoller calquera fonte de carga: Yandex.Tank, Apache JMeter, o teu propio ou todos xuntos. Para desactivar fontes innecesarias, só tes que comentar ou eliminar o traballo. Puntos de entrada para fontes de carga:
- Os parámetros de inicio de Yandex.Tank especifícanse no .,
- Os parámetros de inicio de Apache JMeter especifícanse no ficheiro .
Nota: O modelo de configuración do conxunto úsase para configurar a interacción co sistema CI e non implica a colocación da lóxica de proba nel. Para as probas, especifícase o punto de entrada, onde se atopa o script de control bash. O método de execución de probas, a xeración de informes e os propios scripts de proba deben ser implementados polos enxeñeiros de control de calidade. Na demostración, para ambas fontes de carga, a solicitude da páxina principal de Yandex úsase como a proba máis sinxela. Os scripts e os parámetros de proba están no directorio .
- No escenario cómpre describir como publicar os resultados da proba obtidos na fase de proba en almacenamentos externos, por exemplo, en páxinas de GitLab ou sistemas especiais de informes. GitLab Pages require que o directorio ./public non estea baleiro e conteña polo menos un ficheiro index.html despois de que se completen as probas. Podes ler sobre os matices do servizo de páxinas de GitLab. .
Exemplos de como exportar datos:
- de JMeter a ,
- de Yandex.Tank to .
Instrucións de configuración de publicación:
- Estática HTML en ,
- a InfluxDB e despois a .
No exemplo de demostración, a canalización con probas de carga e dúas fontes de carga (podes desactivar a innecesaria) ten o seguinte aspecto:
Apache JMeter pode xerar un informe HTML por si mesmo, polo que é máis rendible gardalo en GitLab Pages usando ferramentas estándar. Así se ve o informe Apache JMeter:
No exemplo de demostración de Yandex.Tank, só verás na sección de páxinas de GitLab. Durante a proba, o Tank pode gardar os resultados na base de datos InfluxDB, e desde alí pódense mostrar, por exemplo, en Grafana (a configuración realízase no ficheiro ). Así se ve o informe de Tank en Grafana:
Resumo
No artigo, falei sobre o concepto de "proba de carga como servizo" (proba de carga como servizo). A idea principal é utilizar a infraestrutura de grupos preconfigurados de axentes de carga, imaxes docker de fontes de carga, sistemas de informes e unha canalización que os combine en GitLab CI baseado nun modelo simple .gitlab-ci.yml (exemplo). ). Todo isto está apoiado por un pequeno equipo de enxeñeiros de automatización e replícase a petición dos equipos de produto. Espero que isto che axude a preparar e implementar un esquema similar na túa empresa. Grazas pola atención!
PS Quero agradecer moito aos meus compañeiros, Sergey Kurbanov e Nikolai Yusev, a asistencia técnica coa implementación do concepto de proba de carga como servizo na nosa empresa.
Autor: - Deputado Xefe de Tecnoloxía e Procesos de Desenvolvemento (DevOps) en Positive Technologies
Fonte: www.habr.com