Ambiente de execução do Lambda - AWS Lambda
Ciclo de vida do ambiente do runtime

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Ambiente de execução do Lambda

O Lambda invoca a função em um ambiente de execução, que fornece um ambiente do runtime seguro e isolado. O ambiente de execução gerencia os recursos necessários para executar a função. O ambiente de execução também fornece suporte ao ciclo de vida para o runtime da função e qualquer extensão externa associada à função.

O runtime da função se comunica com o Lambda usando a API de runtime. As extensões se comunicam com o Lambda usando a API Extensions. As extensões também podem receber mensagens de log e outras telemetrias da função ao usar a API de telemetria.

Diagrama de arquitetura do ambiente de execução.

Quando você cria uma função do Lambda, você especifica informações de configuração, como a quantidade de memória disponível e o tempo máximo de execução permitido para sua função. O Lambda usa essas informações para configurar o ambiente de execução.

O runtime da função e cada extensão externa são processos executados dentro do ambiente de execução. Permissões, recursos, credenciais e variáveis de ambiente são compartilhados entre a função e as extensões.

Ciclo de vida do ambiente de execução do Lambda

A fase Init é seguida por uma ou mais invocações de função. Quando não há solicitações de invocação, o Lambda inicia a fase Shutdown.

Cada fase começa com um evento que o Lambda envia para o runtime e para todas as extensões registradas. O runtime e cada extensão indicam a conclusão enviando uma solicitação de API Next. O Lambda congela o ambiente de execução quando o runtime e cada extensão tiverem sido concluídos e não houver eventos pendentes.

Fase de inicialização

Na fase Init, o Lambda executa três tarefas:

  • Iniciar todas as extensões (Extension init)

  • Realizar bootstrap no runtime (Runtime init)

  • Executar o código estático da função (Function init)

  • Execute qualquer gancho beforeCheckpoint de tempo de execução (somente SnapStart Lambda)

A fase Init termina quando o runtime e todas as extensões sinalizam que estão prontas enviando uma solicitação de API Next. A fase Init é limitada a 10 segundos. Se todas as três tarefas não forem concluídas em até dez segundos, o Lambda repetirá a fase Init no momento da primeira invocação de função com o tempo-limite de função configurado.

Quando o Lambda SnapStart está ativado, a fase Init ocorre ao você publicar uma versão da função. O Lambda salva um snapshot do estado da memória e do disco do ambiente de execução inicializado, mantém o snapshot criptografado e o armazena em cache para acesso de baixa latência. Se você tiver um hook de runtime beforeCheckpoint, então, o código será executado ao final da fase Init.

nota

O tempo limite de 10 segundos não se aplica a funções que estão usando simultaneidade provisionada ou. SnapStart Para SnapStart funções e simultaneidade provisionadas, seu código de inicialização pode ser executado por até 15 minutos. O limite de tempo é de 130 segundos ou o tempo limite da função configurada (máximo de 900 segundos), o que for maior.

Quando você usa simultaneidade provisionada, o Lambda inicializa o ambiente de execução quando você define as configurações do PC para uma função. O Lambda também garante que os ambientes de execução inicializados estejam sempre disponíveis antes das invocações. Você pode observar lacunas entre a invocação e as fases de inicialização da sua função. Dependendo do runtime e da configuração de memória da sua função, é possível observar uma latência variável na primeira invocação em um ambiente de execução inicializado.

Para funções que usam simultaneidade sob demanda, o Lambda pode ocasionalmente inicializar ambientes de execução antes das solicitações de invocação. Quando isso acontece, você também pode observar uma lacuna de tempo entre as fases de inicialização e invocação da função. Recomendamos que você não dependa desse comportamento.

Falhas durante a fase de inicialização

Se uma função falhar ou atingir o tempo limite durante a fase Init, o Lambda emite informações de erro no log INIT_REPORT.

exemplo — log INIT_REPORT para tempo limite
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
exemplo — log INIT_REPORT para falha de extensão
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Se a Init fase for bem-sucedida, o Lambda não emitirá o INIT_REPORT registro SnapStart, a menos que seja ativado. SnapStart as funções sempre emitem. INIT_REPORT Para ter mais informações, consulte Monitoramento para Lambda SnapStart.

Fase de restauração (somente Lambda SnapStart )

Quando você invoca uma SnapStartfunção pela primeira vez e à medida que a função aumenta, o Lambda retoma novos ambientes de execução a partir do instantâneo persistente em vez de inicializar a função do zero. Se você tiver um hook de runtime afterRestore(), o código será executado ao final da fase Restore. Você terá cobranças pela duração dos hooks de runtime afterRestore(). O runtime (JVM) deve ser carregado e os hooks de runtime afterRestore() devem ser concluídos dentro do limite de tempo limite (dez segundos). Caso contrário, você receberá um SnapStartTimeoutException. Quando a fase Restore é concluída, o Lambda invoca o manipulador de função (a Fase de invocação).

Falhas durante a fase de restauração

Se a fase Restore falhar, o Lambda emite informações de erro no log RESTORE_REPORT.

exemplo — log RESTORE_REPORT para tempo limite
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
exemplo — log RESTORE_REPORT para falha no hook de runtime
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

Para obter mais informações sobre o log RESTORE_REPORT, consulte Monitoramento para Lambda SnapStart.

Fase de invocação

