Modos de gravação com tabelas globais do DynamoDB

As tabelas globais são sempre ativo-ativas no nível da tabela. No entanto, especialmente para tabelas MREC, talvez você queira tratá-las como ativo-passivas ao controlar a forma como direciona as solicitações de gravação. Por exemplo, você pode decidir direcionar solicitações de gravação para uma única região a fim de evitar possíveis conflitos de gravação que podem ocorrer com tabelas MREC.

Há três padrões principais de gravação gerenciada, conforme explicado nas próximas três seções. Você deve considerar qual padrão de gravação se adapta ao seu caso de uso. Essa escolha afeta a forma como você roteia solicitações, evacua uma região e lida com a recuperação de desastres. As orientações nas seções posteriores dependem do modo de gravação da sua aplicação.

Modo de gravação em qualquer região (sem primária)

O modo de gravação em qualquer região, ilustrado no diagrama a seguir, é totalmente ativo-ativo e não impõe nenhuma restrição sobre onde uma gravação pode ocorrer. Qualquer região pode aceitar uma gravação a qualquer momento. Este é o modo mais simples, no entanto, ele pode ser usado somente com alguns tipos de aplicação. Esse modo é adequado para todas as tabelas MRSC. É adequado para tabelas MREC quando todos os gravadores são idempotentes e, portanto, repetíveis com segurança, para que as operações de gravação simultâneas ou repetidas entre regiões não entrem em conflito. Por exemplo, quando um usuário atualiza seus dados de contato. Esse modo também funciona bem para um caso especial de idempotência, um conjunto de dados somente para anexos em que todas as gravações são inserções exclusivas em uma chave primária determinística. Por fim, esse modo é adequado para MREC quando o risco de gravações conflitantes é aceitável.

O modo de gravação em qualquer região é a arquitetura mais simples de implementar. O roteamento é mais fácil porque qualquer região pode ser o destino de gravação a qualquer momento. O failover é mais fácil porque, com as tabelas MRSC, os itens estão sempre sincronizados e, com as tabelas MRSC, qualquer operação de gravação recente pode ser repetida várias vezes em qualquer região secundária. Sempre que possível, defina o design para usar esse modo de gravação.

Por exemplo, os serviços de streaming de vídeo geralmente usam tabelas globais para monitorar favoritos, avaliações, sinalizadores de status de visualização, entre outros. Essas implantações usam tabelas MREC porque precisam de réplicas espalhadas no mundo todo, com cada réplica fornecendo operações de leitura e gravação de baixa latência. Essas implantações podem usar o modo de gravação em qualquer região, desde que garantam que cada operação de gravação seja idempotente. Este será o caso se cada atualização, por exemplo, definir um novo código de horário mais recente, atribuir uma nova avaliação ou definir um novo status de visualização, atribuir diretamente o novo estado ao usuário e o próximo valor correto de um item não depender de seu valor atual. Se, por acaso, as solicitações de gravação do usuário forem encaminhadas para regiões diferentes, a última operação de gravação persistirá e o estado global será resolvido de acordo com a última atribuição. As operações de leitura nesse modo acabarão se tornando consistentes após serem atrasadas pelo valor mais recente de ReplicationLatency.

Em outro exemplo, uma empresa de serviços financeiros usa tabelas globais como parte de um sistema para manter um registro contínuo das compras com cartão de débito para cada cliente, a fim de calcular as recompensas de cashback desse cliente. Ela quere manter um item RunningBalance por cliente. Esse modo de gravação não é naturalmente idempotente porque, à medida que as transações são transmitidas, elas modificam o saldo usando uma expressão ADD em que o novo valor correto depende do valor atual. Ao usar tabelas MRSC, elas ainda podem gravar em qualquer região, porque cada chamada ADD sempre opera com base no valor mais recente do item.

Um terceiro exemplo envolve uma empresa que fornece serviços de veiculação de publicidade on-line. A empresa decidiu que um baixo risco de perda de dados seria aceitável para ter as simplificações de design do modo de gravação em qualquer região. Ao veicular anúncios, ela tem apenas alguns milissegundos para recuperar metadados suficientes a fim de determinar qual anúncio exibir e, depois, para registrar a impressão do anúncio para que o mesmo anúncio não seja repetido. Ela usa tabelas globais para ter operações de leitura de baixa latência para usuários finais no mundo todo e gravações de baixa latência. Ela pode registrar todas as impressões de anúncios de um usuário em um único item, que é representado como uma lista crescente. Também pode usar um item em vez de anexá-lo a uma coleção de itens, pois dessa forma pode remover impressões de anúncios mais antigas como parte de cada operação de gravação sem pagar pela operação de exclusão. Essa operação de gravação não é idempotente. Sendo assim, se o mesmo usuário final vir anúncios veiculados em várias regiões aproximadamente ao mesmo tempo, existe a possibilidade de que uma operação de gravação de uma impressão de anúncio venha a anular outra. O risco é que um usuário talvez veja um anúncio repetido de vez em quando. A empresa decidiu que isso é aceitável.

Gravação em uma região (primária única)

O modo de gravação em uma região, ilustrado no diagrama a seguir, é ativo-passivo e direciona todas as gravações de tabela para uma única região ativa. Observe que o DynamoDB não tem a noção de uma única região ativa; é o roteamento de aplicações fora do DynamoDB que gerencia isso. O modo de gravação em uma região funciona bem para tabelas MREC que precisam evitar conflitos de gravação ao garantir que as gravações fluam somente para uma região por vez. Esse modo de gravação ajuda quando você deseja usar expressões condicionais e não pode usar MRSC por algum motivo, ou quando precisa realizar transações. Essas expressões não são possíveis, a menos que você saiba que está agindo com base nos dados mais recentes, então elas exigem o envio de todas as solicitações de gravação para uma única região que tenha os dados mais recentes.

Ao usar uma tabela MRSC, você pode optar por geralmente gravar em uma região por conveniência. Por exemplo, isso pode ajudar a minimizar a criação de sua infraestrutura além do DynamoDB. O modo de gravação ainda será de gravação em qualquer região, porque com o MRSC você poderá gravar com segurança em qualquer região, a qualquer momento, sem se preocupar com a resolução de conflitos que faria com que as tabelas MREC optassem por gravar em uma região.

As leituras finais consistentes podem ir para qualquer região de réplica a fim de alcançar latências mais baixas. Leituras altamente consistentes devem ir para a única região primária.

Às vezes, é necessário alterar a região ativa em resposta a uma falha regional. Alguns usuários alteram a região atualmente ativa em uma programação regular, como ao implementar uma implantação follow-the-sun. Isso coloca a região ativa perto da região que tem mais atividade (geralmente onde é dia, daí o nome), o que gera operações de leitura e gravação de menor latência. Também tem o benefício adicional de chamar diariamente o código de mudança de região e garantir que ele seja bem testado antes de qualquer recuperação de desastre.

As regiões passivas podem manter um conjunto reduzido de infraestrutura em torno do DynamoDB, que só é aumentado caso se tornem a região ativa. Este guia não abrange os designs de luz piloto e standby passivo. Para acessar mais detalhes, consulte Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e standby passivo.

O uso do modo de gravação em uma região funciona bem ao usar tabelas globais para operações de leitura de baixa latência distribuídas globalmente. Um exemplo é uma grande empresa de rede social que precisa ter os mesmos dados de referência disponíveis em todas as regiões do mundo. Ela não atualiza os dados com frequência, mas quando o faz, grava em apenas uma região para evitar possíveis conflitos de gravação. As operações de leitura sempre são permitidas em qualquer região.

Como outro exemplo, pense em uma empresa de serviços financeiros analisada anteriormente que implementou um cálculo diário de cashback. Ela usa o modo de gravação em qualquer região para calcular o saldo, mas usa o modo de gravação em uma região para rastrear os pagamentos. Esse trabalho requer transações que não comportam tabelas MRSC, então funciona melhor com uma tabela MREC separada e com o modo de gravação em uma região.

Gravação em sua região (primária mista)

O modo de gravação em sua região, ilustrado no diagrama a seguir, funciona com tabelas MREC. Ele atribui diferentes subconjuntos de dados a diferentes regiões de origem e permite operações de gravação em um item somente por meio de sua região de origem. Esse modo é ativo-passivo, mas atribui a região ativa com base no item. Toda região é primária para seu próprio conjunto de dados não sobreposto, e as operações de gravação devem ser protegidas para garantir a localidade adequada.

Esse modo é semelhante à gravação em uma região, exceto pelo fato de permitir operações de gravação de latência mais baixa, pois os dados associados a cada usuário final podem ser colocados mais próximos desse usuário na rede. Também distribui a infraestrutura ao redor de forma mais uniforme entre as regiões e exige menos trabalho para desenvolver a infraestrutura durante um cenário de failover, porque todas as regiões terão uma parte de sua infraestrutura já ativa.

Você pode determinar a região de origem dos itens de várias maneiras:

Por exemplo, imagine que você trabalha em uma empresa de jogos. Você precisa de operações de leitura e gravação de baixa latência para todos os jogadores no mundo todo. Você atribui cada jogador à região mais próxima a ele. Essa região considera todas as operações de leitura e gravação desse jogador, garantindo uma consistência sólida de leitura após gravação. No entanto, se esse jogador viajar ou sua região de origem sofrer uma interrupção, uma cópia completa de seus dados estará disponível em regiões alternativas, e o jogador poderá ser alocado para uma região de origem diferente.

Em outro exemplo, imagine que você trabalha em uma empresa de videoconferência. Os metadados de cada teleconferência são atribuídos a uma região específica. Os chamadores podem usar a região mais próxima de si para ter a latência mais baixa. Se houver uma interrupção na região, o uso de tabelas globais permitirá uma recuperação rápida, pois o sistema poderá mover o processamento da chamada para outra região, onde já existe uma cópia replicada dos dados.