Projetar uma arquitetura geograficamente distribuída
O Azure é um sistema global. Ao projetar uma arquitetura presente em mais de uma região do Azure, podemos criar um aplicativo resiliente até mesmo a desastres em toda a região.
Seu portal de rastreamento de remessas é escalável porque é criado usando 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. Você deseja propor uma arquitetura modificada que possa executar a transição automática para uma segunda região se o Leste dos EUA falhar.
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 original do aplicativo Web
Vamos ver como é o design 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.
Observe como nosso aplicativo usa 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. Optamos por implantar esse grupo de recursos na região Leste dos EUA. Embora o grupo de recursos não nos limite a usar a mesma região do Azure para os recursos incluídos, decidimos usar a região Leste dos EUA para todos os recursos implantados em nosso aplicativo.
Nosso aplicativo usa 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 | Descrição |
|---|---|
| DNS do Azure | Configuramos o DNS do Azure para hospedar nossos registros 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 | Configuramos o balanceador de carga do Application Gateway para equilibrar o tráfego entre várias instâncias do front-end da Web. Este serviço está restrito a uma região do Azure. |
| Azure CDN | Configuramos a CDN do Azure para maximizar a entrega de conteúdo estático não seguro, como gráficos para o conteúdo 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ção
O portal de rastreamento usa os seguintes serviços para dar suporte a requisitos de código, cache e armazenamento intermediário.
| Serviço | Descrição |
|---|---|
| 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 globalmente. |
| Serviço de Aplicativo do Azure | O portal de acompanhamento usa dois Serviços de Aplicativo do Azure. O primeiro executa um conjunto de páginas da Web dinâmicas e o segundo uma API da Web. |
| Aplicativos de Função do Azure | O portal de acompanhamento usa os Aplicativos de Função do Azure para executar todas as tarefas em segundo plano. Algumas dessas tarefas são executadas em um horário regular, e outras tarefas operam sobre as mensagens em uma 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 rastreamento coloca as mensagens geradas na fila a partir de onde as aplicações Function processam essas mensagens. |
| cache Redis | O portal de rastreamento usa um cache Redis entre o serviço de aplicativo 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. |
| Pesquisa do Azure | Habilitamos a Pesquisa do Azure no portal de rastreamento. 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 | Descrição |
|---|---|
| Banco de Dados SQL do Azure | Estamos armazenando dados relacionais, como detalhes do pedido e do cliente no Banco de Dados SQL do Azure. |
| Cosmos DB | Estamos armazenando dados semiestruturados, incluindo nosso catálogo de produtos no Cosmos DB. |
Problemas com a arquitetura original
A arquitetura existente para o portal de rastreamento foi projetada para permitir escalabilidade e 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 Application Gateway pode rotear solicitações para essas instâncias recém-criadas.
No entanto, há cenários em que o nosso projeto arquitetónico tem desafios a ultrapassar, ou mesmo a falhar. Vamos dar uma olhada em cada cenário para entender melhor o impacto no portal de rastreamento.
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.
Esses eventos são ocorrências incomuns, e muitas empresas sentem que podem sustentar esse risco. No entanto, as consequências de uma falha regional que desative o portal de rastreamento são tão arriscadas que a equipa executiva da empresa decidiu eliminá-las.
Acordos de Nível de Serviço
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 projetamos uma arquitetura de aplicativo que consiste em vários serviços do Azure, calculamos o SLA geral do aplicativo como uma composição de todos os outros SLAs de serviços.
Você calcula esse SLA multiplicando os SLAs dos serviços de componentes. Por exemplo, suponha que a nossa aplicação consiste no Serviço de Aplicações do Azure (SLA de 99,95%) e no Microsoft Entra ID (SLA de 99,9%). O SLA final calculado é de 99,85%.
Se essa percentagem de tempo de atividade não for suficiente para o nosso aplicativo, podemos configurar o redirecionamento do aplicativo para outra região.
Componentes globais, regionais e configuráveis
Em nosso projeto, alguns componentes são globais por padrão e não vulneráveis a uma falha regional.
Alguns componentes estão confinados a uma única região, por exemplo, o Application Gateway. Temos que selecionar um serviço alternativo para esses tipos de componentes.
Alguns componentes podem ser configurados para suportar várias regiões. Por exemplo, podemos usar a opção Geo-Redundant Storage (GRS) na conta de Armazenamento do Azure que armazena conteúdo estático. 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 várias regiões | Observações |
|---|---|---|
| Azure DNS | A nível mundial | Não são necessárias alterações. |
| Gateway de aplicativo | Regionais | Cada instância do Application Gateway está localizada em uma única região. |
| Azure CDN | A nível mundial | Nenhuma alteração é necessária, o conteúdo é armazenado em cache globalmente por padrão. |
| Microsoft Entra ID | A nível mundial | Não são necessárias alterações. |
| Serviço de Aplicativo do Azure | Regionais | Cada instância do aplicativo está localizada em uma única região. |
| Aplicativos de função do Azure | Regionais | Cada instância do aplicativo de função está localizada em uma ú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. |
| Azure Redis Cache | Regionais | Cada instância do cache está localizada em uma ú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 | Regionais | Cada instância do serviço de pesquisa está localizada em uma única região. |
| Banco de Dados SQL do Azure | Configurável | Você pode usar a replicação geográfica para sincronizar dados com várias regiões. |
| Azure Cosmos DB | 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 design, há uma região ativa (Leste dos EUA) e uma região de espera (Oeste dos EUA). A região Leste dos EUA lida com todas as solicitações dos componentes em circunstâncias normais. Se um desastre causar uma falha regional, a aplicação será transferida para a Região Oeste dos EUA.
Vamos examinar, em alto nível, como você modificou a arquitetura original. Exploramos essas mudanças com mais detalhes em unidades posteriores.
Ligação em rede
O DNS do Azure e a CDN do Azure são, por padrão, sistemas globais e já resilientes a falhas regionais. Deixamo-los no lugar.
Quando criamos um Gateway de Aplicativo 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 sondar múltiplos Serviços de Aplicações e lidar com a transferência por falha do Serviço de Aplicações da região Leste dos EUA para a região Oeste dos EUA.
Serviços de aplicação
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údo para várias 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 Aplicativo, os Aplicativos de Função, o cache Redis e a Pesquisa do Azure, são regionais. Criamos instâncias duplicadas desses componentes na região Oeste dos EUA em nosso novo projeto arquitetônico. Nesse design, a nova região pode assumir o controle quando ocorre um failover.
Armazenamento de dados
O Banco de Dados SQL do Azure e o Azure Cosmos DB oferecem suporte à replicação geográfica 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. Dentro desses pares, as atualizações e a manutenção planejada são feitas em apenas uma região de cada vez. Se houver uma falha que afete várias regiões, pelo menos uma região em cada par será priorizada para uma recuperação rápida.
A prática recomendada é adotar uma arquitetura de duas regiões para a sua aplicação nas duas regiões de um par regional. Como exemplo, o Leste dos EUA faz par com o Oeste dos EUA. Nosso projeto proposto usa o Leste dos EUA para sua região ativa e o Oeste dos EUA para sua região de espera.