Estratégias de cross-region replication para sistemas globalmente distribuídos

1. Fundamentos da Replicação Cross-Region

1.1. Definição e objetivos: latência, disponibilidade e resiliência a desastres

A replicação cross-region é a prática de manter cópias sincronizadas de dados em datacenters localizados em diferentes regiões geográficas. Seus objetivos principais são três: reduzir a latência para usuários globais (servindo dados da região mais próxima), aumentar a disponibilidade (se uma região falha, outras continuam operando) e garantir resiliência a desastres naturais ou falhas catastróficas que possam derrubar uma região inteira.

1.2. Modelos de consistência: eventual, forte e causal em ambientes multi-região

Em ambientes multi-região, a consistência dos dados é um desafio central. Três modelos são comuns:

  • Consistência eventual: após um período sem novas escritas, todas as réplicas convergem para o mesmo estado. É o modelo mais escalável, mas permite leituras obsoletas temporariamente.
  • Consistência forte: toda leitura retorna o valor da escrita mais recente. Exige coordenação síncrona entre regiões, aumentando a latência.
  • Consistência causal: preserva a ordem de eventos relacionados causalmente. Oferece um equilíbrio entre desempenho e garantias.

1.3. Trade-offs entre throughput, latência e custo de replicação geográfica

A replicação cross-region envolve trade-offs claros: replicação síncrona oferece consistência forte mas aumenta a latência e reduz o throughput; replicação assíncrona maximiza desempenho local mas expõe a janelas de inconsistência. O custo de transferência de dados entre regiões também é significativo — provedores como AWS cobram por GB transferido entre regiões.

2. Arquiteturas de Replicação Ativo-Ativo vs. Ativo-Passivo

2.1. Replicação ativo-passivo: failover manual e automático com réplicas de leitura

Na arquitetura ativo-passivo, uma região primária aceita todas as escritas, enquanto réplicas em outras regiões servem apenas leituras. Em caso de falha da região primária, um failover promove uma réplica a primária. Exemplo de configuração no DynamoDB:

# Configuração de tabela DynamoDB com réplica global (ativo-passivo)
aws dynamodb create-table \
    --table-name Usuarios \
    --attribute-definitions AttributeName=UserId,AttributeType=S \
    --key-schema AttributeName=UserId,KeyType=HASH \
    --billing-mode PAY_PER_REQUEST \
    --region us-east-1

# Adicionar réplica de leitura em sa-east-1
aws dynamodb update-table \
    --table-name Usuarios \
    --replica-updates '[{"Create":{"RegionName":"sa-east-1"}}]' \
    --region us-east-1

2.2. Replicação ativo-ativo: escrita simultânea em múltiplas regiões e conflitos

No modelo ativo-ativo, todas as regiões aceitam escritas e leituras simultaneamente. Isso elimina a necessidade de failover, mas introduz conflitos de escrita. O DynamoDB Global Tables implementa esse modelo:

# Criar tabela global (ativo-ativo) no DynamoDB
aws dynamodb create-global-table \
    --global-table-name CatalogoProdutos \
    --replication-group RegionName=us-east-1 RegionName=eu-west-1 RegionName=ap-southeast-1 \
    --billing-mode PAY_PER_REQUEST

2.3. Estratégias de resolução de conflitos: last-writer-wins, CRDTs e merge customizado

Três abordagens principais resolvem conflitos em sistemas ativo-ativo:

  • Last-Writer-Wins (LWW): o timestamp mais recente vence. Simples, mas pode perder dados.
  • CRDTs (Conflict-free Replicated Data Types): estruturas de dados que convergem automaticamente, como contadores e sets.
  • Merge customizado: lógica de aplicação para combinar versões conflitantes, comum em sistemas como o CouchDB.

Exemplo de resolução LWW no DynamoDB:

# Escrita com timestamp para resolução LWW
aws dynamodb put-item \
    --table-name CatalogoProdutos \
    --item '{
        "ProductId": {"S": "P123"},
        "Price": {"N": "29.99"},
        "UpdatedAt": {"N": "1700000000"}
    }' \
    --condition-expression "attribute_not_exists(UpdatedAt) OR UpdatedAt < :newTime" \
    --expression-attribute-values '{":newTime": {"N": "1700000000"}}' \
    --region us-east-1

3. Protocolos de Replicação e Sincronização de Dados

