Cloudflare ha rediseñado su canalización de propagación de DNS para gestionar de forma más eficiente un flujo creciente de cambios en registros y configuraciones de zonas. Ahora, Zone Builder recibe aproximadamente 700 cambios de registros DNS por segundo, además de unos 100 eventos adicionales, mientras que algunas zonas contienen más de 20 millones de registros y se espera que sigan creciendo.
El problema principal no era la cantidad de eventos, sino el trabajo necesario para ciertos cambios. Antes, un evento de configuración de zona podía activar una reconstrucción completa: leer todos los registros, convertirlos en claves de Quicksilver y comparar el resultado con el estado existente. Este enfoque se volvió cada vez más costoso para las zonas grandes y podía requerir más memoria de la disponible.
Cloudflare desarrolló un planificador de compilación específico que selecciona la operación más pequeña cuya seguridad puede demostrar. A continuación, un programador unificado combina el trabajo pendiente de una misma zona. Según el cambio, el sistema puede reconstruir nombres DNS concretos, actualizar esos nombres junto con metadatos compartidos, reconstruir el ápice de la zona y los metadatos, purgar una zona o realizar una compilación completa de la zona.
Los cambios habituales en los registros, como las actualizaciones de registros A, AAAA, TXT y CNAME, generalmente afectan únicamente a las claves correspondientes a los nombres DNS pertinentes. Los cambios en servidores de nombres y comodines también pueden afectar a los metadatos compartidos, mientras que configuraciones como Universal SSL pueden requerir reconstruir el ápice y esos metadatos. Cuando el sistema no puede establecer que una operación más pequeña producirá exactamente el mismo resultado que una compilación completa, conserva la ruta de compilación completa.
El planificador depende de eventos más detallados procedentes de los sistemas que generan cambios en las zonas. Estos eventos incluyen las configuraciones modificadas y, cuando están disponibles, sus valores anteriores y nuevos. Los eventos ambiguos, la información ausente y las actualizaciones que podrían afectar a registros de toda la zona siguen activando una compilación completa, en lugar de arriesgarse a dejar datos obsoletos en el borde.
Cloudflare también tuvo que tener en cuenta los dominios que temporalmente cuentan con varios objetos internos de zona. Las claves de registros se almacenan por separado para cada zona, mientras que una clave de metadatos compartidos identifica qué zonas con el mismo nombre pueden publicarse. Cuando intervienen esos metadatos, el compilador lee la lista actual de candidatos y reconstruye la clave a partir del estado actualizado, en lugar de aplicar un parche a una versión anterior.
La planificación se realiza dos veces porque la base de datos puede cambiar después de generarse un evento. Inmediatamente antes de la ejecución, Zone Builder comprueba las configuraciones actuales, el estado de publicación para la red pertinente y la última lista de identificadores de zonas con el mismo nombre. Esto puede convertir una operación específica en una compilación completa, transformarla en una purga, omitirla o exigir la reconstrucción de la clave de metadatos compartidos.
El programador fusiona los cambios pendientes de una zona, añade los nombres afectados y conserva los requisitos de metadatos. Una purga tiene prioridad sobre las operaciones de reconstrucción. Las confirmaciones de Kafka se siguen por separado del trabajo de DNS, lo que garantiza que los reintentos no pierdan mensajes incluso cuando varios eventos se han combinado en una sola compilación.
Para proteger el procesamiento ordenado de Kafka, Cloudflare utiliza confirmaciones diferidas. Una compilación completada puede registrarse en memoria antes de que termine el trabajo anterior de la misma partición, pero el desplazamiento confirmado de Kafka solo avanza después de que se hayan completado todos los mensajes precedentes. Si el compilador se reinicia, esas finalizaciones almacenadas en memoria se reproducen, en lugar de arriesgarse a perder un cambio.
En el caso de las zonas muy grandes, el sistema evita escalar a una compilación completa por encima de un umbral fijo de cantidad de registros, porque mantener todos los registros y las claves de Quicksilver existentes en memoria podría impedir que la compilación terminara. En su lugar, reconstruye el ápice, los metadatos y los nombres identificados por los eventos en cola. Este enfoque reduce el riesgo de que una compilación imposible de finalizar bloquee otros cambios en la misma partición de Kafka.
Cloudflare probó las compilaciones específicas frente a las compilaciones completas mediante comparaciones byte por byte de las claves pertinentes de Quicksilver. También desplegó un Zone Builder espejo que consumía eventos de producción y el estado de la base de datos mientras escribía en un entorno aislado de Quicksilver. Antes de desplegar progresivamente el nuevo programador, un comparador comprobó una muestra de zonas en busca de claves ausentes, claves adicionales y valores diferentes.
Los cambios resultantes redujeron las compilaciones completas en un 40 %, disminuyeron en un 85 % el uso máximo de memoria y redujeron a la mitad el retraso entre un cambio de DNS y la escritura de sus datos en Quicksilver. Durante un periodo de medición de 24 horas, el 86,81 % de las compilaciones se clasificaron como operaciones únicamente de recursos, mientras que el 2,54 % reconstruyó recursos junto con metadatos.
Fuentes: Cloudflare Blog.