Serverless

La verdad sobre el cold start de Lambda y estrategias de optimización basadas en mediciones reales

Explicamos el mecanismo por el cual ocurre el cold start de Lambda desde el ciclo de vida de Firecracker MicroVM, y comparamos técnicas de optimización basadas en datos reales en 3 ejes: SnapStart, Provisioned Concurrency y diseño de funciones.

約 4 分で読めます

Por qué ocurre el cold start

Para optimizar correctamente el cold start de Lambda, primero es necesario comprender el mecanismo de ocurrencia. Lambda ejecuta funciones sobre Firecracker MicroVM. Cuando llega una nueva solicitud y no existe un entorno de ejecución reutilizable, AWS pasa por una serie de procesos: inicio de la MicroVM, inicialización del runtime, descarga y extracción del código de la función, y ejecución del scope global fuera del handler. Este proceso completo es el cold start. En un warm start, el entorno de ejecución existente se reutiliza y solo se ejecuta el handler.

Características del cold start por runtime

Las características del cold start por runtime son un factor a considerar en las etapas iniciales del diseño de arquitectura. Node.js y Python son los más ligeros, con cold starts de 200-400 ms incluso con configuración de memoria de 128 MB. Go opera como binario compilado, por lo que el overhead de inicialización del runtime es casi cero, con cold starts de 100-200 ms, la clase más rápida. Por otro lado, Java tiene cold starts de 3-10 segundos debido al tiempo de inicio de la JVM y la carga de clases, lo que puede ser un problema para APIs que requieren baja latencia. .NET también tiende a tener cold starts de 1-3 segundos.

SnapStart - Solución fundamental al problema de cold start de Java

SnapStart, anunciado en re:Invent 2022, es la respuesta de AWS al problema de cold start del runtime Java. SnapStart toma un snapshot del entorno de ejecución inicializado durante el despliegue de la función usando el mecanismo UFFD (Userfaultfd) de Firecracker, y durante el cold start, levanta el entorno de ejecución restaurando desde el snapshot. Esto reduce el cold start de Java de 3-10 segundos a 200-500 ms, una mejora de más del 90%. SnapStart no tiene cargos adicionales y se habilita simplemente configurando la función.

Provisioned Concurrency - Certeza a cambio de costo

Provisioned Concurrency es una función que mantiene un número especificado de entornos de ejecución en estado warm de antemano. Puede eliminar completamente los cold starts, pero como se cobra incluso en estado idle, el diseño de costos es importante. El precio de Provisioned Concurrency se calcula por número de ejecuciones simultáneas provisionadas × tiempo. Por ejemplo, provisionar una función de 1024 MB de memoria con 100 ejecuciones simultáneas cuesta aproximadamente 4,80 USD por hora. Combinado con Application Auto Scaling, puede ajustar dinámicamente el número de Provisioned Concurrency según la hora del día.

Optimización mediante diseño de funciones - Lo que los desarrolladores pueden hacer ahora

Incluso sin usar SnapStart o Provisioned Concurrency, puede reducir significativamente el cold start simplemente revisando el diseño de la función. Lo más efectivo es la reducción del tamaño del paquete. Lambda descarga y extrae el paquete de despliegue desde S3 durante el cold start, por lo que cuanto más grande sea el paquete, más tiempo toma la inicialización. Para Node.js, use esbuild o webpack para tree-shaking y elimine dependencias innecesarias. Para Python, excluya archivos de prueba y documentación del paquete de despliegue.

Diferenciación de los 3 enfoques de optimización

Los 3 enfoques de optimización del cold start deben diferenciarse según el caso de uso. Para casos donde la latencia P99 está directamente vinculada al SLA, como backends de API Gateway, Provisioned Concurrency es lo más seguro. El costo aumenta, pero es el único método que puede eliminar completamente los cold starts. Si usa Java o .NET y el cold start supera 1 segundo, SnapStart (Java) o la reducción del tamaño del paquete (.NET) son efectivos. Para funciones asíncronas o procesamiento por lotes donde la latencia no es crítica, la optimización del diseño de funciones por sí sola es suficiente.

