Lista de verificação de preparação para tabelas globais do DynamoDB

Determine se seu caso de uso se beneficia mais de um modo de consistência MRSC ou MREC. Você precisa de alta consistência, mesmo com a latência mais alta e outras concessões?

Determine quantas e quais regiões devem participar da tabela global. Se você planeja usar MRSC, decida se deseja que a terceira região seja uma réplica ou uma testemunha.

Determine o modo de gravação da sua aplicação. Isso não é o mesmo que o modo de consistência. Para obter mais informações, consulte Modos de gravação com tabelas globais do DynamoDB.

Planeje sua estratégia de Estratégias de roteamento do DynamoDB com base no seu modo de gravação.

Defina seu Processos de evacuação com base no modo de consistência, no modo de gravação e na estratégia de roteamento.

Capture métricas sobre integridade, latência e erros em cada região. Para obter uma lista das métricas do DynamoDB, consulte a postagem do blog da AWS Monitoramento do Amazon DynamoDB para conscientização operacional para obter uma lista de métricas a serem observadas. Você também deve usar canários sintéticos (solicitações artificiais projetadas para detectar falhas, nomeadas em referência aos canários nas minas de carvão), bem como a observação ao vivo do tráfego de clientes. Nem todos os problemas aparecerão nas métricas do DynamoDB.

Se você estiver usando MREC, defina alarmes para qualquer aumento sustentado em ReplicationLatency. Um aumento pode indicar uma configuração incorreta acidental na qual a tabela global tem diferentes configurações de gravação em regiões diferentes, o que leva à falha nas solicitações replicadas e ao aumento das latências. Também pode indicar que há uma interrupção regional. Um bom exemplo é gerar um alerta se a média recente exceder 180 mil milissegundos. Você também pode observar a queda de ReplicationLatency para 0, o que indica uma replicação paralisada.

Atribua configurações máximas de leitura e gravação suficientes para cada tabela global.

Identifique os motivos para evacuar uma região com antecedência. Se a decisão envolver julgamento humano, documente todas as considerações. Esse trabalho deve ser feito com cuidado e com antecedência, não sob pressão.

Mantenha um runbook para cada ação que deve ser tomada ao evacuar uma região. Normalmente, as tabelas globais exigem muito pouco trabalho, mas mover o restante da pilha pode ser complexo.

Para obter mais informações, consulte a postagem do blog da AWS Desenvolver aplicações resilientes com tabelas globais do Amazon DynamoDB: parte 4.

Teste todos os aspectos do runbook periodicamente, incluindo evacuações de região. Um runbook não testado é um runbook não confiável.

Considere usar o AWS Resilience Hub para avaliar a resiliência de toda a sua aplicação (incluindo tabelas globais). Ele fornece uma visão abrangente do status geral de resiliência do seu portfólio de aplicações por meio de seu painel.

Considere usar as verificações de prontidão do ARC para avaliar a configuração atual da aplicação e rastrear quaisquer desvios das práticas recomendadas.

Ao escrever verificações de integridade para uso com o Route 53 ou o Global Accelerator, faça um conjunto de chamadas que abranja todo o fluxo do banco de dados. Se você limitar sua verificação para confirmar apenas se o endpoint do DynamoDB está ativo, não poderá cobrir vários modos de falha, como erros de configuração do AWS Identity and Access Management (IAM), problemas de implantação de código, falha em uma pilha fora do DynamoDB, latências de leitura ou gravação acima da média e assim por diante.

O preço de uma operação de gravação em uma tabela tradicional do DynamoDB é definido em unidades de capacidade de gravação (WCUs, para tabelas provisionadas) ou unidades de solicitação de gravação (WRUs) para tabelas sob demanda. Se você gravar um item de 5 KB, serão cobradas 5 unidades. O preço de uma gravação em uma tabela global é definido em unidades de capacidade de gravação replicada (rWCUs, para tabelas provisionadas), ou unidades de solicitação de gravação replicada (rWRUs, para tabelas sob demanda). As rWCUs e rWRUs têm o mesmo preço que as WCUs e WRUs.

As alterações de rWCU e rWRU ocorrem em todas as regiões em que o item é gravado diretamente ou gravado por meio de replicação. Taxas de transferência de dados entre regiões se aplicam.

A gravação em um índice secundário global (GSI) é considerada uma operação de gravação local e usa unidades de gravação regulares.

Não há nenhuma capacidade reservada disponível para rWCUs ou rWRUs no momento. A compra de capacidade reservada para WCUs ainda pode ser benéfica para tabelas com GSIs que consomem unidades de gravação.

Quando você adiciona uma nova região a uma tabela global, o DynamoDB realiza o bootstrap da nova região automaticamente e cobra como se fosse uma restauração de tabela, com base no tamanho em GB da tabela. Ela também cobra taxas de transferência de dados entre regiões.

Conjunto de regiões dos EUA: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon)

Conjunto de regiões da Europa: Europa (Irlanda), Europa (Londres), Europa (Paris), Europa (Frankfurt)

