Evacuar uma região com tabelas globais do DynamoDB
Evacuar uma região é o processo de afastar a atividade de leitura e gravação dessa região. Isso geralmente envolve a atividade de gravação e, às vezes, a atividade de leitura.
Evacuar uma região ativa
Você pode decidir evacuar uma região ativa por vários motivos. A evacuação pode fazer parte da atividade comercial normal; por exemplo, se você estiver usando um modo de gravação “follow the sun” em uma região. A evacuação também pode ser por causa de uma decisão comercial de mudar a região atualmente ativa, em resposta a falhas na pilha de software fora do DynamoDB ou porque você está enfrentando problemas gerais, como latências mais altas do que o normal na região.
Com o modo de gravação em qualquer região, é fácil evacuar uma região ativa. Você pode rotear o tráfego para as regiões alternativas por meio de qualquer sistema de roteamento e permitir que as operações de gravação que já ocorreram na região evacuada sejam replicadas como de costume.
Com os modos de gravação em uma região e gravação em sua região, é necessário garantir que todas as gravações na região ativa tenham sido totalmente gravadas, processadas no fluxo e propagadas globalmente antes de iniciar as gravações na nova região ativa. Isso é necessário para garantir que as gravações future sejam comparadas à versão mais recente dos dados.
Digamos que a região A esteja ativa e a região B seja passiva (seja para a tabela inteira ou para itens hospedados na região A). O mecanismo típico para realizar uma evacuação é pausar as operações de gravação em A, esperar tempo suficiente para que essas operações sejam totalmente propagadas para B, atualizar a pilha de arquitetura para reconhecer B como ativa e, depois, retomar as operações de gravação em B. Não há métrica que indique com certeza absoluta que a região A replicou totalmente seus dados para a região B. Se a região A estiver íntegra, pausar as operações de gravação na região A e esperar 10 vezes o valor máximo recente da métrica ReplicationLatency normalmente será suficiente para determinar que a replicação foi concluída. Se a região A não estiver íntegra e mostrar outras áreas com latência mais alta, escolha um múltiplo maior para o tempo de espera.
Evacuar uma região off-line
Há um caso especial a considerar: e se a região A ficar totalmente off-line sem aviso prévio? Isso é extremamente improvável, mas, mesmo assim, é prudente considerar. Se isso acontecer, todas as operações de gravação na região A que ainda não foram propagadas serão mantidas e propagadas depois que a região A voltar a ficar on-line. As operações de gravação não serão perdidas, mas a propagação será adiada indefinidamente.
A aplicação decidirá como proceder nesse caso. Para a continuidade dos negócios, talvez seja necessário prosseguir para a nova região primária B. No entanto, se um item na região B receber uma atualização enquanto houver uma propagação pendente de uma operação de gravação para esse item da região A, a propagação será suprimida no modelo último gravador vence. Qualquer atualização na região B pode suprimir uma solicitação de gravação recebida.
Com o modo de gravação em qualquer região, as leituras e gravações podem continuar na região B, confiando que os itens na região A eventualmente serão propagados para a região B e reconhecendo a possibilidade de itens perdidos até que a região A volte a ficar on-line. Quando possível, considere repetir o tráfego de gravação recente (por exemplo, usando uma fonte de eventos upstream) para preencher a lacuna da possível perda de operações de gravação e permitir que a resolução de conflitos do tipo último gravador vence suprima a eventual propagação da operação de gravação de entrada.
Com os outros modos de gravação, você deve considerar até que ponto o trabalho pode continuar com uma visão de mundo ligeiramente desatualizada. Uma pequena duração das operações de gravação, conforme monitoradas por ReplicationLatency, será perdida até que a região A volte a ficar on-line. Os negócios podem prosseguir? Em alguns casos de uso, sim, mas, em outros, talvez não seja possível sem mecanismos adicionais de mitigação.
Por exemplo, imagine que você precise manter um saldo de crédito disponível sem interrupções, mesmo após uma falha na região. Você pode dividir o saldo em dois itens diferentes, um hospedado na região A e outro na região B, cada um começando com metade do saldo disponível. Isso usa o modo de gravação em sua região. As atualizações transacionais processadas em cada região são gravadas com base na cópia local do saldo. Se a região A ficar totalmente off-line, o trabalho ainda poderá prosseguir com o processamento de transações na região B, e as operações de gravação serão limitadas à parte do saldo mantida na região B. Dividir o saldo dessa forma introduz complexidades quando o saldo fica baixo ou o crédito precisa ser reajustado, mas fornece um exemplo de recuperação segura dos negócios, mesmo com operações de gravação pendentes e incertas.
Em outro exemplo, imagine que você está capturando dados de formulários da web. Você pode usar o Controle de Simultaneidade Otimista (OCC) para atribuir versões aos itens de dados e incorporar a versão mais recente ao formulário da web como um campo oculto. Em cada envio, a operação de gravação será bem-sucedida somente se a versão no banco de dados ainda corresponder à versão com a qual o formulário foi criado. Se as versões não corresponderem, o formulário da web poderá ser atualizado (ou mesclado cuidadosamente) com base na versão atual no banco de dados, e o usuário poderá prosseguir novamente. O modelo OCC geralmente protege contra a substituição e a produção de uma nova versão dos dados por outro cliente, mas também pode ajudar durante um failover, quando um cliente pode encontrar versões mais antigas dos dados.
Vamos imaginar que você está usando o carimbo de data/hora como a versão. Digamos que o formulário tenha sido criado pela primeira vez na região A às 12h, mas (após o failover) tenta gravar na região B e percebe que a versão mais recente no banco de dados é das 11h59. Nesse cenário, o cliente pode aguardar até a versão das 12h ser propagada para a região B, depois gravar em cima dessa versão, ou se basear na das 11h59 para criar uma versão das 12h01 (que, depois de ser gravada, vai suprimir a versão recebida após a recuperação da região A).
Como exemplo final, uma empresa de serviços financeiros mantém dados sobre contas de clientes e suas transações financeiras em um banco de dados do DynamoDB. Em caso de interrupção completa da região A, a empresa quer garantir que toda atividade de gravação relacionada às contas esteja totalmente disponível na região B ou, caso contrário, quer colocar suas contas em quarentena na forma em que estão até que a região A voltar a ficar on-line. Em vez de pausar toda a atividade comercial, a empresa decidiu pausar os negócios apenas na pequena fração de contas que determinaram ter transações não propagadas. Para isso, a empresa usou uma terceira região, que chamaremos de região C. Antes de processar qualquer operação de gravação na região A, a empresa incluiu um resumo sucinto dessas operações pendentes (por exemplo, uma nova contagem de transações para uma conta) na região C. Esse resumo foi suficiente para que a região B determinasse se sua visualização estava totalmente atualizada. Essa ação bloqueou efetivamente a conta desde o momento da gravação na região C até a região A aceitar as operações de gravação e a região B recebê-las. Os dados na região C não foram usados, exceto como parte de um processo de failover, após o qual a região B conseguiu comparar seus dados com a região C para verificar se alguma conta estava desatualizada. Essas contas seriam colocadas em quarentena até que a recuperação da região A propagasse os dados parciais para a região B.
Se a região C falhasse, uma nova região D poderia ser criada para ser usada em seu lugar. Os dados na região C eram muito transitórios e, após alguns minutos, a região D já teria um registro suficientemente atualizado das operações de gravação em andamento para ser totalmente útil. Se a região B falhasse, a região A poderia continuar aceitando solicitações de gravação em cooperação com a região C. Essa empresa estava disposta a aceitar gravações com latência mais alta (em duas regiões: C e, depois, A) e teve a sorte de ter um modelo de dados em que o estado de uma conta pudesse ser resumido sucintamente.
