Fundamental multirregional 2: compreender os dados

Gerenciar dados não é um problema trivial quando você adota arquiteturas multirregionais. A distância geográfica entre regiões impõe uma latência inevitável que se manifesta como o tempo necessário para replicar dados entre regiões. Serão necessárias compensações entre disponibilidade, consistência de dados e introdução de maior latência em uma carga de trabalho que usa uma arquitetura multirregional. Se você usa replicação assíncrona ou síncrona, precisará modificar seu aplicativo para lidar com as mudanças comportamentais impostas pela tecnologia de replicação. Os desafios relacionados à consistência e latência dos dados tornam muito difícil transformar um aplicativo existente projetado para uma única região em várias regiões. Compreender os requisitos de consistência de dados e os padrões de acesso aos dados para cargas de trabalho específicas é fundamental para ponderar as compensações.

2.a: Entendendo os requisitos de consistência de dados

O teorema CAP fornece uma referência para raciocinar sobre as compensações entre consistência de dados, disponibilidade e partições de rede. Somente dois desses requisitos podem ser satisfeitos ao mesmo tempo para uma carga de trabalho. Por definição, uma arquitetura multirregional inclui partições de rede entre regiões, então você precisa escolher entre disponibilidade e consistência.

Se você selecionar a disponibilidade de dados entre regiões, não incorrerá em latência significativa durante as operações de gravação transacional, pois a dependência da replicação assíncrona de dados comprometidos entre regiões resulta em redução da consistência entre regiões até que a replicação seja concluída. Com a replicação assíncrona, quando há uma falha na região primária, há uma grande probabilidade de que as operações de gravação estejam pendentes de replicação da região primária. Isso leva a um cenário em que os dados mais recentes ficam indisponíveis até que a replicação seja retomada, e um processo de reconciliação é necessário para lidar com transações em andamento que não foram replicadas da região que sofreu a interrupção. Esse cenário exige entender sua lógica de negócios e criar um processo específico para reproduzir a transação ou comparar os armazenamentos de dados entre regiões.

Para cargas de trabalho em que a replicação assíncrona é preferida, você pode usar serviços como Amazon Aurora e Amazon DynamoDB para replicação assíncrona entre regiões. Tanto os bancos de dados globais do Amazon Aurora quanto as tabelas globais do Amazon DynamoDB têm métricas padrão da CloudWatchAmazon para ajudar a monitorar o atraso na replicação. Um banco de dados global do Aurora consiste em uma região primária em que seus dados são gravados e em até cinco regiões secundárias somente para leitura. As tabelas globais do DynamoDB consistem em tabelas de réplica multiativas em qualquer número de regiões nas quais seus dados são gravados e lidos.

Projetar a carga de trabalho para aproveitar as arquiteturas orientadas por eventos é um benefício para uma estratégia multirregional, pois significa que a carga de trabalho pode adotar a replicação assíncrona de dados e permitir a reconstrução do estado por meio da repetição de eventos. Como os serviços de streaming e mensagens armazenam em buffer os dados da carga útil das mensagens em uma única região, um processo regional de failover ou failback deve incluir um mecanismo para redirecionar os fluxos de dados de entrada do cliente. O processo também deve reconciliar cargas úteis em voo ou não entregues armazenadas na região que sofreu a interrupção.

Se você escolher o requisito de consistência do CAP e usar um banco de dados replicado de forma síncrona em todas as regiões para oferecer suporte aos aplicativos que são executados simultaneamente em várias regiões, você remove o risco de perda de dados e mantém os dados sincronizados entre as regiões. No entanto, isso introduz características de latência mais altas, porque as gravações precisam se comprometer com mais de uma região, e as regiões podem estar a centenas ou milhares de quilômetros umas das outras. Você precisa considerar essa característica de latência no design do seu aplicativo. Além disso, a replicação síncrona pode introduzir a chance de falhas correlacionadas, pois as gravações precisarão ser comprometidas em mais de uma região para serem bem-sucedidas. Se houver uma deficiência em uma região, você precisará formar um quórum para que as gravações sejam bem-sucedidas. Isso normalmente envolve configurar seu banco de dados em três regiões e estabelecer um quórum de duas em cada três regiões. Tecnologias como a Paxos podem ajudar a replicar e confirmar dados de forma síncrona, mas exigem um investimento significativo do desenvolvedor.

Quando as gravações envolvem replicação síncrona em várias regiões para atender aos fortes requisitos de consistência, a latência de gravação aumenta em uma ordem de magnitude. Uma latência de gravação mais alta não é algo que você normalmente possa adaptar em um aplicativo sem alterações significativas, como revisitar o tempo limite e a estratégia de repetição do seu aplicativo. Idealmente, isso deve ser levado em consideração quando o aplicativo está sendo projetado pela primeira vez. Para cargas de trabalho multirregionais em que a replicação síncrona é uma prioridade,AWS Partner as soluções podem ajudar.

2.b: Entendendo os padrões de acesso aos dados

Os padrões de acesso aos dados da carga de trabalho exigem muita leitura ou gravação. Compreender essa característica para uma carga de trabalho específica ajudará você a selecionar uma arquitetura multirregional apropriada.

