Estratégias de roteamento 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. Esta não é uma prática recomendada. Se houver um problema em uma região causado pelo DynamoDB (ou, mais provavelmente, causado por outra coisa na pilha ou por outro serviço que dependa do DynamoDB), é melhor rotear o usuário final para outra região para processar e usar a camada computacional dessa outra região, que se comunicará com o endpoint local do DynamoDB. Essa abordagem desvia da região problemática completamente. Para garantir a resiliência, você precisa de replicação em várias regiões: replicação da camada de computação bem como 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, ilustrado no diagrama a seguir, o cliente usuário final (uma aplicação, uma página da web com JavaScript ou outro cliente) acompanha os endpoints válidos da aplicação (por exemplo, um endpoint do Amazon API Gateway em vez de um endpoint literal do DynamoDB) e usa sua própria lógica incorporada para escolher a região com a qual se comunicar. Pode escolher com base em uma 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.

Como uma vantagem, o roteamento de solicitações orientado pelo cliente pode se adaptar a fatores, como condições reais de tráfego público da internet para mudar regiões, caso observe uma 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 preferencial. 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) da Amazon, 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, ilustrado na diagrama a seguir, o código em execução na camada de computação determina se processa a solicitação localmente ou se a envia 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 pode detectar que não é a região ativa e pode 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 direcionadas 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.

O Vanguard Group usa um sistema chamado Global Orchestration and Status Tool (GOaST) e uma biblioteca chamada Global Multi-Region library (GMRlib) para esse processo de roteamento, conforme apresentado no re:Invent 2022. Eles usam um modelo primário único follow-the-sun. O GOaST mantém o estado global, semelhante ao controle de roteamento do ARC analisado na seção anterior. Ele usa uma tabela global para rastrear qual região é a região primária e para quando está programada a próxima mudança da primária. Todas as operações de leitura e gravação passam pela GMRlib, que coordena com o GOaST. A GMRlib permite que as operações de leitura sejam realizadas localmente, com baixa latência. Para operações de gravação, a GMRlib confere 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 GMRlib encaminha a tarefa de gravação para a GMRlib na região primária. 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. Isso é ilustrado no diagrama a seguir. O Route 53 tem uma longa lista de políticas de roteamento que usa para determinar a região apropriada. Também pode fazer o roteamento por failover para desviar 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, você pode configurar o Route 53 para exibir a região atualmente ativa (usando o ARC do Route 53). Se o cliente quiser se conectar a uma região passiva (por exemplo, para operações de leitura), ele poderá procurar um nome de DNS diferente.

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

Com o AWS Global Accelerator, ilustrado no diagrama a seguir, um cliente procura o nome de domínio conhecido no Route 53. No entanto, em vez de recuperar um endereço IP que corresponde a um endpoint regional, o cliente recebe um endereço IP estático anycast que direciona para o local da borda da AWS mais próximo. Começando nesse local da borda, todo o tráfego é roteado na rede privada da AWS e para algum endpoint (como um balanceador de carga ou o API Gateway) em uma região escolhida pelas regras de roteamento mantidas no Global Accelerator. Em comparação com o roteamento baseado nas regras do Route 53, o roteamento de solicitações no Global Accelerator tem latências mais baixas porque reduz a quantidade de tráfego na Internet pública. Além disso, como o Global Accelerator não depende da expiração da TTL de DNS para alterar as regras de roteamento, ele consegue ajustar o roteamento mais rapidamente.

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.