Exercício: Expandir seu design para diversas regiões

30 minutos

A Contoso Shoes precisa resistir a interrupções regionais. Você deseja implantar o selo atual em uma topologia multirregional ativa-ativa de estado compartilhado. Ela deve ser projetada para redirecionar o tráfego para outra região em caso de falha.

Estado atual e problema

Uma única região tem sido suficiente para o aplicativo. No entanto, uma recente interrupção regional que afetou a rede fez com que o sistema ficasse offline da perspectiva do usuário final. A escala horizontal dentro da região, ou mesmo a implantação de um novo selo nessa região, não teria recuperado o aplicativo do estado de 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 Aplicativos de back-end (apicontososhoes.azurewebsites.net) com TTL (vida útil) de dois dias. Quando a solução é implantada em diversas regiões, o DNS precisa ser migrado.

Especificação

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

Abordagem recomendada

Para começar a usar o seu design, recomendamos que você siga estas etapas:

1–Topologia multirregional

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

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

Em caso de falha, tome um tempo para pensar a respeito da situação. Suponha que a Região 1 receba 75% do tráfego e a Região 2 recém-adicionada receba o tráfego restante. Ambas foram dimensionadas adequadamente para lidar com essa carga. Há uma interrupção regional na Região 1 e todo o tráfego agora é roteado para a Região 2. É possível fazer essa transição ocorrer sem problemas? A região 2 pode dar suporte a essa carga de tráfego aumentada?

Verifique seu progresso: Distribuição global

2 – Roteamento global

Para que os clientes sejam roteados de maneira transparente para qualquer uma das regiões 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 a solicitações frequentes e semelhantes sem que elas cheguem ao back-end?

Escolha um serviço nativo do Azure que se integre à arquitetura existente e seja capaz de fazer failover rapidamente.
Verifique se o caminho de entrada de rede tem controles para negar o tráfego não autorizado.
Minimize a latência da rede atendendo aos usuários finais em 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 falha. Além disso, seja notificado quando a região estiver disponível novamente para que o balanceador de carga possa retomar o roteamento para ela.

Verifique seu progresso: Roteamento de tráfego global

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

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

Certos serviços na arquitetura atual têm recursos de replicação geográfica. Considere separar os serviços em selos diferentes: um carimbo que contém recursos globais e outro selo 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? Ele deve sobreviver ou compartilhar 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. É possível começar a usar esses recursos e fazer explorações adicionais para maximizar a confiabilidade.

Serviço do Azure	Recurso
Azure Cosmos DB	Gravação multirregional
Registro de Contêiner do Azure	Replicação geográfica
Plano do Serviço de Aplicativo do Azure	Suporte à zona de disponibilidade

Verifique seu progresso: Plataforma de aplicativo | Plataforma de dados

Verificar seu trabalho

Veja as escolhas a seguir de design de Aplicativo e Dados para uma arquitetura semelhante. Você cobriu todos os aspectos do projeto?

Qual outra região do Azure você selecionou para a topologia multirregional e por quê?
Você habilitou duas ou mais zonas de disponibilidade do Azure em cada região do Azure para proteger-se contra interrupções do datacenter?
Você incluiu o Firewall de Aplicativo Web para controlar o tráfego de entrada? Quais regras de roteamento estão em vigor e por quê?
Como o balanceador de carga dá suporte ao registro DNS existente?
Como você usou a API de verificação de integridade do exercício anterior?
Você protegeu o aplicativo contra ataques DDoS, especialmente impedindo que clientes mal-intencionados ignorem o balanceador de carga e acessem instâncias regionais?
Como você abordou a migração do DNS?
Você fez alguma alteração de SKU no componente existente para dar suporte à topologia multirregional?
Quais serviços do Azure você deixou como singletons? Como você justificou sua escolha para cada serviço? Você fez alguma alteração na configuração?
Você está registrando recursos? Você acha que isso afetará sua capacidade de inspecionar os logs do sistema geral?