Conjunto de regiões da AP: Ásia-Pacífico (Tóquio), Ásia-Pacífico (Seul) e Ásia-Pacífico (Osaka).

Você pode excluir uma tabela de réplica da mesma forma que excluiria qualquer outra tabela. A exclusão de uma tabela global interromperá a replicação nessa região e excluirá a cópia da tabela mantida nessa região. No entanto, você não pode interromper a replicação enquanto mantém cópias da tabela como entidades independentes nem pode pausar a replicação.

Uma tabela MRSC deve ser implantada em exatamente três regiões. Para excluir as réplicas, você deve excluir todas as réplicas e a testemunha para que a tabela MRSC se torne uma tabela local.

Cada tabela global produz um fluxo independente com base em todas as operações de gravação, independentemente de onde começaram. Você pode optar por consumir o fluxo do DynamoDB em uma região ou em todas as regiões (de forma independente). Se você quiser processar operações de gravações locais, mas não gravações replicadas, poderá adicionar seu próprio atributo de região a cada item para identificar a região de gravação. Depois, você pode usar um filtro de eventos do Lambda para chamar a função do Lambda somente para gravações na região local. Isso ajuda nas operações de inserção e atualização, mas não ajuda nas operações de exclusão.

As tabelas globais configuradas para consistência eventual multirregional (tabelas MREC) replicam as alterações lendo-as de um DynamoDB Stream em uma tabela de réplica e aplicando-as a todas as outras tabelas de réplica. Portanto, o DynamoDB é habilitado por padrão em todas as réplicas em uma tabela MREC global e não pode ser desabilitado nessas réplicas. O processo de replicação do MREC pode combinar várias alterações em um curto período de tempo em uma única operação de gravação replicada. Como resultado, o fluxo de cada réplica pode conter registros ligeiramente diferentes. Os registros do DynamoDB Streams em réplicas de MREC são sempre ordenados por item, mas a ordenação entre itens pode ser diferente entre as réplicas.

As tabelas globais configuradas para consistência forte multirregional (tabelas MRSC) não usam o DynamoDB Streams para replicação, portanto, esse recurso não é habilitado por padrão nas réplicas MRSC. Você pode habilitar o DynamoDB Streams em uma réplica do MRSC. Os registros do DynamoDB Streams em réplicas do MRSC são sempre ordenados por item, mas a ordenação entre itens pode ser diferente entre as réplicas.

As operações transacionais nas tabelas MRSC gerarão erros.

As operações transacionais nas tabelas MREC fornecem garantia de atomicidade, consistência, isolamento e durabilidade (ACID) somente na região em que a operação de gravação ocorreu originalmente. As transações não são compatíveis entre regiões em tabelas globais. Por exemplo, se você tiver uma tabela MREC global com réplicas nas regiões do Leste dos EUA (Ohio) e do Oeste dos EUA (Oregon) e realizar uma operação TransactWriteItems na região do Leste dos EUA (Ohio), poderá observar transações parcialmente concluídas na região do Oeste dos EUA (Oregon) à medida que as alterações forem replicadas. As alterações só são replicadas para outras regiões quando forem confirmadas na região de origem.

Se sua intenção é garantir a durabilidade dos dados, o DynamoDB já fornece essa proteção. O serviço garante a durabilidade.

Se você quiser manter um snapshot para registros históricos (por exemplo, para atender aos requisitos regulatórios), o backup em uma única região deverá ser suficiente. Você pode copiar o backup para outras regiões usando o AWS Backup.

Se você quiser recuperar dados excluídos ou modificados incorretamente, use a recuperação para um ponto no tempo (PITR) do DynamoDB em uma região.

O CloudFormation representa uma tabela do DynamoDB e uma tabela global como dois recursos separados: AWS::DynamoDB::Table e AWS::DynamoDB::GlobalTable. Uma abordagem é criar todas as tabelas que possam ser globais usando o constructo GlobalTable, mantê-las como tabelas independentes inicialmente e adicionar regiões posteriormente, se necessário.

No CloudFormation, cada tabela global é controlada por uma única pilha, em uma só região, independentemente do número de réplicas. Quando seu modelo for implantado, o CloudFormation criará e atualizará todas as réplicas como parte de uma única operação de pilha. Você não deve implantar o mesmo atributo AWS::DynamoDB::GlobalTable em várias regiões. Isso não é compatível e resultará em erros. Se você implantar seu modelo de aplicação em várias regiões, poderá usar condições para criar o recurso AWS::DynamoDB::GlobalTable em uma única região. Se quiser, você poderá optar por definir recursos AWS::DynamoDB::GlobalTable em uma pilha separada da pilha de aplicações e garantir que ela seja implantada apenas em uma região.

Se você tiver uma tabela regular e quiser convertê-la em uma tabela global enquanto a mantém gerenciada pelo CloudFormation, defina a política de exclusão como Retain, remova a tabela da pilha, converta-a em global no console e importe a tabela global como um novo atributo para a pilha. Para acessar mais informações, consulte o repositório do GitHub da AWS.

No momento, a replicação entre contas não é compatível.