Cloudflare recuperó 100TB de RAM en su infraestructura global al reducir la cantidad de puntos hash en su algoritmo de hash consistente y compactar las estructuras de datos que los almacenan en Rust. La optimización surgió del análisis matemático que mostró que los últimos 90,000 hashes de 100,000 por servidor generaban solo una reducción de error de 0.7%, convirtiéndolos en puro desperdicio a escala.
El problema comenzó en Pingora Backend Router, el servicio de balanceo de carga interno de Cloudflare, que utiliza hash consistente para enrutar solicitudes almacenables en caché a servidores por URL. El hash consistente mapea servidores y solicitudes en una línea numérica basada en valores hash, luego asigna cada solicitud al servidor más cercano. Para manejar la distribución desigual de carga—un problema que empeora a medida que aumenta la cantidad de servidores—el estándar de la industria es asignar múltiples puntos hash por servidor. La línea base de Cloudflare era 160 hashes por servidor, el mismo valor predeterminado utilizado en NGINX y adoptado por Pingora. Con un factor de ponderación de 625 basado en la capacidad de almacenamiento del servidor, el número real implementado fue k = 160 × 625 = 100,000 hashes por servidor almacenados en memoria.
El equipo de ingeniería de Cloudflare derivó la relación matemática entre la cantidad de hashes y la precisión del balanceo de carga. Según su publicación, el coeficiente de variación—una medida de cuán desigualmente se distribuyen las solicitudes—sigue la fórmula CV_k = √((N-1)/(N*k+1)), donde N es la cantidad de servidores y k es la cantidad de hashes por servidor. Graficar esto mostró rendimientos decrecientes: cada aumento de orden de magnitud en la cantidad de hashes generaba ganancias de precisión progresivamente menores. Más críticamente, con valores hash de 32 bits, la probabilidad de colisión aumenta entre 10,000 y 100,000 hashes por servidor en centros de datos con 2048 servidores, introduciendo errores impredecibles que el modelo matemático no tiene en cuenta. El equipo determinó que reducir la cantidad de hashes en 90% no incurriría en error apreciable en su configuración.
La segunda optimización provino del empaquetamiento de estructuras. La estructura Point original almacenaba un hash de 32 bits y un índice de servidor de 32 bits como ocho bytes. Zaidoon observó que Pingora nunca coordinaría más de 65,536 servidores, por lo que un índice de 16 bits es suficiente. Las reglas de alineación de Rust normalmente impiden reducir el índice sin reducir la estructura, pero almacenar el hash e índice como un arreglo de seis bytes y acceder a ellos a través de métodos getter logró el mismo resultado compilado. Esto redujo la huella de memoria en 25%.
Desplegar el cambio requirió cuidado: cambiar anillos hash globalmente invalidaría el contenido en caché e incrementaría el tráfico de origen. Cloudflare ejecutó tanto el anillo antiguo como el nuevo en memoria simultáneamente, enrutando solicitudes a cada uno por solicitud utilizando su marco de migración. Desplegaron en capas—primero ubicaciones de validación pequeñas, luego centros de datos progresivamente más grandes—mientras monitoreaban trazas de selección de backend, uso de memoria, comportamiento de caché y tráfico de origen. Solo después de alcanzar 100% de tráfico en el nuevo anillo desmantelaron el antiguo. La caída abrupta de memoria en el día del desmantelamiento mostró la recuperación de 100TB.
Las técnicas están disponibles ahora en el crate pingora-ketama como una bandera de característica de Rust, con anillos v1 y v2 ejecutables simultáneamente. Para cualquier equipo que ejecute hash consistente a escala—ya sea para balanceo de carga, almacenamiento en caché o asignación de tareas distribuidas—la lección es medir la contribución real de cada paso de optimización contra el modelo matemático, luego eliminar lo que no produce resultados.