Anycast não é alta disponibilidade: a falácia da proximidade em cenários de degradação parcial

Por Flank Manoel da Silva Especialista Sênior Full Stack | Analista de Infraestrutura e Performance

A conversa sobre Anycast nos data centers corporativos sempre segue o mesmo roteiro: “distribuir o tráfego entre múltiplos POPs reduz latência e garante disponibilidade”. Essa premissa contém uma verdade parcial que se transforma em armadilha operacional quando confrontada com cenários reais de falha.

A degradação parcial de um POP (Point of Presence) é exatamente o tipo de evento que expõe a diferença entre redução de latência média e garantia de consistência de serviço. Durante esses eventos, dois fenômenos simultâneos criam o perfeito cenário de caos operacional: clientes experienciam latência flutuante enquanto suas sessões são fragmentadas entre múltiplos nós Anycast. Isso não é teoria acadêmica, é o que os times de SRE chamam de “falha silenciosa silenciosamente letal”.

Este artigo destrói o mito de que Anycast é equivalente a alta disponibilidade, focando em três verdades operacionais que nenhum vendor menciona em seus whitepapers:

A convergência BGP não é instantânea: você tem minutos de tráfego divergente enquanto roteadores reconvergem
Consistência de sessão é sacrificada: diferentes requisições do mesmo cliente podem chegar em nós distintos
Debugging operacional se torna um pesadelo: você não consegue rastrear o fluxo real de uma transação

Sumário

O comportamento real de Anycast sob stress: simulação de falha parcial

Vamos estabelecer um cenário concreto. Uma rede Anycast com cinco POPs distribuídos globalmente (Europa Ocidental, Estados Unidos Leste, Estados Unidos Oeste, Ásia-Pacífico, Brasil) experimenta uma falha em um roteador border dentro do POP europeu. Não é uma falha total, é degradação: o POP continua respondendo, mas com latência aumentada (200ms em vez de 5ms) e perda de pacotes em 12%.

Aqui está o que acontece no primeiro minuto:

Linha do tempo de degradação (primeiros 120 segundos):

Tempo	Evento	Estado da Rede	Impacto do Usuário
T+0s	Falha de hardware no roteador	POP EU continua ativo, mas com latência	Nenhum impacto visível (tráfego ainda chega ao destino)
T+3-8s	BGP timeout e route withdrawn	Roteadores locais percebem problema; preparam reconvergência	Spike de latência observado; alguns clientes veem timeout
T+8-25s	Propagação de withdrawal BGP	ASes internacionais recebem notificação; recalculam rotas	Tráfego europeu redirecionado para outros POPs; latência 3x-5x
T+25-45s	Reconvergência completa em roteadores de tier-1	Tráfego agora flui para POPs secundários (Brasil, Asia)	Sessões HTTP/HTTPS quebram; clientes reconectam
T+45-60s	POP EU começa a recuperar (roteador backup online)	Ambos os caminhos competem (rotas antigas e novas)	Clientes oscilam entre latência alta e normal
T+60-120s	Convergência final	Sistema retorna ao estado normal (com latência residual)	Experiência degradada por 2+ minutos; perda de contexto de sessão

Este timeline não é teórico. Estudos do RIPE NCC e dados de operadores como o K-root DNS documentaram que a convergência BGP em topologias Anycast reais varia entre 5 e 45 segundos, dependendo da profundidade da árvore BGP. Durante esse período, o tráfego não desaparece, ele se redistribui de forma caótica.

Convergência BGP: por que leva tanto tempo

O BGP não é instantâneo. Essa sentença deveria estar em letras garrafais na documentação de todo serviço Anycast do mercado, mas raramente aparece antes que você já tenha um incidente.

A convergência BGP passa por três fases distintas:

Fase 1: detecção (Hold Timer) — 3 a 9 segundos

Um roteador não reconhece instantaneamente que um vizinho desapareceu. Ele espera pelo BGP Hold Timer expirar (padrão: 180 segundos, mas geralmente ajustado para 9-15 segundos em redes modernas). Apenas depois que o holddown expira é que o roteador declara a sessão morta e começa a enviar withdrawal routes.

