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

Use a lista de verificação a seguir para decisões e tarefas ao implantar tabelas globais.

• Determine se seu caso de uso se beneficia mais de um modo de consistência MRSC ou MREC. Você precisa de uma consistência forte, mesmo com a maior latência e outras desvantagens?

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

• Determine o modo de gravação do seu aplicativo. (Isso não é o mesmo que o modo de consistência.)

• Planeje sua estratégia de roteamento com base no seu modo de gravação.

• Defina seu plano de evacuação com base em seu modo de consistência, modo de gravação e 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 Monitorando AWS o Amazon DynamoDB para conscientização operacional. Você também deve usar canários sintéticos (solicitações artificiais projetadas para detectar falhas), bem como a observação ao vivo do tráfego de clientes. Nem todos os problemas aparecem nas métricas do DynamoDB.

• Se você estiver usando o 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 as condições em que você evacuaria uma região. 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

  Com os procedimentos de failover, é uma prática recomendada confiar somente nas operações do plano de dados e não nas operações do plano de controle, pois algumas operações do plano de controle podem ser degradadas durante falhas na região. Para obter mais informações, consulte a postagem do AWS blog Crie aplicativos 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 AWS Resilience Hubpara avaliar a resiliência de todo o seu aplicativo (incluindo tabelas globais). Esse serviço fornece uma visão abrangente do status de resiliência do seu portfólio de aplicativos por meio de seu painel.

• Considere usar as verificações de prontidão do ARC para avaliar a configuração atual do seu aplicativo e rastrear quaisquer desvios das melhores práticas.

• Ao escrever verificações de saúde para uso com o Route 53 ou o Global Accelerator, faça um conjunto de chamadas que cubram 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 muitos modos de falha, AWS Identity and Access Management como erros de configuração (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.