Cloudflare reduce a la mitad el retraso de compilación de DNS con planificación dirigida
Cloudflare redujo la latencia de propagación de DNS en un 50% y el uso de memoria en un 85% al sustituir las reconstrucciones completas de zonas por compilaciones dirigidas para cambios específicos en los registros.
Traducido automáticamente del original en inglés.
Cloudflare ha optimizado significativamente su canal de propagación de DNS, reduciendo a la mitad el tiempo necesario para aplicar cambios en su red global. El equipo de ingeniería logró esto sustituyendo las reconstrucciones completas de zonas, amplias y consumidoras de recursos, por un nuevo planificador de compilaciones dirigidas que identifica la unidad mínima segura de trabajo para cada cambio. Este cambio arquitectónico también redujo el consumo máximo de memoria en un 85%, permitiendo al sistema gestionar zonas con decenas de millones de registros de manera más eficiente.
Qué ocurrió
El desafío principal surgió del creciente tamaño de las zonas DNS en la red de Cloudflare. Aunque el volumen de eventos aumentó de 250 a aproximadamente 700 por segundo desde 2022, el cuello de botella principal no era el rendimiento, sino el coste computacional de procesar zonas grandes. Algunas zonas contienen ahora más de 20 millones de registros, una cifra que se espera alcance cientos de millones. Anteriormente, cualquier cambio en la configuración de una zona o en un registro solía provocar una compilación completa, que lee todos los registros de la base de datos, los convierte al formato de borde (edge) y los compara con el estado existente. Para zonas masivas, este proceso es prohibitivamente costoso y a menudo imposible de ajustar en la memoria.
Para resolver esto, los ingenieros de Cloudflare desarrollaron un planificador de compilaciones dirigidas y un programador unificado. El planificador analiza los eventos entrantes para determinar exactamente qué partes de una zona han cambiado, como nombres DNS específicos o metadatos compartidos, en lugar de reconstruir toda la zona. El programador luego combina múltiples eventos pendientes para la misma zona en una única ventana de ejecución. Este enfoque garantiza que los cambios en la configuración de la zona ya no provoquen reconstrucciones completas para zonas con decenas de millones de registros. El resultado es una reducción del 50% en el tiempo desde un cambio de DNS hasta que sus datos se escriben en Quicksilver, el almacén clave-valor distribuido de Cloudflare, y una caída del 85% en el uso máximo de memoria.
Cómo funciona
La optimización se basa en distinguir entre diferentes tipos de cambios de DNS y asignarlos a ámbitos de compilación específicos. El sistema clasifica las compilaciones en cinco categorías: solo recursos (para cambios estándar de registros como A o CNAME), recursos y metadatos (para cambios de servidores de nombres o comodines), ápice y metadatos (para configuraciones como Universal SSL), purga (para zonas no publicadas) y zona completa (cuando no se puede demostrar la seguridad). El planificador garantiza que cualquier compilación dirigida produzca una salida idéntica byte a byte a la que generaría una compilación completa. Si el sistema no puede demostrar que una compilación menor es segura, recurre por defecto a una compilación completa, aunque para zonas extremadamente grandes evita las compilaciones completas por completo para prevenir el agotamiento de la memoria.
Un componente crítico de este sistema es el manejo de metadatos compartidos. En la arquitectura de Cloudflare, pueden existir múltiples objetos de zona internos para el mismo nombre de dominio público durante eventos del ciclo de vida como la incorporación. Una clave de metadatos compartidos en Quicksilver actúa como un directorio, indicando a los servidores autoritativos qué IDs de zona interna están activos. Cuando un cambio afecta a estos metadatos, como una actualización de servidor de nombres, el constructor debe refrescar toda la clave compartida. Para garantizar la consistencia, el sistema realiza una lectura fresca de las réplicas de la base de datos inmediatamente antes de la ejecución. Este enfoque de "planificar dos veces" tiene en cuenta cualquier cambio en la base de datos que haya ocurrido entre el evento inicial y la compilación real, evitando que datos obsoletos o incorrectos se propaguen al borde (edge).
Detalles clave
- El uso máximo de memoria cayó un 85% debido a la eliminación de lecturas innecesarias de zonas completas para conjuntos de datos grandes.
- La latencia de propagación de DNS se redujo a la mitad, disminuyendo en un 50% el tiempo desde el cambio hasta la escritura en Quicksilver.
- El sistema gestiona zonas con más de 20 millones de registros, con expectativas de crecimiento hacia cientos de millones.
- Se utilizan cinco tipos de compilación: solo recursos, recursos y metadatos, ápice y metadatos, purga y zona completa.
- Un programador unificado combina múltiples eventos para la misma zona en una sola compilación para mejorar la eficiencia.
- Las lecturas frescas de la base de datos ocurren inmediatamente antes de la ejecución para asegurar que la compilación refleje el estado actual.
Por qué importa
Para los ingenieros de infraestructura y los equipos de plataforma, este caso de estudio destaca la importancia del procesamiento incremental en sistemas de alta escala. A medida que crecen los conjuntos de datos, las operaciones lineales como las reconstrucciones completas se vuelven insostenibles. El cambio de un modelo de "reconstruir todo" a uno de "reconstruir solo lo que cambió" demuestra cómo un seguimiento preciso de dependencias puede desbloquear ganancias significativas de rendimiento. Esto es particularmente relevante para equipos que gestionan almacenes de configuración a gran escala o servicios con estado donde tanto la consistencia como la velocidad son críticas. La capacidad de demostrar seguridad mientras se minimiza el trabajo permite que los sistemas escalen sin aumentos proporcionales en los recursos de cómputo.
El enfoque también ofrece lecciones sobre el manejo de la consistencia eventual y las condiciones de carrera (race conditions). Al leer el estado fresco de las réplicas justo antes de la ejecución, Cloudflare mitiga el riesgo de actuar sobre información obsoleta sin bloquear el canal de ingesta. Este patrón de planificación conservadora seguido de verificación de último minuto es una estrategia robusta para sistemas distribuidos donde el orden de eventos y el retraso de replicación de bases de datos son desafíos inherentes. Muestra que la resiliencia no siempre requiere añadir tiempos de espera; a veces, requiere validaciones más inteligentes en el punto de acción.
Qué puedes hacer
- Audita tus canales de datos para identificar procesos que realizan reconstrucciones completas cuando solo se necesitan actualizaciones parciales.
- Implementa un sistema de clasificación para los cambios que determine el ámbito mínimo de trabajo requerido para cada tipo de evento.
- Utiliza un programador unificado para agrupar eventos relacionados, reduciendo la sobrecarga derivada de cambios de contexto y configuraciones repetidas.
- Verifica el estado final contra una fuente de verdad fresca inmediatamente antes de la ejecución para manejar de forma segura el retraso de replicación.
- Establece límites estrictos para las operaciones intensivas en memoria y define estrategias alternativas, como reconstrucciones parciales, para casos extremos.
- Asegúrate de que cualquier actualización dirigida produzca una salida idéntica a una reconstrucción completa para mantener las garantías de integridad de datos.