Detalhe crítico: se você está operando um POP degradado (não totalmente morto), o hold timer pode nunca expirar porque o roteador continua recebendo keep-alives. A sessão permanece “up” do ponto de vista do BGP, mas o tráfego está sendo drenado pelas rotas ruins. Isso é pior que uma falha total porque você não sabe que está em estado degradado, seus dashboards mostram que o serviço está online.

Fase 2: disseminação de Withdrawal — 8 a 20 segundos

Depois que um roteador decide que uma rota está ruim, ele envia mensagens BGP UPDATE retirando a rota. Essas mensagens precisam alcançar todos os seus vizinhos BGP. Em uma topologia global com múltiplos ASes, uma única retirada de rota se propaga em ondas. Um roteador de tier-1 nos EUA pode não saber que a rota europeia foi retirada por 5-10 segundos após o evento original.

Pior ainda: roteadores podem ter diferentes políticas de dampening (mecanismo para evitar flapping). Se um roteador vê múltiplas oscilações (route flap), ele ativa route dampening, que aumenta artificialmente o tempo de reconvergência para evitar instabilidade. Uma única oscilação de POP pode gatilhar dampening em múltiplos pontos da rede, estendendo o tempo total de reconvergência para 60+ segundos.

Fase 3: Recalculação de Rota Local — 5 a 15 segundos

Depois que um roteador recebe a retirada, ele precisa recalcular suas próprias rotas usando o algoritmo SPF (Shortest Path First). Em redes Anycast com múltiplos POPs, essa recalculação não é trivial, o roteador precisa reavaliar políticas, preferências de rota e balanceamento de carga.

Um detalhe que a maioria dos engenheiros ignora: roteadores fazem cálculo de rota sequencialmente. Se um roteador recebe 50 retiradas de rota em rápida sequência (o que é comum durante um evento de falha em cascata), ele não processa todas em paralelo. Ele enfileira e processa uma por uma. Com algoritmo SPF O(n log n), isso pode levar até 15 segundos para uma árvore de roteamento complexa.

Dados de operadores de infraestrutura (coletados via BGP monitoring tools como Cisco CSCOpt e RIPE RIS) mostram que em topologias Anycast reais com 30+ POPs, o tempo médio de convergência completa está na faixa de 25-45 segundos, não os “5-15 segundos” que marketing menciona.

A fragmentação de sessão: o problema que BGP não resolve

Anycast roteia cada requisição independentemente. Não há “afinidade de cliente”, a primeira requisição de um cliente pode chegar no POP europeu, a segunda no POP brasileiro. Para aplicações stateless (como DNS puro), isso é aceitável. Para qualquer aplicação com estado (sessões HTTP, transações, estado de aplicação), isso é um desastre.

A autenticação fragmentada

Um usuário acessa uma plataforma de e-commerce via Anycast. Sua primeira requisição (login) é roteada para o POP europeu. O servidor europeu cria uma sessão com um token JWT, armazenando-o no cache local. A resposta volta com um Set-Cookie.

Trinta segundos depois (durante uma degradação parcial do POP europeu), a segunda requisição do usuário é roteada para o POP do Brasil. O servidor brasileiro não tem a sessão armazenada localmente, ele precisa consultá-la em um banco de dados distribuído ou cache compartilhado (Redis/Memcached). Mas:

Se o cache compartilhado está no POP europeu (que está degradado), a latência explode para 500ms+.
Se há replicação de cache, há janelas de inconsistência (rara condição de race condition).
Se a aplicação retrocede para o banco de dados, latência vai para 1-2 segundos.

O resultado: o usuário experimenta “login expirou” ou “sessão inválida”, exatamente como se o serviço estivesse completamente fora. Mas os dashboards mostram 99.9% de uptime.

Comparativo: Anycast vs. DNS Round-Robin vs. Load Balancer Centralizado

Aspecto	Anycast	DNS RR	LB Centralizado
Afinidade de sessão	Nenhuma (por padrão)	TTL-dependente (minutos)	Garantida (ou sticky)
Convergência em falha	25-45 segundos (BGP)	5+ minutos (TTL)	200-500ms (health check)
Debugging (rastrear fluxo)	Muito difícil (múltiplos POPs)	Fácil (mesmo POP por TTL)	Trivial (um ponto central)
Latência média (caso normal)	Mais baixa (rota local)	Média	Mais alta (detour)
Custo operacional	Alto (BGP expertise)	Baixo	Médio

