Balanceamento de carga por DNS: métodos e limitações

O balanceamento de carga por DNS distribui as requisições retornando um ou mais endereços para um nome de host, às vezes selecionando respostas diferentes conforme a localização, a saúde ou uma política. Ele pode espalhar o tráfego entre regiões, direcionar os usuários para a infraestrutura mais próxima e oferecer uma camada simples de failover. O comportamento exato depende do provedor de DNS e dos caches dos resolvedores. As respostas DNS padrão não são reavaliadas a cada requisição HTTP, então uma decisão tomada quando um resolvedor atualiza o cache pode continuar valendo até o TTL expirar. Isso torna o DNS útil para direcionar o tráfego de forma ampla, mas diferente de um balanceador de carga que avalia cada nova conexão em tempo real.

Estratégias comuns de distribuição por DNS

O round-robin pode girar a ordem dos endereços dentro de um conjunto. O DNS geográfico ou baseado em latência pode retornar endpoints regionais com base na localização aparente de um resolvedor recursivo. O roteamento ponderado pode favorecer um endpoint em relação a outro, o que é útil para implantações controladas ou alocação de capacidade. Configurações de failover podem deixar de retornar um endpoint depois que um health check detecta um problema. Cada recurso tem detalhes específicos do provedor: intervalos de health check, limites de falha, inferência da localização do resolvedor e comportamento do TTL afetam o que os usuários finais veem. Leia o guia de implementação do provedor e teste a partir de redes representativas antes de depender desse comportamento.

A localização do resolvedor é uma sutileza importante. Um serviço de DNS com recursos geográficos geralmente enxerga o endereço do resolvedor recursivo, e não o do dispositivo do usuário. O EDNS Client Subnet pode fornecer contexto adicional de localização em alguns sistemas, mas não é enviado universalmente e traz questões de privacidade. Como resultado, um único resolvedor público pode representar muitos usuários e receber uma única resposta regional em nome deles. Observar respostas DNS diferentes em locais distintos é esperado em algumas implantações, mas isso não prova que um visitante específico foi roteado para o servidor físico mais próximo.

As decisões de DNS ficam em cache

O TTL de um registro DNS define por quanto tempo um resolvedor pode guardar uma resposta em cache antes de atualizá-la. TTLs menores podem fazer mudanças planejadas aparecerem mais cedo depois que os caches expiram, mas aumentam o volume de consultas e não garantem propagação instantânea. Um resolvedor pode usar uma resposta já em cache até o fim do tempo de vida restante, e as aplicações podem ter seu próprio cache ou conexões persistentes. Se um endpoint falhar, o failover baseado em DNS pode, portanto, ser mais lento do que remover o endpoint dentro de um balanceador de carga que acompanha as conexões. Considere tanto o tempo crítico de recuperação quanto as camadas de cache esperadas antes de escolher o DNS como único mecanismo de failover.

• Defina o que torna um endpoint saudável e teste todo o caminho da aplicação.
• Verifique como o provedor avalia a geografia dos resolvedores e o status de saúde.
• Defina os TTLs conforme as necessidades operacionais, e não pela crença de que quanto menor, melhor.
• Use um balanceador de carga de aplicação ou de rede para decisões rápidas de conexão que considerem a saúde.
• Monitore os usuários a partir de várias regiões para detectar diferenças de roteamento.

Planeje e valide mudanças de tráfego

Antes de uma mudança de tráfego, confirme que todos os destinos estão prontos para servir o mesmo nome de host, certificado e comportamento da aplicação. Faça uma mudança gradual onde o provedor oferecer ponderação, inspecione logs e taxas de erro e só aumente o tráfego quando os resultados estiverem saudáveis. Para o rollback, saiba por quanto tempo os caches podem reter a resposta anterior e mantenha o ambiente antigo funcional durante essa janela. Não dependa de uma única consulta DNS para confirmar a porcentagem de usuários reais que chega a cada backend; use a telemetria do serviço, as análises do provedor ou sondas controladas que reproduzam os caminhos reais dos clientes.

O DNS é um plano de controle global eficaz quando seus pontos fortes e sua latência são compreendidos. Ele complementa, e não substitui, os balanceadores de carga e os health checks da aplicação. Leia DNS round-robin explicado para o modelo mais simples de conjunto de endereços e TTL de DNS explicado para entender o comportamento do cache. Uma consulta DNS pública mostra o que um resolvedor consegue obter em um momento; as equipes de operações devem combinar essa evidência com o monitoramento real de conexões e da aplicação ao avaliar se o tráfego está chegando à infraestrutura saudável.

Meça a experiência do usuário na camada da aplicação

Uma política de DNS só tem sucesso se melhorar o serviço que os usuários de fato recebem. Acompanhe a latência, as taxas de erro e a disponibilidade no endpoint da aplicação em cada região e compare essas métricas com as respostas DNS que o provedor está retornando. O resolvedor mais próximo nem sempre é o usuário mais próximo, e o servidor mais próximo nem sempre é o menos carregado ou o mais saudável. Inclua verificações sintéticas a partir de redes representativas, mas revise também a telemetria do tráfego real em busca de valores atípicos. Se uma política de roteamento envia os usuários a uma região não saudável, ajuste o sinal de saúde ou o fallback, em vez de apenas mudar o TTL. Uma implantação bem instrumentada dá aos operadores evidências de como a ponderação e a seleção regional se comportam em condições reais de cache.