Criar uma arquitetura distribuída geograficamente
O Azure é um sistema global. Ao criar uma arquitetura que esteja presente em mais de uma região do Azure, podemos criar uma aplicação que seja resiliente até mesmo a desastres ao nível da região.
O seu portal de monitorização de envios é dimensionável porque é criado com uma variedade de recursos do Azure que podem ser dimensionados. Também é resistente a muitas falhas porque seus componentes podem ter várias instâncias. No entanto, seu conselho de administração ficou preocupado que um desastre em grande escala possa causar uma interrupção porque o portal está totalmente contido na região Leste dos EUA Azure. Quer propor uma arquitetura modificada que possa efetuar a ativação pós-falha numa segunda região, caso a região E.U.A. Leste falhe.
Aqui, aprendemos como ajustar a arquitetura do nosso aplicativo para suportar um aplicativo distribuído geograficamente. Também vemos por que essa arquitetura é vantajosa para aplicativos críticos para os negócios.
Arquitetura de aplicação Web original
Vamos dar uma olhada em como o projeto arquitetônico do portal de rastreamento e os componentes usados na solução. Depois de entendermos como usamos todas as partes, podemos investigar como dar suporte a cada um desses componentes em cenários de redundância geográfica.
O design do portal de acompanhamento é baseado na arquitetura de referência mostrada no diagrama a seguir.
Repare como a nossa aplicação utiliza um único grupo de recursos do Azure. Este grupo de recursos permite-nos agrupar e gerir todos os nossos recursos de forma lógica e simplifica a gestão. Optámos por implantar este grupo de recursos na região E.U.A. Leste. Embora o grupo de recursos não nos limite a utilizar a mesma região do Azure para os recursos incluídos, decidimos utilizar a região E.U.A. Leste para todos os recursos implementados na nossa aplicação.
A nossa aplicação utiliza três categorias de recursos do Azure. Vamos dar uma olhada em cada categoria e ver quais recursos estão em uso.
Componentes de rede
O portal de rastreamento usa os seguintes serviços de rede.
| Serviço | Description |
|---|---|
| Azure DNS | Configurámos o DNS do Azure para alojar os nossos registos DNS no Azure. O DNS do Azure permite-nos gerir os nossos registos DNS utilizando as nossas credenciais do Azure no portal do Azure. |
| Gateway de Aplicação | Configurámos o balanceador de carga do Gateway de Aplicação para balancear o tráfego entre várias instâncias do front-end da Web. Este serviço está localizado numa região do Azure. |
| CDN do Azure | Configurámos a CDN do Azure para maximizar a entrega de conteúdos estáticos não seguros, como gráficos para os conteúdos do nosso site. Este serviço global armazena em cache conteúdo estático em pontos de presença em todo o mundo. |
Componentes de aplicações
O portal de monitorização utiliza os seguintes serviços para suportar o código, a cache e os requisitos de armazenamento intermédios.
| Serviço | Description |
|---|---|
| Microsoft Entra ID | Os usuários acessam o portal de rastreamento usando contas do Microsoft Entra. O diretório e a conta são replicados automaticamente de forma global. |
| Serviço de Aplicações do Azure | O portal de monitorização utiliza dois Serviços Aplicacionais do Azure. O primeiro executa um conjunto de páginas da Web dinâmicas e o segundo uma API da Web. |
| Aplicações de Funções do Azure | O portal de monitorização utiliza as Aplicações de Funções do Azure para executar todas as tarefas em segundo plano. Algumas destas tarefas são executadas regularmente e outras tarefas operam nas mensagens numa fila. |
| Filas de Armazenamento do Azure | O portal de acompanhamento usa as Filas de Armazenamento do Azure com os Aplicativos de Função do Azure. O portal de monitorização coloca as mensagens geradas na fila de onde as aplicações de funções processam essas mensagens. |
| Cache de Redis | O portal de monitorização utiliza uma cache de Redis entre o serviço de aplicação de front-end e os sistemas de armazenamento de dados para maximizar o desempenho das consultas. |
| Armazenamento de Blobs do Azure | O conteúdo estático, como gráficos e arquivos de vídeo, é mantido como Blobs (Objetos Grandes Binários) em uma conta de Armazenamento do Azure e é entregue por meio da CDN do Azure. |
| Azure Search | Ativámos o Azure Search no portal de monitorização. A Pesquisa do Azure permite-nos tornar todo o conteúdo pesquisável e fornecer sugestões de pesquisa e resultados de pesquisa difusos aos nossos utilizadores. |
Componentes de armazenamento de dados
O portal de rastreamento usa os seguintes serviços de armazenamento persistente.
| Serviço | Description |
|---|---|
| Base de Dados SQL do Azure | Estamos a armazenar dados relacionais, tais como detalhes de encomendas e clientes na base de dados SQL do Azure. |
| Cosmos DB | Estamos a armazenar dados semiestruturados, incluindo o nosso catálogo de produtos, no Cosmos DB. |
Problemas com a arquitetura original
A arquitetura existente para o portal de monitorização foi concebida para permitir a escalabilidade e a disponibilidade.
Por exemplo, se a demanda for alta e as respostas às solicitações da Web do usuário forem lentas, você poderá considerar a adição de mais instâncias do aplicativo Web front-end no Serviço de Aplicativo. Aqui, o Gateway de Aplicação pode encaminhar pedidos para essas instâncias criadas recentemente.
No entanto, há cenários em que o nosso projeto arquitetónico tem desafios a ultrapassar, ou mesmo a falhar. Vamos analisar cada um dos cenários para compreender melhor o impacto no portal de monitorização.
Falhas regionais
Alguns eventos significativos têm o potencial de interromper uma região inteira do Azure. Os datacenters do Azure são projetados para serem altamente resilientes, mas um evento climático massivo, como um furacão ou inundação, pode interromper o serviço da região.
Estes eventos são ocorrências invulgares e muitas empresas acham que podem resistir a esse risco. No entanto, a consequência de uma falha regional desativar o portal de controlo tem um risco elevado e a equipa executiva decidiu eliminar o risco.
Acordos de Nível de Serviços
A maioria dos serviços do Azure oferece um Contrato de Nível de Serviço (SLA) ou uma garantia de tempo de atividade. Quando criamos uma arquitetura de aplicação que consiste em múltiplos serviços do Azure, calculamos o SLA global da aplicação como um composto de todos os SLAs de outros serviços.
Pode calcular este SLA ao multiplicar os SLAs dos serviços de componentes. Por exemplo, suponha que nosso aplicativo consiste no Serviço de Aplicativo do Azure (SLA de 99,95%) e no ID do Microsoft Entra (SLA de 99,9%). O SLA calculado final é de 99,85%.
Se esta percentagem de tempo de atividade não for suficiente para a nossa aplicação, podemos fazer com que a aplicação efetue a ativação pós-falha para outra região.
Componentes globais, regionais e configuráveis
No nosso projeto, alguns componentes são globais por predefinição e não são vulneráveis a uma falha regional.
Alguns componentes estão limitados a uma única região, por exemplo, o Gateway de Aplicação. Temos que selecionar um serviço alternativo para esses tipos de componentes.
Alguns componentes podem ser configurados para suportar múltiplas regiões. Por exemplo, podemos utilizar a opção Armazenamento Georredundante (GRS) na conta de Armazenamento do Azure que armazena conteúdos estáticos. O GRS replica blobs para outra região.
A tabela a seguir mostra quais componentes são globais, regionais e configuráveis.
| Componente | Suporte para múltiplas regiões | Comentários |
|---|---|---|
| Azure DNS | Global | Não são necessárias alterações. |
| Gateway de Aplicação | Regional | Cada instância do Gateway de Aplicação está localizada numa única região. |
| CDN do Azure | Global | Nenhuma alteração é necessária, o conteúdo é armazenado em cache globalmente por padrão. |
| Microsoft Entra ID | Global | Não são necessárias alterações. |
| Serviço de Aplicações do Azure | Regional | Cada instância da aplicação está localizada numa única região. |
| Aplicações de Funções do Azure | Regional | Cada instância da aplicação de funções está localizada numa única região. |
| Filas de Armazenamento do Azure | Configurável | Você pode optar por replicar uma conta de Armazenamento do Azure para várias regiões. |
| Cache de Redis do Azure | Regional | Cada instância da cache está localizada numa única região. |
| Armazenamento de Blobs do Azure | Configurável | Você pode optar por replicar uma conta de Armazenamento do Azure para várias regiões. |
| Azure Search | Regional | Cada instância do serviço de pesquisa está localizada numa única região. |
| Base de Dados SQL do Azure | Configurável | Você pode usar a replicação geográfica para sincronizar dados com várias regiões. |
| BD do Cosmos para o Azure | Configurável | Você pode usar a replicação geográfica para sincronizar dados com várias regiões. |
Arquitetura distribuída proposta
Após alguma investigação, você propõe a arquitetura conforme mostrado no diagrama a seguir.
Neste projeto, existe uma região ativa (E.U.A. Leste) e uma região de reserva (E.U.A. Oeste). A região E.U.A Leste processa todos os pedidos feitos pelos componentes em circunstâncias normais. Se um desastre causar uma falha regional, a aplicação efetua a ativação pós-falha para a região E.U.A. Oeste.
Vamos examinar, de modo geral, como modificou a arquitetura original. Exploramos essas mudanças com mais detalhes em unidades posteriores.
Rede
O DNS do Azure e CDN do Azure são sistemas globais por predefinição e são resilientes a falhas regionais. Deixamo-los no lugar.
Quando criamos um Gateway de Aplicação do Azure, atribuímos o serviço a uma única região. Removemos esta vulnerabilidade substituindo este serviço pelo Azure Front Door. O Front Door pode pesquisar vários Serviços de Aplicativo e lidar com o failover do Serviço de Aplicativo da região Leste dos EUA para a região Oeste dos EUA.
Serviço de aplicações
O Microsoft Entra ID é um sistema global e não precisa de modificação.
As contas de Armazenamento do Azure podem ser configuradas para replicar conteúdos para múltiplas regiões. Usamos uma das opções de armazenamento com redundância geográfica para alterar nossa configuração.
Os outros componentes, que incluem o Serviço de Aplicações, Aplicações de Funções, Cache de Redis e Azure Search, são regionais. Criamos instâncias duplicadas desses componentes na região Oeste dos EUA em nosso novo projeto arquitetônico. Neste projeto, a nova região pode assumir o controlo quando a ativação pós-falha ocorrer.
Armazenamento de dados
A Base de Dados SQL do Azure e o Azure Cosmos DB suportam a georreplicação de dados para outras regiões. Configuramos esses serviços para replicar dados do Leste dos EUA para os serviços equivalentes no Oeste dos EUA.
Pares regionais
Uma região do Azure é uma área com uma única geografia que contém um ou mais datacenters do Azure. Todas as regiões são emparelhadas com outras regiões na mesma geografia. Nestes pares, as atualizações e a manutenção planeada são efetuadas em apenas uma região de cada vez. Se existir uma falha que afeta múltiplas regiões, pelo menos uma região em cada par tem prioridade para recuperação rápida.
A prática recomendada é utilizar uma arquitetura de duas regiões para a sua aplicação nas duas regiões num par regional. Por exemplo, E.U.A Leste emparelha com E.U.A. Oeste. Nosso projeto proposto usa o Leste dos EUA para sua região ativa e o Oeste dos EUA para sua região de espera.