Este quadro comparativo expõe o trade-off fundamental: Anycast ganha em latência bruta, mas perde em todos os outros critérios operacionais relevantes para “alta disponibilidade”.

O pesadelo do debugging: onde seu tráfego realmente está?

Aqui está um dos problemas menos discutidos na comunidade de operações: quando algo dá errado em uma arquitetura Anycast, você não consegue facilmente responder “por onde esse tráfego passou?”

Considere este cenário real de um grande provedor de DNS:

Um cliente reporta que suas queries DNS estão recebendo respostas incorretas. Ocasionalmente. Não é consistente. Você ativa logs em todos os seus POPs Anycast. Descobre que:

85% das queries do cliente chegam no POP europeu (esperado)
7% chegam no POP americano (explicável por reroute BGP)
8% chegam… em lugar nenhum? Os logs não mostram essas queries?

O que aconteceu? Em 8% dos casos, a query foi roteada para um POP (digamos, Brasil), o servidor respondeu, mas a resposta voltou por um caminho diferente (via Europa). O cliente recebeu a resposta do Brasil, mas seu equipamento de observabilidade não capturou porque está olhando apenas o POP europeu.

Em um load balancer centralizado, você teria um único ponto de observação. Em Anycast, você precisa correlacionar logs de múltiplos POPs, o que requer: IDs de transação únicos, sincronização de relógio entre datacenters (ntpd), e agregação de logs em tempo real. Tudo isso adiciona latência observável para seus clientes e complexidade operacional insana.

Ferramentas e técnicas reais para debugging Anycast

Se você está operando Anycast em produção, estes são os pontos de dor que você conhece bem:

Tcpdump em múltiplos POPs simultaneamente: você precisa capturar tráfego em cada POP, depois correlacionar manualmente. Com 10 POPs, você tem 10 streams de dados desincronizados. Ferramentas como Zeek IDS ou VPCs customizados podem ajudar, mas adicionar ciclo de processamento.

BGP route monitoring (RIS, RIPE collectors): Você pode ver quais rotas foram anunciadas, mas não em tempo real. RIPE atualiza seus dados a cada 8 horas. Pelo tempo que você sabe que uma rota foi retirada, o incidente já passou.

Geo-tagging de queries: Alguns operadores (Cloudflare, Akamai) usam geolocalização de IPs para inferir onde o cliente está, depois comparam com qual POP respondeu. Se o cliente está em Londres, mas a resposta veio de São Paulo, sinal de anomalia. Mas isso requer dados GeoIP precisos, que você não tem em muitos casos (VPNs, proxies corporativos).

Edns-client-subnet (ECS): Um mecanismo DNS que envia ao resolver a sub-rede real do cliente. Permite roteamento mais preciso, mas: requer suporte do cliente, reduz cache hit rates (cada subnet é um cache miss) e cria problemas de privacidade.

Onde Anycast falha silenciosamente

Caso 1: Autenticação Multi-fator com Sessão State

Um usuário inicia login MFA. Primeira requisição: “Envie código para email”. Roteada ao POP A. POP A gera um token temporário, armazena em memória local. Envie código. Usuário recebe e-mail após 2 segundos.

Enquanto isso, BGP reconverge após falha parcial. Segunda requisição: “valide este código”. Roteada ao POP B (devido ao novo estado BGP). POP B não tem o token temporário. Consulta cache distribuído, mas com latência elevada (POP A está degradado). Timeout na operação. Usuário vê erro “Session expired. Please login again.”

Você observa que ambos os POPs estão “up” nos dashboards. Nenhum alerta dispara. O usuário precisa fazer login novamente.

Caso 2: rate limiting descentralizado

Sua API tem proteção contra DDoS baseada em rate limiting. Cada POP mantém um contador local: “Cliente X fez 45 requisições no último minuto”. Quando chega a 50, o cliente é bloqueado.

Agora imagine: um cliente legítimo faz 25 requisições ao POP A (contador local = 25). BGP reconverge. As próximas 25 requisições vão ao POP B (contador local = 0, porque é um novo POP). Cliente chega a 50 requisições totais, mas cada POP só vê 25. Resultado: cliente não é rate-limited, enquanto um atacante explorador de múltiplos POPs pode contornar a proteção.

