El problema de los 100 terabytes
Cloudflare ejecutó recientemente un asombroso robo de memoria, liberando 100 terabytes de capacidad operativa en toda su red global. Esta notable optimización equivale a añadir toda la capacidad de RAM de 130 servidores modernos Gen 13 a su infraestructura, todo ello sin desplegar una sola pieza de hardware nuevo. Una recuperación tan masiva subraya el profundo impacto de la eficiencia del software de bajo nivel.
Al potenciar servicios críticos como 1.1.1.1, Gateway DNS y DNS Firewall, la plataforma Big Pineapple de Cloudflare gestiona una escala enorme. En cualquier momento dado, este sistema almacena más de 250 mil millones de entradas de caché DNS, cada una representando una pieza crucial de información de enrutamiento de internet, facilitando miles de millones de solicitudes globales diariamente. Esta inmensa escala transforma incluso las ineficiencias menores en desafíos operativos y de costos significativos.
El desafío principal para Cloudflare residía en el efecto acumulativo de gastos generales aparentemente minúsculos. Con 250 mil millones de entradas DNS, un solo byte desperdiciado por entrada se multiplica en cientos de gigabytes de memoria superflua en toda la global fleet. Esta ineficiencia microscópica, escalada a través de un sistema tan vasto, no solo consume recursos valiosos; también puede afectar el rendimiento y aumentar los costos operativos, exigiendo una reevaluación fundamental de las estructuras de datos.
Cinco recortes, una recompensa masiva
Cloudflare ejecutó cinco optimizaciones precisas a nivel de Rust, cada una un ataque quirúrgico contra la hinchazón de memoria, culminando en una recompensa masiva de 100 TB. En primer lugar, los ingenieros reemplazaron Vec<T> y String con Box<[T]> y Box<str> para entradas de caché inmutables. Esto eliminó la capacidad preasignada y el gasto innecesario en el heap, liberando inmediatamente 64 bytes por entrada y más de 15 TB en toda la flota.
Un segundo cambio crítico involucró almacenar registros DNS como raw wire-format bytes, en lugar de estructuras Rust completamente analizadas. Esto simplificó el procesamiento, ya que el sistema ahora evita el análisis y la serialización redundantes. También mejoró significativamente la cache locality, empaquetando más datos relevantes en menos líneas de caché.
Otras ingeniosidades en el diseño evitaron el desperdicio de memoria. Cloudflare encapsuló (boxed) grandes enum variants, como NAPTR dentro del enum RecordData, para evitar que los tipos de registro más pequeños y comunes (como A y AAAA) reservaran un relleno excesivo. Esto aseguró que la asignación de memoria coincidiera más estrechamente con el tamaño real de los datos.
Los ingenieros también fusionaron tres listas separadas de registros de respuesta DNS (respuesta, autoridad, adicional) en una sola lista unificada. Dos offsets compactos de 2 bytes u16 ahora delimitan las secciones, reemplazando pares de puntero/longitud más grandes y ahorrando 28 bytes por entrada. Esta consolidación ajustó significativamente la estructura de datos.
Finalmente, el almacenamiento condicional del propietario representó el quinto recorte. Cloudflare ahora almacena el nombre del propietario solo cuando difiere del dominio consultado, deduciéndolo de la clave de caché en caso contrario. Combinadas, estas optimizaciones granulares redujeron la huella por entrada en un 56%, de 953 bytes a 420 bytes, transformando el panorama de memoria de Cloudflare.
Más rápido al volverse más pequeño
Reducir las estructuras de datos a menudo implica un compromiso en el rendimiento, pero las optimizaciones de Cloudflare entregaron una rara doble victoria. El rendimiento de inserción en caché aumentó un impresionante 43%, subiendo de 625,000 a 893,000 entradas por segundo. Simultáneamente, la latencia de búsqueda cayó significativamente, mejorando en un 19% de 828 ns a 670 ns.
Esta aceleración no es magia; es una consecuencia directa de la densidad de memoria. Al reducir la huella de memoria por entrada de caché DNS en un 56% (de 953 bytes a 420 bytes), las estructuras de datos de Cloudflare se volvieron más compactas. Los datos más pequeños ocupan menos espacio, lo que permite que más entradas de caché quepan en las cachés L1, L2 y L3 más rápidas de la CPU, mejorando la CPU cache locality.
Piénselo como organizar una despensa: un paquete más pequeño significa que puede colocar más artículos de uso frecuente en los estantes delanteros de fácil acceso. Los procesadores pasan menos tiempo buscando datos en la memoria principal (RAM) más lenta y más tiempo procesándolos directamente desde estas cachés de alta velocidad, lo que reduce drásticamente los estados de espera.
Una mejora tan profunda tanto en el consumo de recursos como en la velocidad operativa es una rareza en la ingeniería, desafiando los compromisos típicos entre el uso de memoria y el tiempo de ejecución. Cloudflare no solo liberó 100 terabytes de memoria, sino que también hizo que su resolvedor DNS fuera notablemente más rápido. Para profundizar en los detalles técnicos, lea el informe de Cloudflare: How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache.
¿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 efecto dominó de la eficiencia
Cloudflare no dejará que estos 100 TB de memoria liberada permanezcan inactivos. En cambio, reinvierte directamente esta capacidad sustancial en su red global, expandiendo específicamente la caché DNS para servicios como 1.1.1.1. Esta asignación estratégica maximiza el impacto de la recuperación de memoria, convirtiendo un triunfo técnico en una mejora operativa inmediata.
Una caché DNS más grande se traduce directamente en beneficios tangibles para millones de usuarios en todo el mundo. El aumento en las tasas de aciertos de caché significa respuestas DNS más rápidas, ya que los servidores de Cloudflare pueden resolver más consultas desde la memoria local en lugar de iniciar búsquedas ascendentes. Esto mejora directamente la capacidad de respuesta y la resiliencia de la experiencia en Internet.
El logro de Cloudflare ofrece una lección crucial para la industria: la optimización profunda de sistemas sigue siendo una poderosa palanca para la eficiencia. A medida que la demanda de AI workloads eleva los costos de la memoria del servidor, optimizar la infraestructura existente para recuperar 100 terabytes de memoria sin cambios de hardware no es solo una hazaña de ingeniería; es un imperativo estratégico. Este meticuloso trabajo a nivel de Rust subraya el valor duradero de la precisión en la programación de sistemas.
Preguntas frecuentes
¿Cuánta memoria ahorró realmente Cloudflare?
Cloudflare ahorró aproximadamente 100 terabytes (TB) de RAM en toda su flota de servidores global al optimizar su caché DNS 1.1.1.1, equivalente a la memoria de 130 de sus servidores.
¿Qué lenguaje de programación se utilizó para la optimización?
Las optimizaciones se implementaron en Rust, que fue elegido por su eficiencia de memoria, rendimiento y control de bajo nivel sobre las estructuras de datos.
¿Ahorrar memoria ralentizó el resolvedor DNS?
No, contraintuitivamente, las optimizaciones también mejoraron el rendimiento. El rendimiento de inserción en caché aumentó un 43% y la latencia de búsqueda disminuyó un 19%.
¿Cómo se ahorró la memoria?
Los ahorros provinieron de cinco cambios principales en la forma en que se almacenaban los datos DNS, incluida la eliminación de la capacidad de memoria no utilizada en vectores, la fusión de listas de datos y el almacenamiento de registros de manera más eficiente como bytes sin procesar.
¿Qué hará Cloudflare con los 100 TB de memoria ahorrados?
La memoria liberada se reinvertirá para aumentar el tamaño de la caché DNS. Se espera que esto mejore las tasas de aciertos de caché, reduciendo las consultas ascendentes y haciendo que el servicio 1.1.1.1 sea aún más rápido para los usuarios.