Serverless Saga #2: Benchmarks & Custo
Será que vale todo o esforço para transformar ou criar uma aplicação de serverness em uma serverless?
No primeiro post desta série, vimos como transformar ou criar uma aplicação serverness em uma serverless de forma muito mais portável para outras nuvens e até mesmo para migrar de volta para uma infraestrutura com servidores. Mas será que vale a pena todo esse esforço? Neste segundo post, vamos explorar alguns dados reais e simulados de benchmarks para validar nossa hipótese antes de levá-la ao cliente.
Benchmarks
Criamos quatro grupos de chamadas de APIs que simulam o fluxo de uso de um usuário médio no projeto em que atuamos. A ferramenta utilizada foi o Artillery.io.
Ajustamos os valores de quantidade de chamadas por segundo para alcançar o limite das infras construídas, mas depois que encontramos os limites usamos para os dois testes.
Serverness (com servidores)
Na infraestrutura antiga conseguimos apenas 271 chamadas com sucesso num período de 70 segundos e tivemos vários 429, o erro que o Azure API Manager lança quando o serviço esta indisponível.
Com isso, temos apenas 3,9 req/sec com sucesso.
Serverless
Já com o serverless, conseguimos 848 chamadas com sucesso! Isso equivale a 12,11 req/sec com sucesso!
Histórico de Uso
Bem, esses números por si só não representam grandes coisas. Precisamos compará-los com a quantidade real de chamadas que iríamos receber. Abaixo temos o pico histórico da aplicação. Dela tiramos que o maior pico de uso foi no dia 22, com 335 req/min. Para normalizar esse valor com os valores acima, dividimos por 60 segundos.
A infra teve um pico de 5,58 por segundo. Logo, a arquitetura serverless conseguiria atender até 2 Natais sem problemas!
Custo da Aplicação
As duas infraestruturas têm formas muito diferentes de cobrança. Na infraestrutura com servidores nós basicamente pagamos pelo tempo das máquinas usadas, usando o recurso ou não.
Já no serverless, o pagamento é feito pelo número de execuções, duração da execução e memória alocada. Para comparar cenários iguais e críticos pegamos o mês que mais houve estress na aplicação, ou seja, o mês com a maior quantidade de chamadas.
Do plot acima tiramos a pior latência histórica: 600ms e o volume total de chamadas: 2.000.000 chamadas
Serverness (com servidores)
Para achar o custo da aplicação, pegamos o conjunto de máquinas iguais às do cenário de testes e multiplicamos pela quantidade de máquinas. Nesse cenário nós tivemos que levantar dois conjuntos de máquinas com essa config:
Utilizamos dois grupos compostos de 6 máquinas com vCores e 8 GB cada capazes de atender a aplicação.
Da calculadora acima chegamos à conclusão de que cada máquina custa 140 dólares por mês. Multiplicando esse valor por 6 teríamos 840 dólares!
Serverless
Para calcular o custo da infraestrutura serverless podemos simplesmente preencher a calculadora de custos da própria Azure com os dados que coletamos de tempo e quantidade de execuções.
O total é de 190 dólares, ou uma economia prevista de quase 80%!
Um ponto importante a destacar é que, diferentemente do custo por máquinas, o custo serverless pode variar já que o tempo de execução influencia no custo.
Custo, Monitoria e Logs
Um “acidente feliz” que tivemos durante a migração da aplicação foi que não conseguimos reutilizar a ferramenta de tracing e monitoramento que usávamos (Dynatrace), pois ela exigia a execução de um binário ao qual o serverless não dá suporte.
Por isso, precisamos migrar para uma ferramenta de monitoria que não precisasse de binários e, com isso, conhecemos o Azure App Insight, na qual a instrumentação é feita direto no código.
Mas as vantagens do App Insight são ainda maiores do que apenas viabilizar o serverless. Por ser uma ferramenta que cobra por chamada e volume de dados, conseguimos uma redução de custo na monitoria, pois a modalidade de cobrança do Dynatrace é por instância utilizada.
Além disso, conseguimos mitigar um grande problema, que era o link entre o tracing e os logs. Na arquitetura antiga os logs ficavam no appinsight e o tracing no dynatrace. Juntando os dois criamos uma super ferramenta de debug.
Otimizações
Em uma arquitetura clássica não temos tantos incentivos para otimizar o código. Se ele funcionar em 600ms ou 800ms no dia a dia, o impacto pode ser pequeno, ou até nenhum. No entanto, numa arquitetura serverless reduzir de 800ms para 400ms pode cortar o custo da infra pela metade.
Com serverless temos motivação direta de diminuir o tempo de execução, o uso de memória e a quantidade de chamadas que nossa aplicação realiza, pois teremos um impacto direto e visível no custo da aplicação.
Outra flexibilidade para reduzir custos é reduzindo a quantidade de logs e de tracing, já que a modalidade de cobrança é baseada no uso e não em um contrato previamente feito.
Acho que chegamos à conclusão de que uma API serverless é uma excelente ideia e deve ser considerada no início (ou até mesmo no meio) de um projeto, certo? No próximo post, vamos mostrar dados reais da aplicação em produção. Se você tem alguma dúvida ou quer comentar algo, aproveite os campos abaixo. Ou se você quer fazer parte de um time que aprende o tempo todo, é só clicar aqui e se candidatar a alguma de nossas vagas. Até a próxima!
Leia mais:
