Comprender el ciclo de vida del entorno de ejecución de Lambda

Lambda invoca la función en un entorno de ejecución, que proporciona un entorno en tiempo de ejecución seguro y aislado. El entorno de ejecución administra los recursos necesarios para ejecutar la función. El entorno de ejecución también proporciona compatibilidad del ciclo de vida para el tiempo de ejecución de la función y cualquier extensión externa asociada a la función.

El tiempo de ejecución de la función de Lambda se comunica con la API de tiempo de ejecución. Las extensiones se comunican con Lambda mediante la API de extensiones. Las extensiones también pueden recibir mensajes de registro y otros datos de telemetría de la función mediante la API de telemetría.

Al crear una función de Lambda, se debe especificar información de configuración, como la cantidad de memoria y el tiempo máximo de ejecución asignados a su función. Lambda utiliza esta información para configurar el entorno de ejecución.

El tiempo de ejecución de la función y cada extensión externa son procesos que se ejecutan dentro del entorno de ejecución. Los permisos, recursos, credenciales y variables de entorno se comparten entre la función y las extensiones.

Ciclo de vida del entorno de ejecución de Lambda

Cada fase comienza con un evento que Lambda envía al tiempo de ejecución y a todas las extensiones registradas. El tiempo de ejecución y cada extensión registrada indica la finalización mediante el envío de una solicitud API Next. Lambda congela el entorno de ejecución cuando el tiempo de ejecución y cada extensión se han completado y no hay eventos pendientes.

Fase "init"

En la fase Init, Lambda realiza tres tareas:

La fase Init finaliza cuando el tiempo de ejecución y todas las extensiones señalan que están listas mediante el envío de una solicitud Next a la API. La fase Init está limitada a 10 segundos. Si las tres tareas no se completan en 10 segundos, Lambda vuelve a intentar la fase Init en el momento de la primera invocación de la función con el tiempo de espera de la función configurado.

Si Lambda SnapStart está activada, la fase Init ocurre cuando publica una versión de la función. Lambda guarda una instantánea del estado de la memoria y del disco del entorno de ejecución iniciado, conserva la instantánea cifrada y la almacena en caché para acceder a ella con baja latencia. Si tiene un enlace de tiempo de ejecución antes del punto de comprobación, el código se ejecuta al final de la fase Init.

Cuando utiliza la simultaneidad aprovisionada, Lambda inicializa el entorno de ejecución al configurar los ajustes del equipo para una función. Lambda también garantiza que los entornos de ejecución inicializados se encuentren siempre disponibles antes de las invocaciones. Es posible que vea intervalos entre las fases de inicialización e invocación de la función. Dependiendo del tiempo de ejecución y la configuración de memoria de su función, es posible que también vea variabilidad de latencia en la primera invocación en un entorno de ejecución inicializado.

En el caso de las funciones que utilizan la simultaneidad bajo demanda, Lambda puede, en ocasiones, inicializar los entornos de ejecución antes de las solicitudes de invocación. Cuando esto ocurre, también puede observar un intervalo de tiempo entre las fases de inicialización e invocación de la función. Se recomienda que no dependa de este comportamiento.

Errores durante la fase Init

Si una función se bloquea o agota el tiempo de espera durante la fase Init, Lambda emite la información sobre el error en el registro INIT_REPORT.

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Si la fase de Init se realiza correctamente, Lambda no emite el registro de INIT_REPORT a menos que SnapStart o la simultaneidad aprovisionada estén habilitados. Las funciones SnapStart y de simultaneidad aprovisionada siempre emiten INIT_REPORT. Para obtener más información, consulte Monitoreo para Lambda SnapStart.

Fase Restore (solo Lambda SnapStart)

Cuando se invoca por primera vez una función SnapStart y, a medida que la función escala, Lambda vuelve a activar los nuevos entornos de ejecución a partir de la instantánea conservada, en lugar de activar la función desde cero. Si tiene un enlace de tiempo de ejecución posterior a la restauración, el código se ejecuta al final de la fase Restore. Se le cobrará por la duración de los enlaces de tiempo de ejecución posteriores a la restauración. El tiempo de ejecución debe cargarse, y los enlaces del tiempo de ejecución posteriores a la restauración deben completarse antes de que transcurra el tiempo de espera (10 segundos). De lo contrario, obtendrá una excepción SnapStartTimeoutException. Cuando se completa la fase Restore, Lambda invoca el controlador de funciones (la fase Fase "invoke").

Errores durante la fase de Restauración

Si la fase Restore falla, Lambda emite la información sobre el error en el registro RESTORE_REPORT.

RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout

RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

Para obtener más información sobre el registro RESTORE_REPORT, consulte Monitoreo para Lambda SnapStart.

Fase "invoke"

Cuando se invoca una función de Lambda en respuesta a una solicitud API Next, Lambda envía un evento Invoke al tiempo de ejecución y a cada extensión.

La configuración de tiempo de espera de la función limita la duración de toda la fase Invoke. Por ejemplo, si establece el tiempo de espera de la función en 360 segundos, la función y todas las extensiones deben completarse en 360 segundos. Tenga en cuenta que no hay una fase posterior a "invoke" independiente. La duración es la suma de todo el tiempo de invocación (tiempo de ejecución + extensiones) y no se calcula hasta que la función y todas las extensiones han terminado la ejecución.

La fase "invoke" finaliza después de que el tiempo de ejecución y todas las extensiones indiquen que se han terminado mediante el envío de una solicitud Next a la API.

Errores durante la fase Invoke

