Criar uma arquitetura de aplicativo geograficamente distribuído
Quando nossos componentes de rede roteiam solicitações para várias regiões para atenuar os efeitos de uma interrupção regional, deveremos criar serviços de aplicativos que possam responder a essas solicitações em regiões primárias e em espera.
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 primária e a região Oeste dos EUA como nossa região em espera. Quando ocorre uma falha regional, as solicitações são roteadas para o Serviço de Aplicativo na região onde não há falha. Precisamos configurar recursos em cada região para dar suporte a esses failovers para acesso do usuário, armazenamento replicado e código do aplicativo.
Aqui, examinamos os serviços de aplicativo em nossa solução e determinamos se eles precisam ser modificados para funcionar em uma arquitetura de várias regiões. Especificamente, examinamos o Active Directory, o armazenamento de conteúdo estático, os aplicativos Web, as APIs Web, as filas, as funções do Azure e os caches de dados.
Microsoft Entra ID
Em nosso portal de acompanhamento de envio, os usuários podem acompanhar a entrega de suas compras inserindo um número de acompanhamento. No entanto, os usuários regulares podem registrar-se na associação para acessar recursos avançados, como a solicitação de entrega e outras estatísticas. Desenvolvemos o portal de acompanhamento para armazenar contas de usuário no Microsoft Entra ID.
O Microsoft Entra ID é projetado como um sistema global por padrão. Como tal, não é vulnerável a falhas regionais e não precisamos modificar esse componente do sistema.
Armazenamento de Blobs do Azure
O conteúdo estático, como imagens e vídeos, é armazenado em contas do Armazenamento do Azure como Blobs (Objetos Grandes Binários) e fornecido aos usuários por meio da CDN do Azure.
Em nosso design original, a conta de armazenamento está contida em uma única região, porque optamos por usar o LRS (Armazenamento com Redundância Local). Nossos dados são replicados somente em um único datacenter com o LRS. A conta de armazenamento, portanto, não estará disponível se houver uma interrupção regional nessa configuração. Qualquer conteúdo estático já armazenado em cache pela CDN permanece disponível para os usuários.
O mesmo é verdadeiro do ZRS (Armazenamento com Redundância de Zona). Embora os dados sejam replicados para data centers diferentes nessa configuração, todos esses data centers ainda estarão na mesma região. Uma interrupção regional também afeta a conta de armazenamento nessa configuração.
Em nosso design, dependemos muito da configuração da CDN para armazenar em cache o conteúdo estático. Há uma possibilidade de que, durante uma interrupção, um usuário possa solicitar um arquivo estático que ainda não está no cache da CDN. Essa solicitação resultaria em um gráfico ou vídeo que não pode ser exibido.
Poderemos eliminar essa possibilidade replicando a conta de armazenamento para várias regiões quando escolhermos uma opção de armazenamento com redundância geográfica. 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.
Teremos duas opções para escolher quando precisarmos habilitar a redundância geográfica. Essas opções são o RA-GRS (Armazenamento com Redundância Geográfica com Acesso de Leitura) e o RA-GZRS (Armazenamento com Redundância de Zona Geográfica com Acesso de Leitura). A opção que fazemos depende do nosso orçamento e do percentual do tempo de atividade de que precisamos.
Serviço de Aplicativo do Azure e Aplicativo de Funções do Azure
Nosso portal de acompanhamento de envios implementa dois Serviços de Aplicativos do Azure. O primeiro Serviço de Aplicativo hospeda um aplicativo Web que implementa a interface da Web voltada para o usuário e o segundo hospeda uma API Web usada por aplicativos móveis para acompanhar os dados dos envios. Todas as nossas tarefas em segundo plano são executadas como aplicativos de funções do Azure.
Em nosso design original, cada Serviço de Aplicativo do Azure é localizado para uma ú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 de várias regiões. Configuramos o modo de roteamento prioritário do Azure Front Door para enviar solicitações para nossa região secundária quando a primária não estiver disponível.
Para que o failover seja o mais natural possível, verifique se o aplicativo Web não armazena nenhuma informação de estado de sessão na memória. Alteramos nosso site para garantir que não acabamos com uma perda de dados. Por exemplo, se o código armazenasse uma lista dos envios dos usuários na memória, essa lista seria perdida se ocorresse um failover.
Cada solicitação da Web é manipulada sem afetar a outra quando nenhum estado de sessão é armazenado. Se ocorrer um failover no meio de uma sessão do usuário, o failover deverá ser transparente para o usuário.
Fazemos uma alteração semelhante em nossos aplicativos de funções do Azure. Criamos uma instância separada da Função do Azure na região secundária e implantamos nela o mesmo código personalizado executado na região primária.
Importante
Quando você implanta um aplicativo no código personalizado no Serviço de Aplicativo ou no serviço do Aplicativo de Funções, lembre-se de distribuí-lo para todas as instâncias do Serviço de Aplicativo. Se desejar automatizar esse processo, o Azure DevOps tem ferramentas que podem ajudar.
Filas de Armazenamento do Azure
Em nossa arquitetura de região única, usamos uma fila em uma conta de Armazenamento do Azure para gerenciar comunicações entre o Serviço de Aplicativo e o aplicativo de funções. Quando o aplicativo Web ou a API Web precisa executar uma tarefa em segundo plano, coloca uma mensagem com todas as informações necessárias na fila. O aplicativo de funções monitora a fila para ver se há novas mensagens e executa a tarefa em segundo plano executando as consultas necessárias nos armazenamentos de dados.
Podemos gerenciar uma alta demanda nas solicitações da Web de maneira ordenada quando usamos uma fila dessa forma. Quando existem muitas tarefas em segundo plano a serem executadas, a fila pode aumentar, mas as tarefas não são removidas. Elas permanecem na fila até serem processadas. Os aplicativos de funções operam na fila e reduzem seu tamanho quando a demanda cai. Se a demanda persiste, aumentamos o número de instâncias do aplicativo de funções.
Para a versão de várias regiões do portal de acompanhamento de envios, devemos verificar se os itens da fila não são perdidos quando ocorre um failover. Nossa fila é definida no Armazenamento do Azure e podemos usar uma opção de redundância para replicação geográfica.
Tenha em mente que não podemos usar uma opção de redundância com acesso de leitura, pois nossa fila dá suporte a operações de leitura e gravação. O Serviço de Aplicativo deve adicionar itens à fila e o aplicativo de funções deve remover itens concluídos dela. Use o GRS (Armazenamento com Redundância Geográfica) ou o GZRS (Armazenamento com Redundância de Zona Geográfica).
Cache Redis do Azure
Estamos usando o Cache Redis do Azure a fim de maximizar o desempenho do armazenamento de dados. O Redis armazena em cache todos os resultados da consulta gerados dos nossos aplicativos à medida que solicitam dados de nosso banco de dados. Qualquer consulta adicional para dados semelhantes não precisa de uma consulta de banco de dados e é buscada no cache Redis.
Para a arquitetura de várias regiões, criamos uma instância do cache Redis nas regiões primária e em espera. Tenha em mente que, quando ocorrer um failover, o Cache Redis na região em espera provavelmente estará vazio. Esse cache vazio não causa nenhum erro, mas o desempenho pode cair temporariamente à medida que os dados preenchem o novo cache.