3.1. Replicação síncrona vs. assíncrona: impacto na consistência e desempenho

A replicação síncrona aguarda confirmação de todas as réplicas antes de confirmar a escrita, garantindo consistência forte mas aumentando a latência para centenas de milissegundos. A replicação assíncrona confirma a escrita localmente e propaga as alterações em segundo plano, oferecendo latência de milissegundos mas com possibilidade de perda de dados em falhas.

3.2. Log-based replication: Change Data Capture (CDC) e streaming de eventos

CDC captura mudanças no banco de dados a partir do log de transações e as publica em um stream de eventos (Kafka, Kinesis). Outras regiões consomem esse stream e aplicam as mudanças localmente. Exemplo com Debezium e Kafka:

# Configuração Debezium para capturar mudanças no MySQL
{
  "name": "mysql-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "db-primary.internal",
    "database.port": "3306",
    "database.user": "debezium",
    "database.password": "debezium",
    "database.server.id": "184054",
    "database.server.name": "dbserver1",
    "database.include.list": "inventory",
    "table.include.list": "inventory.orders",
    "topic.prefix": "cdc",
    "schema.history.internal.kafka.bootstrap.servers": "kafka:9092",
    "schema.history.internal.kafka.topic": "schemahistory.inventory"
  }
}

3.3. Protocolos de consenso distribuído (Raft, Paxos) adaptados para múltiplas regiões

Protocolos como Raft e Paxos garantem consistência forte mesmo em cenários multi-região, mas com custo de latência elevado. O Google Spanner usa o TrueTime API com Paxos para fornecer consistência externa global. O CockroachDB adapta o Raft para operar entre regiões:

# Configuração de replicação geográfica no CockroachDB
-- Definir zonas de replicação para garantir dados em 3 regiões
ALTER DATABASE bank CONFIGURE ZONE USING
    num_replicas = 5,
    constraints = '{+region=us-east1: 2, +region=eu-west1: 2, +region=ap-southeast1: 1}';

-- Verificar configuração
SHOW ZONE CONFIGURATION FOR DATABASE bank;

4. Gerenciamento de Latência e Roteamento de Tráfego

4.1. Estratégias de georoteamento: DNS anycast, Global Traffic Manager e endpoints regionais

O roteamento geográfico direciona usuários para a região mais próxima. AWS Route 53 com política de latência ou geolocalização, Azure Traffic Manager e Google Cloud Load Balancing oferecem essas capacidades:

# Configuração de política de roteamento por latência no Route 53
aws route53 create-record-set \
    --hosted-zone-id Z123456 \
    --name api.minhaapp.com \
    --type A \
    --set-identifier "us-east-1" \
    --region us-east-1 \
    --latency-routing-policy \
    --failover PRIMARY \
    --resource-records "Value=203.0.113.10" \
    --ttl 60

4.2. Caching distribuído e edge computing para redução de latência

CDNs e edge caches (CloudFront, Cloudflare) armazenam conteúdo estático e dinâmico próximo aos usuários. Para dados dinâmicos, soluções como Redis Enterprise com replicação geo-distribuída ou Memcached multi-região reduzem a latência de leitura.

4.3. Técnicas de read-after-write consistency em cenários cross-region

Para garantir que um usuário veja suas próprias escritas imediatamente, técnicas como session stickiness (manter o usuário na mesma região), read-your-writes consistency com tokens de consistência (DynamoDB) ou roteamento baseado em afinidade são utilizadas.

5. Tratamento de Falhas e Recuperação de Desastres

5.1. Detecção de falhas regionais e mecanismos de failover automático

Health checks, heartbeats e sistemas de monitoramento (CloudWatch, Datadog) detectam falhas. O failover automático pode ser implementado com AWS Route 53 health checks combinados com failover records:

# Configuração de failover automático no Route 53
aws route53 create-health-check \
    --caller-reference "health-check-api-primary" \
    --health-check-config '{
        "Type": "HTTPS",
        "ResourcePath": "/health",
        "FullyQualifiedDomainName": "api-primary.minhaapp.com",
        "Port": 443,
        "RequestInterval": 30,
        "FailureThreshold": 3
    }'

5.2. Estratégias de backup e restore geograficamente distribuídas

Backups devem ser armazenados em região diferente da produção. Serviços como AWS Backup permitem políticas de backup cross-region automáticas:

