Resumen:
Cloudflare recientemente redujo significativamente la memoria caché utilizada por su solucionador de DNS público 1.1.1.1, liberando aproximadamente 100 TB de memoria en toda la red. Esta optimización no implica reemplazar el hardware del servidor ni eliminar módulos de memoria, sino que se logra mejorando el método de almacenamiento del software para almacenar en caché los datos DNS.
Este trabajo gira principalmente en torno a la Gran Piña. Big Pineapple es la plataforma de almacenamiento en caché de Cloudflare que admite el solucionador 1.1.1.1, el firewall DNS y muchos otros servicios DNS. El ingeniero de sistemas de Cloudflare, Sebastiaan Neuteboom, presentó en un blog técnico cinco ajustes al código base de Rust que redujeron el espacio ocupado por un único registro de caché DNS típico de 953 bytes a 420 bytes.
También se ha mejorado la velocidad de ejecución optimizada del sistema. Cloudflare dijo que el rendimiento de inserción de caché aumentó de 625.000 elementos por segundo a 893.000 elementos por segundo, y la latencia de las consultas se redujo de 828 nanosegundos a 670 nanosegundos. Durante el transcurso de la implementación, desde mediados de mayo hasta principios de julio, el uso de memoria del percentil 99 por instancia cayó de 9,3 GB a 5,3 GB.
Cloudflare afirma que Big Pineapple almacena en caché más de 250 mil millones de registros DNS en todo momento. A una escala tan grande, incluso una pequeña cantidad de memoria desperdiciada por registro suma una cantidad significativa. La empresa estima que por cada byte innecesario ocupado en una entrada de caché, todo el clúster de servidores consume más de 250 GB de memoria adicional.
Uno de los cambios importantes involucra los tipos Vec y String en Rust. Estos contenedores están diseñados para expandirse dinámicamente, por lo que además de los datos reales, se guarda información adicional como la capacidad. Sin embargo, no es necesario expandir el registro DNS después de ingresarlo en el caché. Luego, Cloudflare reemplazó estas estructuras con sectores en cuadros de tamaño fijo, eliminando metadatos que ya no eran útiles. Según la empresa, solo este ajuste ahorró más de 15 TB de memoria.
Los ingenieros también rediseñaron la forma en que se organizan las respuestas DNS en la memoria. Anteriormente, Big Pineapple guardaba tres conjuntos de listas de registros para cada respuesta; el nuevo diseño coloca todos los registros en el mismo búfer y luego utiliza un desplazamiento de dos bytes para identificar la ubicación de cada registro.
La caché ahora tampoco retiene los nombres de los propietarios cuando son simplemente duplicados del nombre de dominio que se consulta, sino que se reconstruye cuando se devuelve la respuesta. Además, el sistema guarda datos de registros utilizando bytes de formato de línea DNS sin procesar con un prefijo de longitud, lo que resuelve el problema de espacio desperdiciado en diseños anteriores. Anteriormente, un registro IPv4 A, que solo ocupaba 4 bytes, ocupaba 144 bytes, al igual que el relativamente raro registro NAPTR, el tipo de registro DNS más grande almacenado en caché por Cloudflare. Cambiar a un formato de datos sin procesar de longitud variable elimina la necesidad de que los registros más cortos reserven el mismo espacio que los registros más largos.
Los 100 TB de memoria que Cloudflare recuperó en todo el clúster de servidores equivalen aproximadamente a la capacidad de memoria de 130 servidores de 13.ª generación. Cada uno de estos servidores está equipado con una memoria DDR5-6400 de 768 GB. Cloudflare consideró una configuración de memoria de 1152 GB para esta generación de servidores, pero finalmente desistió después de evaluar el costo de una memoria de mayor capacidad.
Con este espacio de memoria, Cloudflare planea ampliar el tamaño de la caché de DNS. Se espera que mantener más registros localmente mejore las tasas de aciertos de la caché y reduzca el tráfico de solicitudes a los servidores DNS autorizados.
Esta no es la primera vez que Cloudflare lleva a cabo una optimización de la eficiencia de la memoria a gran escala. El año pasado, la compañía también reescribió la capa FL2 responsable de procesar solicitudes en código Rust. Con el aumento de los precios de la memoria para servidores, desbloquear el potencial de la infraestructura existente mediante la optimización del software puede ser más rentable que simplemente agregar hardware.
Comentarios