Implementar o Aplicativos Spring do Azure em várias regiões

Esta arquitetura de referência descreve uma abordagem para a execução de várias instâncias do Aplicativos Spring do Azure entre regiões em uma configuração ativo-ativo.

Esse design é criado na arquitetura de linha de base do Aplicativos Spring do Azure. A linha de base implanta um aplicativo Java Spring Boot em várias zonas de disponibilidade dentro de uma única região. As várias zonas distribuem a carga de trabalho do aplicativo em locais separados para que a carga de trabalho possa tolerar falhas locais dentro da região do Azure.

Entretanto, se toda a região sofrer uma interrupção, a linha de base ficará indisponível para o usuário. A intenção desse projeto é criar uma alta disponibilidade que possa resistir a uma interrupção regional.

Essa arquitetura é útil para atender aos seguintes objetivos:

• Aumentar a resiliência de modo geral e o objetivo de nível de serviço (SLO) do aplicativo.
• Habilitar o alcance global do aplicativo.
• Aproxime a carga de trabalho do usuário final e torne a latência a mais baixa possível.
• Use uma região secundária como um site de failover para a região primária e opte por um design ativo-passivo.

Para aumentar a resiliência e a confiabilidade do aplicativo, você deve implantar o aplicativo em várias regiões. Para esse projeto, você precisa de um roteador global para balancear a carga de solicitações para seus aplicativos entre as regiões. O roteador global nessa arquitetura também endereça outros objetivos.

O maior desafio de uma configuração de várias regiões é replicar os dados do seu aplicativo entre várias regiões. Esse problema não é uma preocupação com a configuração de várias zonas. As zonas de disponibilidade do Azure são conectadas por uma rede de alto desempenho com uma latência de viagem de ida e volta de menos de 2 ms. Esse período de latência é suficiente para a maioria dos aplicativos.

Arquitetura

O diagrama a seguir mostra a arquitetura dessa abordagem:

Componentes

Os componentes dessa arquitetura são os mesmos da arquitetura de linha de base. A lista a seguir destaca apenas as alterações na arquitetura de linha de base. Para obter a documentação do produto sobre os serviços do Azure, consulte a seção Recursos relacionados.

• O Azure Front Door atua como um balanceador de carga global. Esse serviço é utilizado devido à sua capacidade de entregar alta disponibilidade com menor latência, maior escala e colocação em cache na borda.

Workflow

A arquitetura de referência implementa o seguinte fluxo de trabalho:

1. O usuário envia uma solicitação para o nome do host HTTP do aplicativo, como www.contoso.com. O DNS do Azure resolve a solicitação desse nome de host para o Azure Front Door.

2. O Azure Front Door utiliza várias configurações de balanceamento de carga para encaminhar as solicitações de entrada para o ponto de extremidade público do Gateway de Aplicativo do Azure em cada região. As instâncias do Gateway de Aplicativo são configuradas com o mesmo nome de domínio personalizado e nome de certificado TLS que o Azure Front Door.

3. O Gateway de Aplicativo com o Firewall de Aplicativo Web do Azure integrado inspeciona a solicitação. O Firewall de Aplicativo Web permite a entrada de solicitações somente do perfil do Azure Front Door especificado.

4. O Gateway de Aplicativo encaminha o tráfego permitido para o endereço IP do balanceador de carga na instância provisionada do Spring Apps.

5. O balanceador de carga interno apenas roteia o tráfego do Gateway de Aplicativo para os serviços de back-end. Esses serviços são hospedados em uma instância do Spring Apps dentro de uma rede virtual em cada região.

6. Como parte do processamento da solicitação, o aplicativo se comunica com outros serviços do Azure dentro da rede virtual. Os exemplos incluem o aplicativo se comunicando com o Azure Key Vault para obter os segredos e o banco de dados para armazenar o estado.

Distribuição global

Se estiver projetando para alta disponibilidade, você pode configurar essa arquitetura em um modo ativo-ativo, ativo-passivo com espera ativa ou ativo-passivo com espera passiva.

Sua escolha depende dos requisitos de disponibilidade do seu aplicativo. Essa arquitetura utiliza a implantação ativo-ativo em duas regiões porque a organização da amostra deseja ter uma presença global com SLA (Contrato de Nível de Serviço) de alto tempo de atividade. Se você estiver executando aplicativos críticos e desejar alta disponibilidade, precisará utilizar mais de duas regiões.

Ativo-ativo

No modo ativo-ativo, todas as regiões processam solicitações simultaneamente. O maior desafio do modo ativo-ativo é manter a sincronização dos dados entre as regiões. Esse modo é uma abordagem dispendiosa porque você paga duas vezes por quase todos os componentes.

Ativo-passivo com espera ativa

