A Cloudflare redesenhou seu pipeline de propagação de DNS para lidar de forma mais eficiente com um fluxo crescente de alterações em registros e configurações de zonas. O Zone Builder agora recebe cerca de 700 alterações de registros DNS por segundo, além de aproximadamente 100 outros eventos, enquanto algumas zonas contêm mais de 20 milhões de registros e devem crescer ainda mais.
O principal problema não era a quantidade de eventos, mas o volume de trabalho exigido por determinadas alterações. Antes, um evento de configuração de zona podia acionar uma reconstrução completa: ler cada registro, convertê-lo em chaves do Quicksilver e comparar o resultado com o estado existente. Essa abordagem tornou-se cada vez mais dispendiosa para zonas grandes e podia exigir mais memória do que a disponível.
A Cloudflare criou um planejador de compilação direcionado que seleciona a menor operação cuja segurança possa comprovar. Um agendador unificado então combina o trabalho pendente para a mesma zona. Dependendo da alteração, o sistema pode reconstruir nomes DNS específicos, atualizar esses nomes junto com metadados compartilhados, reconstruir o apex da zona e os metadados, eliminar uma zona ou executar uma compilação completa da zona.
Alterações comuns de registros, como atualizações em registros A, AAAA, TXT e CNAME, geralmente afetam apenas as chaves correspondentes aos nomes DNS relevantes. Alterações em servidores de nomes e curingas também podem afetar metadados compartilhados, enquanto configurações como Universal SSL podem exigir a reconstrução do apex e desses metadados. Quando o sistema não consegue estabelecer que uma operação menor produzirá exatamente o mesmo resultado de uma compilação completa, ele mantém o caminho de compilação completa.
O planejador depende de eventos mais detalhados dos sistemas que produzem alterações nas zonas. Esses eventos incluem configurações alteradas e, quando disponíveis, seus valores anterior e novo. Eventos ambíguos, informações ausentes e atualizações que possam afetar registros em toda a zona continuam acionando uma compilação completa, em vez de correr o risco de deixar dados desatualizados na borda.
A Cloudflare também precisou considerar domínios que temporariamente possuem vários objetos internos de zona. As chaves de registros são armazenadas separadamente para cada zona, enquanto uma chave de metadados compartilhada identifica quais zonas com o mesmo nome podem ser publicadas. Quando esses metadados estão envolvidos, o builder lê a lista atual de candidatos e reconstrói a chave a partir do estado atualizado, em vez de aplicar um patch a uma versão antiga.
O planejamento ocorre duas vezes porque o banco de dados pode mudar depois que um evento é gerado. Imediatamente antes da execução, o Zone Builder verifica as configurações atuais, o status de publicação para a rede relevante e a lista mais recente de IDs de zonas com o mesmo nome. Isso pode transformar uma operação direcionada em uma compilação completa, convertê-la em uma eliminação, ignorá-la ou exigir a reconstrução da chave de metadados compartilhada.
O agendador combina alterações pendentes para uma zona, adicionando os nomes afetados e preservando os requisitos de metadados. Uma eliminação tem precedência sobre as operações de reconstrução. As confirmações do Kafka são acompanhadas separadamente do trabalho de DNS, garantindo que as tentativas novamente não percam mensagens, mesmo quando vários eventos são combinados em uma única compilação.
Para proteger o processamento ordenado do Kafka, a Cloudflare usa confirmações flexíveis. Uma compilação concluída pode ser registrada na memória antes que o trabalho anterior na mesma partição termine, mas o deslocamento confirmado do Kafka só avança depois que todas as mensagens precedentes são concluídas. Se o builder for reiniciado, essas conclusões armazenadas na memória serão reproduzidas, em vez de se correr o risco de perder uma alteração.
Para zonas muito grandes, o sistema evita escalar para uma compilação completa acima de um limite fixo de quantidade de registros, porque manter todos os registros e as chaves existentes do Quicksilver na memória pode impedir a conclusão da compilação. Em vez disso, ele reconstrói o apex, os metadados e os nomes identificados pelos eventos enfileirados. Essa abordagem reduz o risco de que uma única compilação impossível de concluir bloqueie outras alterações na mesma partição do Kafka.
A Cloudflare testou compilações direcionadas contra compilações completas usando comparações byte a byte das chaves relevantes do Quicksilver. Também implantou um Zone Builder espelho que consumia eventos de produção e o estado do banco de dados enquanto gravava em um ambiente isolado do Quicksilver. Um comparador verificou uma amostra de zonas em busca de chaves ausentes, chaves adicionais e valores diferentes antes que o novo agendador fosse implementado progressivamente.
As mudanças resultantes reduziram as compilações completas em 40%, diminuíram o uso máximo de memória em 85% e reduziram pela metade o atraso entre uma alteração de DNS e a gravação de seus dados no Quicksilver. Durante um período de medição de 24 horas, 86,81% das compilações foram classificadas como operações somente de recursos, enquanto 2,54% reconstruíram recursos junto com metadados.
Fontes: Cloudflare Blog.