Teste de Carga do Azure com plug-ins personalizados

Artigo
03/28/2024

Ideias de soluções

Este artigo descreve uma ideia de solução. Seu arquiteto de nuvem pode usar essa orientação para ajudar a visualizar os principais componentes para uma implementação típica dessa arquitetura. Use este artigo como ponto de partida para projetar uma solução bem arquitetada que se alinhe aos requisitos específicos de sua carga de trabalho.

Esta solução fornece orientação sobre como usar o Teste de Carga do Azure, um serviço que permite executar scripts Apache JMeter e plug-ins personalizados para simular comportamentos de usuário e dispositivo. Essa solução também explica como projetar KPIs (Indicadores Chave de Desempenho) e desenvolver um painel para monitorar e analisar os resultados do teste de carga em um aplicativo de exemplo com o Azure Functions e os Hubs de Eventos do Azure. O artigo pressupõe que você tenha alguma familiaridade com o JMeter, seus plug-ins e plug-ins personalizados, e também com o Azure Functions e os Hubs de Eventos.

Arquitetura

Para executar o teste de carga, você precisa de um plano de teste, que é um conjunto de instruções que informa o JMeter o que fazer durante o teste. O plano de teste pode incluir vários cenários de teste, cada um com diferentes definições e configurações. Por exemplo, você pode ter um cenário que simula um único usuário acessando um aplicativo Web e outro cenário que simula vários usuários acessando simultaneamente o mesmo aplicativo.

O plano de teste também pode incluir vários casos de teste, cada um com diferentes definições e configurações. Nesse caso, pressupomos que há um dispositivo que está informando a temperatura e a umidade durante um determinado período de tempo. O dispositivo está enviando os dados para um hub de eventos no Azure. O hub de eventos dispara uma Função do Azure que é responsável por processar os dados e, em seguida, enviar os dados para outros serviços downstream, como o Banco de Dados SQL do Azure. A Função do Azure é o serviço que queremos testar. O plano de teste foi projetado para simular o comportamento do dispositivo e enviar dados ao hub de eventos.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

Neste exemplo, o fluxo de dados é o seguinte:

Um dispositivo simulado envia dados para um hub de eventos por meio do agente de Teste de Carga do Azure. Qualquer comportamento do dispositivo pode ser simulado usando plugins personalizados do JMeter. O agente de Teste de Carga do Azure é responsável por enviar dados para o hub de eventos depois de executar o plug-in personalizado para qualquer tipo de dispositivo simulado.
O hub de eventos dispara uma Função do Azure que é responsável por processar os dados e, em seguida, enviar os dados para outros serviços downstream, como o Banco de Dados SQL do Azure e os Gêmeos Digitais do Azure.
O serviço do Azure Monitor é usado para monitorar os Hubs de Eventos e a Função do Azure.
O serviço de Teste de Carga do Azure coleta os dados do serviço do Azure Monitor e os exibe em um painel.

Componentes

Neste exemplo, os seguintes componentes são usados:

Teste de Carga do Azure: o Teste de Carga do Azure permite executar scripts Apache JMeter e plug-ins personalizados para simular comportamentos de usuário e dispositivo. Ele fornece uma interface baseada na Web para gerenciamento e execução de testes de carga e um conjunto de APIs que podem ser usadas para automatizar o processo. O Teste de Carga do Azure é um serviço totalmente gerenciado, o que significa que você não precisa se preocupar com o gerenciamento de servidores ou da infraestrutura. Você pode carregar seus scripts JMeter e plug-ins personalizados, e o Teste de Carga do Azure faz o resto.
Hubs de Eventos do Azure: os Hubs de Eventos do Azure são um serviço de processamento de eventos baseado em nuvem que pode ser usado para coletar, processar e analisar eventos e transmitir dados de várias fontes em tempo real. Os Hubs de Eventos dão suporte a vários protocolos, incluindo AMQP (Advanced Message Queuing Protocol), HTTPS, Protocolo Kafka, MQTT (Message Queuing Telemetry Transport) e AMQP over WebSockets. A escolha do protocolo certo depende de vários fatores, incluindo o tipo de dados com os quais você está trabalhando, os requisitos específicos do seu aplicativo e os recursos e limitações dos próprios protocolos.
Azure Functions: o Azure Functions é um serviço de computação sem servidor que permite executar um código sem a necessidade de gerenciar servidores ou a infraestrutura. Ele dá suporte a várias linguagens de programação, incluindo C#, F#, Java, JavaScript, PowerShell, Python e TypeScript. O Azure Functions pode ser usado para processar eventos e dados de streaming de Hubs de Eventos, bem como outras fontes, como o Armazenamento do Azure e o Azure Cosmos DB.
JMeter GUI: JMeter GUI é uma ferramenta de teste de carga de código aberto que é usada principalmente para testar o desempenho de aplicativos Web. Ele foi originalmente desenvolvido para testar aplicações Web. No entanto, ele também pode ser usado para testar outros tipos de aplicativo, como serviços Web SOAP e REST, servidores FTP e bancos de dados.
Azure Monitor: o Azure Monitor fornece recursos de monitoramento e alerta para recursos do Azure. Ele permite que você monitore o desempenho e a integridade de seus aplicativos e também da infraestrutura subjacente. O Azure Monitor pode ser usado para monitorar Hubs de Eventos e o Azure Functions, bem como outros serviços do Azure, como o Armazenamento do Azure e o Azure Cosmos DB.

