Criar uma arquitetura de aplicação distribuída geograficamente
Quando os nossos componentes de rede encaminham pedidos para várias regiões para atenuar os efeitos de um período de indisponibilidade regional, devemos estruturar os serviços aplicacionais que podem responder a esses pedidos nas regiões primária e de reserva.
Lembre-se de que planejamos configurar o Azure Front Door com atribuição de back-end prioritária. Atribuímos a região Leste dos EUA como nossa região principal e a região Oeste dos EUA como nossa região de espera. Quando ocorre uma falha regional, as solicitações são encaminhadas para o Serviço de Aplicativo na região sem falha. Precisamos de configurar recursos em cada região para suportar estas ativações pós-falha para acesso do utilizador, armazenamento replicado e código da aplicação.
Aqui, examinamos os serviços de aplicativos em nossa solução e determinamos se eles precisam ser modificados para funcionar em uma arquitetura de várias regiões. Especificamente, examinamos o Ative Directory, armazenamento de conteúdo estático, aplicativos Web, APIs Web, filas, funções do Azure e caches de dados.
Microsoft Entra ID
No nosso portal de monitorização de envios, os utilizadores podem monitorizar a entrega das suas compras ao introduzirem um número de controlo. No entanto, os utilizadores normais podem registar-se (subscrever) para aceder a funcionalidades avançadas, como a rapidez de entrega e outras estatísticas. Desenvolvemos o portal de rastreamento para armazenar contas de usuário no Microsoft Entra ID.
O Microsoft Entra ID foi projetado como um sistema global por padrão. Como tal, não é vulnerável a falhas regionais e não precisamos de modificar este componente do sistema.
Armazenamento de Blobs do Azure
Os conteúdos estáticos, como imagens e vídeos, são armazenados em contas de Armazenamento do Azure como Blobs (objetos binários grandes) e apresentados aos utilizadores através da CDN do Azure.
No nosso projeto original, a conta de armazenamento está numa única região porque optamos por utilizar o Armazenamento Localmente Redundante (LRS). Os nossos dados são replicados apenas num único datacenter com LRS. Portanto, a conta de armazenamento está indisponível se existir uma falha regional nesta configuração. Qualquer conteúdo estático já armazenado em cache pela CDN permanece disponível para os usuários.
O mesmo se aplica ao Armazenamento com Redundância entre Zonas (ZRS). Embora os dados sejam replicados para datacenters diferentes nesta configuração, todos estes datacenters ainda estão na mesma região. Uma interrupção regional também afeta a conta de armazenamento nessa configuração.
No nosso projeto, dependemos da configuração da nossa CDN para colocar conteúdos estáticos em cache. Durante uma falha, é possível que um utilizador peça um ficheiro estático que ainda não está na cache da CDN. Este pedido iria resultar num gráfico ou vídeo que não pode ser apresentado.
Podemos eliminar esta possibilidade ao replicar a conta de armazenamento para múltiplas regiões quando selecionarmos uma opção de armazenamento georredundante. Uma opção de replicação somente leitura também está disponível para evitar a adição de conteúdo estático durante uma interrupção regional.
Temos duas opções quando precisamos de ativar a georredundância. Essas opções são RA-GRS (Read-Access Geo-Redundant Storage) e RA-GZRS (Read-Access Geo-Zone-Redundant Storage). A escolha que fazemos depende do nosso orçamento e da percentagem de tempo de atividade de que precisamos.
Serviço de Aplicações do Azure e Aplicações de Funções do Azure
O nosso portal de controlo de envios implementa dois Serviços de Aplicações do Azure. O primeiro Serviço de Aplicativo hospeda um aplicativo Web que implementa a interface Web voltada para o usuário e o segundo hospeda uma API Web usada por aplicativos móveis para rastrear dados de remessas. Todas as nossas tarefas em segundo plano são executadas como Aplicações de Funções do Azure.
No nosso projeto original, cada Serviço de Aplicações do Azure está localizado numa única região do Azure. Criamos um segundo Serviço de Aplicativo na região secundária (Oeste dos EUA) e implantamos o projeto Web lá para dar suporte à nova arquitetura multirregião. Configuramos o modo de roteamento prioritário do Azure Front Door para enviar solicitações para nossa região secundária quando a região primária não estiver disponível.
Para garantir que a ativação pós-falha ocorre sem problemas, certifique-se de que a aplicação Web não armazena informações de estado de sessão na memória. Alteramos o nosso site para garantir que não acabamos com perda de dados. Por exemplo, se nosso código armazena uma lista das remessas dos usuários na memória, essa lista será perdida se ocorrer um failover.
Cada pedido Web é processado sem afetar o outro quando não é armazenado um estado de sessão. Se a ativação pós-falha ocorrer no meio da sessão de um utilizador, a ativação pós-falha deve ser transparente para o utilizador.
Fazemos uma alteração semelhante aos nossos aplicativos do Azure Function. Criamos uma instância separada da Função do Azure na região secundária e implantamos o mesmo código personalizado que é executado na região primária.
Importante
Quando implementa uma atualização ao código personalizado no Serviço de Aplicações ou serviço de Aplicação de Funções, lembre-se de o distribuir para todas as instâncias do Serviço de Aplicações. Se quiser automatizar este processo, o Azure DevOps tem ferramentas que podem ajudar.
Filas de Armazenamento do Azure
Na nossa arquitetura original de uma única região, utilizámos uma fila numa conta de Armazenamento do Azure para gerir comunicações entre o Serviço de Aplicações e a aplicação de funções. Quando a aplicação Web ou a API Web precisa de executar uma tarefa em segundo plano, coloca uma mensagem com todas as informações necessárias na fila. A aplicação de funções monitoriza a fila para ver novas mensagens e executa a tarefa em segundo plano ao executar as consultas necessárias nos arquivos de dados.
Podemos gerir uma elevada procura de pedidos Web metodicamente quando utilizamos uma fila desta forma. Quando há muitas tarefas em segundo plano para executar, a fila pode se acumular, mas as tarefas não são descartadas. Eles ficam na fila até serem processados. As aplicações de funções percorrem a fila e reduzem o seu tamanho quando a procura diminui. Se a demanda persistir, aumentamos o número de instâncias do aplicativo de função.
Para a versão de múltiplas regiões do portal de controlo de envios, temos de garantir que os itens da fila não são perdidos quando a ativação pós-falha ocorre. A nossa fila é definida no Armazenamento do Azure e podemos utilizar uma opção de redundância para georreplicação.
Tenha em atenção que não podemos utilizar uma opção de redundância de acesso de leitura, pois a nossa fila suporta operações de leitura e escrita. O Serviço de Aplicações tem de adicionar itens à fila e a aplicação de funções tem de remover os itens concluídos da fila. Utilize o Armazenamento Georredundante (GRS) ou Armazenamento com Georredundância de Zona (GZRS).
Cache de Redis do Azure
Estamos a utilizar a Cache do Azure para Redis para maximizar o desempenho do armazenamento de dados. O Redis coloca em cache todos os resultados da consulta gerados a partir das nossas aplicações à medida que pedem dados da nossa base de dados. Quaisquer consultas adicionais para dados semelhantes não precisam de uma consulta de banco de dados e são buscadas no cache Redis.
Para a arquitetura de várias regiões, criamos uma instância de Cache Redis em regiões primárias e em espera. Tenha em atenção que quando a ativação pós-falha ocorre, a Cache de Redis na região de reserva deve estar vazia. Esse cache vazio não causa erros, mas o desempenho pode cair temporariamente, à medida que os dados preenchem o novo cache.