Modal escala un millón de sandboxes concurrentes y deja atrás a Kubernetes

Dos ingenieros de Modal han contado cómo reconstruyeron desde cero la infraestructura de sandboxes de la plataforma para sostener un millón de entornos concurrentes y decenas de miles de creaciones por segundo. En su benchmark crearon ese millón de sandboxes en menos de un minuto, con una mediana de tiempo entre el arranque y la ejecución de código por debajo de medio segundo. La conclusión de fondo es que Kubernetes no aguanta ahí.

El argumento lo firman Colin Weld y Connor Adams, staff engineers de la casa, en la nota técnica de Modal. Su diagnóstico: las plataformas de contenedores tradicionales dependen de coordinación centralizada y estado fuertemente consistente, y eso se rompe cuando hablamos de cientos de miles de contenedores repartidos en decenas de miles de nodos. Cualquier operación que sea lineal con el número de contenedores, con el de nodos o con ambos acaba estrangulando al sistema. En el caso concreto de Kubernetes, la carga recae sobre el algoritmo de scheduling y sobre etcd: pods y nodos escriben varias veces en el almacén central, algo que se vuelve problemático con tasas altas de creación y destrucción, y etcd no se puede fragmentar de forma nativa dentro de un keyspace. Se puede arreglar, dicen, pero exige reescribir o sustituir etcd y paralelizar el scheduler.

Scheduling que se parece más a balanceo de carga

La decisión de diseño fue asumir que todo lo que crezca con el número de sandboxes o de nodos tiene que escalar en horizontal por defecto, y que el camino de creación de un sandbox debe ser lo más simple posible. Así que dejaron de coordinar de forma global. Cada worker pasa a ser su propia fuente de verdad y, en lugar de un scheduler serializado, despliegan una flota de servidores de scheduling en paralelo. Cuando uno de ellos elige dónde crear el sandbox, contacta directamente con el worker por RPC; el worker acepta si le quedan recursos y rechaza si no.

Al diseño le queda un único cuello de botella: todos los workers publican su estado en un solo stream de Redis. Según sus pruebas de carga, ese punto aguanta bastante más allá de los 100.000 workers.

Las reacciones en la industria apuntan en la misma dirección. Jim Dowling, consejero delegado de Hopsworks, señala que cada salto de orden de magnitud trae problemas técnicos nuevos, y da por hecho que el equipo tuvo que iterar varias veces hasta llegar a las 50.000 creaciones de sandbox por segundo de forma fiable. Más incisivo es Alex Jones, ingeniero principal de IA en AWS: lo relevante no fue extender Kubernetes, sino rodearlo tras entender sus límites. Para él es la primera señal creíble de que Kubernetes no se está adaptando lo bastante rápido a lo que necesita la infraestructura de IA generativa, y anticipa una separación entre el plano de coordinación y el de ejecución. El primero, con memoria compartida y fronteras de seguridad solapadas para flujos multiagente, sigue encajando en sistemas tipo Kubernetes; el segundo quiere aislamientos que aparezcan en milisegundos.

Modal no es la única que va por ahí. Substrate, Overdrive y Unikraft persiguen objetivos parecidos con arranques en frío por debajo de los diez milisegundos.

Lo que se juega el lector aquí no es un récord de benchmark. Es la pregunta de si el orquestador que sostiene casi todo el despliegue moderno sigue siendo la pieza adecuada para cargas efímeras y masivas, o si conviene separar el plano de control del de ejecución y dejar que cada uno escale a su ritmo. Quien diseñe plataformas de agentes o de ejecución de código hará bien en mirar los números de etcd antes de copiar el patrón por defecto.