A importância dos testes automatizados de performance no preparo para a Black Friday
A Black Friday
A Black Friday é uma data super importante para empresas de tecnologia que trabalham com e-commerce e pagamentos. Só no Brasil, foi estimado para 2018 que 130 milhões de internautas acompanhariam as ofertas disponíveis e 60 milhões seriam compradores em plataformas online. Já parou para imaginar o volume de acessos a sites e plataformas que o e-commerce precisa suportar nesse período? E a quantidade de transações de compras?
O efeito que a Black Friday, uma demanda sazonal, tem no faturamento das empresas é enorme. Também é um super estímulo à cadeia produtiva, principalmente no mercado de e-commerce. Levantamentos indicam que em 2017 a data cresceu 9% em relação ao ano anterior, sendo superior ao Natal e Dia das Mães que registraram 3% e 2,3% respectivamente.
Quem é de tecnologia e já trabalhou nesse cenário sabe que, quando a Black Friday se aproxima, começa a bater um desespero. Parece que o fim do mundo está batendo na porta e que todo o throughput (número de transações que um sistema pode processar em um dado intervalo de tempo) não terá capacidade suficiente. Nestes tempos são frequentes as discussões dos times de tecnologia sobre a capacidade dos sistemas de suportar uma demanda de acessos muitas vezes maior do que a habitual.
Ter uma estratégia para testar a capacidade da aplicação em cada um dos commits dados no repositório é bem importante. Isso habilita o time a agir rapidamente em cima de uma eventual degradação de performance.
Você reconhece este cenário?
Imagina que você trabalha no time de tecnologia do Siri Cascudo. O seu time cuida de um microsserviço que é responsável por entregar a página HTML com o conteúdo do e-commerce de vendas de Hambúrguer de Siri. Fora das sazonalidades esse e-commerce recebe um número estável de usuários, variando muito pouco nos finais de semana, porém, em eventos como a BlackFriday, o número de acessos sobe incontrolavelmente. O time de operação começa a fazer análises de performance um pouco antes do evento para descobrir como irá escalar os serviços. Um valor médio de requisição é encontrado manualmente e com base nisso a escalabilidade é planejada.
É importante notar que o time fica limitado por conta deste tipo de análise. É como se existisse um número mágico vindo de uma reunião cansativa, cheia de achismos. Na véspera de todos os eventos sazonais isso será feito? Imagina se o Netflix tivesse que se preparar desta forma para cada lançamento ou se o Google tivesse que fazer isso todos os dias.
Essa análise não é escalável!
“If it hurts, do it frequently” (Jez Humble)
Agora imagine um novo cenário. Neste é possível ver a capacidade da sua aplicação em cada commit e os outputs dos testes são usados para definir os parâmetros de escalabilidade. Sim! É possível!
Existe uma metodologia chamada Threshold Test que ajuda a alcançar esse novo cenário. Esta é uma técnica que nos habilita a ter melhoria contínua da nossa performance. A cada commit da pipeline é executado um teste de performance que nos diz a capacidade do nosso serviço em um dado cenário, o qual é chamado de baseline test.
Vamos voltar ao exemplo do e-commerce de Hambúrguer de Siri. Após aprenderem mais sobre a metodologia, o time decidiu melhorar a forma de lidar com o caos da Black Friday. Para isso, executaram os seguintes passos:
- Deploy da aplicação em um ambiente de testes de performance isolado em sua mínima unidade, tipo uma g1-small do Google Cloud;
- Execução de uma bateria de testes usando uma ferramenta (como o JMeter, Gatling ou Locust) que simula um número X de usuários, fazendo N requisições por segundo;
- Análise do limite de saúde da aplicação, ou seja, quando o teste começa a encontrar falhas nos requisitos funcionais (a página começa a responder com erro) e não funcionais (o tempo de entrega está além do aceitável).
Esse valor se torna nosso Threshold que então é setado como o mínimo aceitável de performance para a nossa aplicação. A pipeline ficaria vermelha caso este limite seja ultrapassado. Em outras palavras, saberíamos instantaneamente qual foi a alteração que degradou a performance para o time poder trabalhar imediatamente para mitigar este problema.
Um outro proveito que tiveram com esta metodologia é que sempre que uma alteração melhorar a performance, o Threshold pode ser ajustado. O mínimo de qualidade se torna cada vez melhor através do tempo, como a analogia do Ratchet feita pelo Patrick Kua.
Agora, o time de tecnologia do Siri Cascudo faz os testes de performance diariamente e de forma automatizada. Conhecer e acompanhar a capacidade do sistema se tornou simples e permitiu dimensionar adequadamente os sistemas para suportar uma Black Friday por dia, se for preciso.
That’s all folks!
Referências:
- https://martinfowler.com/bliki/FrequencyReducesDifficulty.html
- https://medium.com/@tspm/vis%C3%A3o-geral-testes-de-performance-efa9f5e4f90
- https://martinfowler.com/bliki/ThresholdTest.html
- https://martinfowler.com/articles/useOfMetrics.html#MetricsAsARatchet
- https://www.thinkwithgoogle.com/intl/pt-br/tendencias-de-consumo/temporada-black-friday-muito-alem-da-sexta-feira/
Indicação de outros conteúdos:
- Capítulo 9 do livro Continuous Delivery, dos autores Jez Humble e David Farley
- https://gatling.io/blog/
Por Rafael Rodrigues, José Roniérison e Dilter Porto (todos trabalham remotamente na Stone Pagamentos)