Em um sistema centralizado com rate limiting global, isso não acontece. Você sacrificaria latência, mas ganharia consistência de segurança.

Caso 3: cache warming e sincronização falha

Você deploua uma atualização de conteúdo (digamos, uma nova versão de um certificado SSL ou um cache de dados críticos). Você envia o comando “warm cache” para todos os POPs. Cada POP reconhece com sucesso: “cache warm OK”.

Mas enquanto você está aquecendo o cache do POP D, BGP reconverge e o tráfego que seria para D é redirecionado para E. POP E nunca recebeu o comando de aquecimento. Agora seus usuários estão experimentando cache miss, causando latência anormalmente alta por 10-15 minutos até que o cache seja reconstruído organicamente.

Isso é especialmente crítico para serviços de origem alta (imagens, vídeos, objetos grandes). Uma falha silenciosa de sincronização causa cascata de cache misses que se propaga em toda a rede.

Métricas reais: o que os operadores medem

Operadores de infraestrutura global (com base em trabalhos publicados pela RIPE, APNIC, e relatórios internos de ISPs) medem regularmente o que chamam de “Quality of Experience” em Anycast. Aqui estão as métricas que importam:

Métrica	Caso Normal	Degradação Parcial POP	Implicação
Latência p99	45ms	180ms	4x degradação visível para power users
Convergência BGP	N/A	25-45 segundos	Janela de 45s com tráfego malformado
Taxa de erro (timeout)	0.01%	2-5%	Afeta 1 em 20-50 requisições
Fragmentação de sessão	~1%	15-30%	Múltiplos POPs veem mesmo cliente
Jitter (variação latência)	±5ms	±50ms	Experiência “floppy”; buffers de app desabam

Note o padrão: durante a degradação parcial, não é que o serviço fica “down”. É que ele fica inconsistente. Aplicações que esperavam consistência (mesmo POP = mesma sessão) quebram silenciosamente.

Alternativas práticas: quando não usar Anycast

Para serviços stateless (DNS, NTP, SNMP)

Anycast continua excelente. Cada query é independente. Não há estado compartilhado. O único problema é debugging (você não sabe de qual POP veio a resposta), mas para disponibilidade pura, funciona.

Para APIs com estado (autenticação, sessões)

Preferir: Load balancer centralizado com failover redundante. Tradeoff: latência +10-20ms, mas consistência garantida. Se você precisa de múltiplos datacenters, use DNS com TTL baixo (30–60 segundos) + sticky sessions.

Para serviços híbridos (parcialmente stateless)

Use Anycast para roteamento de borda, mas com “session pinning” aplicado na camada de aplicação. Exemplo: em DNS, você roteia queries para POPs via Anycast, mas usa EDNS-client-subnet + uma lógica de afinidade interna para evitar que o mesmo cliente seja fragmentado entre POPs durante 60 segundos.

Implementação real (usada por operadores grandes): cada POP roda um “consistent hasher” local que mapeia cliente para “home POP”. Se a query chega em um POP que não é o home, o POP redireciona via anycast interno. Não é perfeito (ainda há overhead de redirecionamento), mas reduz fragmentação de 30% para <5%.

Operacionalização: como mitigar os problemas que ninguém avisa

1. BGP Monitoring em Tempo Real

Não use apenas RIPE RIS (que atualiza a cada 8 horas). Implemente BGP exabgp ou similar para monitorar rotas localmente. Configure alerta para:

Retirada de rota (withdrawal) detectada
Route flap (rota anunciada/retirada mais de 5x em 5 minutos)
AS path lengthening (rota agora requer mais hops do que antes)

Tempo de resposta: você sabe em 2-5 segundos que uma anomalia ocorreu, antes que seus clientes vejam impacto.

2. Session Affinity na camada de aplicação

Se você usa Anycast mas precisa de estado, implemente: cookie-based routing que mapeia cliente para “servidor preference”. Exemplo em nginx:

map $cookie_preferred_server $backend { ~*^server_a server.a.pop; ~*^server_b server.b.pop; default server.closest.pop; }

