Este artículo describe la construcción de un runtime de servidorless similar a AWS Lambda utilizando microVMs de Firecracker, un proyecto personal del autor Vivek Jadhav. El objetivo principal es entender el funcionamiento interno de las plataformas serverless, que a menudo se perciben como 'mágicas'.
¿Por qué Firecracker? Firecracker es un monitor de máquinas virtuales minimalista, diseñado para ofrecer un equilibrio entre la velocidad de arranque de los contenedores y la seguridad de las máquinas virtuales tradicionales. Es ideal para ejecutar código arbitrario de usuarios en entornos compartidos, como Lambda y Fargate. La principal ventaja es su rapidez y aislamiento.
El Problema del 'Cold Start': El mayor desafío es la latencia de arranque en frío. El proceso tradicional implica crear una VM, arrancar el kernel, iniciar el runtime y cargar el código del usuario, lo que puede llevar alrededor de 200ms. La solución implementada es el uso de 'snapshots': se arranca la VM una vez, se inicializa el runtime y se crea una instantánea de ese estado. Las invocaciones posteriores restauran desde esta instantánea, reduciendo el tiempo de arranque a 1-5ms, una mejora significativa.
Arquitectura: El runtime se divide en dos capas: un 'Control Plane' que gestiona el ciclo de vida de las VMs, el despliegue, la programación y el enrutamiento de peticiones, y una 'Execution Layer' que se encarga de la ejecución aislada de las funciones dentro de las microVMs. Ambas capas se comunican a través de vsock.
Desafíos: El proyecto enfrentó varios desafíos inesperados, incluyendo problemas con el PID 1 (el proceso inicial de Linux), la complejidad de la gestión de snapshots (especialmente en relación con el estado de vsock) y las condiciones de carrera en la comunicación vsock. Para solucionar estos problemas, se utilizaron herramientas como tini (un init system minimalista) y se requirió una cuidadosa sincronización.
Diseño y Optimización: El runtime utiliza un entorno Node.js ligero para la ejecución de funciones, con un ciclo de vida determinista. Se implementó la reutilización de runtimes 'calientes' (warm runtime reuse) para mejorar el rendimiento, sacrificando cierto grado de aislamiento. También se implementó un sistema de programación para gestionar la carga de trabajo de forma equitativa entre las funciones.
Resultados: Las pruebas de rendimiento mostraron un throughput de ~5,400 requests por segundo y una latencia p50 de ~1ms, con una latencia p99 de ~4ms. Estos resultados se lograron gracias a la reutilización de snapshots, runtimes y canales vsock.
Conclusiones: El proyecto proporcionó una valiosa comprensión de los desafíos de ingeniería subyacentes a las plataformas serverless, incluyendo la gestión de cold starts, el equilibrio entre aislamiento y rendimiento, y la importancia del diseño de la observabilidad. El autor anima a otros a construir proyectos similares para desarrollar una mejor intuición de los sistemas.