Exercício: Expandir seu design para diversas regiões
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. O dimensionamento horizontal dentro da região ou mesmo a implantação de um novo selo nela 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 o design, recomenda-se seguir as etapas a seguir.
1 – Topologia
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 nela.
- 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 que você adicionou receba o 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. As verificações de integridade que você adicionou no exercício anterior devem ser usadas pelo balanceador de carga para determinar se um selo 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 ativa-ativa que não requer nenhum failover manual na qual as solicitações do cliente podem 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 selo que contém recursos globais. O 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?