Decidi recentemente experimentar a API em nosso site CardGames.io e experimentar a estrutura sem servidor . Nos últimos anos, tornou-se um tópico importante no mundo da tecnologia, e eu procrastinei que queria manter minhas habilidades técnicas atualizadas e tentar algo novo. Portanto, decidi passar várias horas estudando o Serverless e ver se há algum sentido nesse posicionamento da API.

Configuração atual

O CardGames.io é executado na AWS. Todas as páginas html, CSS, JavaScript e imagens são armazenadas no S3. Temos uma API C # hospedada no Elastic Beanstalk, que é executada em servidores Linux executando o .NET Core com Docker. Por fim, usamos o CloudFront CDN antes da estática no S3 e API. Abaixo está a pontuação do EC2 de agosto de 2019. Temos várias outras instâncias, mas as APIs funcionam no m1.small (sim, t2.small provavelmente funciona melhor) com o balanceamento de carga clássico. Se você resumir o realçado em vermelho, sai $ 164,21 por mês, nada mal. Inclusive incluí o EBS lá, porque não tenho certeza de como quebrar essas despesas, temos vários projetos no EC2.


Conta da AWS para Elastic Beanstalk

Temos dois ambientes com 1 a 3 instâncias em cada: ativa e inativa, porque a implantação do .NET Core no Docker na AWS leva vários minutos; portanto, fazemos isso em um ambiente inativo e, em seguida, alternamos os registros CNAME para o implantado recentemente. A implantação lenta foi um dos motivos pelos quais eu queria tentar algo novo. Temos vários servidores com aplicativos node.js no Beanstalk - e eles são implantados em segundos. Eu queria que fosse o mesmo para a API.

Mudando para sem servidor

Estudei um tutorial muito bom de hospedagem de API da Web do ASP.NET com a estrutura Serverless e descobri que você só precisa adicionar um arquivo de configuração simples, uma dependência e uma pequena classe de inicialização a um projeto de API existente. A implantação levou cerca de vinte segundos - muito melhor do que no Beanstalk. Acho que, graças ao suporte interno ao .NET Core no Lambda (no entanto, apenas 2.2), enquanto no Beanstalk ele é suportado apenas se você usar o Docker com controle independente. De qualquer forma, fiquei feliz sem pensar em grupos de dimensionamento automático, no máximo de instâncias e similares.

Teste de desempenho

Sem servidor na AWS é o Lambda, que realmente hospeda seus recursos, e a API do Front Gateway, que permite adicionar itens como limites de velocidade, chaves de API e muito mais. Hospedei os recursos do Lambda na região us-west-2, onde estão os servidores Beanstalk. Em seguida, configurei a instância do CloudFront para rotear solicitações de um de nossos jogos para a nova configuração sem servidor e a outra para a configuração antiga do Beanstalk. Em seguida, ele lançou um teste simples em dois URLs: um sem servidor e o outro Beanstalk. Os dois URLs invocaram a mesma API, armazenando o mesmo evento no banco de dados. Fiz 100 consultas para cada uma, e aqui estão os resultados:


Comparação de desempenho

Em várias execuções, a configuração sem servidor era 15% mais lenta (se houver, executei na Islândia, daí o grande ping). A velocidade foi uma decepção, mas permaneceu bastante alta - percebi que há alguma sobrecarga na frente do API Gateway na frente da nossa API: há muitas funções, mesmo que não as utilizemos. Então, triste, mas não crítico!

Preços

Honestamente, no começo eu não pensava em preços. Acabei de decidir que pagar pelo uso real provavelmente seria mais barato do que pagar por instâncias 24/7. Portanto, permitiu que a nova instalação sem servidor funcionasse por vários dias e começou a verificar contas. Opa! A fatura do Lambda + API Gateway já ultrapassou cem dólares! No começo, comecei a mexer na configuração do Lambda, alocando menos memória para salvar, mas quando observei o que estava acontecendo bem, ficou óbvio que o problema estava no gateway. Aqui estão as taxas do API Gateway:


Taxas da API de gateway

Nossa API aceita cerca de 10 milhões de solicitações por dia. Isso equivale a aproximadamente US $ 35 por gateway, apenas a cada dia . Além disso, o Lambda custa cerca de US $ 10 por dia, embora isso possa ser reduzido alocando menos memória. Juntos, eles custam cerca de US $ 45 por dia, ou US $ 1350 por mês , contra US $ 164 por mês no Elastic Beanstalk. Oito vezes mais caro ! Gosto de novas tecnologias e de uma implantação rápida, mas não pagarei US $ 1200 por mês por isso. De volta ao Beanstalk!

Conclusão

Provavelmente, eu deveria ter me familiarizado com os preços antecipadamente e feito alguns cálculos matemáticos! Mas é claro, então eu teria que fazer um trabalho real, e não aprender habilidades técnicas valiosas! Estou certo de que, em algumas situações, as APIs Gateway e Lambda são melhores que o Elastic Beanstalk. Simplesmente não é o nosso caso. Talvez se você usar chaves de API, limites de velocidade e outros recursos do API Gateway, faça sentido pagar US $ 3,50 por milhão de solicitações. Seria melhor colocar um balanceador de carga normal na frente do Lambda. Tanto quanto eu sei, isso não é possível; a API do Gateway é necessária para o acesso http ao Lambda.

Mas mesmo se apenas pagássemos a Lambda, com US $ 10 por dia, seriam US $ 300 por mês em vez de US $ 164. Temos muitas consultas, mas cada consulta faz muito pouco: basicamente, uma chamada de banco de dados por consulta. Talvez consultas mais pesadas que usem mais tempo de computação sejam mais adequadas para o Lambda, onde você paga por 100 ms de tempo de computação. Abaixo está um relatório para uma solicitação. Como você pode ver, usamos 3,50 ms de tempo de computação, mas a fatura está definida para 100 ms, esse não é um arredondamento fraco.


Relatório Lambda para uma solicitação

Por fim, não critico as APIs Gateway, Lambda ou Serverless. Apenas mostrando que, para algumas cargas de trabalho, elas são muito mais caras que o EC2 e o Elastic Beanstalk. Sobre o que vamos permanecer. Também é provável que exista uma maneira muito melhor ou mais eficiente de configurar o sistema; eu não sou um especialista da AWS; portanto, se houver algum erro flagrante, indique nos comentários.