Detalhes do cenário

O Teste de Carga do Azure permite que você pegue um script Apache JMeter existente e use-o para executar um teste de carga em escala de nuvem em qualquer recurso do Azure.

O JMeter permite que os testadores criem e executem testes de carga, testes de estresse e testes funcionais. Ele simula vários usuários acessando simultaneamente um aplicativo Web, permitindo que os testadores identifiquem possíveis gargalos de desempenho ou outros problemas que possam surgir sob cargas pesadas. O JMeter pode ser usado para medir várias métricas de desempenho, como tempo de resposta, taxa de transferência e taxa de erro.

O JMeter usa uma interface baseada em GUI para permitir que os usuários criem planos de teste, que podem incluir vários cenários de teste, cada um com configurações e ajustes diferentes. Os testadores também podem personalizar o JMeter usando plug-ins ou escrevendo código personalizado, permitindo que eles estendam a funcionalidade do script. Os plug-ins podem nos ajudar a trabalhar com serviços que usam protocolos que não são HTTP, como AMQP e Websocket.

Embora o JMeter forneça uma ampla gama de recursos e funções para teste de carga, pode haver casos de uso ou requisitos específicos que não sejam cobertos pela funcionalidade interna. Ao desenvolver plug-ins personalizados, os testadores podem adicionar novas funcionalidades ou personalizar recursos existentes para melhor atender às suas necessidades

Por exemplo, um plug-in personalizado pode ser desenvolvido para simular um tipo específico de comportamento do usuário ou para gerar dados de teste mais realistas. Além disso, plug-ins personalizados podem ser desenvolvidos para integrar o JMeter a outros sistemas ou ferramentas, como as de registro em log e relatórios, ou pipelines de integração e implantação contínua. Os plug-ins personalizados podem ajudar a simplificar o processo de teste e facilitar a incorporação do teste de carga no fluxo de trabalho geral de desenvolvimento de software. No geral, eles permitem que os testadores adaptem o JMeter às suas necessidades específicas e melhorem a precisão e a eficácia de seus esforços de teste de carga.

Neste exemplo, presumimos que há um dispositivo que está informando a temperatura e a umidade durante um período definido. Podemos simular esse comportamento simples usando um plug-in JMeter personalizado. Na implementação atual do plug-in personalizado fornecido aqui, geramos dados aleatórios usando um modelo fornecido. No entanto, o plug-in pode conter qualquer possível comportamento complexo para qualquer dispositivo. Neste exemplo, o dispositivo está enviando os dados para um hub de eventos no Azure. O hub de eventos dispara uma Função do Azure que é responsável por processar os dados e, em seguida, enviar os dados para outros serviços downstream, como o Banco de Dados SQL do Azure. A Função do Azure é o serviço que queremos testar. O plano de teste foi projetado para simular o comportamento do dispositivo e enviar dados ao hub de eventos.

Possíveis casos de uso

Usar o Teste de Carga do Azure com plug-ins personalizados pode ser útil em vários cenários, como estes:

Testando o desempenho de um aplicativo que usa protocolos que não são HTTP, como AMQP e Websocket.
Testando o desempenho de um aplicativo que usa um protocolo personalizado.
Testando o desempenho de um aplicativo que usa um SDK que não é da Microsoft.
Simulando um tipo específico de comportamento de usuário ou dispositivo, ou gerando dados de teste mais realistas.

Plug-ins personalizados

Plug-ins personalizados no contexto do JMeter são componentes de software que podem ser adicionados ao JMeter para estender sua funcionalidade. Usuários ou desenvolvedores que não são da Microsoft podem desenvolver plug-ins personalizados para adicionar novos recursos, funções ou integrações ao JMeter. Os plug-ins personalizados podem ser desenvolvidos usando a linguagem de programação Java e o PDK (Kit de Desenvolvimento de Plug-in) do JMeter. O PDK fornece um conjunto de ferramentas e APIs que facilitam a criação de novos plug-ins, incluindo elementos GUI, ouvintes e amostras.

Os plug-ins personalizados podem adicionar uma ampla gama de funcionalidades ao JMeter. Eles também podem integrar o JMeter a outros sistemas, como ferramentas de registro em log e relatório, ou habilitar o uso de outras fontes de dados para dados de teste. No geral, os plug-ins personalizados permitem que os usuários estendam o JMeter para atender às suas necessidades específicas e melhorar a precisão e a eficácia de seus esforços de teste de carga.

Para implementar uma amostra personalizada para Hubs de Eventos no JMeter, siga as instruções fornecidas em Plug-ins de Teste de Carga do Azure. Depois que a amostra personalizada for implementada, você poderá usá-la em seu plano de teste do JMeter no Teste de Carga do Azure como qualquer outra amostra.

Um plano de teste pode ser implementado usando um grupo de threads que controla o número de threads (usuários virtuais e dispositivos) para execução de um cenário específico. Cada grupo de threads pode ter configurações diferentes para o número de threads, período de aceleração, contagem de loop e duração. Os grupos de threads podem ser executados sequencialmente ou em paralelo, dependendo da configuração do plano de teste e dos requisitos do aplicativo. Você pode adicionar a amostra a um grupo de threads, definir seus parâmetros e configurá-la conforme a necessidade. As amostras personalizadas podem ser ferramentas poderosas no JMeter, permitindo que você simule cenários complexos e solicitações que as amostras internas não aceitam.

Criar um script Apache JMeter com plug-in personalizado

Nesta seção, você cria um script de teste JMeter de exemplo para teste de carga de um aplicativo com Hubs de Eventos.

Para criar um script de teste do JMeter de amostra:

Crie um arquivo LoadTest.jmx em seu computador local:
```
touch LoadTest.jmx
```

Abra LoadTest.jmx em um editor de texto e cole o trecho de código a seguir no arquivo. Esse script simula um teste de carga de 36 máquinas virtuais que enviam eventos simultaneamente para um hub de eventos e leva 10 minutos para ser concluído:

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
        <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
        <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
            <boolProp name="LoopController.continue_forever">false</boolProp>
            <intProp name="LoopController.loops">-1</intProp>
        </elementProp>
        <stringProp name="ThreadGroup.num_threads">36</stringProp>
        <stringProp name="ThreadGroup.ramp_time">20</stringProp>
        <boolProp name="ThreadGroup.scheduler">true</boolProp>
        <stringProp name="ThreadGroup.duration">600</stringProp>
        <stringProp name="ThreadGroup.delay"></stringProp>
        <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
        <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
            <stringProp name="eventHubConnectionVarName">EventHubConnectionString</stringProp>
            <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
            <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
        </com.microsoft.eventhubplugin.EventHubPlugin>
        <hashTree/>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

A implementação de com.microsoft.eventhubplugin.EventHubPluginGui e com.microsoft.eventhubplugin.EventHubPlugin está disponível em Amostras do Azure.

No arquivo, defina o valor do nó eventHubConnectionVarName como o nome da variável que especifica o host da cadeia de conexão dos Hubs de Eventos. Por exemplo, se você quiser que a variável de ambiente que armazena a cadeia de conexão dos Hubs de Eventos seja EventHubConnectionString, defina essa variável como EventHubConnectionString e defina o valor da variável de ambiente.