Si la función Lambda se bloquea o agota el tiempo de espera durante la fase Invoke, Lambda restablece el entorno de ejecución. El siguiente diagrama ilustra el comportamiento del entorno de ejecución de Lambda cuando se produce un error de invocación:

En el diagrama anterior:

Fase "shutdown"

Cuando Lambda está a punto de cerrar el tiempo de ejecución, envía un evento Shutdown a cada extensión externa registrada. Las extensiones pueden utilizar este tiempo para las tareas de limpieza finales. El evento Shutdown es una respuesta a una solicitud Next a la API.

Duración: toda la fase Shutdown está limitada a 2 segundos. Si el tiempo de ejecución o cualquier extensión no responde, Lambda lo termina a través de una señal (SIGKILL).

Después de que la función y todas las extensiones se hayan completado, Lambda mantiene el entorno de ejecución durante algún tiempo en previsión de otra invocación de función. Sin embargo, Lambda finaliza los entornos de ejecución cada pocas horas para permitir las actualizaciones y el mantenimiento del tiempo de ejecución, incluso para las funciones que se invocan de forma continua. No debe suponer que el entorno de ejecución durará de manera indefinida. Para obtener más información, consulte Implementación de la ausencia de estado en las funciones.

Cuando se invoca de nuevo la función, Lambda descongela el entorno para su reutilización. La reutilización del entorno de ejecución tiene las siguientes implicaciones:

Latencia y arranques en frío

Cuando Lambda recibe una solicitud para ejecutar una función mediante la API de Lambda, el servicio primero prepara un entorno de ejecución. Durante esta fase de inicialización, el servicio descarga el código, inicia el entorno y ejecuta cualquier código de inicialización fuera del controlador principal. Por último, Lambda ejecuta el código del controlador.

En este diagrama, los dos primeros pasos de descarga del código y configuración del entorno se denominan generalmente “arranque en frío”. No se cobra por este tiempo, pero sí se agrega latencia a la duración total de la invocación.

Una vez finalizada la invocación, el entorno de ejecución se congelará. Para mejorar la administración de recursos y el rendimiento, Lambda retiene el entorno de ejecución durante un periodo. Durante este tiempo, si llega otra solicitud para la misma función, Lambda puede reutilizar el entorno. Esta segunda solicitud normalmente finaliza más rápido, puesto que el entorno de ejecución ya se encuentra plenamente configurado. Esto se denomina “arranque en caliente”.

Los arranques en frío por lo general se producen en menos del 1 % de las invocaciones. La duración de un arranque en frío varía desde menos de 100 ms hasta más de 1 segundo. Normalmente, los arranques en frío son más habituales en las funciones de desarrollo y pruebas que en las cargas de trabajo de producción. Esto se debe a que las funciones de desarrollo y prueba suelen invocarse con menos frecuencia.

Reducción de los arranques en frío con simultaneidad aprovisionada

Si necesita tiempos de inicio de función predecibles para la carga de trabajo, la simultaneidad aprovisionada resulta la solución recomendada para garantizar la menor latencia posible. Esta función preinicializa los entornos de ejecución, lo que reduce los arranques en frío.

Por ejemplo, una función con una simultaneidad aprovisionada de 6 tiene 6 entornos de ejecución precalentados.

Optimización de la inicialización estática

La inicialización estática se produce antes de que el código del controlador comience a ejecutarse en una función. Este es el código de inicialización que deberá proporcionar, que se encuentra fuera del controlador principal. Este código se utiliza con frecuencia para importar bibliotecas y dependencias, realizar configuraciones e inicializar conexiones con otros servicios.

El siguiente ejemplo de Python muestra la importación y configuración de módulos y la creación del cliente de Amazon S3 durante la fase de inicialización, antes de que la función lambda_handler se ejecute durante la invocación.

import os
import json
import cv2
import logging
import boto3

s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

  # Handler logic...

El factor que más contribuye a la latencia antes de la ejecución de una función corresponde al código de inicialización. Este código se ejecuta cuando un nuevo entorno de ejecución se crea por primera vez. El código de inicialización no se vuelve a ejecutar si la invocación utiliza un entorno de ejecución en caliente. Estos son algunos de los factores que afectan a la latencia del código de inicialización:

Los desarrolladores pueden tomar una serie de medidas para optimizar la latencia de inicialización estática. Si una función tiene muchos objetos y conexiones, es posible que pueda rediseñar una sola función para convertirla en varias funciones especializadas. Estos son más pequeños individualmente y cada uno tiene menos código de inicialización.

Es importante que las funciones solo importen las bibliotecas y dependencias que necesiten. Por ejemplo, si solo usa Amazon DynamoDB en el AWS SDK, puede necesitar un servicio individual en lugar de todo el SDK. Compare los tres ejemplos siguientes:

// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')

// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')

// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)

La inicialización estática también suele ser el mejor lugar para abrir las conexiones de bases de datos y permitir que una función pueda reutilizar las conexiones en múltiples invocaciones en el mismo entorno de ejecución. Sin embargo, es posible que tenga un gran número de objetos que solo se utilicen en determinadas rutas de ejecución de la función. En este caso, puede cargar variables de forma lenta en el ámbito global para reducir la duración de la inicialización estática.

Evite las variables globales para la información específica del contexto. Si su función tiene una variable global que se usa solo durante la duración de una única invocación y se restablece para la siguiente invocación, use un ámbito de variable que sea local para el controlador. Esto no solo evita las filtraciones de variables globales entre las invocaciones, sino que también mejora el rendimiento de la inicialización estática.