# Criar plano de backup cross-region no AWS Backup
aws backup create-backup-plan \
    --backup-plan '{
        "BackupPlanName": "cross-region-backup",
        "Rules": [{
            "RuleName": "daily-backup",
            "TargetBackupVaultName": "SecondaryRegionVault",
            "ScheduleExpression": "cron(0 5 * * ? *)",
            "StartWindowMinutes": 60,
            "CompletionWindowMinutes": 120,
            "Lifecycle": {
                "DeleteAfterDays": 30
            },
            "CopyActions": [{
                "DestinationBackupVaultArn": "arn:aws:backup:sa-east-1:123456789:backup-vault:SecondaryVault",
                "Lifecycle": {
                    "DeleteAfterDays": 90
                }
            }]
        }]
    }'

5.3. Testes de resiliência: chaos engineering e simulações de perda de região

Ferramentas como Chaos Monkey, Gremlin e AWS Fault Injection Simulator permitem testar a resiliência do sistema injetando falhas controladas, como latência artificial ou derrubada completa de uma região.

6. Custos, Monitoramento e Otimização Operacional

6.1. Custos de transferência de dados entre regiões e largura de banda

O custo de transferência de dados entre regiões pode ser significativo. Na AWS, a transferência entre regiões custa aproximadamente $0.02/GB a $0.09/GB dependendo das regiões envolvidas. Para otimizar, reduza o volume de dados replicados usando filtragem e compressão.

6.2. Métricas-chave: RPO (Recovery Point Objective) e RTO (Recovery Time Objective)

  • RPO: quantidade máxima de dados que pode ser perdida em uma falha (ex: 5 minutos de dados).
  • RTO: tempo máximo para recuperar o serviço após uma falha (ex: 1 hora).

Sistemas assíncronos oferecem RPO de segundos a minutos; sistemas síncronos oferecem RPO zero.

6.3. Ferramentas de monitoramento de replicação e alertas de divergência

Ferramentas como AWS CloudWatch Metrics para DynamoDB Global Tables (ReplicationLatency, PendingReplicationCount) e CloudWatch Logs para monitorar logs de replicação permitem detectar divergências:

# Alerta de latência de replicação no CloudWatch
aws cloudwatch put-metric-alarm \
    --alarm-name "ReplicationLatencyHigh" \
    --alarm-description "Alarme para latencia de replicacao > 5 segundos" \
    --metric-name ReplicationLatency \
    --namespace AWS/DynamoDB \
    --statistic Average \
    --period 60 \
    --evaluation-periods 3 \
    --threshold 5000 \
    --comparison-operator GreaterThanThreshold \
    --dimensions Name=TableName,Value=CatalogoProdutos \
    --alarm-actions arn:aws:sns:us-east-1:123456789:ReplicationAlerts

7. Casos de Uso e Exemplos Práticos

7.1. Sistemas de e-commerce global: catálogo de produtos e carrinhos de compra

Um e-commerce global pode usar DynamoDB Global Tables para o catálogo de produtos (ativo-ativo) e Redis Enterprise com replicação geo-distribuída para carrinhos de compra. O catálogo usa LWW para resolver conflitos de preço, enquanto o carrinho usa CRDTs para evitar perda de itens.

7.2. Aplicações financeiras: contas bancárias e transações multi-região

Aplicações financeiras exigem consistência forte. O Google Spanner oferece transações ACID globais com TrueTime. Alternativamente, sistemas como CockroachDB com replicação síncrona entre regiões próximas (ex: us-east1 e us-east4) garantem RPO zero com latência aceitável.

7.3. Plataformas de streaming e redes sociais: feeds e dados de usuário

Plataformas como Netflix e Twitter usam replicação eventual para feeds e dados de usuário, priorizando disponibilidade e baixa latência. O Apache Cassandra com replicação multi-região e consistência configurável por query (ONE, QUORUM, ALL) é uma escolha comum:

-- Configuração de keyspace no Cassandra para replicação multi-região
CREATE KEYSPACE social_media
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'us-east': 3,
  'eu-west': 3,
  'ap-southeast': 2
};

-- Query com consistência LOCAL_QUORUM para leitura
SELECT * FROM user_feed WHERE user_id = 'U123'
USING CONSISTENCY LOCAL_QUORUM;

Referências