Escolher a plataforma de computação da AWS para sua carga de trabalho em termos de custo não é uma tarefa fácil. Fiz o cálculo para um dos projetos em que trabalho e decidi compartilhar minhas descobertas. Neste artigo, farei uma comparação simplificada e de alto nível para delinear uma maneira de fazer a comparação.

Não sendo um especialista em utilizar todas as opções de computação, encorajo você a usar a seção de comentários para corrigir minhas suposições erradas ou sugerir melhorias e ideias que devem ser incorporadas ao esforço de comparação.

Definição de configuração

Usando a Calculadora de preços da AWS , podemos comparar o custo mensal dos serviços de configurações aproximadamente equivalentes em poder de computação. Eu já achei isso uma tarefa complicada de fazer. Cada serviço tem seu próprio tipo de configuração para escolher, tendo especificações diferentes não apenas para vCPUs e memória, mas também para limitações na largura de banda da rede, tendo restrições para usar GPUs ou volumes EBS e assim por diante.

Para simplificar, vamos comparar serviços com requisitos apenas por ter disponível 1 vCPU e cerca de 2 GB de memória. Para Lambda, a vCPU escala junto com o tamanho da memória configurável. O Lambda obtém 1 vCPU por 1,769 GB de memória , então essa será nossa escolha para o Lambda. O Fargate tem contagem de vCPU e tamanho de memória configuráveis, para que possamos escolher exatamente 1 vCPU e 2 GB de memória disponíveis. Para o EC2, para um valor tão baixo de vCPU e memória na geração atual dos tipos de instância do EC2, nossa única opção é ir com a família T que possui um desempenho expansível. Isso traz outro nível de complexidade, pois a instância é precificada com base na utilização abaixo ou igual ao desempenho da CPU da linha de base, e cobranças adicionais ocorrem quando o consumo excede a linha de base. No entanto, nos tipos de instância da geração anterior , o tipo de instância m1.small atende muito bem aos requisitos com 1 vCPU e 1,7 GB de memória, então vamos usá-lo em vez do tipo de instância da família T. Além disso, as seguintes opções não foram consideradas em comparação por uma questão de simplicidade:

• CPUs de arquitetura ARM
• SO não Linux
• Identificar instâncias e detectar tarefas do Fargate
• Transferência e armazenamento de dados
• Instâncias reservadas e planos de economia de computação

Intuitivamente, EC2 deve ser o serviço mais barato, seguido por Fargate e Lambda. O raciocínio é que cada próximo serviço requer menos administração de infraestrutura do que o anterior, deixando as tarefas de gerenciamento de infraestrutura para a AWS. O gráfico a seguir mostra o preço mensal de cada serviço com base em uma porcentagem do tempo de utilização.

O preço do EC2 é de fato o mais baixo, seguido de perto pelo Fargate, enquanto o preço do Lambda é quase o dobro do Fargate. O preço do EC2 pode ser reduzido ainda mais com a utilização do tipo de instância expansível da família T, dependendo das necessidades reais de sua carga de trabalho.

Fatores de Faturamento e Inicialização

Como vimos acima, o custo de execução do Lambda é bastante alto em comparação com o Fargate e o EC2. Vamos agora examinar os fatores que podem afetar por que ainda podemos escolher o Lambda para computação, apesar de seu preço mais alto.

A primeira coisa a considerar é o intervalo de cobrança dos serviços. O EC2 é cobrado por segundo, com duração mínima de 60 segundos. A cobrança começa quando a instância é iniciada e termina quando a instância é encerrada ou interrompida. Fargate é cobrado por segundo, também com duração mínima de 60 segundos. A cobrança começa quando a imagem é puxada e termina quando a tarefa termina. O Lambda, por outro lado, é cobrado por milissegundo sem limite mínimo. A cobrança começa quando a inicialização ou o código do manipulador começa a ser executado e para quando o código retorna ou termina.

Esse é um dos motivos pelos quais o Lambda é uma boa opção para cargas de trabalho executadas com pouca frequência e de curta duração.

