Habilitando testes de performance com AWS Distributed Load Testing

Neste artigo pretendemos compartilhar como o AWS Distributed Load Testing, que carinhosamente chamamos de "DLT" na Livelo, uma solução serverless desenvolvida para facilitar a criação, execução e armazenamento de testes de performance, impulsionou nossa estratégia de habilitar nossos engenheiros a executarem seus próprios testes e otimizou nossos custos.

Antes da habilitação do AWS Distributed Load Testing, nosso modelo de trabalho em torno de testes de performance era baseado na solicitação de testes para um time composto por Analistas e Especialistas em Testes de Performance, que recebiam os pedidos e os executavam utilizando Apache JMeter.

Workflow de atendimento de pedidos de testes de performance

Com o tempo, percebemos um crescente aumento no número de testes. Recebíamos mais de 60 pedidos de testes de performance com apenas 5 pessoas, e o lead time chegava a até 60 dias, mesmo com um processo eficiente.

Por isso, implementamos a regressão de performance, conforme detalhado no artigo “Maior velocidade e eficácia: automatizando Testes de Performance para otimizar resultados”. Desde que habilitamos os testes regressivos a quantidade de pedidos reduziu, afinal, já gerávamos o resultado de forma antecipada e proativa para os casos recorrentes.

Impacto dos regressivos na redução da quantidade de pedidos de teste

São mudanças frequentes que nos impulsionam a evoluir continuamente. E a alteração no nosso modelo de atuação nos mostrou que em toda mudança existem oportunidades.

Motivadores e escolhas

Como mencionado no inicio, nossa estratégia passou a ser habilitar os Engenheiros de Software a executarem seus próprios testes de performance.

Diante desse cenário, nosso time de testes de performance se ajustou e iniciou a criação de treinamentos, elaboração de catálogos com os scripts existentes, descontinuação de soluções antigas e adoção de novas ferramentas que proporcionassem uma boa experiência para os engenheiros reaproveitarem os scripts prontos, além de garantir um baixo custo e agilidade na implementação.

E foi nesse cenário que entre tantas soluções optamos pelo AWS Distributed Load Testing (DLT), por alguns motivos principais:

• Reaproveitamento dos nossos scripts .jmx, pois o DLT utiliza esse formato de script.
• Possibilidade de integrar outras soluções com a mesma ferramenta. Como mostrado neste Pull Request para o repositório oficial, podemos habilitar o uso do K6.
• Agilidade na implementação: adquirir ferramentas no mercado corporativo pode ser demorado. Como destacado no Guia de Implementação Oficial do AWS Distributed Load Testing (DLT), o tempo foi um dos nossos critérios principais.
• Outros fatores: custo, facilidade de alterações, adequação ao nosso cenário e satisfação dos nossos colaboradores com a tecnologia.

Além do Guia de Implementação Oficial — Desafios de implementação em cenário corporativo

O guia oficial de implementação da ferramenta está disponível na documentação da AWS, acessível em: AWS Distributed Load Testing Documentation.

No entanto, em um ambiente corporativo, o acesso irrestrito aos recursos em nuvem nem sempre está disponível, o que requer uma abordagem mais cuidadosa para habilitar a solução. Portanto, foram necessárias as seguintes etapas para a implementação interna:

1. Análise de Custos: Utilizamos a calculadora de custos da AWS para realizar simulações prévias e evitar surpresas financeiras. Esta etapa garantiu que os custos associados à implementação fossem compreendidos e gerenciáveis.
2. Análise de Segurança e Infraestrutura: Em colaboração com outras áreas da empresa, avaliamos a complexidade de ativar a solução, identificamos riscos para a segurança e analisamos a complexidade tecnológica e a carga cognitiva associada à manutenção e evolução da solução.
3. Implementação Inicial Sem Customizações: Após decidir pela exploração da ferramenta, iniciamos um Projeto Piloto (POC) com a solução padrão, sem alterações ou personalizações. Durante esta fase, coletamos feedbacks e identificamos áreas de melhoria para atender tanto aos requisitos internos de segurança e infraestrutura quanto às necessidades externas de recursos adicionais solicitados pelos nossos clientes.
4. Evoluções Necessárias: Com base no uso da ferramenta e no engajamento contínuo, mapeamos as evoluções necessárias e iniciamos o processo de melhoria contínua, priorizando as melhorias que melhor atendem às nossas necessidades e às expectativas dos nossos usuários.

Além disso, alguns desafios que enfrentamos durante a implementação foram:

• Inserção do DLT na Virtual Private Cloud (VPC) da Livelo para garantir mais segurança na exibição dos dados.
• Integração do Cognito com o identity provider (IDP) interno: o DLT cria um cadastro de usuários próprio no AWS Cognito por padrão. Ajustamos o DLT para buscar os usuários diretamente no nosso IDP oficial, evitando que cada usuário precise se cadastrar separadamente e centralizando as permissões de acesso.
• Remoção de ferramentas que geravam altos custos: eliminamos a integração do DLT com o AWS IoT Core, que era usada para criar dashboards de acompanhamento em tempo real. Durante a avaliação, vimos que essa solução elevava bastante os custos. Substituímos essa função pelo Grafana (que mostraremos a seguir), oferecendo uma solução mais econômica e com melhor visualização dos dados.

Manutenção e evolução

À medida que surgiram novas necessidades e melhorias, estabelecemos um processo de deploy bem definido. Como a maioria das funcionalidades do DLT usa Lambdas, adotamos um processo de CI/CD que se integra com a AWS.

Assim, sempre que um merge é feito na branch principal, os Lambdas são atualizados automaticamente, garantindo qualidade e segurança por meio de testes unitários e validações de segurança.

Além disso, tivemos que aumentar o conhecimento do time sobre soluções em nuvem, já que toda a nossa arquitetura depende disso.

A seguir, listamos algumas das novas funcionalidades e melhorias que implementamos além das oferecidas na versão oficial.

Monitoramento pelo Grafana

Para otimizar os custos associados à ferramenta e oferecer uma visão mais detalhada dos resultados dos testes, decidimos substituir as métricas nativas do AWS Distributed Load Testing (DLT), que utilizam o CloudWatch, por uma dashboard no Grafana.

Com essa abordagem, ao iniciar um teste, uma inteligência coleta e transmite dados em tempo real para nossa monitoria. Isso permite que a dashboard seja constantemente atualizada com informações instantâneas sobre o desempenho do teste, proporcionando uma visão clara e precisa dos resultados.

Exemplo de visão de resultado de teste

Mensagem de Fim de Teste

Ao fim de um teste, nosso DLT envia automaticamente uma mensagem com uma análise preliminar dos resultados para um canal específico no Slack, previamente indicado durante a configuração do teste.

Exemplo de mensagem de final de teste enviada para o responsável via Slack

Outras melhorias

1. Delete — O DLT mantinha registros de testes no S3 mesmo após a remoção do teste. Como já temos um histórico no ElasticSearch, otimizamos a funcionalidade de delete para remover todos os registros do S3, reduzindo custos e mantendo uma base de buckets mais limpa.
2. Limites — Ao criar um teste agendado no DLT, cada teste adicionava uma linha no arquivo de política de permissões da função Lambda de agendamentos, que tem um limite de tamanho. Criamos uma política única e centralizada para todos os testes agendados, eliminando problemas de limitação e otimizando recursos.
3. Segurança — Como temos integração com vários serviços internos, é essencial garantir que os parâmetros utilizados pela aplicação sejam gerenciados de forma segura. Para isso, utilizamos o AWS Systems Manager Parameter Store. Todos os parâmetros necessários para a aplicação estão armazenados de forma segura e são recuperados conforme necessário, sem serem expostos diretamente no código.
4. Paginação e Busca — O DLT exibia os testes em uma lista corrida na dashboard principal. Melhoramos isso com paginação e filtros. Agora, os testes são exibidos de forma paginada, com um filtro que permite recuperar testes por qualquer valor desejado. Como os testes estão armazenados no DynamoDB, a velocidade não é um problema, então toda a lógica de paginação e busca foi implementada no front-end, tornando esses recursos quase instantâneos.
5. Single Click — Todos os botões agora indicam carregamento enquanto aguardam retorno da execução, melhorando a usabilidade e prevenindo falhas por duplo clique acidentais ou intencionais.

Custo

O Distributed Load Testing (DLT) vem integrado com o CloudWatch para a geração de métricas dos testes, o que pode resultar em custos consideráveis. No entanto, um dos maiores diferenciais do DLT é a flexibilidade de personalização, que nos permite ajustar as configurações de acordo com as necessidades específicas. Esse controle sobre as personalizações pode resultar em uma otimização significativa dos custos, garantindo que paguemos apenas pelo que realmente utilizamos.

Por exemplo, o uso do DynamoDB é particularmente vantajoso, pois a cobrança é feita por consultas. No caso do DLT, o DynamoDB é utilizado apenas para registrar os testes, sem ser acionado durante a execução, o que minimiza os custos significativamente.

https://aws.amazon.com/pt/dynamodb/pricing/on-demand/

Outro exemplo é o uso das funções Lambda, que são acionadas tanto para consultas ao banco de dados quanto para iniciar os testes. Essas funções são executadas apenas quando necessário, evitando gastos com recursos ociosos e garantindo que os custos permaneçam baixos e alinhados com o uso real.

Visão de custos com AWS Distributed Load Testing

É importante destacar que os custos na AWS podem variar. As informações apresentadas refletem os custos que experimentamos em nosso ambiente específico. Esses valores podem mudar com base em diferentes fatores, por isso recomendamos consultar a documentação oficial da AWS para obter as informações mais recentes e garantir que suas estimativas de custos estejam sempre atualizadas.

Considerações finais e resultados

Embora existam diversas soluções e ferramentas para testes de performance disponíveis no mercado, a escolha e implementação ideal dependem fortemente dos processos e necessidades específicas de cada empresa. Por isso, é crucial avaliar cuidadosamente o seu cenário antes de tomar uma decisão.

Em nossa experiência com o uso do DLT, os resultados têm sido muito positivos. Conseguimos não apenas otimizar custos, mas também alcançar nossos objetivos ao capacitar nossos engenheiros para utilizar a ferramenta de maneira a descentralizar a execução de testes de performance apenas de um time.

Crescimento de uso interno do AWS Distributed Load Testing

Além disso, exploramos com sucesso o potencial da arquitetura serverless e incentivamos nossas equipes de engenharia a se envolverem ativamente no desenvolvimento da solução. Esses avanços têm contribuído significativamente para a evolução de nossas práticas e para o sucesso contínuo da nossa plataforma.