DynamoDB Global Tables: replicação multirregião explicada

Uma global table é uma única tabela DynamoDB replicada por múltiplas regiões da AWS, onde toda réplica é gravável. O DynamoDB as mantém sincronizadas automaticamente — você obtém leituras e escritas locais de baixa latência em cada região mais recuperação de desastres entre regiões, sem rodar a sua própria replicação.

No cenário do log de auditoria, um cliente da UE exige que os seus dados morem em eu-west-1, enquanto o resto roda em us-east-1. E como um log crítico de conformidade, ele precisa sobreviver a uma queda regional completa. Uma global table responde a ambos com um único recurso.

Como funcionam as DynamoDB Global Tables?

As DynamoDB Global Tables são uma única tabela replicada por múltiplas regiões da AWS, onde toda réplica é legível e gravável. O DynamoDB as sincroniza automaticamente por replicação assíncrona eventualmente consistente, resolvendo conflitos com last-writer-wins. Você obtém leituras e escritas locais de baixa latência por região mais recuperação de desastres entre regiões, dando suporte ao SLA de 99,999% de disponibilidade do DynamoDB.

• Multirregião, ativa-ativa. Cada réplica é totalmente legível e gravável; escritas em qualquer região se propagam para as outras.
• No modo padrão, a replicação é assíncrona e eventualmente consistente entre regiões — tipicamente dentro de um segundo, mas não instantânea. (Um modo de consistência forte também existe — veja abaixo.)
• Conflitos resolvem com last-writer-wins. Escritas concorrentes ao mesmo item em duas regiões reconciliam para a mais recente.
• Ela dá suporte ao SLA de 99,999% de disponibilidade — uma global table multirregião é a configuração de mais alta disponibilidade do DynamoDB.

O problema: uma região não é suficiente

Uma tabela de região única tem dois limites que o log de auditoria não pode aceitar. Primeiro, residência de dados: os eventos de um cliente da UE devem ser armazenados na UE, mas a sua aplicação roda nos EUA. Segundo, recuperação de desastres: se us-east-1 tem uma queda, um log de auditoria de região única fica ilegível e não gravável pela duração — exatamente quando você mais precisa do registro do que aconteceu.

Construir qualquer um deles você mesmo — replicação entre regiões, failover, tratamento de conflitos — é um projeto grande e propenso a erros. Global tables o tornam uma escolha de configuração.

Mecânica da replicação

Você adiciona uma região de réplica à tabela; o DynamoDB cria uma cópia lá e mantém todas as réplicas em sincronia.

Duas regras de consistência definem o comportamento padrão (MREC):

• A replicação entre regiões é assíncrona. Uma escrita em us-east-1 é confirmada localmente, depois propagada para eu-west-1 — geralmente dentro de um segundo, mas uma leitura na outra região logo depois de uma escrita pode ainda não vê-la. (No modo MREC padrão, leituras fortemente consistentes ainda funcionam, mas apenas dentro de uma única região.)
• Conflitos são last-writer-wins. Se o mesmo item é escrito em duas regiões em quase o mesmo momento, o DynamoDB mantém a escrita com o timestamp mais recente e descarta a outra.

Um exemplo prático: uma réplica da UE que também é DR

Você adiciona eu-west-1 como uma réplica da tabela de log de auditoria. Agora:

A aplicação do cliente da UE escreve e lê da réplica local eu-west-1 — baixa latência e dados residentes na região. A mesma replicação que satisfaz a residência funciona dupla como recuperação de desastres: se us-east-1 cai, a réplica eu-west-1 ainda contém o log completo e serve tráfego; você faz failover para ela.

Como o log de auditoria é append-only e particionado por tenant, o last-writer- wins é essencialmente um não-problema aqui — os eventos de um dado tenant são escritos de uma região e as chaves de evento são únicas, então duas regiões raramente competem pelo mesmo item. Isso não é sorte; é por isso que um log append-only é um dos encaixes mais limpos para global tables. Um contador mutável, em contraste, precisaria de cuidado sob escritas concorrentes entre regiões.

Faça isso no DynoTable

Depois de adicionar uma réplica, você quer confirmar que os dados de fato pousaram na nova região e correspondem à fonte — que a réplica da UE realmente contém os eventos de acme, com os atributos certos, e não está atrasada.

O DynoTable conecta a qualquer região com as suas próprias credenciais, então você pode apontar uma janela para us-east-1 e outra para eu-west-1 e comparar os itens do mesmo tenant lado a lado para verificar a replicação.

Você pode prototipar as consultas por região que você vai rodar contra cada réplica no Construtor de Expressões do DynamoDB.

Armadilhas e próximos passos

• Não leia a sua própria escrita entre regiões. O atraso de replicação significa que uma escrita em uma região pode não aparecer em outra por ~um segundo. Não escreva nos EUA e então leia imediatamente da UE esperando por ela. No modo MREC padrão, leituras fortemente consistentes funcionam apenas dentro de uma única região; o MRSC estende leituras fortes entre regiões.
• Last-writer-wins descarta dados silenciosamente. Para itens mutáveis escritos concorrentemente em duas regiões, o perdedor é descartado sem erro. Designs append-only ou de escritor-único-por-item (como este log de auditoria) evitam o problema; estado mutável compartilhado precisa de um design ciente de conflitos.
• Toda réplica custa. Cada região armazena uma cópia completa e cobra a sua própria capacidade e armazenamento — uma réplica praticamente dobra o custo. Adicione regiões para uma real necessidade de residência ou DR, não por padrão.
• Backups são por réplica. Uma global table restaurada vira uma tabela independente — planeje a recuperação por região. Veja backup & recuperação para um ponto no tempo.

Global tables protegem contra perder uma região. A última preocupação operacional é proteger contra perder dados — um deploy ruim ou uma exclusão acidental — com backup & recuperação para um ponto no tempo.

Baixe o DynoTable para conectar a múltiplas regiões e verificar que as suas réplicas de global table contêm os mesmos dados.