O blog da AWS
Usando as novas features Serverless : API Gateway HTTP APIs, Lambda Provisioned Concurrency, Amazon RDS Proxy, Step Functions Express Workflows e Amazon EventBridge
Por Luiz Yanai, Arquiteto de Soluções e especialista em Serverless, AWS Brasil
Recentemente, foram lançadas diferentes features dentro do espectro de serviços Serverless para tornar ainda mais escaláveis as soluções baseadas em tal tecnologia.
Este blog post apresenta um exemplo de cenário que demonstra o uso de cada uma das novas features para solucionar problemas de escala, por exemplo, em uma aplicação web ou mobile.
Imaginando um cenário onde temos uma aplicação disponibilizada tanto via web como mobile e que possui um grande volume de acessos, dependendo da escala dos acessos podemos cair em alguma limitação de recursos ou também aumento de gastos da solução. Especificamente sobre o problema de gastos inesperados em soluções serverless, recomendo a leitura deste post.
Novas Features Serverless
Eis abaixo a lista de novas features lançadas nos últimos meses:
- APIs HTTP do Amazon API Gateway: Para criar APIs RESTful, você pode usar APIs HTTP ou APIs REST do Amazon API Gateway. As APIs HTTP são até 71% mais econômicas que as APIs REST, mas oferecem somente a funcionalidade de proxy de API. APIs HTTP são otimizadas para performance. Elas oferecem a principal funcionalidade do API Gateway por um preço menor;
- Step Functions Express Workflows: Express Workflows usam o mesmo modelo de especificação declarativa do Step Functions Standard mas é projetado para casos de uso com alto volume e pequena duração de transação (até 5 minutos). Express Workflows são projetados para suportar uma taxa de invocação por conta AWS maior que 100.000 eventos por segundo;
- Amazon RDS Proxy: O Amazon RDS Proxy atua como um intermediário entre seu aplicativo e um banco de dados RDS. O RDS Proxy estabelece e gerencia os conjuntos de conexões necessários ao seu banco de dados para que seu aplicativo crie menos conexões com o banco de dados.
- Lambda Provisioned Concurrency: habilidade de esquentar ambientes de execução de Lambda para suportar uma carga de requisições concorrentes pré-definida entregando respostas com menor latência para o usuário final;
- Amazon EventBridge: Muitos serviços na nuvem da AWS produzem eventos, incluindo aplicativos de software como serviço (SaaS) integrado. Seus aplicativos personalizados também podem produzir e consumir eventos. Com tantos eventos de fontes diferentes, você precisa de uma maneira de coordenar esse tráfego. O Amazon EventBridge é um barramento de eventos serverless que ajuda a criar uma arquitetura orientada a eventos permitindo uma maior escalabilidade e flexibilidade das suas aplicações, com menor manutenção.
Caso de Uso: Aplicação mobile com transações de compra com múltiplos passos
A arquitetura de exemplo abaixo faz uso das features anteriores para suportar os seguintes requisitos:
- Número alto de requisições de APIs para transações de compras;
- Mínima necessidade de manutenção da infraestrutura para suportar picos de utilização;
- Controle de múltiplas operações durante o checkout do carrinho de compra incluindo tratamento de exceções;
- Possibilidade de integração futura da solução utilizando eventos para processamento assíncrono;
 |
Detalhamento da solução
Para suportar um grande número de requisições com baixa latência (recomendado para suportar aplicações mobile) e com um custo controlado podemos combinar o uso de APIs HTTP do API Gateway e Concorrência Provisionada de funções Lambda. As APIs HTTP tem um custo e performance melhores com relação a APIs REST tradicionais e consegue integrar diretamente com funções Lambda.
A interface de criação de APIs no API Gateway ficou muito mais intuitiva e já traz de cara a opção para se criar uma API HTTP.
 |
Selecionando a opção de construir uma nova API (Build), podemos começar a incluir as integrações com os recursos existentes (funções Lambda ou endpoints HTTP).
 |
