Criar uma arquitetura de rede geograficamente distribuída
Em um aplicativo distribuído, é essencial verificar se os componentes podem se comunicar com confiança e se as solicitações podem ser roteadas para um componente ou região diferente quando há uma falha.
Decidimos projetar novamente nosso portal de envio no Azure para reduzir sua vulnerabilidade a falhas regionais. Queremos garantir que o aplicativo faça failover em componentes em uma região secundária quando a região primária não estiver disponível. O failover deve causar interrupções mínimas na entrega de serviço aos usuários.
Aqui, aprendemos como o DNS do Azure, o Gerenciador de Tráfego, o Front Door e a CDN do Azure dão suporte à arquitetura de aplicativo da nossa empresa de transporte.
DNS do Azure
Lembre-se do que foi abordado anteriormente: não precisamos que a implementação do DNS do Azure seja alterada. Usamos o DNS do Azure para hospedar os registros de nome de domínio que identificam nosso aplicativo.
O DNS do Azure fornece a resolução de nomes inteiramente por meio da infraestrutura do Azure. Esse serviço é inerentemente de várias regiões e é por isso que não há a necessidade de modificar nossa configuração existente do DNS do Azure para dar suporte ao recurso em nosso novo design arquitetônico.
O SLA do DNS do Azure tem uma garantia de 100% de que as solicitações de DNS válidas recebem uma resposta de pelo menos um servidor de nomes DNS do Azure o tempo todo.
Escolher um roteador de tráfego
Precisamos de um serviço que possa balancear carga e redirecionar o tráfego entre várias regiões com aplicativos Web distribuídos.
O Azure fornece vários serviços diferentes que podem rotear tráfego entre componentes de front-end. Lembre-se de que precisamos substituir nosso Gateway de Aplicativo do Azure, pois ele está associado a uma única região. Se essa região falhar, não haverá nada para fazer o roteamento.
Há dois roteadores de tráfego no Azure que podem fazer o roteamento global entre várias regiões e não são vulneráveis a uma interrupção de região única:
- Gerenciador de Tráfego do Azure
- Azure Front Door
Vamos examinar esses serviços mais detalhadamente para podermos escolher o roteador correto para nosso aplicativo.
O que é o Gerenciador de Tráfego do Azure?
O Gerenciador de Tráfego do Azure é um balanceador de carga global que usa registros DNS para rotear o tráfego para destinos em várias regiões do Azure.
Podemos configurar o Gerenciador de Tráfego para rotear todas as solicitações para nossa região primária e monitorar a capacidade de resposta do Serviço de Aplicativo nessa região. Se o Serviço de Aplicativo na região primária falhar, o Gerenciador de Tráfego redirecionará automaticamente as solicitações do usuário para o Serviço de Aplicativo na região secundária. Esse redirecionamento executa o failover que garante o serviço contínuo. Chamamos essa disposição de modo de roteamento de prioridade.
Como o Gerenciador de Tráfego usa o sistema de DNS para rotear o tráfego, ele roteia qualquer protocolo, não apenas o tráfego HTTP. No entanto, o Gerenciador de Tráfego não pode rotear ou filtrar tráfego com base em propriedades HTTP, como códigos de país do cliente ou cabeçalhos de agente do usuário. Ele também não pode realizar a terminação do protocolo TLS, em que o roteador descriptografa solicitações e criptografa respostas para retirar essa carga dos servidores virtuais do Serviço de Aplicativo. Se precisarmos de qualquer um desses recursos, temos que usar o Azure Front Door.
O Gerenciador de Tráfego usa o monitoramento de ponto de extremidade altamente configurável. Por exemplo, podemos definir o protocolo, a porta, o caminho, as configurações de cabeçalho personalizadas, os intervalos de código de status esperados e o número de falhas toleradas. O monitoramento de ponto de extremidade nos dá uma ideia contínua da integridade geral de todas as partes do nosso aplicativo.
O que é o Azure Front Door?
Como o Gerenciador de Tráfego, o Azure Front Door é um balanceador de carga global. Ao contrário do Gerenciador de Tráfego, ele funciona na camada de aplicativo de rede, Camada 7, e usa as propriedades HTTP e HTTPS para fazer a filtragem e o roteamento.
Com o Front Door, podemos fazer muitos tipos de roteamento não compatíveis com o Gerenciador de Tráfego. Por exemplo, podemos rotear o tráfego com base no código de país do navegador. O Front Door também dá suporte à terminação do protocolo TLS.
No entanto, há uma exceção. Se desejamos rotear o tráfego de qualquer protocolo diferente do HTTP e HTTPS, precisamos usar o Gerenciador de Tráfego.
Com o Front Door, podemos atribuir prioridades aos vários back-ends que compõem o portal de acompanhamento. Essas prioridades permitem que o Front Door roteie solicitações conforme necessário. Atribuímos nossos serviços de região primária com uma prioridade mais alta e nosso serviço de região secundária com uma prioridade mais baixa.
O Front Door implementa investigações de integridade para monitorar o status de integridade de nossos serviços e, se houver uma falha, ele poderá rotear o tráfego corretamente. O modo de roteamento de prioridade e o monitoramento de ponto de extremidade no Front Door são semelhantes a esses recursos no Gerenciador de Tráfego, exceto que as investigações de integridade sempre funcionam por HTTP.
Todo o tráfego para a interface do usuário da Web do portal de envio e suas APIs são realizados por HTTPS e permitem mudar o Gerenciador de Tráfego do Azure com o Front Door. Também podemos configurar o Front Door com a atribuição de back-end de prioridade.
CDN do Azure
Em nossa arquitetura de região única, usamos a CDN do Azure para armazenar em cache conteúdo estático do Armazenamento de Blobs do Azure. O serviço da CDN do Azure é uma rede global de servidores que armazena em cache conteúdo estático próximo dos usuários. Não precisamos modificar esse serviço para a arquitetura de várias regiões. No entanto, há considerações com relação à nossa conta do Armazenamento do Azure que abordaremos na próxima unidade.