Cloudflare recupera 100TB de RAM afinando el hashing consistente de Pingora

Cloudflare ha recuperado más de 100 TB de RAM repartidos por toda su red después de retocar el algoritmo de hashing consistente que usa Pingora Backend Router, su servicio interno de balanceo. La cifra va sobre los 100 TB que el equipo de DNS ya había liberado el mes anterior, según cuenta la compañía en su blog de ingeniería. El origen no fue un rediseño: fue un ticket.

Un ticket y una librería que comía de más

Lo abrió Ivan, y señalaba un consumo de memoria excesivo en pingora-ketama, la librería de hashing consistente que Cloudflare mantiene como open source dentro de Pingora. PBR la usa para enrutar peticiones cacheables por URL, de forma que cada objeto viva en una sola copia por centro de datos y su localización siga siendo estable cuando entran o salen servidores.

El hashing consistente se explica muchas veces con un anillo, pero el post lo dibuja como una recta numérica: la salida de la función hash es un entero sin signo, y cada servidor y cada tarea caen en un punto de esa recta. Asignar una tarea a un servidor es buscar el primer punto de servidor a su izquierda. Simple. El problema es el reparto: los huecos entre puntos no miden lo mismo, y la carga de cada nodo es proporcional al trozo de recta que le toca.

Ahí entra la estadística de primero de carrera. Con N servidores, el valor esperado de la fracción que cubre cada uno es 1/N y la desviación típica es (1/N)·sqrt((N-1)/(N+1)). Traducido: con 100 servidores la desviación ronda el 0,99%, pero el coeficiente de variación —esa desviación dividida por la media— se va al 99%. O sea, algunos nodos pueden acabar atendiendo el doble de peticiones de las que les corresponderían mientras otros no hacen casi nada.

La respuesta que plantean es añadir hashes: en lugar de un único punto por servidor, varios. Es la técnica que ya usa ketama, y con ella la varianza del reparto cae y la carga se reparte de verdad. Todo esto vive en Rust dentro del repositorio de pingora-ketama, así que cualquier servicio que use la librería hereda el ajuste sin tocar su propia lógica.

La compañía insiste en que a su escala hasta una mejora del 1% justifica el trabajo, y este caso es la excepción que confirma la regla: no es un 1%, son más de 100 TB de memoria que dejan de estar ocupados en miles de servidores de todo el mundo. Cloudflare presume de operar petabytes de RAM y millones de núcleos al máximo, y con ese margen tan justo un algoritmo que reparte mal la memoria se nota en la factura y en la capacidad de meter más trabajo por nodo.

El detalle interesante para quien administra infraestructura propia es que el arreglo no sale de comprar más hierro, sino de mirar la estructura de datos. El hashing consistente está en cualquier capa de balanceo, y una implementación que guarda un punto por servidor gasta y reparte peor que una que guarda varios. El post no publica cifras de latencia ni de CPU, solo el ahorro de memoria, así que queda por ver si el cambio trae algún coste en tiempo de consulta o si el reemplazo de la estructura es neutro en rendimiento.