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

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 de seus aplicativos. Essa arquitetura mostra como você pode melhorar a resiliência de uma implantação de Ambiente do Serviço de Aplicativo implantando-a em uma arquitetura redudant 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 uma implantação de assinatura única.

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

Os serviços do Azure que dão suporte a zonas de disponibilidade podem ser zonais, com redundância de zona ou ambos. Os 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 à zona de disponibilidade. A versão anterior do Ambiente do Serviço de Aplicativo (v2) tinha suporte apenas para implantações zonais, mas a versão atual (v3) dá suporte a implantações com redundância de zona.

Uma implementação de referência para esta arquitetura está disponível no GitHub.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Os recursos nas sub-redes Ambiente do Serviço de Aplicativo nessa implementação de referência são os mesmos da arquitetura de implantação de Ambiente do Serviço de Aplicativo padrão. Essa implementação de referência usa os recursos com redundância de zona do Ambiente do Serviço de Aplicativo v3 e 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.

Fluxo de trabalho

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

• 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 que dão suporte a todas as dependências Ambiente do Serviço de Aplicativo v3. Cada Serviço de Aplicativo plano em um Ambiente do Serviço de Aplicativo com redundância de zona precisa ter no mínimo três instâncias para que possam ser implantadas em três zonas. A cobrança mínima é para nove instâncias. Para obter mais informações, consulte estas diretrizes de preços. Para obter diretrizes e recomendações detalhadas, consulte Suporte Ambiente do Serviço de Aplicativo para Zonas de Disponibilidade.

• O Azure Rede Virtual abrange todas as zonas de disponibilidade que estão em uma única região. As sub-redes na rede virtual também cruzam zonas de disponibilidade. Para obter mais informações, consulte os requisitos de rede para Ambiente do Serviço de Aplicativo.

• Gateway de Aplicativo v2 é com redundância de zona. Assim como a rede virtual, ela abrange várias zonas de disponibilidade por região. Portanto, um único 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 waf de 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, consulte Dimensionamento Gateway de Aplicativo 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 precisar, você também poderá configurar uma zona de disponibilidade específica ao implantar o firewall. Consulte Firewall do Azure e Zonas de Disponibilidade para obter mais informações. (Essa configuração não é usada na arquitetura de referência.)

• O Azure Active Directory é um serviço global altamente disponível e altamente redundante, abrangendo zonas e regiões de disponibilidade. Para obter mais informações, consulte Avançando a disponibilidade do Azure Active Directory.

• GitHub Actions fornece recursos de CI/CD (integração contínua e implantação contínua) nessa arquitetura. Como 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 de Serviço de Aplicativo. A ação cria os aplicativos fora da rede virtual. Para segurança aprimorada e conectividade RDP/SSH contínua, considere usar o Azure Bastion para o jumpbox.

• Cache do Azure para Redis é 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, que é um conjunto de princípios orientadores que você pode usar para melhorar 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 Ambiente do Serviço de Aplicativo em zonas de disponibilidade para fornecer 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ê implementa a redundância de zona, a plataforma implanta automaticamente as instâncias do plano de Serviço de Aplicativo em três zonas na região selecionada. Portanto, a contagem mínima de instâncias do plano Serviço de Aplicativo é sempre três. Se você 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 Serviço de Aplicativo planos criados nesse Ambiente do Serviço de Aplicativo exigem um mínimo de três instâncias. Eles serão automaticamente redundantes por zona.
• Você só pode especificar zonas de disponibilidade ao criar um novo Ambiente do Serviço de Aplicativo. Não é possível converter um Ambiente do Serviço de Aplicativo pré-existente para usar zonas de disponibilidade.
• As zonas de disponibilidade têm suporte apenas 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 em Ambiente do Serviço de Aplicativo formam o pool de back-end para 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 da Web main, 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 essa investigação em 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 código a seguir mostra como o script commands_ha.azcli configura os pools de back-end e a investigação de integridade para o 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 algum dos componentes (o front-end da Web, a API ou o cache) falhar na investigação de integridade, Gateway de Aplicativo roteia 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 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. Lá, o gateway simplesmente retornará um erro se a investigação de integridade falhar. No entanto, a implementação altamente disponível melhora a resiliência do aplicativo e a qualidade da experiência do usuário.

Otimização de custo

A otimização de custos trata da redução de despesas desnecessárias e da melhoria da 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 semelhantes às da implantação padrão.

As seguintes diferenças podem afetar o custo:

• Você é cobrado por pelo menos nove instâncias de plano de Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo com redundância de zona. Para obter mais informações, consulte preços Ambiente do Serviço de Aplicativo.
• Cache do Azure para Redis também é 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 é o aumento do 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 de nível de produção que a implantação padrão, com apenas uma VM jumpbox. No entanto, você pode decidir usar um jumpbox para cada uma das três zonas. Essa arquitetura usa apenas um jumpbox porque 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 implantação de alta disponibilidade.

Colaboradores

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

Autores principais:

• Bhattacharya profunda | Arquiteto de Soluções na Nuvem
• Suhas Rao | Arquiteto de Soluções na Nuvem

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

Próximas etapas

Você pode modificar essa 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 pode ajudar a atenuar os riscos de falhas mais amplas do datacenter geográfico, como as causadas por terremotos ou outros desastres naturais. Para saber mais sobre o dimensionamento horizontal, confira Escala Distribuída Geográfica com ambientes de Serviço de Aplicativo. Para uma solução de roteamento global e altamente disponível, considere usar o Azure Front Door.