Exercício - Expanda o seu design para várias regiões

30 minutos

A Contoso Shoes precisa de uma maneira de resistir a interrupções regionais. Você deseja implantar o carimbo atual em uma topologia ativa, de estado compartilhado e de várias regiões. A arquitetura deve ser projetada para redirecionar o tráfego para outra região no caso de uma região falhar.

Estado atual e problema

Uma única região foi suficiente para a aplicação. No entanto, uma recente interrupção regional que afetou a rede fez com que o sistema ficasse offline do ponto de vista do usuário final. O dimensionamento horizontal dentro da região — ou mesmo a implantação de um novo carimbo nessa região — não teria recuperado o aplicativo do estado com falha.

O DNS é mantido por um registrador existente para api.contososhoes.com. O registro DNS é resolvido para o ponto de extremidade dos Serviços de Aplicativo de back-end (apicontososhoes.azurewebsites.net) com um período de tempo de vida útil (TTL) de dois dias. Quando a solução é implantada em várias regiões, o DNS precisa ser migrado.

Especificação

Estenda a arquitetura para trabalhar em uma topologia ativa-ativa e multirregional.
Modifique o modelo de carimbo de implantação que permite adicionar e remover regiões dinamicamente conforme necessário, em vez de uma lista de recursos codificados em duas regiões.
Se houver uma falha regional, o tráfego precisa ser roteado para a região sem falhas sem qualquer impacto notável para os clientes que já estão na região sem falhas.
Os clientes não devem ser fixados a uma região.
Os clientes não precisam alterar URLs para entrar em contato com a API. O DNS deve ser migrado para o roteador global.

Abordagem recomendada

Para começar a desenvolver o seu design, recomendamos que siga estes passos:

1–Topologia multirregião

A arquitetura deve ser distribuída para duas ou mais regiões do Azure para proteger contra interrupções regionais. Considere estes fatores ao escolher uma região:

A região deve ser capaz de resistir a interrupções do datacenter nessa região.
Os serviços do Azure e os recursos usados na arquitetura devem ter suporte na região.
A região e os recursos implantados na região devem ter proximidade com os usuários finais e sistemas dependentes para minimizar a latência da rede.

Pense em um cenário de fracasso. Suponha que a Região 1 recebe 75% do tráfego e a Região 2 recém-adicionada recebe o tráfego restante. Ambos são dimensionados adequadamente para lidar com essa carga. Há uma interrupção regional na Região 1 e todo o tráfego agora é encaminhado para a Região 2. Você pode fazer essa transição suave? A Região 2 pode suportar esse aumento da carga de tráfego?

Verifique o seu progresso: Distribuição global

2–Roteamento global

Para que os clientes sejam roteados de forma transparente para qualquer região de trabalho, adicione um balanceador de carga global. O balanceador de carga deve usar as verificações de integridade que você adicionou no exercício anterior para determinar se um carimbo está íntegro. Você consegue pensar em maneiras de atender solicitações frequentes e semelhantes que podem ser atendidas sem chegar ao backend?

Escolha um serviço nativo do Azure que se integre com a arquitetura existente e seja capaz de fazer failover rapidamente.
Verifique se o caminho de entrada na rede tem controles para negar o tráfego não autorizado.
Minimize a latência da rede atendendo aos usuários finais a partir de um cache de borda.
Migre o DNS existente sem afetar os clientes existentes.
Tenha uma maneira automatizada de indicar uma falha regional para garantir que o tráfego não seja roteado para a região com defeito. Além disso, seja notificado quando a região estiver disponível novamente para que o balanceador de carga possa retomar o roteamento para essa região.

Verifique o seu progresso: Roteamento de tráfego global

3 – Alterações de carimbo de implantação

O estado ideal é uma configuração ativo-ativo que não requer nenhum failover manual e as solicitações do cliente podem ser atendidas de qualquer região. Pense no que isso implica para a sua arquitetura. Por exemplo, você tem algum estado que está armazenado no selo regional?

Determinados serviços na arquitetura atual têm recursos de replicação geográfica. Considere separar os serviços em carimbos diferentes: um carimbo que contém recursos globais e outro carimbo regional que compartilha recursos com o selo global. Um dos fatores decisivos deve ser o ciclo de vida desses recursos. Qual é o tempo de vida esperado do recurso em relação a outros recursos na arquitetura? O recurso deve sobreviver ou partilhar o tempo de vida com todo o sistema ou região, ou deve ser temporário?

Explore os recursos de confiabilidade dos serviços do Azure usados na arquitetura. Você pode começar com esses recursos e explorar mais para maximizar a confiabilidade.

Serviço do Azure	Caraterística
Azure Cosmos DB	Gravação em várias regiões
Registo de Contentores do Azure	Georreplicação
Plano do Serviço de Aplicações do Azure	Suporte à zona de disponibilidade

Verifique o seu progresso: Plataforma | de aplicação Plataforma de dados

Verifique o seu trabalho

Aqui estão as opções de design de aplicativos e dados para uma arquitetura semelhante. Cobriu todos os aspetos do seu projeto?

Que outra região do Azure você selecionou para sua topologia de várias regiões e por quê?
Você habilitou duas ou mais Zonas de Disponibilidade do Azure em cada região do Azure para proteger contra interrupções do datacenter?
Você incluiu o Web Application Firewall para controlar o tráfego de entrada? Que regras de encaminhamento implementou e porquê?
Como é que o balanceador de carga suporta o seu registo DNS existente?
Como você usou sua API de verificação de saúde do exercício anterior?
Você protegeu o aplicativo contra ataques DDoS, especialmente impedindo que clientes mal-intencionados contornassem o balanceador de carga e alcançassem instâncias regionais?
Como você abordou a migração de DNS?
Você fez alguma alteração de SKU no componente existente para oferecer suporte à topologia de várias regiões?
Quais serviços do Azure você deixou como singletons? Como justificou a sua escolha para cada serviço? Fez alguma alteração de configuração?
Você está registrando recursos? Você acha que isso afetará sua capacidade de inspecionar os logs para o sistema geral?