Roteamento de solicitações com tabelas globais do DynamoDB
Talvez a parte mais complexa da implantação de uma tabela global seja gerenciar o roteamento de solicitações. As solicitações devem primeiro ir de um usuário final para uma região escolhida, depois devem ser roteadas de alguma forma. A solicitação encontra uma pilha de serviços nessa região, incluindo uma camada de computação que talvez consista em um balanceador de carga respaldado por uma função do AWS Lambda, um contêiner ou um nó do Amazon Elastic Compute Cloud (Amazon EC2) e, possivelmente, outros serviços, incluindo outro banco de dados. Essa camada de computação se comunica com o DynamoDB. Ela deve fazer isso usando o endpoint local dessa região. Os dados na tabela global se replicam para todas as outras regiões participantes, e cada região tem uma pilha de serviços semelhante em torno de sua tabela do DynamoDB.
A tabela global fornece a cada pilha nas várias regiões uma cópia local dos mesmos dados. Você pode pensar em projetar uma única pilha em uma única região e antecipar a realização de chamadas remotas para o endpoint do DynamoDB de uma região secundária em caso de problemas com a tabela local do DynamoDB. Essa não é uma prática recomendada. As latências associadas ao cruzamento de regiões podem ser 100 vezes mais altas que as do acesso local. Uma série de ida e volta de cinco solicitações pode levar milissegundos quando executada localmente, mas segundos ao cruzar o globo. É melhor rotear o usuário final a outra região para processamento. Para garantir a resiliência, você precisa de replicação em várias regiões, com replicação da camada de computação e da camada de dados.
Existem várias técnicas alternativas para rotear uma solicitação do usuário final a uma região para processamento. A escolha ideal depende do modo de gravação e das considerações de failover. Esta seção aborda quatro opções: orientado pelo cliente, camada de computação, Route 53 e Global Accelerator.
Roteamento de solicitações orientado pelo cliente
Com o roteamento de solicitações orientado pelo cliente, um cliente de usuário final, como uma aplicação, uma página da web com JavaScript ou outro cliente, acompanhará os endpoints válidos da aplicação. Nesse caso, serão endpoints de aplicação, como um Amazon API Gateway, em vez de endpoints literais do DynamoDB. O cliente de usuário final usa sua própria lógica incorporada para escolher com qual região se comunicar. Essa escolha pode ser baseada em seleção aleatória, nas latências mais baixas observadas, nas medições mais altas de largura de banda observadas ou em verificações de integridade realizadas localmente.
A vantagem do roteamento de solicitações orientado pelo cliente é que pode se adaptar às condições reais de tráfego público da Internet para mudar de região, caso observe redução na performance. O cliente deve estar ciente de todos os possíveis endpoints, mas o lançamento de um novo endpoint regional não ocorre com frequência.
Com o modo de gravação em qualquer região, um cliente pode selecionar unilateralmente seu endpoint preferido. Se seu acesso a uma região ficar prejudicado, o cliente poderá rotear para outro endpoint.
Com o modo de gravação em uma região, o cliente precisará de um mecanismo para rotear suas gravações para a região atualmente ativa. Isso pode ser tão básico quanto testar empiricamente qual região está aceitando gravações (observando quaisquer rejeições de gravação e recorrendo a uma alternativa) ou tão complexo quanto chamar um coordenador global para consultar o estado atual da aplicação (talvez baseado no Controlador de Recuperação de Aplicações (ARC) do Route 53, que fornece um sistema controlado por quórum de cinco regiões para manter o estado global em casos como esse). O cliente pode decidir se as leituras podem ir para qualquer região a fim de obter consistência eventual ou se devem ser roteadas para a região ativa a fim de obter uma consistência sólida. Para obter mais informações, consulte Como funciona o Route 53.
Com o modo de gravação em sua região, o cliente precisa determinar a região de origem do conjunto de dados com o qual está trabalhando. Por exemplo, se o cliente corresponder a uma conta de usuário e cada conta de usuário estiver hospedada em uma região, o cliente poderá solicitar o endpoint apropriado de um sistema de login global.
Por exemplo, uma empresa de serviços financeiros que ajuda os usuários a gerenciar suas finanças comerciais pela web pode usar tabelas globais com um modo de gravação em sua região. Cada usuário precisa fazer login em um serviço central. Esse serviço retorna as credenciais e o endpoint da região em que essas credenciais vão funcionar. As credenciais são válidas por um curto período. Depois disso, a página da web negociará automaticamente um novo login, o que oferecerá a oportunidade de redirecionar potencialmente a atividade do usuário para uma nova região.
Roteamento de solicitações na camada de computação
Com o roteamento de solicitações na camada de computação, o código em execução na camada de computação decide se deseja processar a solicitação localmente ou enviá-la para uma cópia de si mesma que está sendo executada em outra região. Quando você usa o modo de gravação em uma região, a camada de computação consegue detectar que não é a região ativa e permitir operações de leitura locais enquanto encaminha todas as operações de gravação para outra região. Esse código da camada de computação precisa estar ciente da topologia de dados e das regras de roteamento e aplicá-las de forma confiável com base nas configurações mais recentes que especificam quais regiões estão ativas para quais dados. A pilha de software externa da região não precisa estar ciente de como as solicitações de leitura e gravação são roteadas pelo microsserviço. Em um design robusto, a região receptora valida se é a primária atual para a operação de gravação. Se não for, vai gerar um erro que indica que o estado global precisa ser corrigido. A região receptora também pode armazenar em buffer a operação de gravação por um tempo se a região primária estiver em processo de alteração. Em todos os casos, a pilha de computação em uma região grava somente em seu endpoint local do DynamoDB, mas as pilhas de computação podem se comunicar entre si.
Nesse cenário, digamos que uma empresa de serviços financeiros use um modelo de primária única “follow-the-sun”. A empresa usa um sistema e uma biblioteca para esse processo de roteamento. Seu sistema geral mantém o estado global, semelhante ao controle de roteamento do ARC da AWS. A empresa usa uma tabela global para rastrear qual região é a região primária e para quando está programada a próxima mudança de primária. Todas as operações de leitura e gravação passam pela biblioteca, que coordena com seu sistema. A biblioteca permite que as operações de leitura sejam realizadas localmente, com baixa latência. Para operações de gravação, a aplicação verifica se a região local é a região primária atual. Nesse caso, a operação de gravação é concluída diretamente. Caso contrário, a biblioteca encaminha a tarefa de gravação para a biblioteca que está na região primária atual. Essa biblioteca receptora confirma que ela também se considera como região primária e gerará um erro se não for, o que indicará um atraso na propagação com o estado global. Essa abordagem oferece um benefício de validação ao não gravar diretamente em um endpoint remoto do DynamoDB.
Roteamento de solicitações do Route 53
O Controlador de Recuperação de Aplicações (ARC) da Amazon é uma tecnologia de serviço de nomes de domínio (DNS). Com o Route 53, o cliente solicita seu endpoint pesquisando um nome de domínio DNS conhecido, e o Route 53 retorna o endereço IP correspondente aos endpoints regionais que considera mais apropriados. O Route 53 tem uma lista de políticas de roteamento que usa para determinar a região apropriada. O Route 53 também pode fazer o roteamento por failover para afastar o tráfego de regiões com falhas nas verificações de integridade.
Com o modo de gravação em qualquer região, ou quando combinado com o roteamento de solicitação na camada de computação no back-end, o Route 53 pode receber acesso total para retornar a região com base em quaisquer regras internas complexas, como a região mais próxima na rede, a mais próxima geograficamente ou qualquer outra opção.
Com o modo de gravação em uma região, o Route 53 pode ser configurado para retornar a região atualmente ativa (usando o Route 53 ARC).
nota
Os clientes armazenam em cache os endereços IP na resposta do Route 53 por um tempo indicado pela configuração de vida útil (TTL) no nome de domínio. Uma TTL mais longa estende o objetivo de tempo de recuperação (RTO) para que todos os clientes reconheçam o novo endpoint. É comum um valor de 60 segundos para uso em failover. Nem todo software adere perfeitamente à expiração da TTL de DNS.
Com o modo de gravação em sua região, é melhor evitar o Route 53, a menos que você também esteja usando o roteamento de solicitações na camada de computação.
Roteamento de solicitações no Global Accelerator
Um cliente usa o AWS Global Accelerator
Com o modo de gravação em qualquer região, ou quando combinado com o roteamento de solicitações na camada de computação no back-end, o Global Accelerator funciona de maneira integrada. O cliente se conecta ao local da borda mais próximo e não precisa se preocupar com qual região recebe a solicitação.
Com o modo de gravação em uma região, as regras de roteamento do Global Accelerator devem enviar solicitações para a região atualmente ativa. Você pode usar verificações de integridade que relatam artificialmente uma falha em qualquer região que não seja considerada como a região ativa pelo seu sistema global. Assim como no DNS, é possível usar um nome de domínio DNS alternativo para rotear solicitações de leitura se as solicitações puderem ser de qualquer região.
Com o modo de gravação em sua região, é melhor evitar o Global Accelerator, a menos que você também esteja usando o roteamento de solicitações na camada de computação.