Em segundo lugar, a ativação de uma nova instância do EC2 leva cerca de um minuto ou mais, semelhante à inicialização de uma nova tarefa do Fargate. Em comparação, a criação de uma nova instância do Lambda geralmente leva algumas centenas de milissegundos para tempos de execução com linguagens interpretadas e até alguns segundos para tempos de execução com linguagens compiladas.

Dependendo de sua carga de trabalho, pode ser que você não possa esperar um minuto para iniciar uma instância EC2 ou tarefa Fargate e, portanto, precise manter a instância ou tarefa em execução. Esse não é o caso do Lambda, pois você geralmente espera alguns segundos para iniciar uma nova instância. Você também pode manter a instância do Lambda aquecida pelo preço diminuto, executando ping a cada poucos minutos pelo evento CloudWatch.

Para enfatizar os dois fatores descritos acima, agora podemos comparar a cobrança de serviços para um tipo de computação de manipulador de API da Web, no qual queremos que não haja atraso na inicialização e estejamos prontos para atender o tráfego a qualquer momento.

Tanto a instância EC2 quanto a tarefa Fargate precisam ser utilizadas 100% do tempo para não sofrer problemas de inicialização. A cobrança do Lambda, por outro lado, depende do tempo real em que o código do manipulador está em execução para atender ao tráfego para a API da Web. Assim, a utilização do Lambda é preferível até que o Lambda seja utilizado cerca de 40 a 50% do tempo, apesar de seu preço mais alto pelo mesmo poder de computação. Isso torna o Lambda adequado para tarefas de processamento rápido, por exemplo, tarefas de E/S, como leitura de dados do DynamoDB e assim por diante.

Exemplo do mundo real

Utilizamos a função Lambda em um de nossos projetos para lidar com solicitações de API. Possui uma configuração de memória de 2 GB principalmente para minimizar os atrasos de inicialização a frio, caso contrário, poderia ter uma configuração inferior. Ele usa uma biblioteca .NET com mais de 4 MB, portanto diferenças de inicialização a frio entre, por exemplo, 512 MB de memória e 2 GB são perceptíveis.

O tráfego para o Lambda aumentou constantemente nos últimos meses e queremos descobrir se é hora de considerar a migração para outro serviço.

De acordo com as métricas de utilização diária, a função é invocada em média cerca de 250 mil vezes por dia, ou seja, 2,89 solicitações por segundo. A duração média da execução é algo em torno de 250 ms. 2,89 vezes 250 é aproximadamente 723. Isso significa que a função é utilizada aproximadamente 70% do tempo.

Métricas de intervalo de um minuto mais granulares mostram que os padrões de invocação são pontiagudos, no entanto, em geral, a carga é tratada por pouco menos de 10 instâncias simultâneas da função.

As métricas coletadas sinalizam que ultrapassamos o limite em que o faturamento do Lambda era ideal. Potencialmente, para lidar com o tráfego com o mesmo poder de computação e ter espaço para crescer, poderíamos utilizar, por exemplo, 2 tarefas multi-AZ Fargate, cada uma com 0,5 vCPU e 1 GB de memória. Com base nos gráficos acima, isso reduziria os custos mensais de cobrança de US$ 53,50 para US$ 36,04. Poderíamos tentar reduzir ainda mais os custos utilizando instâncias do EC2 com capacidade de explosão do tamanho certo e hospedando o contêiner ou aplicativo lá. É claro que esta é apenas uma ideia teórica aproximada que exigiria verificação na aplicação real.

Como nota final, gostaria de mencionar que os custos brutos de faturamento devem ser estendidos considerando a complexidade e os custos de gerenciamento de infraestrutura. Para cenários específicos, isso pode significar que, embora, por exemplo, os custos de faturamento do EC2 possam ser alguns por cento menores do que Fargate ou Lambda, a diferença ainda não está compensando a complexidade adicional da solução.

Somos a ACTUM Digital e este artigo foi escrito por Milan Gatyas , Líder de Tecnologia .NET da Divisão Apollo. Sinta-se a vontade para entrar em contato.