No modo ativo-passivo com espera ativa, a região secundária não recebe nenhuma solicitação do Azure Front Door enquanto a região primária estiver ativa. Verifique se você fez a replicação dos dados do aplicativo da região primária para a secundária. Se ocorrer uma falha na região primária, você precisará alterar as funções dos bancos de dados de back-end e fazer failover todo o tráfego pelo Azure Front Door para a região secundária.

No modo ativo-passivo, espera-se que o failover leve algum tempo, o que facilita garantir que todos os dados permaneçam sincronizados. Entretanto, o modo ativo-passivo com espera ativa é tão dispendioso quanto trabalhar com o modo ativo-ativo.

Ativo-passivo com espera passiva

No modo ativo-passivo com espera passiva, a região primária tem todos os recursos e serve o tráfego. A região secundária pode ter menos componentes ou componentes com menos recursos de computação. As opções de tecnologia dependem de quanto tempo de inatividade é aceitável de acordo com os requisitos comerciais. A extensão da configuração da sua região secundária também afeta os custos. Verifique se pelo menos os dados do aplicativo estão presentes na região secundária.

Conforme mencionado, o modo ativo-passivo inclui failover que leva algum tempo, portanto, é mais fácil manter todos os dados sincronizados. O modo ativo-passivo com espera passiva é a abordagem com melhor custo-benefício porque você não implantará todos os recursos em ambas as regiões.

Se toda a configuração da sua solução utilizar modelos, você poderá implantar facilmente uma região secundária em espera passiva criando seus recursos conforme necessário. Você pode utilizar modelos do Terraform, Bicep ou Azure Resource Manager e automatizar a configuração da infraestrutura em um pipeline de integração contínua/implantação contínua (CI/CD). Você deve testar regularmente sua configuração recriando sua região secundária para garantir que seus modelos possam ser implantados em uma emergência.

O padrão de carimbos de implantação é recomendado porque várias cópias independentes de um aplicativo ou componente podem ser implantadas a partir de um único modelo em várias regiões.

Comparação de modo

A tabela a seguir resume o esforço exigido para sincronizar os dados de cada modo e compara o custo.

Roteando entre regiões

Essa arquitetura de referência utiliza nós geográficos (Geodes) em que qualquer região pode atender a qualquer solicitação.

O Azure Front Door está configurado com roteamento igual entre as duas regiões de implantação. O Azure Front Door também fornece outros métodos de roteamento de tráfego para a origem. Se você deseja rotear os clientes para a origem mais próxima, o roteamento baseado em latência é o que faz mais sentido. Se estiver projetando uma solução ativa-passiva, o roteamento baseado em prioridade será mais apropriado.

O exemplo da arquitetura de referência utiliza uma regra de balanceamento de carga de peso igual entre as duas regiões. O Azure Front Door está configurado com:

• Um domínio personalizado e um certificado de segurança da camada de transporte (TLS) com o mesmo do nome do host do aplicativo, como www.contoso.com.

• Uma origem por região em que o aplicativo está implantado, em que cada origem é uma instância do Gateway de Aplicativo do Azure.

Layout do grupo de recursos

Use os grupos de recursos do Azure para gerenciar os recursos implantados em cada região como uma única coleção. Considere colocar a região primária, a região secundária e o Azure Front Door em grupos de recursos separados, conforme mostrado no diagrama a seguir:

O diagrama mostra a seguinte configuração de grupos de recursos:

• O Azure Front Door está implantado no grupo de recursos Application-shared.
• Todos os recursos hospedados na região Oeste da Europa (weu) são implantados no grupo de recursos Application-weu.
• Os recursos hospedados na região Leste dos EUA (eus) são hospedados no grupo de recursos Application-eus.
• Os recursos hospedados na região Leste do Japão (jae) são hospedados no grupo de recursos Application-jae.

Os recursos no mesmo grupo de recursos compartilham o mesmo ciclo de vida e podem ser facilmente criados e excluídos juntos. Cada região tem seu próprio conjunto de recursos em um grupo de recursos dedicado que segue uma convenção de nomenclatura com base no nome da região. O Azure Front Door está em seu próprio grupo de recursos porque deve existir mesmo se outras regiões forem adicionadas ou removidas.

Configuração de proxy reverso

O Azure Front Door faz o balanceamento de carga global entre as regiões. Esse proxy reverso ajuda a distribuir o tráfego se você implantar uma carga de trabalho em várias regiões. Como alternativa, você pode utilizar o Gerenciador de Tráfego do Azure. O Gerenciador de Tráfego é um balanceador de carga de tráfego baseado em DNS que faz o balanceamento de carga somente no nível do domínio.