Adicionadas as integrações, pode-se associar as regras de roteamento para cada PATH + Método HTTP para as respectivas integrações cadastradas. Finalizando os mapeamentos, basta definir o ambiente de execução e finalizar a criação. Habilitando a opção de Auto-deploy, a API já ficará disponível para invocação.
 |
Para não termos o problema de cold start na execução das funções Lambda podemos provisionar os ambientes de execução conforme a concorrência de acesso esperada. Em cada função que se deseja realizar o provisionamento, deve-se criar uma configuração de provisionamento na seção específica do console.
 |
Na configuração de provisionamento deve-se mapear a qual Alias ou Versão específica da função Lambda deseja-se criar os ambientes de execução e também a quantidade de concorrência.
 |
O provisionamento dos ambientes leva alguns minutos e o status é apresentado no console.
 |
É muito comum transações de uma aplicação (por exemplo, transação de compra) envolverem vários passos de validação, checagem e persistência de informação. Em uma implementação baseada em funções Lambda, a recomendação é evitar que as diferentes funções específicas para cada passo sejam orquestradas por outra função Lambda tornando difícil a visibilidade do processo como um todo e consumindo mais recursos do tempo de execução do Lambda. Uma boa alternativa é utilizar o AWS Step Functions que permite coordenar múltiplas chamadas a serviços (incluindo serviços AWS) em workflows serverless. Em aplicações com alto volume de requisições e onde se deseja baixa latência, a feature de Express Workflows ajuda a entregar performance e menor custo de infraestrutura.
Na criação de um workflow do Step Functions, a nova feature pode ser selecionado no primeiro passo de criação.
 |
O restante dos passos de configuração é bem similar ao workflow standard. A máquina de estados a ser definida no workflow pode incluir todos os passos envolvidos em uma operação complexa e também incluir tratamentos de erros e compensação. Este fluxo fica definido de forma visual e fica fácil fazer manutenção posterior.
Para entregar os benefícios citados existe a restrição de execução do workflow em no máximo 5 minutos. Este tempo é mais que suficiente para realizar os passos de uma transação de compra.
Com um grande número de requisições, o ponto que pode impactar mais na performance é onde há uma limitação de escalabilidade. No caso da nossa aplicação de exemplo, a limitação está no banco de dados relacional utilizado na persistência das compras onde há um limite máximo de número de conexões disponíveis. Uma forma de extrair o máximo de performance destas conexões é através do reuso das mesmas. Um componente que ajuda a fazer este controle das conexões é o Amazon RDS Proxy. O Proxy RDS atua como um intermediário entre seu aplicativo e um banco de dados RDS. O Proxy RDS estabelece e gerencia os conjuntos de conexões necessários ao seu banco de dados para que seu aplicativo crie menos conexões com o banco de dados.
Da mesma forma que para Provisioned Concurrency do Lambda, na configuração da função que vai acessar o banco de dados existe uma seção para configurar o database proxy.
 |
Na configuração do proxy define-se que instância RDS se deseja acessar, o secret que armazena as credenciais de acesso ao banco registrados no AWS Secrets Manager e a role que dá acesso a este último.
 |
Após a criação do proxy será disponibilizado um endpoint que deverá ser utilizado no seu código ao invés da url de acesso ao banco de dados diretamente.
Para tornar esta arquitetura facilmente integrável com outros componentes e aplicações pode-se trabalhar em uma arquitetura orientada a eventos. Por exemplo, poderíamos gerar um evento após a execução de uma compra para indicar o sucesso/falha da operação. Este evento poderia ser consumido por uma ou mais aplicações que precisassem desta informação trabalhando de forma independente e escalável sem impactar a solução de origem do evento.
Uma das soluções que habilitam este modelo é com o uso do Amazon EventBridge. É possível criar um barramento de eventos no EventBridge para receber uma série de diferentes eventos que ocorrem no seu ambiente e criar regras de roteamento e tratamento para cada um deles. Uma funcionalidade muito útil presente no EventBridge é a possibilidade de se criar um Registro de Schemas dos eventos enviados para o barramento de forma dinâmica e integrar este registro com ferramentas de desenvolvimento para criar aplicações que consomem os dados no corpo do evento.
Para criar um barramento de eventos para sua aplicação basta nomeá-lo e definir quem poderá ter acesso a seu barramento.
 |
