Princípio fundamental da multirregião 3: Entender suas dependências de carga de trabalho

Uma carga de trabalho específica pode ter várias dependências em uma região, como dependências Serviços da AWS usadas, internas, dependências de terceiros, dependências de rede, certificados, chaves, segredos e parâmetros. Para garantir a operação da carga de trabalho durante um cenário de falha, não deve haver dependências entre a região principal e a região de espera; cada uma deve ser capaz de operar independentemente da outra. Para conseguir isso, examine todas as dependências na carga de trabalho para garantir que elas estejam disponíveis em cada região. Isso é necessário porque uma falha na região principal não deve afetar a região de espera. Além disso, você deve entender como a carga de trabalho opera quando uma dependência está em um estado degradado ou completamente indisponível, para que você possa criar soluções para lidar com isso adequadamente.

3.a: Serviços da AWS

Ao projetar uma arquitetura multirregional, é importante entender o Serviços da AWS que será usado, os recursos multirregionais desses serviços e quais soluções você precisará criar para atingir as metas multirregionais. Por exemplo, o Amazon Aurora e o Amazon DynamoDB podem replicar dados de forma assíncrona para uma região em espera. Todas as AWS service (Serviço da AWS) dependências precisarão estar disponíveis em todas as regiões nas quais uma carga de trabalho será executada. Para confirmar se os serviços que você usa estão disponíveis nas regiões desejadas, consulte a lista Serviços da AWS por região.

3.b: Dependências internas e de terceiros

Certifique-se de que as dependências internas de cada carga de trabalho estejam disponíveis nas regiões nas quais elas operam. Por exemplo, se a carga de trabalho for composta por muitos microsserviços, identifique todos os microsserviços que compõem uma capacidade de negócios e verifique se todos esses microsserviços estão implantados em cada região na qual a carga de trabalho opera. Como alternativa, defina uma estratégia para lidar com microsserviços que se tornam indisponíveis.

Chamadas entre regiões entre microsserviços dentro de uma carga de trabalho não são recomendadas, e o isolamento regional deve ser mantido. Isso ocorre porque a criação de dependências entre regiões aumenta o risco de falhas correlacionadas, o que compensa os benefícios de implementações regionais isoladas da carga de trabalho. As dependências locais também podem fazer parte da carga de trabalho, por isso é importante entender como as características dessas integrações poderiam mudar se a região principal mudasse. Por exemplo, se a região de espera estiver localizada mais longe do ambiente local, o aumento da latência poderá ter um impacto negativo.

Compreender as soluções de software como serviço (SaaS), os kits de desenvolvimento de software (SDKs) e outras dependências de produtos de terceiros e a capacidade de testar cenários em que essas dependências estejam degradadas ou indisponíveis fornecerá mais informações sobre como a cadeia de sistemas opera e se comporta em diferentes modos de falha. Essas dependências podem estar no código do seu aplicativo, como gerenciar segredos externamente usando AWS Secrets Manager, ou podem envolver uma solução de cofre de terceiros (como HashiCorp) ou sistemas de autenticação que dependem de logins federados. AWS IAM Identity Center

Ter redundância quando se trata de dependências pode aumentar a resiliência. Se uma solução SaaS ou uma dependência de terceiros usa a mesma carga primária Região da AWS da carga de trabalho, trabalhe com o fornecedor para determinar se a postura de resiliência corresponde aos requisitos da carga de trabalho.

Além disso, esteja ciente do destino compartilhado entre a carga de trabalho e suas dependências, como aplicativos de terceiros. Se as dependências não estiverem disponíveis em (ou de) uma região secundária após um failover, a carga de trabalho pode não se recuperar totalmente.

3.c: Mecanismo de failover

O DNS é comumente usado como um mecanismo de failover para transferir o tráfego da região primária para uma região em espera. Analise e examine criticamente todas as dependências que o mecanismo de failover assume. Por exemplo, se sua carga de trabalho usa o Amazon Route 53, entender que o plano de controle está hospedado em us-east-1 significa que você está se tornando dependente do plano de controle nessa região específica. Isso não é recomendado como parte de um mecanismo de failover se a região principal também for us-east-1 porque cria um único ponto de falha. Se você usar outro mecanismo de failover, deverá ter uma compreensão profunda dos cenários nos quais o failover não funcionaria conforme o esperado e, em seguida, planejar a contingência ou desenvolver um novo mecanismo, se necessário. Leia a postagem do blog Criando mecanismos de recuperação de desastres usando o Amazon Route 53 para saber mais sobre as abordagens que você pode usar para realizar um failover bem-sucedido.

Conforme discutido na seção anterior, todos os microsserviços que fazem parte de um recurso de negócios precisam estar disponíveis em cada região na qual a carga de trabalho é implantada. Como parte da estratégia de failover, todos os microsserviços que fazem parte da capacidade de negócios devem fazer o failover juntos para eliminar a chance de chamadas entre regiões. Como alternativa, se os microsserviços falharem de forma independente, existe a possibilidade de comportamentos indesejáveis, como microsserviços potencialmente fazendo chamadas entre regiões. Isso introduz latência e pode fazer com que a carga de trabalho fique indisponível durante o tempo limite do cliente.

3.d: Dependências de configuração

Certificados, chaves, segredos, Amazon Machine Images (AMIs), imagens de contêineres e parâmetros fazem parte da análise de dependência necessária ao projetar uma arquitetura multirregional. Sempre que possível, é melhor localizar esses componentes em cada região para que eles não tenham um destino compartilhado entre as regiões para essas dependências. Por exemplo, você deve variar as datas de expiração dos certificados para evitar um cenário em que um certificado expirado (com alarmes definidos para “notificar com antecedência”) afete várias regiões.

As chaves e segredos de criptografia também devem ser específicos da região. Dessa forma, se houver um erro na rotação de uma chave ou segredo, o impacto será limitado a uma região específica.

Por fim, todos os parâmetros da carga de trabalho devem ser armazenados localmente para que a carga de trabalho seja recuperada na região específica.

Orientação-chave

• Uma arquitetura multirregional se beneficia da separação física e lógica entre regiões. A introdução de dependências entre regiões na camada de aplicação elimina esse benefício. Evite essas dependências.

• Os controles de failover devem funcionar sem dependências na região principal.

• O failover deve ser coordenado em toda a jornada do usuário para eliminar a possibilidade de maior latência e dependência de chamadas entre regiões.