O Azure Front Door tem redes de distribuição de conteúdo (CDNs) integradas que entregam o conteúdo da rede de borda global da Microsoft com pontos de presença (PoPs) distribuídos em todo o mundo.

A solução atual utiliza dois proxies reversos para manter a consistência com a arquitetura de linha de base. O Azure Front Door é o roteador global. O Gateway de Aplicativo atua como um balanceador de carga por região. Na maioria dos casos, essa configuração não é exigida. Você pode remover o Gateway de Aplicativo se atender aos seguintes requisitos:

• Como o Firewall de Aplicativo Web do Azure está anexado ao Gateway de Aplicativo, você precisa anexar o Firewall de Aplicativo Web ao serviço Front Door do Azure.
• É necessário garantir que as chamadas de entrada sejam originadas apenas da sua instância do Azure Front Door. Você pode adicionar a verificação X-Azure-FDID header e a verificação dos intervalos de IP do Azure Front Door no aplicativo Spring Cloud Gateway. Para obter mais informações, consulte Usar o Azure Front Door como proxy reverso com o Spring Cloud Gateway.

Para obter informações sobre diferentes cenários de proxy reverso, como configurá-los e suas considerações de segurança, consulte Expor o Aplicativos Spring do Azure por meio de um proxy reverso.

Banco de dados de back-end

Para implantação em várias regiões, você precisa ter uma estratégia de replicação de dados. Quando o aplicativo estiver disponível em várias regiões, os dados deverão ser sincronizados para que os usuários não vejam dados obsoletos.

A arquitetura atual utiliza um banco de dados MySQL para o banco de dados de ponta a ponta, mas essa configuração não aborda a sincronização de dados. Ao escolher uma tecnologia de banco de dados, verifique como fazer para replicar e sincronizar os dados entre as regiões da melhor maneira possível. Uma opção é o Banco de Dados SQL do Azure, que tem um recurso de replicação geográfica ativa que fornece um banco de dados secundário legível e continuamente sincronizado para um banco de dados primário.

Você pode utilizar esse recurso nos seguintes cenários:

• Se sua região secundária for uma espera passiva que não recebe solicitações ativas
• Para fazer failover se sua região primária falhar
• Configurar os bancos de dados primário e secundário com conexões por link privado com suas respectivas regiões por meio de emparelhamento de rede virtual entre as duas regiões.

Outra abordagem é utilizar o Azure Cosmos DB. Esse serviço pode distribuir globalmente os dados, replicando-os de forma transparente para todas as regiões em sua conta do Azure Cosmos DB. Você também pode configurar o Azure Cosmos DB com várias regiões de gravação. Para obter mais informações, confira o Padrão geode.

Implantação automatizada

Automatize a implantação da infraestrutura e as implantações de código de aplicativo o máximo possível.

A automação das implantações de infraestrutura garante que a infraestrutura seja configurada de forma idêntica, o que ajuda a evitar descompassos de dados, como entre regiões. A automação da infraestrutura também pode testar as operações fazer failover.

Para a implantação de aplicativos, verifique se seus sistemas de implantação têm como destino as várias regiões nas quais precisam implantar. Você também pode utilizar várias regiões em uma estratégia de implantação azul-verde ou canário. Com essas estratégias de implantação, você deve distribuir novas versões de aplicativos em uma região para testes e em outras regiões após o teste ser bem-sucedido.

Desempenho e escalabilidade

Essa arquitetura é mais adequada do que a arquitetura de linha de base para atender às demandas dos aplicativos, pois distribui a carga entre as regiões. Se você configurar o Azure Front Door para rotear solicitações com base em latência, os usuários obterão melhores tempos de resposta porque as solicitações serão roteadas para as regiões mais próximas a eles.

Dependendo da configuração do seu banco de dados, você poderá incorrer em latência extra quando os dados precisarem ser sincronizados entre as regiões. Você pode superar essa latência utilizando o Azure Cosmos DB com um nível de consistência mais relaxado.

Essa arquitetura de referência tem vários componentes que podem ter um dimensionamento automático com base em métricas:

• O Azure Front Door pode dimensionar automaticamente com base na demanda. Você pode utilizar outros recursos do Azure Front Door, como aceleração de tráfego e capacidades de cache, para aproximar os ativos de seus usuários finais.
• O Gateway de Aplicativo dá suporte ao dimensionamento automático. Para obter mais informações, consulte Dimensionamento de Gateway de Aplicativo v2 e Firewall de Aplicativo Web v2.
• O Aplicativos Spring do Azure também dá suporte ao dimensionamento automático. Para saber mais, confira Configurar o dimensionamento automático para aplicativos.

Considerações de custo

Essa solução efetivamente dobra as estimativas de custo da arquitetura de linha de base.

As principais causas de custos associadas à solução de várias regiões incluem:

• Os bancos de dados primário e secundário devem utilizar a mesma camada de serviço; caso contrário, o banco de dados secundário poderá não acompanhar as alterações de replicação.
• Um tráfego significativo entre regiões aumenta as os custos. O tráfego de rede entre as regiões do Azure incorre em cobranças.

Para gerenciar esses custos, considere estas recomendações para sua implementação:

• Use versões reduzidas de recursos como os Aplicativos Spring do Azure e o Gateway de Aplicativo na região em espera e escale verticalmente os recursos somente quando a espera se tornar ativa.
• Se seus cenários de negócios permitirem, crie uma configuração ativa-passiva para economizar em custos.
• Implemente uma configuração de várias zonas em uma única região para atender às necessidades comerciais de disponibilidade e resiliência. Essa opção pode ser o melhor custo-benefício porque você só paga pela maioria dos recursos uma vez.
• Escolha a configuração alternativa que utiliza apenas um proxy reverso para ajudar a economizar custos. Lembre-se de que você precisa aplicar uma configuração extra para manter a segurança dessa alternativa.

Estimamos o custo dos serviços nessa arquitetura com a Calculadora de preços do Azure utilizando valores padrão razoáveis para um aplicativo de pequena escala. Você pode atualizar essa estimativa com base nos valores de taxa de transferência esperados para seu aplicativo.

Outras considerações

As considerações de projeto para a arquitetura de linha de base de várias zonas também se aplicam à solução de várias regiões descrita neste artigo. Analise os seguintes pontos no contexto da arquitetura de várias regiões:

• Segurança de rede. É importante controlar a comunicação por meio da rede. Essa solução permite a entrada de chamadas somente do Azure Front Door, em que as chamadas são roteadas para o Gateway de Aplicativo de cada região. No Gateway de Aplicativo do Azure, as chamadas são roteadas para o serviço de back-end do Aplicativos Spring do Azure. A comunicação do Aplicativos Spring do Azure com os serviços de suporte, como o Key Vault, também é controlada pelo uso de pontos de extremidade privados. Para obter mais informações, consulte Arquitetura de linha de base: segurança de rede.

• Gerenciamento de identidades e acesso. Implementar um acesso mais seguro usando identidades gerenciadas para conectar-se entre diferentes componentes. Um exemplo é como o Aplicativos Spring do Azure utiliza uma identidade gerenciada para conectar-se ao Key Vault. Para obter mais informações, consulte Arquitetura de linha de base: gerenciamento de identidade e acesso.

• Monitoramento. Você pode adicionar instrumentação e habilitar o rastreamento distribuído para coletar os dados do aplicativo. Combine essa fonte de dados com o diagnóstico da plataforma para obter insights de ponta a ponta sobre seu aplicativo. Para obter mais informações, consulte Arquitetura de linha de base: monitoramento.

• Gerenciamento do segredo. A solução para várias regiões armazena os segredos e certificados do aplicativo em um único cofre de chaves. Para obter mais informações, consulte Arquitetura de linha de base: gerenciamento de segredos.

Implantação do cenário

Uma implantação para essa arquitetura de referência está disponível em Arquitetura de referência de várias regiões do Aplicativos Spring do Azure no GitHub. A implantação usa modelos do Terraform.

Para implantar a arquitetura, siga as instruções passo a passo.

Colaboradores

A Microsoft faz a manutenção desse conteúdo. O seguinte Colaborador desenvolveu o conteúdo original.

Autor principal:

• Gitte Vermeiren | Engenheiro do FastTrack for Azure

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas

Para integrar essa carga de trabalho a serviços compartilhados gerenciados por equipes centrais na sua organização, implante-a em uma zona de destino de aplicativos do Azure.

Recursos relacionados

Para obter a documentação sobre os serviços e recursos do Azure utilizados nessa arquitetura, consulte os artigos a seguir:

• Aplicativos Spring do Azure
• Azure Front Door
• Gateway de Aplicativo do Azure v2
• Banco de Dados do Azure para MySQL
• Azure Key Vault
• DNS do Azure
• Firewall do aplicativo Web do Azure
• Link Privado do Azure
• Identidades gerenciadas do Microsoft Entra para recursos do Azure

Recomendamos os seguintes guias para uma compreensão mais profunda das opções de configuração envolvidas nessa arquitetura:

• Expor os Aplicativos Spring do Azure por meio de um proxy reverso
• Implantação azul/verde de alta disponibilidade para aplicativos
• Preservar o nome do host HTTP original entre um proxy reverso e seu aplicativo Web de back-end

Essa arquitetura foi projetada alinhada com os pilares do Microsoft Azure Well-Architected Framework. Recomendamos que você analise os princípios de design de cada pilar.