Noções básicas sobre o ambiente de execução das instâncias gerenciadas do Lambda
As instâncias gerenciadas do Lambda fornecem um modelo de implantação alternativo que executa seu código de função em instâncias do Amazon EC2 de propriedade do cliente, enquanto o Lambda gerencia os aspectos operacionais. O ambiente de execução das instâncias gerenciadas tem várias diferenças importantes em relação às funções do Lambda (padrão), principalmente na forma como ele lida com invocações simultâneas e gerencia os ciclos de vida do contêiner.
Observação: para obter informações sobre o ambiente de execução do Lambda (padrão), consulte Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda.
Ciclo de vida do ambiente de execução
O ciclo de vida de um ambiente de execução de uma função das instâncias gerenciadas do Lambda difere do Lambda (padrão) de várias maneiras fundamentais:
Fase de inicialização
Durante a fase de inicialização, o Lambda executa as etapas a seguir:
-
Inicialização e registro de todas as extensões
-
Bootstrap do ponto de entrada do runtime. O runtime gera o número configurado de operadores de runtime (a implementação depende do runtime)
-
Execução do código de inicialização da função (código fora do manipulador)
-
Espere que pelo menos um operador de runtime sinalize que está pronto chamando
/runtime/invocation/next
A fase de inicialização é considerada concluída quando as extensões são inicializadas e pelo menos um operador de runtime tiver chamado /runtime/invocation/next. A função está então pronta para processar as invocações.
nota
Para as funções das instâncias gerenciadas do Lambda, a inicialização pode levar até 15 minutos. O tempo limite é de no máximo 130 segundos ou o tempo limite configurado da função (até 900 segundos).
Fase de invocação
A fase de invocação para funções das instâncias gerenciadas do Lambda tem várias características exclusivas:
Operação contínua. Ao contrário do Lambda (padrão), o ambiente de execução permanece continuamente ativo, processando as invocações à medida que elas chegam, sem congelar entre as invocações.
Processamento paralelo. Várias invocações podem ser executadas simultaneamente no mesmo ambiente de execução, cada uma gerenciada por um operador de runtime diferente.
Tempos limite independentes. O tempo limite configurado da função se aplica a cada invocação individual. Quando uma invocação expira, o Lambda marca essa invocação específica como com falha, mas não interrompe outras invocações em andamento nem encerra o ambiente de execução.
Tratamento de contrapressão. Se todos os operadores de runtime estiverem ocupados processando invocações, novas solicitações de invocação serão rejeitadas até que um operador fique disponível.
Tratamento de erros e recuperação
O tratamento de erros em ambientes de execução das funções de instâncias gerenciadas do Lambda difere do Lambda (padrão):
Falhas do operador de runtime. Se um processo de operador de runtime falhar, o ambiente de execução continuará funcionando com os demais operadores íntegros.
Falhas de extensão. Se um processo de extensão falhar durante a inicialização ou operação, todo o ambiente de execução será marcado como não íntegro e encerrado. O Lambda criará um novo ambiente de execução para substituí-lo.
Sem redefinição/reparo. Diferentemente do Lambda (padrão), as instâncias gerenciadas não tentam redefinir e reinicializar o ambiente de execução após erros. Em vez disso, os contêineres não íntegros são encerrados e substituídos por novos.
Tempo limite de invocações
Quando uma invocação individual expira, o Lambda retorna o erro Task timed out after <timeout> seconds com um status de erro de função para o chamador. No entanto, as instâncias gerenciadas do Lambda não encerram seu código à força; elas continuam em execução no ambiente de execução. Como desenvolvedor de funções, você é responsável por detectar e gerenciar o tempo limite. O objeto de contexto expõe o tempo restante para a invocação. O valor zero ou negativo indica que a invocação atingiu o tempo limite. Outras invocações simultâneas no ambiente de execução continuam sendo processadas normalmente.
Comportamento de repetição
Quando uma invocação atinge o tempo limite:
-
Invocação síncrona: o chamador recebe o erro de tempo limite e é responsável por fazer novas tentativas.
-
Invocação assíncrona: novas tentativas do Lambda com base na política de repetição da sua função (padrão: 2 novas tentativas). Depois que todas as novas tentativas forem esgotadas, o evento será enviado para a fila de mensagens não entregues configurada ou para o destino em caso de falha, se houver.
-
Mapeamento da origem do evento: o comportamento da repetição de tentativas depende da configuração da origem do evento (por exemplo, tamanho do lote, bisseção em caso de erro ou máximo de tentativas de repetição). O lote pode ser repetido ou enviado para um destino em caso de falha com base em suas políticas de repetição de tentativas.
O que acontece se você não lidar com o tempo limite
Se seu código não verificar o tempo restante e interromper a execução:
-
A invocação já está marcada como falha. O Lambda já retornou um erro de tempo limite para o chamador. Qualquer trabalho que seu código conclua após o tempo limite é efetivamente perdido do ponto de vista do chamador.
-
Os recursos permanecem consumidos. Seu código continua ocupando um espaço do operador de runtime, reduzindo a simultaneidade disponível para novas invocações nessa instância.
-
Comportamento não determinístico. Seu código não para quando o tempo limite é acionado, ele continua sendo executado em segundo plano. Portanto, os efeitos colaterais ainda podem ocorrer depois que o Lambda já informou ao chamador que a invocação falhou. Por exemplo, seu manipulador grava um registro no DynamoDB, depois o tempo limite é acionado e o Lambda retorna um erro de tempo limite para o chamador, mas seu código ainda está em execução e envia uma notificação de SNS. O chamador repete a invocação, que grava o registro novamente e envia a notificação mais uma vez. Agora você tem dados e notificações duplicados e não há uma maneira fácil de saber quais vieram da invocação “com falha” que ainda estava sendo executada em segundo plano.
Gerenciar tempos limite em seu código
Use o objeto de contexto para verificar o tempo restante e interromper o processamento antes do tempo limite. Configure um buffer com base na duração esperada da sua próxima unidade de trabalho: por exemplo, se cada item levar aproximadamente 500 ms para ser processado, defina o buffer em pelo menos 500 ms além da margem.
Para exemplos específicos de linguagem de tratamento de tempo limite, consulte a seção de contexto de solicitação de cada página de runtime:
