Lista de verificação de preparação para tabelas globais do DynamoDB e perguntas frequentes
Use a lista de verificação a seguir para decisões e tarefas ao implantar tabelas globais.
Determine quantas e quais regiões devem participar da tabela global.
Determine o modo de gravação da sua aplicação. Para ter mais informações, consulte Modos de gravação com tabelas globais do DynamoDB.
Planeje sua estratégia de Roteamento de solicitações com tabelas globais do DynamoDB com base no seu modo de gravação.
Defina seu plano de evacuação com base 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. Defina alarmes para qualquer aumento contínuo 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 ReplicationLatencypara 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.
nota
É uma prática recomendada depender somente de operações do plano de dados e não das operações do ambiente de gerenciamento, pois algumas operações do ambiente de gerenciamento podem ser comprometidas durante falhas na região.
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 Hub de Resiliência 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 uma verificação de integridade para uso com o Route 53 ou o Global Accelerator, não basta apenas enviar um ping para verificar se o endpoint do DynamoDB está ativo. Isso não abrange os vários modos de falha, como erros de configuração do IAM, problemas de implantação de código, falha na pilha fora do DynamoDB, latências de leitura ou gravação acima da média e assim por diante. É melhor realizar um conjunto de chamadas que exerçam um fluxo completo do banco de dados.
Perguntas frequentes (FAQ) sobre a implantação de tabelas globais
Quais são alguns princípios úteis para o uso geral das tabelas globais do DynamoDB?
As tabelas globais do DynamoDB têm poucos botões de controle, mas ainda exigem diversas considerações. Você deve determinar seu modo de gravação, modelo de roteamento e processos de evacuação. Você deve instrumentar sua aplicação em todas as regiões e se preparar para ajustar o roteamento ou realizar uma evacuação para manter a integridade global. A recompensa é ter um conjunto de dados distribuído globalmente com leituras e gravações de baixa latência e um acordo de serviço de 99,999%.
Qual é o preço das tabelas globais?
O preço de 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 incluem o custo da infraestrutura de streaming necessária para gerenciar a replicação. Dessa forma, são 50% mais caras do que as WCUs e WRUs. Taxas de transferência de dados entre regiões se aplicam.
As unidades de gravação replicada são cobradas em todas as regiões em que o item é gravado diretamente ou gravado em replicação.
A gravação em um índice secundário global (GSI) é considerada uma gravação local e usa unidades de gravação regulares.
Não há nenhuma capacidade reservada disponível para rWCUs no momento. A compra de capacidade reservada ainda pode ser benéfica para tabelas com GSIs que consomem unidades de gravação.
O bootstrap inicial ao adicionar uma nova região a uma tabela global é cobrado como uma restauração por GB de dados restaurados, mais taxas de transferência de dados entre regiões.
Quais regiões são compatíveis com tabelas globais?
O Global Tables versão 2019.11.21 (atual) está disponível na maioria das regiões. Você pode ver a lista mais recente na lista suspensa Região no console do DynamoDB ao adicionar uma réplica.
Como os GSIs são tratados com tabelas globais?
Em Global Tables versão 2019.11.21 (atual), ao criar um GSI em uma região, ele é criado e preenchido automaticamente em outras regiões participantes.
Como faço para interromper a replicação de uma tabela global?
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.
Como o DynamoDB Streams interage com as tabelas globais?
Cada tabela global produz um fluxo independente com base em todas as gravações, 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 infelizmente não ajuda nas operações de exclusão.
Como as tabelas globais lidam com as transações?
As operações transacionais 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 global com réplicas nas regiões Leste dos EUA (Ohio) e Oeste dos EUA (Oregon) e realizar uma operação TransactWriteItems na região Leste dos EUA (Ohio), poderá observar transações parcialmente concluídas na região 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.
Como as tabelas globais interagem com o cache do DynamoDB Accelerator (DAX)?
As tabelas globais ignoram o DAX ao atualizar o DynamoDB diretamente, por isso o DAX não sabe que está armazenando dados obsoletos. O cache do DAX só é atualizado quando a TTL do cache expira.
As etiquetas nas tabelas são propagadas?
Não, as etiquetas não são propagadas automaticamente.
Devo fazer backup de tabelas em todas as regiões ou em apenas uma?
A resposta depende da finalidade do backup. 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.
Como faço para implantar tabelas globais usando o AWS CloudFormation?
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 a estrutura GlobalTable. Você pode mantê-las como tabelas independentes inicialmente, depois adicionar regiões, 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 Reter, remova a tabela da pilha, converta a tabela em uma tabela global no console e importe a tabela global como um novo recurso para a pilha.
No momento, a replicação entre contas não é compatível.
