Cloudflare Reduz Latência em Centenas de Milissegundos com Atualização do Smart Tiered Cache

Cloudflare introduziu um recurso de sugestão de região para seu Smart Tiered Cache, abordando um problema de roteamento que adicionava latência a falhas de cache de origens hospedadas em nuvem. A atualização permite que os operadores especifiquem a região geográfica onde as backends do AWS, GCP, Azure ou Oracle Cloud funcionam, evitando que a topologia de cache selecione uma camada superior transcontinental que roteia o tráfego de maneira ineficiente.

O Smart Tiered Cache normalmente direcionava todas as falhas de cache através do único ponto de presença (PoP) de menor latência antes que o backend recebesse a solicitação, aumentando as taxas de acerto no cache e reduzindo a contagem de conexões de origem. No entanto, os balanceadores de carga da nuvem pública muitas vezes estão por trás de frentes anycast ou unicast regionais, fazendo com que um único IP resolva para a borda mais próxima do provedor de nuvem em vez de um servidor físico específico. Cloudflare usa uma restrição baseada em física para detectar origens anycast: se sondas de dois pontos de verificação globais retornarem latências combinadas mais rápidas do que a luz poderia viajar em fibra entre esses pontos de verificação, a origem é anycast. Anteriormente, isso resultaria em uma retrocesso para uma topologia multi-nível ou um risco de escolher um PoP incorreto.

Um modo de falha específico descrito em um post no blog da empresa envolvia uma origem em Singapura por trás de um IP anycast que mediu a menor latência de Chicago, levando o Smart Tiered Cache a promover Chicago como a única camada superior. Isso resultou em usuários asiáticos sendo direcionados a Chicago, que então buscou de Singapura, adicionando um round trip transcontinental completo e centenas de milissegundos de latência extra. A solução é um menu suspenso "Definir Dica de Região" no painel, sob Configuração de Origem, que mapeia a verdadeira região de nuvem para a pegada geográfica correta e atribui camadas superiores primárias e de fallback perto do backend real.

O recurso está disponível gratuitamente em todos os planos e não requer mudanças no lado da origem. Cloudflare alega que essa mudança concentra falhas de cache em um PoP perto da origem real, resultando em menos solicitações de origem e melhores taxas de acerto do que a retrocesso multi-nível. No entanto, a empresa não fornece porcentagens específicas de taxas de acerto no cache antes e depois, deltas de contagem de conexões ou latências de busca de origem p50/p99, então os arquitetos precisarão validar esses ganhos em relação às próprias métricas e ao analítico do Cloudflare.

O desafio operacional é que a dica é estática; se uma carga de inferência migra para uma nova região de nuvem, a dica se torna obsoleta até ser atualizada. Equipes que executam réplicas de modelo multi-região devem manter a anotação de cada origem precisa para evitar reverter para ambiguidade anycast. O post no blog também apresenta a melhoria na eficiência do cache como direcional em vez de medida, então os engenheiros de plataforma devem considerar a correção da latência como provada, mas o ganho na taxa de acerto como uma hipótese para testar contra as métricas de carga no lado da origem.

A mensagem chave é parar de deixar que as sondas anycast de nível de rede substituam os mapas de implantação — anotar cada origem com sua verdadeira localização física para permitir que a camada de cache roteie de acordo.