Implantação empresarial de alta disponibilidade usando o Ambiente do Serviço de Aplicativo

Microsoft Entra ID

Gateway de Aplicativo do Azure

Firewall do Azure

Rede Virtual do Azure

Serviço de aplicativo do Azure

Observação

Ambiente do Serviço de Aplicativo versão 3 é o principal componente dessa arquitetura. A versão 3 já está disponível. As versões 1 e 2 serão desativadas em 31 de agosto de 2024.

As Zonas de Disponibilidade são coleções fisicamente separadas de datacenters em uma determinada região. A implantação de recursos entre zonas garante que as interrupções limitadas a uma zona não afetem a disponibilidade dos aplicativos. Essa arquitetura mostra como você pode melhorar a resiliência de uma implantação do Ambiente do Serviço de Aplicativo implantando-a em uma arquitetura com redundância de zona. Essas zonas não estão relacionadas à proximidade. Eles podem ser mapeadas para diferentes locais físicos para assinaturas diferentes. A arquitetura pressupõe apenas uma implantação de assinatura.

Quando você configura o Ambiente do Serviço de Aplicativo para ter redundância de zona, a plataforma implanta automaticamente as instâncias do Plano do Serviço de Aplicativo do Azure nas três zonas na região selecionada. Portanto, a contagem mínima de instâncias do Plano do Serviço de Aplicativo é sempre três.

Os serviços do Azure que oferecem suporte a Zonas de Disponibilidade podem ser zonais, com redundância de zona ou ambos. Serviços zonais podem ser implantados em uma zona específica. Os serviços com redundância de zona podem ser implantados automaticamente entre zonas. Para obter diretrizes e recomendações detalhadas, consulte Suporte a Zonas de Disponibilidade. A versão anterior do Ambiente do Serviço de Aplicativo (v2) dava suporte apenas a implantações zonais, mas a versão atual (v3) oferece suporte a implantações com redundância de zona.

Logotipo do GitHub Há uma implantação de referência para essa arquitetura disponível no GitHub.

Arquitetura

Diagrama exibindo uma arquitetura de referência para implantação de alta disponibilidade do Ambiente do Serviço de Aplicativo.

Baixe um Arquivo Visio dessa arquitetura.

Os recursos nas sub-redes do Ambiente do Serviço de Aplicativo na implementação de referência são os mesmos da arquitetura de implementação do Ambiente do Serviço de Aplicativo. Essa implementação de referência usa os recursos com redundância de zona do Ambiente do Serviço de Aplicativo v3 e do Cache do Azure para Redis para fornecer maior disponibilidade. Observe que o escopo dessa arquitetura de referência está limitado a apenas uma região.

Workflow

Esta seção descreve a natureza da disponibilidade dos serviços usados nesta arquitetura:

O Ambiente do Serviço de Aplicativo v3 pode ser configurado para redundância de zona. Você só pode configurar a redundância de zona durante a criação do Ambiente do Serviço de Aplicativo e somente em regiões com suporte a todas as dependências do Ambiente do Serviço de Aplicativo v3. Cada Plano do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo de zona redundante precisa ter, no mínimo, três instâncias para que possam ser implantadas nas três zonas. A cobrança mínima é para nove instâncias. Para obter mais informações, confira essas diretrizes de preços. Para obter diretrizes e recomendações detalhadas, confira Suporte do Ambiente do Serviço de Aplicativo para Zonas de Disponibilidade.
A Rede Virtual do Azure abrange todas as Zonas de Disponibilidade que estão em uma região. As sub-redes na rede virtual também cruzam Zonas de Disponibilidade. Para obter mais informações, confira os requisitos de rede para o Ambientes do Serviço de Aplicativo.
O Gateway de Aplicativo v2 tem redundância de zona. Assim como a rede virtual, ela abrange várias zonas de disponibilidade por região. Portando, apenas um gateway de aplicativo é suficiente para um sistema altamente disponível, conforme mostrado na arquitetura de referência. A arquitetura de referência usa o SKU do WAF do Gateway de Aplicativo, que fornece maior proteção contra ameaças e vulnerabilidades comuns, com base em uma implementação do CRS (Conjunto de Regras Principais) do OWASP (Open Web Application Security Project). Para obter mais informações, confira Gateway de Aplicativo de Dimensionamento v2 e WAF v2.
O Firewall do Azure tem suporte interno para alta disponibilidade. Ele pode cruzar várias zonas sem nenhuma configuração adicional.

Se necessário, você também pode configurar uma Zona de Disponibilidade específica ao implantar o firewall. Veja Regiões do Azure e Zonas de Disponibilidade para obter mais informações. (Essa configuração não é usada na arquitetura de referência.)
O Microsoft Entra ID é um serviço global altamente disponível e altamente redundante, abrangendo Zonas de Disponibilidade e regiões. Para obter mais informações, confira Avanço na disponibilidade do Microsoft Entra.
O GitHub Actions fornece integração contínua e recursos de implantação contínua (CI/CD) nesta arquitetura. Como o Ambiente do Serviço de Aplicativo está na rede virtual, uma máquina virtual é usada como um jumpbox na rede virtual para implantar aplicativos nos Planos do Serviço de Aplicativo. A ação cria os aplicativos fora da rede virtual. Para maior segurança e conectividade contínua de RDP/SSH, considere usar o Azure Bastion como jumpbox.
O Cache do Azure para Redis não é um serviço com redundância de zona. Um cache com redundância de zona é executado em VMs implantadas em várias Zonas de Disponibilidade. Esse serviço fornece maior resiliência e disponibilidade.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Disponibilidade

