Concorrência, limitação e concorrência reservada

O Lambda escala executando várias execuções simultâneas da sua função — uma para cada evento simultâneo. Quando 100 solicitações chegam ao mesmo tempo, o Lambda executa 100 instâncias paralelas da sua função. A AWS gerencia automaticamente a infraestrutura subjacente. O limite de simultaneidade no nível da conta é de 1.000 execuções simultâneas por Região por padrão (um limite flexível que pode ser aumentado por meio de uma solicitação de cota de serviço).

A simultaneidade é calculada da seguinte forma: Simultaneidade = solicitações por segundo × duração média em segundos. Se sua função processa 500 solicitações por segundo e cada uma leva 0,2 segundo, você precisa de 100 execuções simultâneas. Entender essa fórmula ajuda a prever se os limites da sua conta são suficientes e se você precisa solicitar aumentos de cota antes de um evento de alto tráfego.

Quando o Lambda recebe mais solicitações do que o limite de simultaneidade permite, ele limita o excesso. Para invocações síncronas (por exemplo, pelo API Gateway), as solicitações limitadas recebem imediatamente um 429 TooManyRequestsException, que deve ser tratado pelo chamador. Para invocações assíncronas (por exemplo, eventos do S3), o Lambda coloca os eventos em uma fila e tenta novamente por até 6 horas antes de enviá-los para uma fila de mensagens não entregues.

A simultaneidade reservada garante um número específico de execuções simultâneas para determinada função, reservando-as do grupo da conta. Ela tem duas finalidades: (1) garantir capacidade — a função sempre terá esse número de execuções disponíveis, mesmo que outras funções estejam consumindo a cota da conta; (2) limitar a simultaneidade — a função nunca poderá exceder o número reservado, protegendo as dependências posteriores contra sobrecarga.

Um cenário importante de prova: uma função do Lambda grava em um banco de dados RDS que tem um limite de 50 conexões. Sem controles de simultaneidade, o Lambda poderia escalar para centenas de execuções simultâneas e esgotar todas as conexões do banco de dados, causando erros em todas as funções. Definir a simultaneidade reservada como 40 garante que o Lambda nunca exceda 40 conexões simultâneas com o banco de dados, protegendo a instância do RDS. Esse é um padrão crítico para qualquer função do Lambda que chame um serviço com limite de conexões.

A simultaneidade provisionada pré-inicializa um número especificado de ambientes de execução do Lambda para que estejam prontos para responder imediatamente, sem uma inicialização a frio. Isso é essencial para APIs sensíveis à latência, nas quais até mesmo uma inicialização a frio de 100 ms é inaceitável. Você paga uma tarifa por hora pela simultaneidade provisionada mesmo quando esses ambientes estão ociosos; portanto, combine-a com o Auto Scaling para ajustar os níveis provisionados com base nos padrões de tráfego previstos.

Esses recursos costumam ser confundidos, mas têm finalidades diferentes. A simultaneidade reservada limita e garante a alocação de capacidade do grupo da conta; ela não elimina as inicializações a frio. A simultaneidade provisionada mantém os ambientes de execução aquecidos para eliminar as inicializações a frio; ela não impede que outras funções usem o mesmo grupo. Use a simultaneidade reservada para limitar o fluxo; use a simultaneidade provisionada para melhorar a latência. Ambas podem ser usadas juntas na mesma função.

O Lambda não escala instantaneamente até a simultaneidade máxima. Existe um limite de explosão no nível da conta (taxa de escalabilidade inicial) que varia por Região — normalmente, uma explosão inicial de 3.000 execuções, seguida de 500 execuções adicionais por minuto até que o limite seja atingido. Para aplicações que preveem picos repentinos e massivos (tráfego viral e vendas relâmpago), use a simultaneidade provisionada para pré-aquecer ambientes suficientes, evitando que o limite de explosão cause limitações durante o aumento inicial.

Monitore a simultaneidade do Lambda com estas métricas essenciais do CloudWatch:

• ConcurrentExecutions: número atual de instâncias em execução
• Throttles: quantidade de invocações limitadas (deve ser zero em um sistema saudável)
• UnreservedConcurrentExecutions: grupo não reservado no nível da conta
• ProvisionedConcurrencyUtilization: quanto da capacidade provisionada está em uso

Configure alarmes em Throttles para receber notificações antes que a limitação afete os usuários finais.

Ao projetar sistemas que invocam o Lambda de forma síncrona (API Gateway e chamadas diretas pelo SDK), implemente recuo exponencial com aleatoriedade no chamador. Os SDKs da AWS têm lógica integrada de novas tentativas, mas, para funções do Lambda expostas pelo API Gateway, você deve tratar as respostas 429 na aplicação cliente. Para o Lambda acionado pelo SQS, o próprio serviço SQS trata as novas tentativas; defina adequadamente o número máximo de recebimentos na fila de origem e configure uma DLQ para as novas tentativas esgotadas.

Para Kinesis Data Streams e Streams do DynamoDB, a simultaneidade do Lambda é limitada pelo número de (Kinesis) ou partições (DynamoDB). Cada fragmento/partição é processado exatamente por uma execução simultânea do Lambda. Se você tiver 10 fragmentos do Kinesis, o Lambda executará até 10 execuções simultâneas para esse acionador. Isso significa que os problemas de limitação com acionadores baseados em fluxos geralmente são resolvidos aumentando a quantidade de fragmentos, em vez de aumentar os limites de simultaneidade.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que a simultaneidade reservada garante e limita as execuções simultâneas de uma função para proteger serviços posteriores e assegurar a disponibilidade; a simultaneidade provisionada pré-inicializa ambientes para eliminar inicializações a frio em cargas de trabalho sensíveis à latência; e a limitação se manifesta como erros 429 em invocações síncronas e novas tentativas enfileiradas em invocações assíncronas — monitore-a com a métrica Throttles do CloudWatch. A seguir, exploraremos as camadas do Lambda e os pacotes de implantação para gerenciar grandes dependências.