CDN: distribuindo conteúdo globalmente

1. Fundamentos de uma CDN na Arquitetura de Software

1.1 Definição e papel arquitetural

Uma CDN (Content Delivery Network) é, em essência, um proxy reverso geograficamente distribuído. Seu papel arquitetural é aproximar o conteúdo do usuário final, reduzindo latência e aliviando a carga no servidor de origem. Na prática, a CDN atua como uma camada de cache global que intercepta requisições HTTP e responde com conteúdo previamente armazenado ou dinamicamente gerado nos pontos de presença (PoPs) mais próximos do cliente.

1.2 Componentes principais

Os componentes arquiteturais de uma CDN incluem:

  • PoPs (Points of Presence): Data centers distribuídos globalmente que hospedam servidores de borda.
  • Servidores de borda (edge servers): Máquinas que armazenam cache, executam lógica de roteamento e realizam terminação SSL.
  • DNS anycast: Mecanismo que resolve o domínio da CDN para o IP do PoP mais próximo, baseado em roteamento BGP.
  • Servidor de origem (origin): O backend principal que armazena o conteúdo original e é consultado apenas quando ocorre cache miss.

1.3 Diferenças entre CDN para conteúdo estático vs. dinâmico

Conteúdo estático (imagens, CSS, JS, vídeos) é ideal para cache de longa duração. Já o conteúdo dinâmico (páginas personalizadas, APIs) requer estratégias como edge-side includes (ESI) ou cache de consultas com TTL curto. A CDN para conteúdo dinâmico precisa de comunicação contínua com a origem, usando conexões persistentes e roteamento otimizado.

# Exemplo: Configuração de cache para conteúdo estático vs. dinâmico
# CDN (ex: Cloudflare Workers ou Varnish config)

# Conteúdo estático: cache por 7 dias
if (url.path ~ "\.(jpg|png|css|js)$") {
    set ttl = 604800;  # 7 dias
    set cache-control = "public, max-age=604800";
}

# Conteúdo dinâmico: cache por 60 segundos
if (url.path ~ "^/api/") {
    set ttl = 60;
    set cache-control = "public, max-age=60";
}

2. Estratégias de Cache e TTL em CDNs

2.1 Políticas de cache

As três situações principais são:

  • Cache hit: O conteúdo está no PoP e é servido diretamente (baixa latência).
  • Cache miss: O conteúdo não está em cache; a borda busca na origem, armazena e responde.
  • Cache stampede: Múltiplas requisições simultâneas para um recurso expirado podem sobrecarregar a origem. Soluções incluem bloqueio distribuído (locking) e grace mode (servir conteúdo expirado enquanto atualiza).

2.2 Gerenciamento de TTL e invalidação

O TTL define por quanto tempo o conteúdo permanece em cache. A invalidação pode ser feita por:

  • Purga (purge): Remove manualmente um recurso específico do cache.
  • Versão (versioning): Altera o nome do arquivo (ex: style.v2.css) para forçar cache miss.
# Exemplo: Invalidação por versão vs. purga
# Versão: URL com hash
https://cdn.exemplo.com/assets/style.a1b2c3.css

# Purga via API (ex: Cloudflare)
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
     -H "Authorization: Bearer TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"files":["https://cdn.exemplo.com/style.css"]}'

2.3 Cache de conteúdo dinâmico

Para conteúdo dinâmico, técnicas como:

  • Edge-side includes (ESI): Permite cachear partes estáticas de uma página (cabeçalho, rodapé) enquanto o conteúdo dinâmico é montado na borda.
  • Cache de consultas: Resultados de APIs podem ser cacheados por poucos segundos, desde que a tolerância a dados obsoletos seja aceitável.

3. Roteamento e Distribuição de Conteúdo

3.1 Algoritmos de seleção de PoP

Os provedores de CDN usam algoritmos que consideram:

  • Latência mínima: Mede o tempo de ida e volta (RTT) para cada PoP.
  • Geolocalização: Direciona o usuário ao PoP mais próximo geograficamente.
  • Carga do servidor: Evita PoPs sobrecarregados, distribuindo o tráfego uniformemente.

3.2 DNS anycast vs. HTTP redirecionamento

  • DNS anycast: Um único IP é anunciado por múltiplos PoPs; o roteamento BGP leva o tráfego ao PoP mais próximo. É transparente para o cliente e eficiente.
  • HTTP redirecionamento: O DNS resolve para um balanceador central que redireciona o cliente (302) para o PoP ideal. Oferece mais controle, mas adiciona latência.

3.3 Balanceamento de carga entre servidores de borda

Dentro de um PoP, múltiplos servidores de borda compartilham a carga. Em caso de falha, o tráfego é redirecionado automaticamente para servidores vizinhos ou PoPs alternativos.

# Exemplo: Configuração de failover regional (DNS-based)
# Registro DNS com múltiplos IPs
cdn.exemplo.com.   IN A  203.0.113.10   # PoP América do Norte
cdn.exemplo.com.   IN A  198.51.100.20  # PoP Europa
cdn.exemplo.com.   IN A  192.0.2.30     # PoP Ásia

