Descripción del entorno de ejecución de instancias administradas de Lambda
Las instancias administradas de Lambda proporcionan un modelo de implementación alternativo que ejecuta el código de función en instancias de Amazon EC2 propiedad del cliente, mientras que Lambda administra los aspectos operativos. El entorno de ejecución de las instancias administradas presenta varias diferencias importantes con respecto a las funciones de Lambda (predeterminadas), especialmente en la forma en que gestiona las invocaciones simultáneas y gestiona los ciclos de vida de los contenedores.
Nota: Para obtener información sobre el entorno de ejecución de Lambda (predeterminado), consulte Descripción del ciclo de vida del entorno de ejecución de Lambda.
Ciclo de vida del entorno de ejecución
El ciclo de vida de un entorno de ejecución de funciones de instancias administradas de Lambda difiere del de Lambda (predeterminado) en varios aspectos clave:
Fase "init"
Durante la fase de inicialización, Lambda realiza los siguientes pasos:
-
Inicializa y registra todas las extensiones.
-
Arranca el punto de entrada del tiempo de ejecución. El tiempo de ejecución genera el número configurado de trabajadores en tiempo de ejecución (la implementación depende del tiempo de ejecución).
-
Ejecuta el código de inicialización de la función (código externo al controlador).
-
Espera a que al menos un trabajador en tiempo de ejecución indique que está listo mediante una llamada a
/runtime/invocation/next.
La fase de inicio se considera completa cuando las extensiones se han inicializado y al menos un trabajador en tiempo de ejecución ha llamado a /runtime/invocation/next. La función está entonces lista para procesar las invocaciones.
nota
En el caso de las funciones de las instancias administradas de Lambda, la inicialización puede tardar hasta 15 minutos. El tiempo de espera es 130 segundos o el tiempo de espera de la función configurado (máximo de 900 segundos), lo que sea mayor.
Fase "invoke"
La fase de invocación para las funciones de instancias administradas de Lambda tiene varias características únicas:
Funcionamiento continuo. A diferencia de Lambda (predeterminado), el entorno de ejecución permanece activo de forma continua y procesa las invocaciones a medida que llegan sin bloquearse entre las invocaciones.
Procesamiento en paralelo. Se pueden ejecutar varias invocaciones simultáneamente en el mismo entorno de ejecución, y cada una de ellas es administrada por un trabajador en tiempo de ejecución diferente.
Tiempos de espera independientes. El tiempo de espera configurado de la función se aplica a cada invocación individual. Cuando se agota el tiempo de espera de una invocación, Lambda marca esa invocación específica como fallida, pero no interrumpe otras invocaciones en ejecución ni finaliza el entorno de ejecución.
Gestión de la contrapresión. Si todos los trabajadores en tiempo de ejecución están ocupados procesando las invocaciones, se rechazan las nuevas solicitudes de invocación hasta que haya un trabajador disponible.
Gestión de errores y recuperación
La gestión de errores en los entornos de ejecución de funciones de instancias administradas de Lambda es diferente al de Lambda (predeterminado):
Errores del trabajador en tiempo de ejecución. Si un proceso de trabajo en tiempo de ejecución se bloquea, el entorno de ejecución sigue funcionando con el resto de los trabajadores en buen estado.
La extensión se bloquea. Si un proceso de extensión se bloquea durante la inicialización o la operación, todo el entorno de ejecución se marca como en mal estado y finaliza. Lambda crea un nuevo entorno de ejecución para reemplazarlo.
Sin reinicio/reparación. A diferencia de Lambda (predeterminado), las instancias administradas no intentan restablecer ni reinicializar el entorno de ejecución después de los errores. En cambio, los contenedores en mal estado se finalizan y se reemplazan por otros nuevos.
Tiempos de espera de invocación
Cuando se agota el tiempo de espera de una invocación individual, Lambda devuelve al iniciador un error Task timed out after <timeout> seconds con el estado de error de función. Sin embargo, las instancias administradas por Lambda no terminan el código por la fuerza; este continúa ejecutándose en el entorno de ejecución. Como desarrollador de funciones, usted es responsable de detectar y gestionar el tiempo de espera. El objeto de contexto expone el tiempo restante de la invocación. Un valor cero o negativo indica que se ha agotado el tiempo de espera de la invocación. Otras invocaciones simultáneas en el entorno de ejecución se siguen procesando con normalidad.
Comportamiento de los reintentos
Cuando se agota el tiempo de espera de una invocación:
-
Invocaciones sincrónicas: el iniciador recibe el error de tiempo de espera y es responsable de volver a intentarlo.
-
Invocaciones asíncronas: Lambda lo reintenta según la política de reintentos de la función (predeterminado: 2 reintentos). Una vez agotados todos los reintentos, el evento se envía a la cola de mensajes fallidos configurada o al destino en caso de fallo, si lo hubiera.
-
Asignaciones de orígenes de eventos: el comportamiento de los reintentos depende de la configuración de la fuente de eventos (por ejemplo, el tamaño del lote, la división en caso de error y el número máximo de reintentos). Se puede realizar un reintento con el lote o enviar a un destino en caso de fallo según sus políticas de reintentos.
¿Qué sucede si no administra el tiempo de espera?
Si el código no comprueba el tiempo restante y detiene la ejecución:
-
La invocación ya está marcada como fallida. Lambda ya ha devuelto un error de tiempo de espera al iniciador; cualquier trabajo que el código complete después del tiempo de espera se pierde de hecho desde la perspectiva del iniciador.
-
Los recursos siguen consumidos. El código sigue ocupando un espacio de trabajo en tiempo de ejecución, lo que reduce la simultaneidad disponible para las nuevas invocaciones en esa instancia.
-
Comportamiento no determinista. El código no se detiene cuando se agota el tiempo de espera, sino que sigue ejecutándose en segundo plano. Esto significa que los efectos secundarios pueden seguir produciéndose después de que Lambda le haya dicho al iniciador que la invocación ha fallado. Por ejemplo, el controlador escribe un registro en DynamoDB, después se activa el tiempo de espera y Lambda devuelve un error de tiempo de espera al iniciador, pero el código sigue ejecutándose y envía una notificación de SNS. El iniciador vuelve a intentar la invocación, que reescribe el registro y envía la notificación de nuevo. Ahora se tienen datos y notificaciones duplicados, y no hay una forma fácil de saber cuáles provienen de la invocación “fallida” que seguía ejecutándose en segundo plano.
Administración de los tiempos de espera en el código
Se debe utilizar el objeto de contexto para comprobar el tiempo restante y detener el procesamiento antes de que se agote el tiempo de espera. Se debe configurar un búfer en función de la duración prevista de la siguiente unidad de trabajo; por ejemplo, si cada elemento tarda aproximadamente 500 ms en procesarse, el búfer debe establecerse en al menos 500 ms más un margen.
Para ver ejemplos de administración del tiempo de espera específicos del idioma, consulte la sección de contexto de solicitud de cada página de tiempo de ejecución:
