Quem já trabalhou com o AWS Lambda já se deparou com o "temido" cold start hehehe, presente em praticamente toda discussão sobre o serviço e frequentemente citado como uma das principais preocupações ao utilizá-lo. A ideia desse artigo é tentar trazer um pouco mais de clareza sobre esse comportamento da Lambda e se de fato ele impacta negativamente o uso do serviço.
O que é um cold start?
O cold start refere-se ao tempo que uma função AWS Lambda leva para ficar pronta para executar o código implementado, é o seu tempo de inicialização no ambiente de execução. Isso ocorre quando ela é executada pela primeira vez ou após ficar ociosa por um período de tempo.
Como podemos ver na imagem acima, o cold start inclui o tempo de download do código da função e o tempo de inicialização do ambiente de execução.
Uma vez que a Lambda foi inicializada, invocações posteriores não sofrerão o cold start e utilizarão da mesma instância, a menos que, devido às demandas de tráfego, aumente o número de execuções concorrentes, resultando em novas invocações e novos cold starts. Para ajudar na visualização desse comportamento, veja a imagem abaixo:
Para processar execuções concorrentes, foi necessário a inicialização de novas instâncias, causando novos cold starts, porém algumas execuções (execução 6, 7, 8, 10) utilizaram de instâncias já inicializadas e por isso não tiveram o tempo de cold start somados ao tempo total de execução.
Impactos do cold start
O cold start pode adicionar desde alguns milissegundos até alguns segundos no tempo total de execução de uma Lambda, dependendo do tamanho da Lambda e alguns outros fatores, como por exemplo, o uso de VPC.
Outro dado importante é a taxa em que o cold start ocorre perante o total de execuções da Lambda. Isso pode variar muito dependendo do cenário de uso. Lambdas que são muito requisitadas e possuem um padrão de requisição com poucos picos tendem a ter uma taxa muito baixa de cold start, abaixo de 1%. Porém, Lambdas com um padrão de requisição com muitos picos ou Lambdas com pouca requisição tendem a ter taxas maiores de cold start. É muito importante acompanhar essa taxa através de ferramentas de observabilidade. Obs.: A própria AWS menciona que o valor geralmente é abaixo de 1% - Documentação AWS.
E é aqui que a história começa a ficar interessante. Frequentemente participo de discussões sobre Lambdas onde o cold start recebe atenção desproporcional, em muitos casos, vejo equipes descartando prematuramente o uso de Lambdas apenas por causa desse fator.
No entanto, como sempre dizemos na arquitetura de software: tudo depende do contexto (a clássica frase da arquitetura, hahaha). Existem cenários onde esse tempo adicional é aceitável, assim como há situações onde esse atraso torna-se inviável.
Cenários onde o cold start não é um problema
Cenário mais simples - Quando os cold starts são tão rápidos que não representam um problema
Isso geralmente ocorre com funções que utilizam runtimes como C++, Go e Rust e o código da Lambda é enxuto, facilitando a etapa de download. No entanto, você deve seguir as melhores práticas e otimizações em cada runtime para manter um cold start de baixo impacto.
Para conhecer melhor o benchmark de cold start por runtime, confira este Link.
Execução assíncrona
Outro caso simples é quando sua função é executada de forma assíncrona, seja por SQS, SNS, EventBridge, DynamoDB stream, etc. Nesses casos, um segundo adicional geralmente é aceitável e não representa um problema crítico.
Fluxos não críticos
Um tempo adicional de latência de 0,5-1 segundo importa em fluxos não críticos para 1% dos clientes? Provavelmente não, especialmente se for um fluxo interno entre serviços, sem exposição direta ao cliente. Geralmente SLOs de fluxos não críticos observam o percentil p95 ou p97, tolerando o cold start quando a taxa de cold starts se mantém em torno de 1%.
Cenários com impacto maior - Onde realmente é um problema
Quando o desempenho é essencial
Os cold starts prejudicam mais quando lidamos com fluxos voltados para o cliente onde o desempenho é crítico, mesmo para aqueles 1% dos clientes. Por exemplo, se você tem microsserviços dedicados à pagamento online que precisam operar com alta concorrência e concluir a execução em menos de 200 ms, 1% de um tempo adicional de 0,5-1 segundo pode ser inaceitável.
Quando a taxa de cold start é alta
Conforme vimos anteriormente, a taxa de cold start pode aumentar em cenários com muitos picos de requisição, cenários com poucas requisições ou ainda cenários com grandes variações, tornando o comportamento da Lambda imprevisível. Para esses casos sua função pode ter mais cold starts do que o usual, impactando mais do que 1% do total de requisições.
Estratégias para mitigar o cold start
Existem estratégias para tentar mitigar o cold start. Entre elas as principais são:
- Configurar Provisioned Concurrency para sua Lambda (porém vai acarretar em um aumento significativo no custo da sua Lambda, que é uma das principais vantagens do serviço).
- Aquecer sua função implementando mecanismos próprios onde executa a sua função de tempos em tempos de maneira forçada (Este método é menos eficaz para funções com muitas execuções concorrentes, pois sua execução forçada atingiria apenas uma das Lambdas já instanciadas).
- Desenvolvendo funções Lambda em linguagens com menor tempo de cold start (C++, Rust ou Go).
- Ajustando a memória da função para otimizar a inicialização.
- Otimizando dependências e tamanho do pacote (existem muitos artigos na internet que exploram melhor essas otimizações).
- Evitando VPCs sempre que possível! Configurar VPC na sua função requer que a Lambda crie ENIs (elastic network interface) para a VPC alvo, o que facilmente adiciona alguns segundos ao seu cold start.
Conclusão
Os cold starts podem desencorajar as pessoas de usar Serverless, e entendo esse ponto de vista, mas conforme vimos, existem casos e casos, não dá para generalizarmos em relação a esse comportamento. Ao usar o serviço AWS Lambda, é importante monitorar a taxa de cold start através de ferramentas de observabilidade para decisões mais embasadas.
Top comments (0)