Importante

Verifique se o valor de EventHubConnectionString foi definido como parte do processo de criação do teste de carga do Azure antes de executar o script de teste de carga.
No arquivo, defina o valor do nó eventHubName como o nome do hub de eventos, como telemetry-data-changed-eh.
Defina o valor do nó liquidTemplateFileName para o arquivo que contém a mensagem enviada ao hub de eventos. Por exemplo, crie um arquivo chamado StreamingDataTemplate.liquid como:
```
{
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}
```
Neste exemplo, a carga da mensagem do hub de eventos é um objeto JSON com três propriedades, incluindo MachineId, Temperature e Humidity, em que MachineId é uma ID gerada aleatoriamente de 27 caracteres, e Temperature e Humidity são inteiros aleatórios inferiores a 100. Esse arquivo é uma sintaxe de modelo Liquid. O modelo Liquid é uma linguagem de modelagem popular usada em várias estruturas de desenvolvimento da Web. Os modelos Liquid permitem que os desenvolvedores criem conteúdo dinâmico que pode ser facilmente atualizado e modificado. Eles permitem inserir variáveis, condições, loops e outros elementos dinâmicos nas mensagens do hub de eventos. A sintaxe é simples e há muitos recursos online disponíveis que ajudam você a se familiarizar com ele. No geral, os modelos Liquid oferecem uma maneira poderosa e flexível de criar mensagens dinâmicas e personalizáveis.
Salve e feche o arquivo.

Importante

Não inclua dados pessoais no nome da amostra no script JMeter. Os nomes de amostra aparecem no painel de resultados de teste do Teste de Carga do Azure. Uma amostra de um modelo Liquid com o arquivo de script JMeter está disponível para download em Amostras do Azure

Executar o teste de carga usando o novo plug-in

Quando o Teste de Carga do Azure inicia seu teste de carga, ele primeiro implanta o script JMeter com todos os outros arquivos em instâncias do mecanismo de teste e, em seguida, inicia o teste de carga conforme orientado em Personalizar um teste de carga com plug-ins Apache JMeter e Teste de Carga do Azure. Antes de executar o teste, vá para a guia de parâmetros, defina EventHubConnectionString e forneça a cadeia de conexão para o hub de eventos.

Configuração de teste de desempenho para ambiente

Em qualquer teste de desempenho, é importante ter um ambiente semelhante ao ambiente de produção. Neste exemplo, o ambiente a seguir é usado para testes de desempenho a fim de entender melhor a capacidade e o desempenho do sistema.

De acordo com a arquitetura de exemplo, os seguintes serviços podem ser usados para testes de desempenho:

Serviço	Configuração
Eventhub	Premium com uma PU (Unidade de Processamento).
Azure Function	Linux com Plano Premium (EP1) - 210 ACU, 3,5 GB de memória e 1 vCPU Standard_D1_v2 equivalente
Region	Leste dos EUA

A escolha da camada certa de serviço para qualquer serviço do Azure, incluindo Hubs de Eventos e Azure Functions, é um processo complexo e depende de muitos fatores. Para obter mais informações, confira Preços dos Hubs de Eventos do Azure e Preços do Azure Functions.

Projetando KPIs para testes de desempenho

Antes de criar KPIs (Indicadores Chave de Desempenho) para testes de desempenho, você precisa de dois itens: os requisitos de negócios e a arquitetura do sistema. Os requisitos de negócios informam quais KPIs você deseja medir, como tempo de resposta, taxa de transferência ou taxa de erros. A arquitetura do sistema informa como testar o desempenho de cada componente, como servidores Web, bancos de dados ou APIs. Ela também ajuda você a escolher a melhor estratégia de teste de desempenho, como teste de carga, teste de estresse ou teste de resistência.

Neste exemplo, os requisitos de negócios são:

O sistema deve ser capaz de lidar com 1.000 solicitações por segundo.
A confiabilidade do sistema deve ser superior a 0,99.
O sistema deve ser capaz de lidar com 1.000 dispositivos simultâneos que relatam suas informações de dados pessoais.
Especificar a capacidade máxima do sistema em termos do número de dispositivos que podem ser suportados. Por exemplo, o sistema com 3 vezes a capacidade atual pode dar suporte a 1.000 dispositivos simultâneos?