Para cargas de trabalho com uso intenso de leitura, como conteúdo estático totalmente somente para leitura, você pode obter uma arquitetura multirregional ativa-ativa que tenha menos complexidade de engenharia quando comparada a uma carga de trabalho com muita gravação. Servir conteúdo estático na borda usando uma rede de entrega de conteúdo (CDN) garante a disponibilidade ao armazenar em cache o conteúdo mais próximo do usuário final. Usar conjuntos de recursos como failover de origem na Amazon CloudFront pode ajudar a conseguir isso. Outra opção é implantar a computação sem estado em várias regiões e usar o DNS para direcionar os usuários para a região mais próxima para ler o conteúdo. Você pode usar o Amazon Route 53 com uma política de roteamento de geolocalização para conseguir isso.

Para cargas de trabalho de leitura intensiva que têm uma porcentagem maior de tráfego de leitura do que tráfego de gravação, você pode usar uma estratégia global de leitura local e gravação. Isso significa que todas as solicitações de gravação vão para um banco de dados em uma região específica, os dados são replicados de forma assíncrona para todas as outras regiões e as leituras podem ser feitas em qualquer região. Essa abordagem exige que uma carga de trabalho adote uma consistência eventual, porque as leituras locais podem se tornar obsoletas como resultado do aumento da latência na replicação de gravações entre regiões.

Os bancos de dados globais do Aurora podem ajudar a provisionar réplicas de leitura em uma região de espera que pode lidar exclusivamente com todo o tráfego de leitura localmente e provisionar um único armazenamento de dados primário em uma região específica para lidar com o tráfego de gravação. Os dados são replicados de forma assíncrona do banco de dados principal para bancos de dados stand-by (réplicas de leitura), e os bancos de dados stand-by podem ser promovidos a primários se você precisar fazer failover de operações para a região stand-by. Você também pode usar o DynamoDB nessa abordagem. As tabelas globais do DynamoDB podem provisionar tabelas de réplica em todas as regiões, cada uma delas escalável para suportar qualquer volume de tráfego local de leitura ou gravação. Quando uma aplicação grava dados em uma tabela-réplica em uma região, o DynamoDB propaga automaticamente a gravação para as outras tabelas-réplica nas demais regiões da . Com essa configuração, os dados são replicados de forma assíncrona de uma região primária definida para tabelas de réplica em regiões em espera. As tabelas de réplica em qualquer região sempre podem aceitar gravações, portanto, a promoção de uma região de espera para primária é gerenciada no nível do aplicativo. Novamente, a carga de trabalho precisa adotar uma consistência eventual, o que pode exigir que ela seja reescrita se não tiver sido projetada para isso desde o início.

Para cargas de trabalho com muita gravação, uma região primária deve ser selecionada e a capacidade de fazer failover para uma região em espera deve ser incorporada à carga de trabalho. Em comparação com uma abordagem ativo-ativa, uma abordagem de espera primária tem vantagens adicionais. Isso ocorre porque, para uma arquitetura ativa-ativa, a carga de trabalho precisa ser reescrita para lidar com o roteamento inteligente para regiões, estabelecer afinidade de sessão, garantir transações idempotentes e lidar com possíveis conflitos.

A maioria das cargas de trabalho que usam uma abordagem multirregional para resiliência não exigirá uma abordagem ativo-ativa. Você pode usar uma estratégia de fragmentação para fornecer maior resiliência, limitando o escopo do impacto de uma deficiência em toda a base de clientes. Se você puder fragmentar efetivamente uma base de clientes, poderá selecionar diferentes regiões primárias para cada fragmento. Por exemplo, você pode fragmentar clientes para que metade dos clientes estejam alinhados à Região um e metade estejam alinhados à Região dois. Ao tratar as regiões como células, você pode criar uma abordagem celular multirregional, o que resulta na redução do escopo do impacto em sua carga de trabalho. Para obter mais informações, consulte a apresentação do AWS re:Invent sobre essa abordagem.

Você pode combinar a abordagem de fragmentação com uma abordagem de espera primária para fornecer recursos de failover para os fragmentos. Você precisará criar um processo de failover testado na carga de trabalho e também um processo de reconciliação de dados, para garantir a consistência transacional dos armazenamentos de dados após o failover. Eles serão abordados com mais detalhes posteriormente neste guia.

Orientação-chave

• Há uma grande probabilidade de que as gravações pendentes para replicação não sejam confirmadas na região de espera quando houver uma falha. Os dados ficarão indisponíveis até que a replicação seja retomada (supondo a replicação assíncrona).

• Como parte do failover, será necessário um processo de reconciliação de dados para garantir que um estado transacionalmente consistente seja mantido para armazenamentos de dados que usam replicação assíncrona. Isso requer uma lógica comercial específica e não é algo que seja tratado pelo próprio armazenamento de dados.

• Quando for necessária uma consistência forte, as cargas de trabalho precisarão ser modificadas para tolerar a latência necessária de um armazenamento de dados que se replica de forma síncrona.