Implantação corporativa 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 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 do Ambiente do Serviço de Aplicativo implantando-a em uma arquitetura redutora de zona. Estas zonas não estão relacionadas com a proximidade. Eles podem mapear para diferentes locais físicos para diferentes assinaturas. A arquitetura pressupõe uma implantação de assinatura única.

Os serviços do Azure que dão suporte a zonas de disponibilidade podem ser zonais, redundantes 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 orientações e recomendações detalhadas, consulte Suporte à zona de disponibilidade. O Ambiente do Serviço de Aplicativo oferece suporte a implantações com redundância de zona.

Quando você configura o Ambiente do Serviço de Aplicativo para ser redundante de zona, a plataforma implanta automaticamente instâncias do plano do Serviço de Aplicativo do Azure em 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.

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

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Os recursos nas sub-redes do Ambiente do Serviço de Aplicativo nesta implementação de referência são os mesmos da arquitetura de implantação padrão do Ambiente do Serviço de Aplicativo. Essa implementação de referência usa os recursos redundantes de zona do Ambiente do Serviço de Aplicativo v3 e do Cache Redis do Azure para fornecer maior disponibilidade. Observe que o escopo dessa arquitetura de referência é limitado a uma única região.

Fluxo de Trabalho

Esta seção descreve a natureza da disponibilidade para serviços usados nessa 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 que oferecem suporte a todas as dependências do Ambiente do Serviço de Aplicativo v3. Cada plano do Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo com redundância de zona precisa ter um mínimo de três instâncias para que possam ser implantados em três zonas. A taxa mínima é para nove casos. Para obter mais informações, consulte estas diretrizes de preços. Para obter orientações e recomendações detalhadas, consulte Suporte ao 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 ú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 o Ambiente do Serviço de Aplicativo.

• O Application Gateway v2 é redundante de zona. 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 WAF SKU do Application Gateway, que fornece maior proteção contra ameaças e vulnerabilidades comuns, com base em uma implementação do Core Rule set (CRS) do Open Web Application Security Project (OWASP). Para obter mais informações, consulte Dimensionamento do Application Gateway v2 e WAF v2.

• O Firewall do Azure tem suporte interno para alta disponibilidade. Pode atravessar várias zonas sem qualquer configuração adicional.

  Se precisar, você também pode 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 Microsoft Entra ID é 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 Microsoft Entra.

• O GitHub Actions fornece recursos de integração contínua e implantação contínua (CI/CD) nessa arquitetura. Como o Ambiente do Serviço de Aplicativo está na rede virtual, uma máquina virtual é usada como uma caixa de salto 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 RDP/SSH perfeita, considere usar o Azure Bastion para a jumpbox.

• O Cache Redis do Azure é 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. Este serviço proporciona 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, consulte Microsoft Azure Well-Architected Framework.

Disponibilidade

Ambiente do Serviço de Aplicações

Você pode implantar o Ambiente do Serviço de Aplicativo em zonas de disponibilidade para fornecer resiliência e confiabilidade para suas cargas de trabalho críticas para os negócios. 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 do Serviço de Aplicativo em 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 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 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 serão automaticamente redundantes de zona.
• Você pode especificar zonas de disponibilidade somente quando 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 são suportadas apenas em um subconjunto de regiões.

Para obter mais informações, consulte Confiabilidade no Serviço de Aplicativo do Azure.

Resiliência

Os aplicativos executados no Ambiente do Serviço de Aplicativo formam o pool de back-end do Application Gateway. 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. Esta arquitetura de referência implementa verificações de integridade no frontend principal da Web, votingApp. Esta investigação de integridade verifica se a API da Web e o cache Redis estão íntegros. Você pode ver o código que implementa essa sonda em Startup.cs:

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

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

O código a seguir mostra como o script commands_ha.azcli configura os pools de back-end e a sonda 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}"
      }
    ],
    "probePath": "/health"
  }
]

Se algum dos componentes (o front-end da Web, a API ou o cache) falhar na investigação de integridade, o Application Gateway 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 completamente disponível do Ambiente do Serviço de Aplicativo.

A sonda de integridade também é implementada na implementação de referência padrão. Lá, o gateway simplesmente retorna um erro se o teste 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 custos

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

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 do plano do 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 do Ambiente do Serviço de Aplicativo.
• O Cache Redis do Azure também é um serviço com redundância de zona. Um cache com redundância de zona é executado em VMs que são implantadas em várias zonas de disponibilidade para fornecer maior resiliência e disponibilidade.

A contrapartida para 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 sobre implementaçã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 de caixa de salto. Você pode, no entanto, decidir usar um jumpbox para cada uma das três zonas. Essa arquitetura usa apenas uma jumpbox porque a caixa de salto não afeta a disponibilidade do aplicativo. O jumpbox é usado apenas para implantação e teste.

Implementar 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.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Deep Bhattacharya - Brasil | Arquiteto de Soluções Cloud
• Suhas Rao - Brasil | Arquiteto de Soluções Cloud

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

Próximos passos

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 reduzir os riscos de falhas mais amplas no datacenter geográfico, como as causadas por terremotos ou outros desastres naturais. Para saber mais sobre dimensionamento horizontal, consulte Escala distribuída geográfica com ambientes do Serviço de Aplicativo. Para obter uma solução de roteamento global e altamente disponível, considere usar o Azure Front Door.