De acordo com esses requisitos, os KPIs para testes de desempenho podem ser:

KPI	Descrição
RPS	Solicitação por segundo para um hub de eventos
LOAD	Número de cargas ou solicitações enviadas ao hub de eventos durante o teste de desempenho
IR	Número de execuções de função ou taxa de ingestão
RT	Tempo médio para o tempo de execução da função do Azure
AMU	Uso médio de memória para o Azure Functions
SR	Taxa de sucesso de todas as execuções de função
ARS	Tempo médio de resposta do serviço downstream (por exemplo, SQL Server ou um microsserviço)
DF	Contagem de falhas de dependência, incluindo erros internos de função do Azure
MRPS	RPS máximo sem lista de pendências no hub de eventos (Capacidade do Sistema)

Como medir KPIs

Para medir KPIs, você precisa ter uma estratégia de teste de desempenho. A estratégia define a abordagem de teste de desempenho para cada componente. Neste exemplo, a seguinte estratégia de teste de desempenho é usada:

Hubs de Eventos: a abordagem de teste de desempenho para o hub de eventos é enviar muitas mensagens para o hub de eventos e, em seguida, medir o RPS e o LOAD. O RPS é o número de mensagens enviadas ao hub de eventos por segundo. O LOAD é o número total de mensagens enviadas ao hub de eventos durante o teste de desempenho. O serviço de Teste de Carga do Azure pode medir RPS e LOAD.
Azure Functions: a abordagem de teste de desempenho para o Azure Functions é medir as seguintes métricas:
- O IR é o número de execuções de função ou taxa de ingestão.
- O RT é o tempo médio para o Tempo de Execução da Função do Azure.
- O AMU é o uso médio de memória para o Azure Functions.
- O SR é a taxa de sucesso de todas as execuções de função.
- O ARS é o tempo de resposta médio do serviço downstream.
- O DF é a contagem de falhas de dependência, incluindo erros internos de função do Azure.
- O serviço do Azure Monitor pode medir AMU, ARS e DF, mas não IR, RT ou SR.

Para medir KPIs usando o serviço do Azure Monitor, precisamos habilitar o Application Insights para o Azure Functions. Para obter mais informações, confira Habilitar a integração do Application Insights.

Depois de habilitar o serviço do Azure Monitor, você pode usar as seguintes consultas para medir KPIs:

IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Exemplo do painel do Azure Monitor

Veja a seguir um exemplo do painel do Azure Monitor que mostra os KPIs do Azure Functions com base nas consultas:

Conclusão

Neste artigo, você aprendeu a projetar KPIs e desenvolver um painel para o Teste de Carga do Azure. Você também aprendeu a usar plug-ins personalizados no JMeter para executar testes de carga no Azure Functions integrado aos Hubs de Eventos. Você pode usar a mesma abordagem para executar testes de carga em outros serviços do Azure. Você também pode configurar um pipeline CI/CD (integração e entrega contínua) para seus scripts de teste de carga usando o Azure DevOps.

Para obter mais informações, confira Teste de Carga do Azure.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Mahdi Setayesh | Engenheiro de Software Principal

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Compartilhar via

Teste de Carga do Azure com plug-ins personalizados

Arquitetura

Fluxo de dados

Componentes

Detalhes do cenário

Possíveis casos de uso

Plug-ins personalizados

Criar um script Apache JMeter com plug-in personalizado

Executar o teste de carga usando o novo plug-in

Configuração de teste de desempenho para ambiente

Projetando KPIs para testes de desempenho

Como medir KPIs

Exemplo do painel do Azure Monitor

Conclusão

Colaboradores

Próximas etapas

Comentários

Recursos adicionais

Compartilhar via

Teste de Carga do Azure com plug-ins personalizados

Arquitetura

Fluxo de dados

Componentes

Detalhes do cenário

Possíveis casos de uso

Plug-ins personalizados

Criar um script Apache JMeter com plug-in personalizado

Executar o teste de carga usando o novo plug-in

Configuração de teste de desempenho para ambiente

Projetando KPIs para testes de desempenho

Como medir KPIs

Exemplo do painel do Azure Monitor

Conclusão

Colaboradores

Próximas etapas

Recursos relacionados

Comentários

Recursos adicionais