Depois basta criar as regras de roteamento dos eventos com as seguintes informações:
- Nome e descrição da regra;
- Padrão do evento a ser consumido ou agendamento de execução da regra;
- Qual barramento que a regra se aplica;
- Destinos (serviços AWS) para os eventos recebidos no barramento que atendem ao padrão estabelecido acima;
- Tags associados ao recurso a ser criado.
 |
 |
Esta foi uma visão geral dos novos recursos aplicados em um cenário simples para melhor entendimento. Antes de começar a aplicar estas novas funcionalidades recomendo checar a disponibilidade das mesmas na região desejada e também checar a forma de precificação. Abaixo é apresentada de forma geral a precificação de cada uma.
Precificação
Provisioned Concurrency: Você paga apenas pela quantidade de simultaneidade configurada e pelo período em que a configura. O preço no leste dos EUA (Virgínia do Norte) é de US $ 0,015 por GB-hora para simultaneidade provisionada e US $ 0,035 por GB-hora para duração. O número de solicitações é cobrado na mesma taxa que as funções normais. Você pode encontrar mais informações na página de preços do Lambda.
API Gateway HTTP API: US $ 1,00 / milhão para os primeiros 300 milhões de solicitações e US $ 0,90 / milhão para todas as solicitações depois disso. A maioria dos clientes verá um custo médio economizando até 70% quando comparado às APIs REST do API Gateway.
Step Function Express Workflows: Standard Workflows são precificados com base no número de transições de estado. Express Workflows são precificados com base no número de chamadas e uma carga de GB / segundo com base na quantidade de memória usada para rastrear o estado do fluxo de trabalho durante a execução. Embora os modelos de precificação não sejam diretamente comparáveis, os Express Workflows serão muito mais econômicos em escala. Para saber mais, leia sobre AWS Step Functions Pricing.
RDS Proxy: O Amazon RDS Proxy é precificado por vCPU por hora para cada instância de banco de dados para a qual está ativado. O preço depende do tipo de instância do RDS usado pelo seu banco de dados e pode variar por região.
EventBridge: Com o Amazon EventBridge, você paga pelos eventos publicados no barramento de eventos e pelos eventos ingeridos para a descoberta do esquema. Não há cobranças adicionais por regras ou entrega de eventos. Todos os eventos de mudança de estado publicados pelos serviços da AWS são gratuitos. Em geral, você paga $ 1.00 / milhão de eventos publicados.
DevOps
Um outro assunto bastante importante para viabilizar o uso destas tecnologias de forma corporativa e ágil é o suporte para Integração Contínua e Implantação/Entrega Contínua. Sobre este tema específico voltado para tecnologias serverless está disponível um workshop que apresenta uma solução de CI/CD baseado em SAM em forma de produto usando o Service Catalog.
Conclusão e próximos passos
Nesse blog post, descrevemos novas funcionalidades que possibilitam suportar grande escala de transações em seus workloads na AWS.
Para saber mais sobre os recursos e funcionalidades utilizadas, visite os seguintes links:
https://aws.amazon.com/blogs/compute/icymi-serverless-reinvent-recap-2019/
https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/
https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/
https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/
https://aws.amazon.com/blogs/aws/new-aws-step-functions-express-workflows-high-performance-low-cost/
Sobre o autor
Luiz Yanai é arquiteto de soluções na AWS e especialista em tecnologias Serverless, atua auxiliando clientes de diversos segmentos en suas jornadas para a nuvem. Com mais de 15 anos de experiência em arquitetura e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica.