El problema de los 100 terabytes escondido a plena vista
La infraestructura global de DNS de Cloudflare, impulsada por la plataforma acertadamente llamada Big Pineapple, opera a una escala asombrosa. Gestiona constantemente más de 250 mil millones de entradas de caché DNS, lo que sustenta servicios críticos como 1.1.1.1, Gateway DNS y DNS Firewall para innumerables usuarios en todo el mundo.
A pesar de esta inmensa huella operativa, los ingenieros de Cloudflare descubrieron una ineficiencia oculta y generalizada. Una entrada de caché DNS típica, con un punto de referencia de 953 bytes, contenía una proporción significativa de sobrecarga de memoria dedicada no a los datos DNS en sí, sino a la contabilidad de la estructura de datos interna. Los tipos Vec y String predeterminados de Rust, por ejemplo, almacenan un puntero, una longitud y un campo de capacidad.
Para los registros DNS almacenados en caché estáticos, que no crecen, este campo de capacidad se convirtió en una carga innecesaria, consumiendo memoria preciosa. Esta ineficiencia aparentemente menor se agravó drásticamente en toda la vasta red. Incluso un solo byte desperdiciado por entrada en 250 mil millones de registros se traduce en más de 250 gigabytes de RAM superflua.
Este extenso desperdicio de memoria equivalía al costo operativo de servidores completos, lo que destaca cómo los detalles pequeños y pasados por alto en el diseño de estructuras de datos pueden convertirse en gastos de infraestructura masivos. La revelación de Cloudflare subrayó la importancia crítica de la gestión de memoria de grano fino incluso en lenguajes de alto nivel como Rust.
Eliminar la capacidad: el arma de doble filo de Rust
Las estructuras de datos de Rust a menudo priorizan la flexibilidad. Los tipos estándar como Vec y String gestionan de manera eficiente los datos dinámicos asignando más memoria de la necesaria de inmediato, reservando capacidad adicional para el crecimiento futuro. Cada instancia almacena implícitamente tres piezas de información: un puntero a sus datos, su longitud actual y esta capacidad preasignada.
Esta estrategia es altamente efectiva para datos mutables, pero representa un desperdicio puro para registros inmutables. Las 250 mil millones de entradas de caché DNS de Cloudflare son fijas una vez almacenadas; nunca se expanden ni se contraen. El campo de capacidad adicional, por lo tanto, no tenía ningún propósito funcional dentro de "Big Pineapple", pero consumía valiosos recursos del sistema.
Al reconocer esta ineficiencia, los ingenieros reemplazaron Vec y String con boxed slices (Box<[T]>) y boxed strings (Box<str>). Estos tipos especializados de Rust asignan solo la memoria exacta requerida para los datos, eliminando el campo de capacidad por completo. Este cambio aparentemente pequeño ahorró 64 bytes por entrada de caché individual.
En toda la vasta flota global de Cloudflare, esta optimización recuperó instantáneamente más de 15 TB de RAM. Demuestra cómo una comprensión profunda de la semántica de la estructura de datos, combinada con los requisitos específicos de la aplicación, puede desbloquear inmensas ganancias de eficiencia, convirtiendo la memoria inactiva en recursos activos y utilizables.
Más allá de los Box: el arte del empaquetado de datos
Cloudflare fue más allá de los punteros individuales para secciones DNS como respuesta, autoridad y adicional, adoptando una estrategia de datos densamente empaquetados. Consolidaron estas secciones en un único bloque de memoria contiguo y luego utilizaron pequeños desplazamientos de dos bytes para navegar con precisión a cada parte. Esto eliminó la sobrecarga de punteros, contribuyendo significativamente a la reducción del 56% en el tamaño de la entrada de caché, pasando de 953 bytes a solo 420 bytes por entrada.
Otras optimizaciones se centraron en la redundancia y las ineficiencias estructurales dentro de la caché. Cloudflare dejó de almacenar el nombre del propietario si duplicaba la consulta, reconstruyéndolo a partir de la clave de caché solo cuando era necesario. Al abordar el tamaño de los enum de Rust, que por defecto adopta el tamaño de la variante más grande, implementaron boxing para tipos de registro grandes y poco comunes como NAPTR. Esto aseguró que los registros más pequeños y comunes, como A y AAAA, pudieran ocupar significativamente menos memoria.
El último cambio importante consistió en almacenar los datos de los registros como wire-format bytes sin procesar y con prefijo de longitud, en lugar de structs de Rust totalmente analizados. Esto evita la sobrecarga de memoria del rico sistema de tipos de Rust para datos que no requieren un análisis constante, reduciendo aún más la huella en memoria en las 250 mil millones de entradas de caché de Big Pineapple. Para profundizar en estas ingeniosas técnicas de ahorro de memoria, los lectores pueden consultar How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache | Cloudflare Blog.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
El resultado: más rápido y más pequeño
La meticulosa reingeniería de datos culminó en un resultado sorprendente: Cloudflare redujo el tamaño típico de sus entradas de caché DNS de 953 bytes a solo 420 bytes. Esto representa una reducción sustancial del 56% en la huella de memoria por entrada. En toda la flota global de Cloudflare, que gestiona más de 250 mil millones de entradas de caché, esta optimización recuperó la asombrosa cantidad de 100 terabytes de memoria total sin añadir un solo servidor nuevo.
Fundamentalmente, estos ahorros de memoria no supusieron un coste en el rendimiento; al contrario, las operaciones se aceleraron significativamente. Las inserciones en caché fueron un 43% más rápidas, pasando de 625.000 a unas impresionantes 893.000 entradas por segundo. Del mismo modo, las búsquedas experimentaron una mejora de velocidad del 19%, con una latencia que descendió de 828 nanosegundos a unos rápidos 670 nanosegundos. Este raro escenario en el que todos ganan proporcionó una eficiencia de recursos significativa y una mayor velocidad operativa, desafiando las compensaciones convencionales.
Cloudflare desplegará estratégicamente los 100 terabytes de memoria liberados para ampliar su capacidad de caché DNS. Una caché más grande y robusta permite a la plataforma "Big Pineapple" resolver una proporción aún mayor de consultas localmente. Esto reduce directamente la necesidad de obtener datos de servidores ascendentes, lo que se traduce en una resolución DNS más rápida para los usuarios de todo el mundo y mejora visiblemente la velocidad de internet general para todos.
Preguntas frecuentes
¿Cuánta memoria ahorró Cloudflare con esta optimización?
Cloudflare recuperó aproximadamente 100 terabytes (TB) de RAM en toda su flota global, equivalente a la memoria de unos 130 servidores, sin añadir nuevo hardware.
¿Hizo la optimización de memoria que el DNS de Cloudflare fuera más lento?
No, las optimizaciones tuvieron el efecto contrario. Las inserciones en caché fueron un 43% más rápidas y las búsquedas un 19% más rápidas, desmintiendo la compensación común entre el uso de memoria y la velocidad.
¿Qué lenguaje de programación utilizó Cloudflare para lograr esto?
Cloudflare utilizó el lenguaje de programación Rust, aprovechando sus características para un control de memoria de grano fino para reescribir cómo se estructuran las entradas de la caché DNS.
¿Cuál fue el principal cambio que hizo Cloudflare para ahorrar memoria?
Un cambio clave fue reemplazar los tipos de datos estándar de Rust como Vec y String por Box<[T]> y Box<str>. Esto eliminó un campo de 'capacidad' innecesario para los datos en caché que nunca cambian de tamaño, ahorrando 64 bytes por entrada.
¿Cómo redujo Cloudflare el tamaño de la entrada de caché DNS en un 56%?
Implementaron cinco cambios clave a nivel de Rust: eliminar los campos de capacidad, empaquetar secciones de datos en un solo bloque con offsets, eliminar información redundante, aplicar boxing a variantes de enum grandes y almacenar los datos en su formato wire-format sin procesar.