Isso força que requisições subsequentes do mesmo cliente vão sempre para o mesmo POP (ou pelo menos o mesmo “grupo” de POPs). Reduz fragmentação de sessão de 30% para <3%.

3. Proactive load balancing entre POPs

Não espere Anycast + BGP fazer tudo. Implemente health checks ativos entre POPs. Se um POP está degradado (latência > 100ms, loss > 5%), reduza o peso seu anúncio BGP manualmente (via local-preference ou multi-exit discriminator).

Ferramentas: ExaBGP + scripts custom podem ajustar local-preference baseado em métricas de saúde. Exemplo: se latência ao POP A > 150ms por 30 segundos, reduz local-preference de 100 para 50. Isso force BGP a preferir outros POPs, mesmo que A continue “up”.

4. Distributed session store com replicação forte

Redis com replicação cruzada entre POPs. Não eventual consistency, use Redis + Lua scripting para garantir que quando a sessão é criada em POP A, é replicada sincronicamente para B e C. Aumenta latência em ~50ms, mas elimina 99% dos problemas de fragmentação.

O teste de realidade: Anycast em cenário de cascata de falha

Vamos simular um cenário pior: não é apenas um POP degradado. É um evento em cascata.

T+0s: Um ISP major (digamos, Cogent ou Level3) experiencia congestão. Começa a redirecionar tráfego para caminhos alternativos via BGP.

T+5s: Múltiplos POPs veem aumento simultâneo de tráfego (redirecionado por BGP). Seus CPU/memory disparam.

T+10s: Um POP (por exemplo, POP4) atinge limite de CPU, começa a descartar pacotes. BGP timeout começa.

T+15s: POP4 é removido das rotas Anycast. BGP dissemina retirada.

T+20s: Tráfego de POP4 é redirecionado para POP5. POP5 agora recebe 2x seu tráfego normal. Começa a degradar.

T+30s: POP5 também começa a descartar pacotes. Sistema entra em cascata. Tráfego oscila entre múltiplos POPs enquanto cada um degrad.

Resultado: o serviço “não está down”, mas “está inutilizável”. Você tem tráfego viajando, mas com perdas severas (15-30%), latência anormalmente alta (500ms+), e fragmentação de sessão total. Um health check simples baseado em “ping” não detecta isso porque o POP ainda responde, está apenas degradado.

Em um sistema centralizado com load balancer, o LB detectaria que os backends estão unhealthy e stoparia de enviar tráfego. Em Anycast puro, não há nada para parar, o BGP continua anunciando a rota porque o roteador continua “up”.

Conclusão: Anycast é uma ferramenta, não uma solução de alta disponibilidade

Anycast é uma ferramenta extraordinária para reduzir latência em serviços globais, especialmente serviços stateless como DNS. Mas a equação “Anycast = Alta Disponibilidade” é matematicamente falsa.

O que Anycast oferece: redução de latência média (talvez 40–60% melhor que um load balancer centralizado).

O que Anycast NÃO oferece: consistência de sessão, convergência rápida em falha (25–45 segundos é ainda muito tempo), ou debugging simplificado.

A verdade não dita pelas apresentações de vendor: Anycast melhora o comportamento médio do sistema, mas degrada o comportamento em cauda (tail latency, falhas parciais, cenários de cascata).

Se você está considerando Anycast para sua infraestrutura, faça estas perguntas antes:

Seu serviço é verdadeiramente stateless? (Se não, Anycast não é para você)
Você consegue aceitar latência de 25–45 segundos durante reconvergência BGP? (Se não, você precisa de health checks ativos)
Você tem expertise em operações de BGP, debugging distribuído, e monitoramento de rede? (Se não, o custo oculto de operação é enorme)
Seu SLA permite oscilação de latência de 3-5x durante falhas parciais? (Provavelmente não)

Se respondeu “não” a qualquer uma dessas perguntas, um híbrido (Anycast + sticky sessions + health checks ativos + session affinity) é essencial. Ou simplesmente use um load balancer centralizado robusto com failover, você sacrifica 15-20ms de latência, mas ganha previsibilidade operacional que vale muito mais.

A história não é “Anycast é ruim”. É: “Anycast é excelente para um contexto específico e desastroso fora dele”. Marketing raramente menciona essa nuance.