Multi-region deployment: alta disponibilidade global

1. Fundamentos da Arquitetura Multi-região

A arquitetura multi-região consiste em distribuir a infraestrutura de uma aplicação em duas ou mais regiões geográficas distintas. O objetivo principal é garantir alta disponibilidade global, tolerância a falhas catastróficas (como desastres naturais ou falhas completas de um provedor de nuvem), baixa latência para usuários distribuídos e conformidade com regulamentações de residência de dados.

Existem três modelos principais de implantação:

  • Ativo-Passivo: Uma região principal processa todo o tráfego. A região secundária permanece em espera, recebendo réplicas de dados, mas sem servir requisições. Em caso de falha, o tráfego é redirecionado para a região passiva.
  • Ativo-Ativo: Todas as regiões processam tráfego simultaneamente. Requer estratégias sofisticadas de sincronização de dados e resolução de conflitos.
  • Híbrido: Combina elementos dos dois modelos. Por exemplo, uma região ativo-ativo para leituras e ativo-passivo para escritas.

O teorema CAP impõe um trade-off fundamental: em sistemas distribuídos multi-região, não é possível garantir simultaneamente Consistência, Disponibilidade e Tolerância a Partições. A maioria das arquiteturas globais opta por disponibilidade e tolerância a partições (AP), sacrificando consistência forte em favor de consistência eventual.

2. Estratégias de Roteamento e Balanceamento de Carga Global

O roteamento global de tráfego é implementado através de DNS com geo-routing. Serviços como AWS Route53 e Cloudflare DNS permitem configurar políticas baseadas em geolocalização, latência ou peso.

Exemplo de configuração Route53 com failover:

Registro A - primary.seudominio.com
  - Região: us-east-1
  - Health check: endpoint /health
  - Failover: PRIMARY

Registro A - secondary.seudominio.com  
  - Região: eu-west-1
  - Health check: endpoint /health
  - Failover: SECONDARY

O Anycast é uma técnica onde o mesmo endereço IP é anunciado de múltiplas localizações, roteando o usuário para o ponto mais próximo. Balanceadores de carga globais (GLB) como o Google Cloud Load Balancer ou AWS Global Accelerator utilizam Anycast para distribuir tráfego com baixa latência.

Políticas de failover automático incluem:
- Baseado em latência: Roteia para a região com menor tempo de resposta
- Baseado em peso: Distribui tráfego proporcionalmente entre regiões
- Baseado em geolocalização: Direciona usuários para a região mais próxima

3. Sincronização e Consistência de Dados entre Regiões

A replicação de dados entre regiões pode ser síncrona ou assíncrona. Replicação síncrona garante consistência forte, mas aumenta a latência. Replicação assíncrona oferece melhor desempenho, mas com risco de perda de dados em failover.

Exemplo de configuração de replicação assíncrona PostgreSQL:

-- Região primária (us-east-1)
CREATE PUBLICATION pub_global FOR ALL TABLES;

-- Região secundária (eu-west-1)
CREATE SUBSCRIPTION sub_global 
CONNECTION 'host=primary-endpoint dbname=mydb user=replicator'
PUBLICATION pub_global;

Para bancos de dados NoSQL, o Cassandra oferece replicação multi-região nativa com configuração de consistência por operação:

CREATE KEYSPACE mykeyspace 
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'us-east-1': 3,
  'eu-west-1': 3
};

Estratégias de cache distribuído incluem Redis Global com replicação ativo-passivo e CDNs para conteúdo estático. A invalidação de cache cross-region é desafiadora e frequentemente resolvida com TTLs curtos ou sistemas de mensageria.

Para tratamento de conflitos, as abordagens incluem:
- CRDTs (Conflict-free Replicated Data Types): Estruturas de dados que resolvem conflitos automaticamente
- LWW (Last Writer Wins): A última escrita vence, baseada em timestamp
- Resolução manual: Conflitos são registrados para intervenção humana

4. Design de Aplicações Stateless e Stateful para Resiliência

Aplicações stateless são ideais para multi-região, pois qualquer instância pode atender qualquer requisição. O estado deve ser externalizado:

// Exemplo de sessão em Redis (stateless)
const session = await redis.get(sessionId);
if (!session) {
  // Criar nova sessão no Redis global
  await redis.set(sessionId, userData, 'EX', 3600);
}

Para componentes stateful, padrões de idempotência são essenciais:

// Idempotência com token único
async function processPayment(orderId, amount, idempotencyKey) {
  const existing = await redis.get(`idempotency:${idempotencyKey}`);
  if (existing) return JSON.parse(existing);

  const result = await paymentGateway.charge(orderId, amount);
  await redis.set(`idempotency:${idempotencyKey}`, JSON.stringify(result));
  return result;
}

Filas distribuídas como SQS ou Kafka proporcionam tolerância a falhas regionais. Mensagens não processadas em uma região podem ser redirecionadas para outra:

// Configuração de DLQ cross-region
{
  "QueueName": "orders-queue",
  "RedrivePolicy": {
    "deadLetterTargetArn": "arn:aws:sqs:eu-west-1:...:orders-dlq",
    "maxReceiveCount": 3
  }
}

5. Observabilidade e Monitoramento em Múltiplas Regiões

Métricas unificadas devem incluir latência cross-region, taxa de erro por região e disponibilidade global. Ferramentas como Datadog ou Grafana Cloud permitem dashboards consolidados:

// Métricas recomendadas para dashboard global
{
  "metrics": [
    "p99_latency_by_region",
    "error_rate_by_region",
    "active_connections_by_region",
    "replication_lag_seconds"
  ]
}

Logs centralizados são preferíveis, mas exigem cuidado com latência de ingestão. Uma abordagem híbrida armazena logs localmente e os agrega assincronamente.

Alertas proativos devem detectar:
- Split-brain: Quando duas regiões acreditam ser a primária
- Degradação parcial: Aumento de latência ou erros em uma região
- Atraso de replicação: Replication lag acima do阈值

6. Segurança e Conformidade em Deployments Globais

Controle de acesso deve usar TLS mútuo (mTLS) para comunicação entre regiões. Chaves de criptografia devem ser gerenciadas por região usando serviços como AWS KMS ou Azure Key Vault com isolamento regional.

Para data residency, dados de usuários europeus devem permanecer na UE:

// Política de armazenamento regional
if (user.region === 'EU') {
  await saveToEuropeanDatabase(userData);
} else if (user.region === 'US') {
  await saveToUSDatabase(userData);
}

Auditoria e compliance exigem logs imutáveis e isolamento regional para atender GDPR, LGPD e SOC2. Cada região deve manter seus próprios logs de auditoria.

7. Estratégias de Deploy e Testes de Resiliência

Deploy canário por região permite testar alterações em uma região antes de expandir globalmente:

# Estratégia de deploy progressivo
1. Deploy em us-east-1 (10% do tráfego)
2. Monitorar por 30 minutos
3. Aumentar para 50% em us-east-1
4. Deploy em eu-west-1 (10%)
5. Monitorar por 30 minutos
6. Completar rollout global

Chaos engineering é crucial para validar a resiliência. Ferramentas como Gremlin ou AWS Fault Injection Service permitem simular:
- Falha completa de uma região
- Degradação de rede entre regiões
- Atraso de replicação de banco de dados

Playbooks de failover devem ser testados regularmente. Para clusters Kubernetes multi-região, a orquestração automática pode gerenciar failover:

# Configuração de pod anti-affinity por região
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - my-app
              topologyKey: topology.kubernetes.io/region

Referências