# Prioridade: health check automático remove IPs com falha

4. Segurança e Proteção contra Ataques

4.1 Mitigação de DDoS na borda

A CDN absorve ataques DDoS distribuindo o tráfego malicioso entre milhares de servidores. Técnicas incluem:

  • Rate limiting: Limita requisições por IP.
  • Filtragem por assinatura: Bloqueia padrões de ataque conhecidos.
  • Anycast de absorção: O ataque é diluído entre múltiplos PoPs.

4.2 Autenticação de origem

Para garantir que apenas a CDN acesse a origem:

  • Tokens de autenticação: A CDN adiciona um header secreto (ex: X-Auth-Token) nas requisições à origem.
  • Assinaturas de URL: URLs com parâmetros criptografados que expiram.
  • IP whitelist: A origem só aceita tráfego dos IPs da CDN.
# Exemplo: URL assinada (AWS CloudFront)
# URL original: https://cdn.exemplo.com/video.mp4
# URL assinada: https://cdn.exemplo.com/video.mp4?Expires=1700000000&Signature=abc123

4.3 HTTPS e terminação SSL/TLS no edge

A terminação SSL na borda reduz a carga na origem, mas exige cuidado com a segurança do tráfego entre CDN e origem (origin pull). Pode-se usar:

  • Full SSL (strict): Certificado válido também na origem.
  • Flexible SSL: Tráfego criptografado até a CDN, mas HTTP puro para a origem (menos seguro, mas mais rápido).

5. Otimização de Performance e Entrega

5.1 Compressão e minificação

CDNs modernas aplicam compressão automática:

  • gzip/brotli: Reduzem o tamanho de arquivos de texto em até 70%.
  • Minificação: Remove espaços e comentários de CSS/JS.

5.2 HTTP/2 e HTTP/3 (QUIC)

  • HTTP/2: Multiplexação de requisições em uma única conexão TCP, reduzindo head-of-line blocking.
  • HTTP/3 (QUIC): Baseado em UDP, elimina o head-of-line blocking do TCP e reduz latência em redes instáveis.

5.3 Aceleração de conteúdo dinâmico

Para conteúdo dinâmico, a CDN pode usar:

  • Rota otimizada: Roteia o tráfego pela internet pública, mas por caminhos de menor latência.
  • Conexões persistentes: Mantém conexões TCP abertas entre a borda e a origem, reduzindo handshakes.

6. Integração com Outros Padrões Arquiteturais

6.1 CDN como parte de uma arquitetura de microsserviços

Em microsserviços, a CDN pode atuar como gateway de borda, cacheando respostas de APIs de leitura e redirecionando requisições de escrita para os serviços corretos. Funções serverless na borda (Cloudflare Workers, Lambda@Edge) permitem executar lógica de negócio próxima ao usuário.

6.2 Relação com filas e workers

Conteúdo gerado sob demanda (ex: thumbnails de vídeo) pode ser enfileirado. A CDN, ao receber um cache miss, dispara um worker que gera o conteúdo e o armazena na borda, enquanto o usuário aguarda ou recebe uma resposta assíncrona.

6.3 CDN e escalabilidade

A CDN reduz drasticamente a carga no servidor de origem. Em eventos de pico (Black Friday, lançamentos), a origem precisa processar apenas cache misses, enquanto a CDN absorve a maior parte do tráfego.

# Exemplo: Arquitetura com CDN e origem escalável
# Fluxo de requisição:
# 1. Usuário -> CDN (cache hit) -> resposta imediata
# 2. Usuário -> CDN (cache miss) -> origem -> CDN -> resposta
# A origem escala horizontalmente apenas para os misses

7. Monitoramento, Custos e Governança

7.1 Métricas-chave

  • Taxa de acerto de cache (cache hit ratio): Percentual de requisições servidas do cache. Ideal acima de 90%.
  • Latência: Tempo de resposta médio por PoP.
  • Taxa de transferência: Volume de dados servidos (Gbps).

7.2 Modelos de precificação

  • Por tráfego: Custo por GB transferido.
  • Por requisições: Custo por número de requisições HTTP.
  • Funcionalidades avançadas: Custo adicional para edge computing, WAF, ou suporte premium.

7.3 Estratégias de multi-CDN e failover

Para resiliência global, muitas empresas adotam múltiplas CDNs (ex: Cloudflare + Akamai). Um balanceador DNS ou um roteador de tráfego (ex: Cedexis) decide qual CDN usar com base em desempenho em tempo real.

# Exemplo: Configuração de multi-CDN com failover DNS
# Provedor primário: Cloudflare
cdn.primario.exemplo.com.   IN A  104.16.0.1
# Provedor secundário: Fastly
cdn.secundario.exemplo.com.  IN A  151.101.0.1
# Balanceador DNS escolhe com base em health check

Referências