Arranque en frío: WASM frente a contenedores

El arranque en frío se refiere a la latencia adicional que paga una solicitud cuando el entorno de ejecución debe inicializarse antes de que se ejecute el código de la aplicación. En una función clásica de borde o sin servidor, esto está lejos de ser un caso marginal: una plataforma que reduce a cero instancias entre dos picos de tráfico, o que distribuye su ejecución entre docenas de nodos de borde geográficamente dispersos, paga este costo de forma permanente, no solo en la primera implementación.

El tema ha adquirido una importancia casi simbólica en el ecosistema WASM desde que Solomon Hykes, cofundador de Docker, publicó en Twitter en marzo de 2019 una frase: "Si WASM+WASI existiera en 2008, no habríamos necesitado crear Docker. Así de importante es. WebAssembly en el servidor es el futuro de la informática. » Esta es la opinión de un profesional reconocido, no una medición. Explica por qué el tema fascina, no reemplaza una figura de origen.

Aurabase ofrece dos rutas para sus funciones perimetrales: el editor Studio, que ejecuta código en el tiempo de ejecución de Deno como se documenta en nuestra guía de migración de Supabase , y la CLI aura functions deploy, que apunta a una ruta separada para funciones escritas en Rust y compiladas en WASM en Wasmtime. Es este segundo camino el que este artículo arroja luz, sin dar una cifra de partida en frío que aún no existe.

La diferencia no proviene de un tiempo de ejecución más rápido en términos absolutos: proviene de una pila de pasos más corta entre la consulta y el código de la aplicación.

Iniciar un contenedor moviliza el kernel del host: crear un nuevo proceso, configurar los cgroups y los espacios de nombres que lo aíslan, montar las capas de la imagen y luego iniciar el tiempo de ejecución de la aplicación en su interior (Node.js y su motor V8, por ejemplo, tienen un costo de inicialización). Cada paso agrega llamadas al sistema y, para una imagen que nunca se ve localmente, una descarga de red incluso antes de que comience.

Un módulo WebAssembly está aislado en el nivel del lenguaje de la máquina virtual, no en el nivel del sistema operativo. Crear una instancia de un módulo significa asignar su memoria lineal, vincular sus importaciones y luego saltar a su punto de entrada, todo dentro del proceso ya iniciado del tiempo de ejecución del host. Sin nuevos procesos, sin capas de imágenes, sin montajes de sistema de archivos predeterminados.

La elección del modo de compilación añade una variable adicional. Wasmtime compila en JIT a través de su backend Cranelift cuando se carga el módulo, o puede precompilarlo por adelantado con wasmtime compile, que produce un archivo .cwasm ya transformado en código de máquina nativo. La compilación temprana (AOT) elimina el paso de compilación de la ruta crítica de la solicitud: esta es exactamente la palanca que debe activar una arquitectura de borde sensible al arranque en frío.

# Extracto real del repositorio de Aurabase
# Tiempo de ejecución WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Esta es una dependencia de producción, no de desarrollo: confirma que Wasmtime realmente se ejecuta en la ruta CLI de las funciones perimetrales de Aurabase. Sin embargo, no confirma ninguna cifra de latencia, lo que sigue siendo cierto mientras no se publique ningún punto de referencia con fecha.

En esta área, la fuente más sólida es un artículo de investigación de la industria, no una publicación de blog de marketing. Firecracker, la tecnología microVM liviana desarrollada por AWS y utilizada principalmente para Lambda y Fargate, fue presentada en la conferencia USENIX NSDI 2020 por Agache et al. en el artículo “Firecracker: virtualización ligera para aplicaciones sin servidor”.

Este documento documenta un tiempo de arranque de menos de 125 ms y una sobrecarga de memoria de menos de 5 MiB por microVM, con la capacidad de ejecutar miles de microVM en la misma máquina física. Esta es una cifra fechada (2020), extraída de una publicación académica revisada por pares y ampliamente citada desde entonces en la literatura sobre el aislamiento sin servidor.

Un contenedor Docker estándar es generalmente más alto: desde unos pocos cientos de milisegundos hasta varios segundos, según el tamaño de la imagen, la necesidad de descargarla y el tiempo de inicio del tiempo de ejecución de la aplicación integrada. No hay una cifra única citada universalmente aquí, a diferencia de Firecracker: el resultado depende demasiado de la imagen probada para un valor único para lograr un consenso.

Tres fuentes, tres estados diferentes: un proveedor histórico, un proyecto bajo el gobierno de una fundación y un trabajo de investigación.

Fastly lanzó Compute@Edge en 2019 en Lucet, su propio compilador y tiempo de ejecución WASM precompilado. En este lanzamiento, la compañía documentó tiempos de creación de instancias de WASM por debajo de un milisegundo, un orden de magnitud que tuvo un impacto duradero en el discurso sobre el arranque en frío de WASM en la industria. En 2021, Fastly dejó de desarrollar de forma autónoma Lucet y redirigió sus esfuerzos hacia Wasmtime, cuyo backend de compilación Cranelift heredó parte de estas optimizaciones: esta es una de las razones por las que Wasmtime sigue siendo hoy una referencia para este tipo de carga.

WasmEdge, un tiempo de ejecución WASM bajo la gobernanza CNCF (originalmente SSVM, respaldado por Second State), afirma en su documentación oficial un inicio y una huella de memoria significativamente menores que un contenedor Docker equivalente, con un posicionamiento explícito en el borde y cargas de IoT. Se trata de una cifra publicada por el propio editor del proyecto, que debe leerse como tal: una afirmación del producto, no una auditoría independiente.

Desde el punto de vista de la investigación académica, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, también disponible en prepublicación) crea una plataforma sin servidor con estado que se basa en el aislamiento de WebAssembly (a través de WAVM, no Wasmtime) precisamente porque permite crear instancias de una función a un costo mucho menor que el aislamiento por contenedor o por VM. El artículo no trata específicamente sobre Wasmtime, pero proporciona una validación académica independiente al argumento estructural de la sección anterior.

Comparar estos tres tiempos de ejecución sólo por su nombre oculta la variable real: el backend de compilación elegido, que cambia radicalmente el equilibrio entre la velocidad de inicio y el rendimiento de ejecución.

Singlepass, el backend de compilación más rápido de Wasmer, existe precisamente porque su equipo identificó el arranque en frío como un eje distinto del rendimiento de ejecución en estado estable: un módulo compilado en Singlepass se inicia más rápido, pero se ejecuta más lento durante la carga máxima que el mismo módulo compilado en LLVM. Es un compromiso aceptado, no un defecto oculto.

Estas cinco líneas no se leen como una clasificación única: provienen de diferentes metodologías, fechas y generaciones de tiempo de ejecución. Para una crítica metodológica más profunda de la confiabilidad de este tipo de punto de referencia WASM, nuestro artículo sobre los límites de los puntos de referencia de WebAssembly va más allá de la presente comparación, que permanece centrada en lo que cada fuente afirma concretamente.

La ventaja del arranque en frío de WASM depende más de las cargas más sensibles a la latencia de la primera solicitud, no de todas las cargas por igual.

En particular, pesa sobre el tráfico de borde muy irregular (ráfagas seguidas de silencios), sobre el aislamiento por solicitud en lugar de por contenedor compartido entre varias solicitudes, y sobre una infraestructura que en realidad se reduce a cero instancias entre dos picos en lugar de mantener un grupo activo permanentemente. En una carga estable y predecible, donde las instancias permanecen calientes de todos modos, la brecha de arranque en frío importa menos estructuralmente.

WebAssembly también mantiene restricciones distintas del arranque en frío: el acceso al sistema de archivos o a la red pasa por WASI, una interfaz que aún evoluciona dependiendo de los tiempos de ejecución y sus versiones, y un módulo compilado para iniciarse rápidamente (Singlepass en el lado de Wasmer, por ejemplo) no es necesariamente el más rápido una vez establecido bajo una carga pesada. El arranque en frío y el rendimiento máximo de ejecución siguen siendo dos ejes distintos, rara vez óptimos simultáneamente en el mismo perfil de compilación.

Para evaluar una elección de arquitectura de borde según este criterio, Aurabase incluyó tres preguntas concretas para hacerle a cualquier proveedor: qué tiempo de ejecución exacto se utiliza, qué backend de compilación (JIT o AOT) y si la cifra de arranque en frío avanzado ha sido medida por un tercero independiente o solo por el propio editor del tiempo de ejecución.

Para conocer la capa de base de datos de este mismo problema, consulte nuestro artículo sobre el arranque en frío de Postgres sin servidor.