Quando uma função do Lambda é invocada em resposta a uma solicitação de API Next, o Lambda envia um evento Invoke para o runtime e para cada extensão.

A configuração de tempo limite da função limita a duração de toda a fase Invoke. Por exemplo, se você definir o tempo limite da função como 360 segundos, a função e todas as extensões precisam ser concluídas em até 360 segundos. Observe que não há fase de pós-invocação independente. A duração é a soma de todo o tempo de invocação (runtime + extensões) e não é calculada até que a função e todas as extensões tenham terminado a execução.

A fase de invocação termina após o runtime e todas as extensões sinalizam que elas foram concluídas enviando uma solicitação de API Next.

Falhas durante a fase de invocação

Se a função do Lambda falhar ou expirar durante oInvokefase, o Lambda redefine o ambiente de execução. O diagrama a seguir ilustra o comportamento do ambiente de execução do Lambda quando há falha de invocação:

No diagrama anterior:

  • A primeira fase é a fase INIT, que é executada sem erros.

  • A segunda fase é a fase INVOKE, que é executada sem erros.

  • Em algum momento, suponha que a função tenha uma falha de invocação durante a execução (como erro de tempo limite ou de runtime da função). A terceira fase, chamada INVOKE WITH ERROR, ilustra esse caso. Quando isso ocorre, o serviço do Lambda executa uma redefinição. A redefinição se comporta como um evento Shutdown. Primeiro, o Lambda encerra o runtime; depois, envia um evento Shutdown para cada extensão externa registrada. O evento inclui o motivo do desligamento. Se esse ambiente for usado para uma nova invocação, o Lambda reinicializará a extensão e o runtime com a próxima invocação.

    nota

    Redefinir o Lambda não limpa o conteúdo do diretório /tmp antes da próxima fase de inicialização. Esse comportamento é consistente com a fase de desligamento regular.

  • A quarta fase representa a fase INVOKE imediatamente após uma falha de invocação. Aqui, o Lambda reinicializa o ambiente executando a fase INIT. Isso se chama inicialização suprimida. Quando ocorrem inits suprimidos, o Lambda não relata explicitamente uma fase adicional de INIT nos Logs. CloudWatch Em vez disso, você perceberá que a duração na linha REPORT inclui uma duração adicional de INIT mais a duração de INVOKE. Por exemplo, suponha que você veja os seguintes registros CloudWatch:

    2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST 
2022-12-20T01:00:02.500-08:00 END RequestId: XXX 
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms 
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB

    Neste exemplo, a diferença entre os carimbos de data e hora REPORT e START é de 2,5 segundos. Isso não corresponde à duração relatada de 3022,91 milissegundos, pois não leva em conta o INIT adicional (inicialização suprimida) que o Lambda executou. Neste exemplo, podemos inferir que a fase INVOKE exata durou 2,5 segundos.

    Para obter mais insights sobre esse comportamento, você pode usar API de Telemetria do Lambda. A API Telemetry emite eventos INIT_START, INIT_RUNTIME_DONE e INIT_REPORT com phase=invoke sempre que ocorrem inicializações suprimidas entre as fases de invocação.

  • A quinta fase representa a fase SHUTDOWN, que é executada sem erros.

Fase de desligamento

Quando o Lambda estiver prestes a encerrar o runtime, ele enviará um evento Shutdown a cada extensão externa registrada. As extensões podem usar esse tempo para tarefas de limpeza finais. O evento Shutdown é uma resposta a uma solicitação de API Next.

Duração: toda a fase Shutdown é limitada a 2 segundos. Se o runtime ou qualquer extensão não responder, o Lambda o encerrará por meio de um sinal (SIGKILL).

Após a conclusão da função e de todas as extensões, o Lambda mantém o ambiente de execução por algum tempo à espera de uma outra invocação de função. Na verdade, o Lambda congela o ambiente de execução. Quando a função é invocada novamente, o Lambda descongela o ambiente para reutilização. Reutilizar o ambiente de execução tem as seguintes implicações:

  • Os objetos declarados fora do método do manipulador da função permanecem inicializados, fornecendo otimização adicional quando a função é invocada novamente. Por exemplo, se sua função do Lambda estabelecer uma conexão com o banco de dados, em vez de restabelecer a conexão, a conexão original é usada em invocações subsequentes. Recomendamos que você adicione lógica em seu código para verificar se uma há conexão existente antes de criar outra.

  • Cada ambiente de execução fornece entre 512 MB e 10.240 MB, em incrementos de 1 MB, de espaço em disco no diretório /tmp. O conteúdo do diretório permanece quando o ambiente de execução é congelado, fornecendo cache transitório que pode ser usado para várias invocações. Você pode adicionar um código extra para verificar se o cache tem os dados que você armazenou. Para obter mais informações sobre limites de tamanho de implantação, consulte Cotas Lambda.

  • Processos em segundo plano ou retornos de chamada que foram iniciados pela função do Lambda e não foram concluídos quando a função terminou serão retomados se o Lambda reutilizar o ambiente de execução. Garanta que todos os processos em segundo plano ou retornos de chamadas no seu código sejam concluídos antes que o código seja encerrado.

Ao escrever o código da função, não presuma que o Lambda reutilizará automaticamente o ambiente de execução para invocações subsequentes da função. Outros fatores podem ditar a necessidade de o Lambda criar um ambiente de execução, o que pode gerar resultados inesperados, como falhas de conexão do banco de dados.