Criar uma arquitetura geograficamente distribuída
O Azure é um sistema global. Ao criar uma arquitetura presente em mais de uma região do Azure, podemos criar um aplicativo resiliente a até mesmo desastres em toda a região.
Seu portal de acompanhamento de envio é escalonável porque é criado usando uma variedade de recursos do Azure que podem ser dimensionados. Ele também é resiliente a muitas falhas porque seus componentes podem ter várias instâncias. No entanto, sua diretoria tem a preocupação de que um desastre de grande escala possa causar uma interrupção, porque o portal está totalmente contido na região do Azure Leste dos EUA. Convém propor uma arquitetura modificada que possa fazer failover para uma segunda região se o Leste dos EUA falhar.
Aqui, aprendemos a ajustar a arquitetura do nosso aplicativo para dar suporte a um aplicativo geograficamente distribuído. Também vemos por que essa arquitetura é vantajosa para aplicativos comercialmente críticos.
Arquitetura do aplicativo Web original
Vamos dar uma olhada no design de arquitetura do portal de acompanhamento e nos 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 com 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. Esse grupo de recursos permite agrupar e gerenciar todos os recursos de forma lógica e simplifica o gerenciamento. 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 examinar cada categoria e ver quais recursos estão em uso.
Componentes de rede
O portal de acompanhamento usa os serviços de rede a seguir.
| Serviço | Descrição |
|---|---|
| DNS do Azure | Configuramos o DNS do Azure para hospedar nossos registros de DNS no Azure. O DNS do Azure permite gerenciar nossos registros de DNS usando nossas credenciais do Azure no portal do Azure. |
| Gateway de Aplicativo | Configuramos o balanceador de carga do Gateway de Aplicativo para balancear o tráfego entre várias instâncias do front-end da Web. Esse serviço está localizado em uma região do Azure. |
| CDN do Azure | Configuramos o CDN do Azure para maximizar a entrega de conteúdo estático não protegido, como gráficos para o conteúdo do nosso site. Esse serviço global armazena em cache conteúdo estático em pontos de presença no mundo inteiro. |
Componentes do aplicativo
O portal de acompanhamento usa os seguintes serviços para dar suporte a código, ao cache e aos requisitos de armazenamento intermediários.
| Serviço | Descrição |
|---|---|
| Microsoft Entra ID | Os usuários acessam o portal de acompanhamento usando contas do Microsoft Entra. O diretório e a conta são replicados automaticamente de maneira global. |
| Serviço de Aplicativo do Azure | O portal de acompanhamento usa dois Serviços de Aplicativos do Azure. O primeiro executa um conjunto de páginas da Web dinâmicas e o segundo, uma API Web. |
| Aplicativos de Funções do Azure | O portal de acompanhamento usa os Aplicativos de Funções do Azure para executar todas as tarefas em segundo plano. Algumas dessas tarefas são executadas em um agendamento regular e outras tarefas operam nas 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ções do Azure. O portal de acompanhamento coloca as mensagens geradas na fila de onde os Aplicativos de funções processam essas mensagens. |
| Cache Redis | O portal de acompanhamento usa um cache Redis entre o serviço de aplicativo de front-end e os sistemas de armazenamento de dados para maximizar o desempenho de consultas. |
| Armazenamento de Blobs do Azure | Os conteúdos estáticos, como os arquivos de gráficos e de vídeos, são mantidos como Blobs (objetos binários grandes) em uma conta de Armazenamento do Microsoft Azure e são entregues por meio da CDN do Azure. |
| Azure Search | Habilitamos o Azure Search no portal de acompanhamento. O Azure Search possibilita tornar todo o conteúdo pesquisável e oferecer sugestões de pesquisa e resultados da pesquisa difusa para nossos usuários. |
Componentes do armazenamento de dados
O portal de acompanhamento usa os serviços de armazenamento persistentes a seguir.
| 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 do portal de acompanhamento foi criada 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 adicionar mais instâncias do aplicativo Web de front-end no Serviço de Aplicativo. Aqui, o Gateway de Aplicativo pode rotear solicitações para essas instâncias recém-criadas.
No entanto, há cenários em que o design da arquitetura tem desafios a serem superados ou até mesmo falhará. Vamos dar uma olhada em cada cenário para entender melhor o impacto no portal de acompanhamento.
Falhas regionais
Alguns eventos significativos têm o potencial de interromper uma região do Azure inteira. Os datacenters do Azure são criados para serem altamente resilientes, mas um grande evento meteorológico, 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 aguentar esse risco. No entanto, a consequência de uma falha regional que desabilita o portal de acompanhamento é de tão grande risco que a equipe executiva da empresa decidiu acabar com o risco.
Contratos de Nível de Serviço
A maioria dos serviços do Azure oferece um SLA (Contrato de Nível de Serviço) ou garantia de tempo de atividade. Quando criamos uma arquitetura de aplicativo composta por vários serviços do Azure, calculamos o SLA geral do aplicativo como uma composição dos SLAs de todos os outros serviços.
Calcule o SLA multiplicando todos os SLAs dos serviços de componentes. Por exemplo, suponha que nosso aplicativo consista no Serviço de Aplicativo do Azure (99,95% de SLA) e no Microsoft Entra ID (99,9% de SLA). O SLA calculado final é de 99,85%.
Se esse percentual de tempo de atividade não for suficiente para o nosso aplicativo, poderemos preparar o aplicativo para fazer failover em outra região.
Componentes globais, regionais e configuráveis
Em nosso design, alguns componentes são globais por padrão e não estão vulneráveis a uma falha regional.
Alguns componentes estão confinados em uma única região, por exemplo, o Gateway de Aplicativo. Precisamos selecionar um serviço alternativo para esses tipos de componentes.
Alguns componentes podem ser configurados para dar suporte a várias regiões. Por exemplo, podemos usar a opção GRS (Armazenamento com Redundância Geográfica) 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 | Comentários |
|---|---|---|
| DNS do Azure | Global | Nenhuma alteração é necessária. |
| Gateway de Aplicativo | Regional | Cada instância do Gateway de Aplicativo está localizada em uma única região. |
| CDN do Azure | Global | Nenhuma alteração é necessária, e o conteúdo é armazenado em cache globalmente por padrão. |
| Microsoft Entra ID | Global | Nenhuma alteração é necessária. |
| Serviço de Aplicativo do Azure | Regional | Cada instância do aplicativo está localizada em uma única região. |
| Aplicativos de Funções do Azure | Regional | Cada instância do aplicativo de funções 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 em várias regiões. |
| Cache Redis do Azure | Regional | 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 em várias regiões. |
| Azure Search | Regional | 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 para várias regiões. |
| Azure Cosmos DB | Configurável | Você pode usar a replicação geográfica para sincronizar dados para várias regiões. |
Arquitetura distribuída proposta
Depois de investigar um pouco, você propõe a arquitetura mostrada no diagrama a seguir.
Nesse design, há uma região ativa (Leste dos EUA) e uma região em espera (Oeste dos EUA). A região Leste dos EUA manipula todas as solicitações pelos componentes em circunstâncias comuns. Se um desastre causar uma falha regional, o aplicativo fará failover para a região Oeste dos EUA.
Vamos examinar, em um alto nível, como você modificou a arquitetura original. Exploramos essas alterações mais detalhadamente em unidades posteriores.
Rede
O DNS do Azure e a CDN do Azure são, por padrão, sistemas globais e já resilientes a falhas regionais. Nós os deixamos no lugar.
Quando criamos um Gateway de Aplicativo do Azure, atribuímos o serviço a uma única região. Removemos essa vulnerabilidade substituindo o serviço pelo Azure Front Door. O Front Door pode sondar vários Serviços de Aplicativos e manipular o failover do Serviço de Aplicativo da região Leste dos EUA para a região Oeste dos EUA.
Serviços de aplicativo
O Microsoft Entra ID é um sistema global e não precisa de nenhuma modificação.
As contas do Armazenamento do Azure podem ser configuradas para replicar conteúdo em 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ções, o cache Redis e o Azure Search, são regionais. Criamos instâncias duplicadas desses componentes na região Oeste dos EUA em nosso novo design de arquitetura. Nesse design, a nova região pode assumir quando ocorre um failover.
Armazenamento de dados
O Banco de Dados SQL do Azure e o Azure Cosmos DB dão suporte à replicação geográfica de dados para outras regiões. Configuramos esses serviços para replicar os dados da região Leste dos EUA para os serviços equivalentes na região Oeste dos EUA.
Pares regionais
Uma região do Azure é uma área com uma região geográfica única que contém um ou mais datacenters do Azure. Todas as regiões se emparelham com outras regiões na mesma geografia. Nesses pares, as atualizações e a manutenção planejada são feitas em apenas uma região por vez. Em caso de falha que afete várias regiões, pelo menos uma região em cada par será priorizada para recuperação rápida.
A melhor prática é colocar uma arquitetura de duas regiões para seu aplicativo nas duas regiões em um par regional. Como um exemplo, a região Leste dos EUA emparelha-se com a região Oeste dos EUA. Nosso design proposto usa as regiões Leste dos EUA como região ativa e Oeste dos EUA como região em espera.