Ambiente do Serviço de Aplicativo

Você pode implantar o Ambiente do Serviço de Aplicativo em Zonas de Disponibilidade para proporcionar resiliência e confiabilidade para suas cargas de trabalho comercialmente críticas. Essa configuração também é conhecida como redundância de zona.

Quando você implementar a redundância de zona, a plataforma implantará automaticamente as instâncias do Plano do Serviço de Aplicativo nas três zonas na região selecionada. Portanto, a contagem mínima de instâncias do Plano do Serviço de Aplicativo é sempre três. Se especificar uma capacidade maior que três e o número de instâncias for divisível por três, as instâncias serão implantadas uniformemente. Caso contrário, todas as instâncias restantes serão adicionadas à zona restante ou implantadas nas duas zonas restantes.

Você configura as zonas de disponibilidade ao criar seu Ambiente do Serviço de Aplicativo.
Todos os Planos do Serviço de Aplicativo criados nesse Ambiente do Serviço de Aplicativo exigem um mínimo de três instâncias. Eles terão automaticamente redundância de zona.
Você pode especificar Zonas de Disponibilidade somente ao criar um Ambiente do Serviço de Aplicativo. Não é possível converter um Ambiente do Serviço de Aplicativo preexistente para usar Zonas de Disponibilidade.
As Zonas de Disponibilidade só recebem suporte em um subconjunto de regiões.

Para obter mais informações, veja Migrar o Ambiente do Serviço de Aplicativo para o suporte a zonas de disponibilidade.

Resiliência

Os aplicativos executados no Ambiente do Serviço de Aplicativo formam o pool de back-end do Gateway de Aplicativo. Quando uma solicitação para o aplicativo vem da Internet pública, o gateway encaminha a solicitação para o aplicativo em execução no Ambiente do Serviço de Aplicativo. Essa arquitetura de referência implementa verificações de integridade no front-end principal da Web, o votingApp. Essa investigação de integridade verifica se a API Web e o cache Redis estão íntegros. Você pode ver o código que implementa a investigação no Startup.cs:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

O seguinte código mostra como o script commands_ha.azcli configura os pools de back-end e a investigação de integridade do Gateway de Aplicativo:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Se um dos componentes (o front-end da Web, a API ou o cache) falhar na investigação de integridade, o Gateway de Aplicativo roteará a solicitação para o outro aplicativo no pool de back-end. Essa configuração garante que a solicitação seja sempre roteada para o aplicativo em uma sub-rede do Ambiente do Serviço de Aplicativo completamente disponível.

A investigação de integridade também é implementada na implementação de referência padrão. Nela, o gateway simplesmente retornará um erro se a investigação de integridade falhar. No entanto, a implementação altamente disponível aprimora a resiliência do aplicativo e a qualidade da experiência do usuário.

Otimização de custo

A otimização de custos consiste em reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

As considerações de custo para a arquitetura de alta disponibilidade são muito semelhantes às da implantação padrão.

As seguintes diferenças podem afetar o custo:

Você recebe uma cobrança para pelo menos nove instâncias do Plano do Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo com redundância de zona. Para saber mais, veja Preços do Ambiente do Serviço de Aplicativo.
O Cache do Azure para Redis também não é um serviço com redundância de zona. Um cache com redundância de zona é executado em VMs implantadas em várias Zonas de Disponibilidade para fornecer maior resiliência e disponibilidade.

A compensação por um sistema altamente disponível, resiliente e altamente seguro é um maior custo. Use a calculadora de preços para avaliar suas necessidades em relação aos preços.

Considerações de implantação

Essa implementação de referência usa o mesmo pipeline de CI/CD no nível da produção que a implantação padrão, com apenas uma VM jumpbox. Você pode, no entanto, decidir usar um jumpbox para cada uma das três zonas. Essa arquitetura usa apenas um jumpbox, pois o jumpbox não afeta a disponibilidade do aplicativo. O jumpbox é usado apenas para implantação e teste.

Implantar este cenário

Para obter informações sobre como implantar a implementação de referência para essa arquitetura, consulte o leiame do GitHub. Use o script para a implantação de alta disponibilidade.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Deep Bhattacharya | Arquiteto de Soluções em Nuvem
Suhas Rao | Arquiteto de Soluções em Nuvem

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

Próximas etapas

Você pode modificar a arquitetura dimensionando horizontalmente seus aplicativos, dentro da mesma região ou em várias regiões, com base na capacidade de carga de pico esperada. Replicar seus aplicativos em várias regiões poderá ajudar a atenuar os riscos de falhas mais amplas do data center geográfico, como aquelas causadas por terremotos ou outros desastres naturais. Para saber mais sobre dimensionamento horizontal, confira Escala distribuída geograficamente com Ambientes do Serviço de Aplicativo. Para uma solução de roteamento global e altamente disponível, considere usar o Azure Front Door.

Compartilhar via