Servicios relacionados

AWS LambdaServicio de computación serverless que ejecuta código sin gestión de servidoresAmazon API GatewayUn servicio completamente administrado para crear, publicar, gestionar y monitorear APIs

Artículos relacionados

Desarrollo serverless con AWS Lambda - Diseño de funciones y uso de event sourcesExplicamos el diseño de funciones de Lambda, el mapeo de event sources, las contramedidas para cold start y el uso de Powertools.Diseño de orquestación de flujos de trabajo con AWS Step Functions - Elección entre Standard y ExpressClarificamos los criterios de selección entre flujos de trabajo Standard y Express, y explicamos el manejo de errores, el procesamiento paralelo y los patrones de integración.Construcción de APIs serverless - Infraestructura API escalable con Amazon API GatewayExplicamos cómo construir APIs serverless utilizando Amazon API Gateway y Lambda.

Más sobre este tema

Patrones de diseño de Amazon API Gateway - Criterios de selección entre REST API y HTTP APIClarificamos los criterios de selección entre HTTP API y REST API, y presentamos patrones de autenticación con Cognito y Lambda Authorizer, así como métodos prácticos de diseño de throttling.Patrones de integración de Amazon EFS con Lambda y ECS - Uso de sistemas de archivos compartidos en serverlessMonta EFS en funciones Lambda y tareas ECS para aprovechar un sistema de archivos compartido. Presentamos el diseño de puntos de acceso y la optimización del rendimiento.Por qué el límite de Lambda es 15 minutos - La racionalidad oculta en las restricciones de diseño serverlessExplicamos por qué el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB, el payload de 6 MB y otras restricciones serverless están configuradas en esos valores, desde la perspectiva de la filosofía de diseño de Firecracker y la operación multi-tenant.Desarrollo serverless con AWS Lambda - Diseño de funciones y uso de event sourcesExplicamos el diseño de funciones de Lambda, el mapeo de event sources, las contramedidas para cold start y el uso de Powertools.Detrás de las 1.000 ejecuciones simultáneas de Lambda - Mecanismo del warm pool de Firecracker y el worker managerExplicamos 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.Construcción de APIs serverless - Infraestructura API escalable con Amazon API GatewayExplicamos cómo construir APIs serverless utilizando Amazon API Gateway y Lambda.Diseño de máquinas de estado - Orquestación de flujos de trabajo con Step FunctionsExplicamos técnicas de diseño de máquinas de estado con AWS Step Functions, incluyendo diseño visual de flujos de trabajo, selección de tipos de flujo, manejo de errores e integración directa con servicios.Diseño de orquestación de flujos de trabajo con AWS Step Functions - Elección entre Standard y ExpressClarificamos los criterios de selección entre flujos de trabajo Standard y Express, y explicamos el manejo de errores, el procesamiento paralelo y los patrones de integración.

Artículos y servicios similares

Desarrollo serverless con AWS Lambda - Diseño de funciones y uso de event sourcesExplicamos el diseño de funciones de Lambda, el mapeo de event sources, las contramedidas para cold start y el uso de Powertools.AWS LambdaServicio de computación serverless que ejecuta código sin gestión de servidores, con facturación completamente por uso basada en número de solicitudes y tiempo de ejecuciónDetrás de las 1.000 ejecuciones simultáneas de Lambda - Mecanismo del warm pool de Firecracker y el worker managerExplicamos 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.Por qué el límite de Lambda es 15 minutos - La racionalidad oculta en las restricciones de diseño serverlessExplicamos por qué el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB, el payload de 6 MB y otras restricciones serverless están configuradas en esos valores, desde la perspectiva de la filosofía de diseño de Firecracker y la operación multi-tenant.La historia del nacimiento de Firecracker - Por qué se creó la micro VM que sustenta Lambda y FargateExplicamos la filosofía de diseño del monitor de micro VM Firecracker desarrollado por AWS para Lambda y Fargate, las diferencias con la virtualización tradicional, el secreto de su arranque en 125ms y la intención estratégica de su código abierto.