Cloudflare ahorra 100TB de RAM con Rust y matemáticas

Cloudflare recupera 100TB de RAM con un truco de Rust y algo de matemáticas

Cloudflare sumó esta semana otra victoria de ingeniería: recuperó más de 100TB de RAM en uno de sus servicios globales, Pingora Backend Router (PBR), mediante cambios pequeños al algoritmo de hashing consistente que usa para enrutar peticiones cacheables a servidores por URL.

La cifra llega encima de los 100TB que el equipo de DNS ya había liberado el mes pasado al optimizar el caché del resolver público 1.1.1.1, conocido internamente como Big Pineapple y detallado por la propia compañía en un post anterior sobre el ahorro en DNS.

Por qué Cloudflare necesita que cada byte cuente

Cloudflare opera "miles de servidores en todo el mundo con petabytes de RAM y millones de núcleos de CPU", como explica la propia empresa en su blog. Cuando cada servicio debe correr en cada nodo, el espacio desperdiciado se vuelve un lujo que nadie puede pagar.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El ahorro lo disparó un ticket abierto por Ivan, un ingeniero del equipo de Performance, que detectó uso excesivo de memoria en pingora-ketama, la librería open-source de Cloudflare para hashing consistente. PBR es el servicio interno de balanceo de carga que la compañía usa para distribuir peticiones entre sus servidores.

Qué es el hashing consistente y por qué importa

El hashing consistente es una técnica para distribuir tareas entre servidores sin redistribuir casi nada cuando un nodo entra o sale del pool. Cloudflare lo usa para enrutar peticiones cacheables a servidores por URL: así guarda una sola copia de cada archivo por centro de datos y encuentra su ubicación de forma estable.

El concepto básico es simple: cualquier entrada (dirección IP de un servidor, clave de caché de una tarea) se mapea a un número entero (de 32, 64 o 128 bits según la función hash). Cada servidor "se queda" con el rango de números anterior a su hash, y cada tarea se asigna al primer servidor que encuentra a su izquierda.

El problema es que, con un solo hash por servidor, la distribución queda desigual. Si tienes 100 servidores, el rango esperado que atenderá cada uno es 0.99% del total, pero con una desviación estándar que ronda el 99% del valor esperado. Es decir, en la práctica algunos servidores reciben mucha más carga que otros.

Cómo Cloudflare descubrió que podía borrar el 90% de los hashes

La solución tradicional al desbalance es agregar más hashes por servidor. NGINX y Pingora usan 160 hashes por servidor como valor por defecto. Con 160 puntos, el coeficiente de variación cae del 99% al 8%, un salto enorme.

Pero el equipo de Cloudflare fue un paso más allá con las matemáticas: si reduces la cantidad de hashes, ¿en qué punto el error empieza a importar?

La respuesta depende de dos efectos contrapuestos:

Menos hashes significa menos precisión estadística en la distribución.
Más hashes significa más colisiones por la paradoja del cumpleaños: con 32 bits de espacio, la probabilidad de colisión sube sorprendentemente rápido.

Las simulaciones del equipo mostraron que, en centros de datos con 2048 servidores, la tasa de error empieza a subir entre 10.000 y 100.000 hashes por servidor. Eso significa que podían borrar el 90% de los hashes generados por servidor sin introducir error apreciable. Esa fue la palanca principal del ahorro.

El truco de Rust que ahorró otro 25%

Antes de tocar la cantidad de hashes, Zaidoon, otro ingeniero del equipo, atacó el tamaño de cada punto en memoria. La estructura original era:

struct Point {
    hash: u32,
    index: u32,
}

Aunque index cabe en 16 bits, Rust aplica reglas de alineación: el tamaño de la estructura debe ser múltiplo del campo más grande (4 bytes), así que cada punto terminaba ocupando 8 bytes en memoria.

La solución fue empacar ambos campos en un array de 6 bytes:

struct Point([u8; 6]);

Esa reducción del 25% en el tamaño de cada punto, multiplicada por millones de puntos en cada servidor y por miles de servidores, se tradujo en decenas de terabytes recuperados.

Migración sin invalidar el caché global

Cambiar el anillo de hash cambia dónde van algunas peticiones cacheables. Si Cloudflare hubiera hecho un cambio global, habría invalidado casi todo el caché de golpe y disparado el tráfico a los servidores de origen.

En lugar de eso, PBR corrió las dos versiones del anillo de balanceo en memoria durante semanas. Cada petición usaba el framework de migración interno para decidir qué anillo seleccionar el backend, con decisión estable por hash de petición y rollback limpio si algo fallaba.

El rollout fue por capas: primero ubicaciones pequeñas de validación, luego grupos de data centers progresivamente más grandes, después el resto del mundo. Monitorearon trazas de selección de backend, contadores de versión de anillo, errores de conexión, memoria del proceso, tiempo de arranque, comportamiento del caché y tráfico al origen. Cuando la migración llegó al 100%, retiraron la ruta del anillo viejo.

El resultado fue una caída brusca de memoria en PBR el día en que la versión con anillos grandes fue dada de baja para siempre.

Qué significa esto para tu startup

Las decisiones de bajo nivel sobre estructuras de datos y algoritmos clásicos siguen pagando dividendos en sistemas modernos. Cloudflare no compró hardware, no migró a otro lenguaje ni refactorizó todo: ajustó dos palancas muy concretas (representación en memoria y parámetros del algoritmo) y recuperó 100TB.

Tres lecciones prácticas para equipos de ingeniería en startups:

Audita el tamaño real de tus estructuras, no el teórico. Lo que Rust, Go o Java te dicen que pesa un struct no es lo que ocupa en memoria por alineación, padding y overhead del runtime. Una simple compactación puede liberar entre 20% y 30% de RAM sin tocar la lógica de negocio.
Mide antes de asumir que "más es mejor". El caso de Cloudflare demuestra que multiplicar por 10 la cantidad de hashes no mejora la precisión de forma lineal; pasada cierta densidad, las colisiones empiezan a comerse el beneficio. Antes de subir un parámetro "por las dudas", modela y simula.
Diseña migraciones que se puedan deshacer. El enfoque de correr dos anillos en paralelo con decisión estable por hash de petición le dio a Cloudflare un rollback instantáneo sin redespliegues. Cuando cambias parámetros que afectan producción, el costo de mantener dos versiones en memoria suele ser menor que el costo de un incidente global.

Todos los cambios están disponibles en el crate open-source pingora-ketama como feature de Cargo no listada por defecto, según explica Cloudflare en su post. Cualquier equipo que use la librería puede aprovechar las mismas optimizaciones.