Detrás de las 1.000 ejecuciones simultáneas de Lambda - Mecanismo del warm pool de Firecracker y el worker manager
Explicamos el mecanismo por el cual Lambda gestiona micro VMs dentro del límite predeterminado de 1.000 ejecuciones simultáneas, la estrategia de reutilización mediante warm pool, las decisiones de ubicación del worker manager y las optimizaciones internas para reducir la tasa de cold start.
Ciclo de vida del entorno de ejecución de Lambda
Cuando llega una invocación de función Lambda, el servicio Lambda asigna un entorno de ejecución (Execution Environment). El entorno de ejecución es un sandbox que opera sobre una Firecracker micro VM y contiene el código de la función, el runtime y las variables de entorno configuradas. El ciclo de vida del entorno de ejecución consta de 3 fases. En la fase INIT, se inicia el runtime y se ejecuta el código de inicialización global (fuera del handler). En la fase INVOKE, se ejecuta el handler de la función. En la fase SHUTDOWN, el runtime se cierra y los recursos se liberan. Después de la fase INVOKE, el entorno de ejecución se mantiene en el warm pool para su reutilización.
Estrategia de gestión del warm pool
La gestión del warm pool de Lambda es un problema de optimización que equilibra la minimización de la tasa de cold start y la maximización de la eficiencia de recursos. Si se mantienen los entornos de ejecución en el warm pool durante mucho tiempo, los cold starts disminuyen, pero la memoria se ocupa continuamente, presionando la capacidad del host físico. Por el contrario, si se destruyen rápidamente, los recursos se liberan pero los cold starts aumentan. AWS describió en un paper de 2019 que la gestión del warm pool de Lambda utiliza un algoritmo predictivo que analiza los patrones de invocación de cada función y predice la demanda futura para determinar cuántos entornos de ejecución mantener.
Worker manager - En qué host físico ubicar
El worker manager de Lambda es el componente que decide en qué host físico (worker) ubicar un nuevo entorno de ejecución. Esta decisión de ubicación debe satisfacer múltiples restricciones simultáneamente. Primero, que el host físico tenga capacidad disponible (CPU, memoria). Segundo, que los entornos de ejecución del mismo cliente se distribuyan entre múltiples hosts físicos (aislamiento de fallos). Tercero, para funciones que requieren conexión VPC, que el host esté en la misma zona de disponibilidad que la ENI de destino. El worker manager toma decisiones de ubicación óptimas considerando estas restricciones en milisegundos.
Gestión de ejecuciones simultáneas y burst limit
Las 1.000 ejecuciones simultáneas predeterminadas por cuenta de Lambda se comparten entre todas las funciones dentro de la región. Si la función A usa 800 ejecuciones simultáneas, la función B solo puede usar 200. El burst limit es una restricción en la velocidad a la que pueden aumentar las ejecuciones simultáneas. En us-east-1, us-west-2 y eu-west-1, el burst inicial es de 3.000, seguido de un aumento de 500 por minuto. En otras regiones, el burst inicial es de 500-1.000. La concurrencia reservada permite reservar un número específico de ejecuciones simultáneas para una función, evitando que otras funciones consuman toda la capacidad.
Precauciones con la reutilización de entornos de ejecución
La reutilización de entornos de ejecución (warm start) es ventajosa desde la perspectiva del rendimiento, pero hay efectos secundarios que los desarrolladores deben tener en cuenta. Primero, el estado de las variables globales se preserva. Los valores de variables globales establecidos en la invocación anterior permanecen en la siguiente invocación. Usar esto para cachear conexiones de base de datos (connection pooling) es un patrón recomendado, pero almacenar datos específicos de la solicitud en variables globales puede causar fugas de datos entre solicitudes. Segundo, el directorio /tmp se preserva. Los archivos escritos en /tmp en la invocación anterior permanecen, por lo que es necesario limpiar al inicio de la función o usar nombres de archivo únicos.