Serverless Saga #3: Produção
Já diziam: jogo é jogo, treino é treino. Vamos aos resultados?
Nesta série de posts, nós já conversamos sobre a migração de “servermess” para serverless e mostramos alguns resultados de um benchmark, provando que os custos compensam e muito essa migração. Agora, vamos por fim mostrar o resultado em produção de uma infraestrutura em serverless. Vamos lá?
Volume de Requests
No gráfico abaixo conseguimos observar o volume das chamadas efetuadas na última semana:
Constatamos que o uso da aplicação segue uma tendência senoidal. Esse cenário é excelente para serverless, pois temos diariamente um período com uma quantidade mínima de acessos que seriam anteriormente atendidos por duas máquinas (para garantir a alta disponibilidade), porém potencialmente com elas 100% sem uso.
Filtrando pelas últimas 48h conseguimos ver essa falta de uso de forma fácil e ela fica em torno de 7h com uso mínimo. Isso são 210h de tempo de máquinas desperdiçadas e pagas sem motivo por mês. Com a hora das máquinas custando 0,20 centavos/hora temos uma economia de 45 dólares sem perder disponibilidade do serviço.
Latência
No gráfico abaixo conseguimos observar que a latência se mantém ao longo da semana entre 250–700ms. Há um grande pico de latência, mas foi causado pela indisponibilidade de um serviço terceiro.
Aplicando um Fourier nos pontos de latência temos o seguinte gráfico.
Nele conseguimos ver que a frequência com que as latências ocorrem gira em torno de 75ms. Infelizmente não conseguimos dados reais para comparação, mas “de cabeça” a latência ficava próxima de 100ms. Esse é um excelente sinal, que indica que nosso wrapper não adicionou nenhum grande aumento de ciclos de máquina.
Como a API é parecida com agregação, ou seja, consome outros serviços, ela se torna fortemente acoplada a esse serviço terceiro. Logo, não é uma métrica que devemos interpretar no vácuo da ausência de contexto. Conseguimos, então, mostrar como aplicações serverless conseguem alcançar performance igual e equivalente (talvez maior) do que a aplicação com servidores.
Memória
Abaixo temos o uso de memória dos últimos 3 dias do aplicativo serverless:
Nele podemos ver um padrão claro de uso e desuso. Esse valor de uso de memória é apenas uma fração do total de memória RAM alocada nos servidores e processos. Isso evidencia a eficiência de execução do código.
Porém, o ponto mais interessante desse gráfico é o limite superior do uso de memória. Pelo gráfico podemos afirmar que ele fica em torno dos 300 MB, e isso é 1/3 da memória que usamos nos cálculos de custo.
Custo
Como observamos nos dois últimos tópicos, os valores que colocamos em nossas estimativas estavam exagerados e portanto o seu resultado também.
Abaixo temos a contagem de chamadas totais e a média do tempo de respostas calculados pela Azure Insight em um período de 7 dias.
Aplicando o mesmo cálculo de previsão de custo com os valores de tempo de respostas e memórias reais temos o seguinte resultado:
Nosso custo será de 90 dólares, ou seja, 11 vezes mais barato. Incrível, não?
Ressalto que isso ainda é uma estimativa baseada na última semana e o valor pode ser tanto maior quanto menor.
Mas acabamos esquecendo de um detalhe: a comparação está correta mas esse volume de chamadas representa o pior pico de uso no Natal, e não um mês usual. Se extrapolarmos o volume do primeiro gráfico da sessão sobre o volume de chamadas, temo que a média semanal é próxima a 1,8 milhões.
Incrível! Uma API com 7,2 milhões de chamadas por mês custando 28 dólares. Bem-vindo ao mundo do serverless!
Otimizações valem Ouro
É importante frisar a vantagem “oculta” do serverless, que é o alto retorno de investimento nas ações que otimizam o uso de memória e do tempo de respostas. Todas essas otimizações têm efeito direto no custo da API, diferente de aplicações nos servidores que são geralmente tratadas com bastante abundância de recursos para evitar que quebrem.
Nos gráficos acima, fornecidos no dashboard do azure app insights, temos as APIs mais lentas e mais chamadas da aplicação. Com esses dados podemos criar um plano de ação que visa otimizar o código desses grandes ofensores e cortar ainda mais nossos custos.
Entre outros benefícios não ditos temos a vasta complexidade reduzida migrando de uma arquitetura com Kubernetes para uma em Azure Functions. Essa redução diminui pontos de falha a serem administrados e reduz a necessidade de um time para monitoria da aplicação, já que nós apenas cuidamos do código e todo restro é provido pela Azure.
Gostaram dos posts? Querem outros cenários serverless? Deixem seus comentários com o feedback. E se quiser trabalhar em um time que preza pela automação, é só clicar aqui e se candidatar a alguma de nossas vagas. Obrigado a todos que acompanharam essa pequena saga. Até mais!
