Confiabilidade no Gateway de Aplicativo do Azure v2

Este artigo descreve o suporte à confiabilidade do Gateway de Aplicativo do Azure v2, abrangendo a resiliência intra-regional por meio de zonas de disponibilidade e implantações de várias regiões. Saiba como configurar o Gateway de Aplicativo v2 para a máxima confiabilidade e tolerância a falhas em ambientes de produção.

A confiabilidade é uma responsabilidade compartilhada entre você e a Microsoft. Você pode usar este guia para determinar quais opções de confiabilidade atendem aos seus objetivos de negócios específicos e metas de tempo de atividade.

O Gateway de Aplicativo v2 é um balanceador de carga de tráfego da Web que você pode usar para gerenciar o tráfego para seus aplicativos Web. Ele fornece recursos avançados, como dimensionamento automático, redundância de zona, endereços VIP (IP virtual estático) e integração do WAF (firewall do aplicativo Web) para fornecer serviços de entrega de aplicativos altamente disponíveis e seguros.

Recomendações de implantação de produção

Para saber mais sobre como implantar o Gateway de Aplicativo para dar suporte aos requisitos de confiabilidade da solução e como a confiabilidade afeta outros aspectos de sua arquitetura, consulte as práticas recomendadas de arquitetura para o Gateway de Aplicativo no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

O Gateway de Aplicativo é um serviço gerenciado. É importante entender alguns dos principais elementos da arquitetura de serviço para que você possa tomar decisões de confiabilidade informadas.

• Instâncias: Uma instância é uma unidade no nível da VM (máquina virtual) do gateway. Cada instância representa uma VM dedicada que manipula o tráfego. Uma instância é igual a uma VM.

  Você não vê nem gerencia as VMs diretamente. A plataforma gerencia automaticamente a criação da instância, o monitoramento de integridade e a substituição de instâncias não íntegras. Ele também gerencia a remoção normal de instâncias durante eventos de escala. Esse processo é conhecido como esvaziamento de conexão.

• Escala: Um aspecto importante da confiabilidade de um gateway é como ele é dimensionado para atender à demanda de tráfego. Se um gateway não for dimensionado adequadamente, o tráfego não poderá fluir e seu aplicativo poderá experimentar tempo de inatividade. Você pode configurar o Gateway de Aplicativo para usar um dos seguintes modos de dimensionamento.

  • Dimensionamento automático: Ajusta automaticamente o número de instâncias dentro de um intervalo especificado. O dimensionamento automático dimensiona o número de instâncias com base na demanda de tráfego atual.

  • Dimensionamento manual: Exige que você especifique um número exato de instâncias. Você é responsável por selecionar uma contagem de instâncias que atenda à sua demanda de tráfego.

  Uma unidade de capacidade representa uma quantidade de capacidade que o gateway pode processar. Uma unidade de capacidade é uma medida sintética que incorpora o tráfego, o número de conexões e os recursos de computação. Cada instância pode lidar com pelo menos 10 unidades de capacidade. Para obter mais informações, consulte Scale Application Gateway v2 e WAF v2.

• Investigações de integridade: O Gateway de Aplicativo usa investigações de integridade para monitorar continuamente seus servidores de back-end, como servidores de aplicativos individuais. O tráfego pode ser redirecionado automaticamente para servidores de back-end íntegros quando servidores não íntegros são detectados.

Falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Ao usar o Gateway de Aplicativo, considere as seguintes práticas recomendadas:

• Implementar lógica de repetição. Os clientes devem implementar mecanismos de repetição apropriados para falhas transitórias de conexão.

• Configurar investigações de integridade com tolerância. Configure suas investigações de integridade para permitir um período de carência para falhas transitórias. Investigações de integridade podem ser configuradas com um limite não íntegro, que especifica o número de tentativas de conexão com falha consecutivas que devem disparar o servidor de back-end a ser marcado como não íntegro. O valor padrão de três garante que falhas transitórias em seus servidores de back-end não disparem o Gateway de Aplicativo para marcar desnecessariamente o servidor como não íntegro.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em cada região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

O Gateway de Aplicativo fornece dois tipos de suporte à zona de disponibilidade quando você implanta um gateway de Standard_v2 ou WAF_v2 em uma região com suporte.

• Com redundância de zona: O Azure distribui automaticamente as instâncias em duas ou mais zonas de disponibilidade.

• Zonal: O Azure implanta todas as instâncias do Gateway de Aplicativo em uma única zona selecionada na região do Azure escolhida.

  Importante

  A fixação em uma única zona de disponibilidade só é recomendada quando a latência entre zonas é muito alta para suas necessidades e quando você verifica se a latência não atende aos seus requisitos. Por si só, um gateway zonal não fornece resiliência a uma interrupção de zona de disponibilidade. Para melhorar a resiliência de uma implantação do Gateway de Aplicativo zonal, você precisa implantar explicitamente gateways separados em várias zonas de disponibilidade e configurar o roteamento e o failover de tráfego.

Suporte de regiões

O Gateway de Aplicativo dá suporte a zonas de disponibilidade para as camadas Standard_v2 e WAF_v2 em todas as regiões do Azure que dão suporte a zonas de disponibilidade.

Requisitos

• Você deve usar o SKU Standard_v2 ou WAF_v2 para habilitar o suporte à zona de disponibilidade.

• Seu gateway deve ter no mínimo duas instâncias.

  Observação

  Todos os gateways têm no mínimo duas instâncias. Mesmo que o portal do Azure indique que o gateway tem uma única instância, internamente ele sempre é criado com um mínimo de duas instâncias.

Considerações

Gateways com redundância de zona são distribuídos em duas ou mais zonas de disponibilidade na região. Por exemplo, em uma região que tem três zonas de disponibilidade, uma implantação do Gateway de Aplicativo v2 com redundância de zona tem instâncias em pelo menos duas dessas zonas. Dependendo da capacidade regional e das decisões de plataforma, as instâncias podem ser distribuídas em duas zonas ou três zonas.

Custo

O suporte à zona de disponibilidade para o Gateway de Aplicativo v2 não incorre em encargos extras além do preço da unidade de capacidade padrão. Para obter detalhes de preços, consulte Entenda os preços do Gateway de Aplicativo e do WAF e do Gateway de Aplicativo.

Configurar o suporte à zona de disponibilidade

Esta seção explica como configurar o suporte à zona de disponibilidade para seus gateways.

• Crie um novo gateway com suporte à zona de disponibilidade. A abordagem que você usa para configurar zonas de disponibilidade depende se você deseja criar um gateway zonal ou com redundância de zona.

  • Com redundância de zona: Os novos gateways são criados como com redundância de zona por padrão. As instâncias são distribuídas em várias zonas de disponibilidade e podem usar duas ou mais zonas na região.

    Para implantar um novo gateway, consulte Início Rápido: Direcionar o tráfego da Web usando o Gateway de Aplicativo – portal do Azure.

    Observação

    Depois de implantar um novo gateway usando o portal do Azure, o portal ou outras ferramentas podem indicar que o gateway não é com redundância de zona. No entanto, se o gateway for implantado em uma região que dá suporte a zonas de disponibilidade, é garantido que ele seja redundante de zona.

    Ao usar a CLI do Azure, o Azure PowerShell, o Bicep, os modelos do ARM (modelos do Azure Resource Manager) ou o Terraform, você pode, opcionalmente, especificar as zonas de disponibilidade para implantar o gateway. Você pode implantar um gateway com redundância de zona especificando duas ou mais zonas. No entanto, recomendamos que você omita a lista de zonas para que o gateway possa usar todas as zonas de disponibilidade, a menos que você tenha um motivo específico para não usar uma zona específica.

  • Zonal: Você pode implantar um gateway zonal usando as ferramentas a seguir.

    • CLI do Azure: Você deve selecionar explicitamente zonas usando o --zones parâmetro no az network application-gateway create comando. Para fixar o gateway em uma única zona, especifique o número da zona lógica.

    • Azure PowerShell: Use o -Zone parâmetro no New-AzApplicationGateway comando. Para fixar o gateway em uma única zona, especifique o número da zona lógica.

    • Modelos Bicep e ARM: Configure a zones propriedade na definição de recurso. Para fixar o gateway em uma única zona, especifique o número da zona lógica.

    Observação

    Quando você seleciona quais zonas de disponibilidade usar, na verdade está selecionando a zona de disponibilidade lógica. Se você implantar outros componentes de carga de trabalho em uma assinatura diferente do Azure, eles podem usar um número de zona de disponibilidade lógica diferente para acessar a mesma zona de disponibilidade física. Para obter mais informações, confira Zonas de disponibilidade físicas e lógicas.

• Altere a configuração da zona de disponibilidade de uma instância existente do Gateway de Aplicativo v2. A Microsoft está atualizando automaticamente todos os gateways nonzonal existentes para serem redundantes por zona, sem nenhuma ação sua. Essa atualização deve ser concluída em 2025.

  Se você precisar mover de um gateway com redundância de zona para uma configuração zonal, precisará implantar um novo gateway.

• Desabilite o suporte à zona de disponibilidade. O suporte à zona de disponibilidade não pode ser desabilitado. Todos os gateways em regiões que dão suporte a zonas de disponibilidade devem ser com redundância de zona ou zonal.

Planejamento e gerenciamento de capacidade

Quando você planeja falhas de zona para um gateway de aplicativo com redundância de zona ou vários gateways zonais implantados em várias zonas, considere que as instâncias em zonas sobreviventes podem ter maior carga à medida que o tráfego é redistribuído. As conexões podem sofrer breves interrupções que podem durar alguns segundos.

Para gerenciar a capacidade com eficiência, execute as seguintes ações:

• Use o dimensionamento automático. Configure o dimensionamento automático com contagens máximas de instância apropriadas para lidar com possíveis redistribuições de tráfego durante interrupções de zona.

  Se você usar o dimensionamento manual, para se preparar para falha na zona de disponibilidade, considere o excesso de provisionamento do número de instâncias em seu gateway. O excesso de provisionamento permite que a solução tolere algum grau de perda de capacidade, enquanto continua a funcionar sem desempenho degradado. Para obter mais informações, consulte Gerenciar capacidade com provisionamento excessivo.

• Responda às alterações nos padrões de tráfego. Monitore as métricas de capacidade e ajuste os parâmetros de dimensionamento com base em seus padrões de tráfego e requisitos de desempenho.

Operações normais

A seção a seguir descreve o que esperar quando o Gateway de Aplicativo v2 está configurado com suporte à zona de disponibilidade e todas as zonas de disponibilidade estão operacionais.

• Roteamento de tráfego entre zonas: O Gateway de Aplicativo distribui automaticamente as solicitações de entrada entre instâncias em todas as zonas que o gateway usa. Essa configuração ativa-ativa garante o desempenho ideal e a distribuição de carga em condições operacionais normais.

• Gerenciamento de instância: A plataforma gerencia automaticamente o posicionamento da instância entre as zonas que o gateway usa. Ele substitui instâncias com falha e mantém a contagem de instâncias configurada. O monitoramento de integridade garante que apenas instâncias íntegras recebam tráfego.

Experiência de redução de atividade na zona

A seção a seguir descreve o que esperar quando o Gateway de Aplicativo v2 está configurado com suporte à zona de disponibilidade e uma ou mais zonas de disponibilidade não estão disponíveis.

• Detecção e resposta: A responsabilidade pela detecção e resposta depende da configuração da zona de disponibilidade usada pelo gateway.

  • Com redundância de zona: A Microsoft gerencia a detecção de falhas de zona e inicia automaticamente o failover. Não é necessária nenhuma ação do cliente.

  • Zonal: Você precisa detectar a perda de uma zona de disponibilidade e iniciar um failover para um gateway secundário criado em outra zona de disponibilidade.

• Notificação: Os eventos de falha de zona podem ser monitorados por meio da Integridade do Serviço do Azure e do Resource Health. Configure alertas nesses serviços para receber notificações de problemas no nível da zona.

• Solicitações ativas: Durante uma interrupção de zona, as solicitações que estão sendo processadas por instâncias nessa zona são encerradas. Os clientes devem repetir as solicitações seguindo as diretrizes de como lidar com falhas transitórias.

• Perda de dados esperada: Não se espera que falhas de zona causem perda de dados porque o Gateway de Aplicativo é um serviço sem estado.

• Tempo de inatividade esperado: O tempo de inatividade que você pode esperar depende da configuração da zona de disponibilidade usada pelo gateway.

  • Com redundância de zona: Durante interrupções de zona, as conexões podem sofrer breves interrupções que normalmente duram alguns segundos à medida que o tráfego é redistribuído.

  • Zonal: Quando uma zona não está disponível, o gateway fica indisponível até que a zona de disponibilidade se recupere.

• Gerenciamento de instância: O comportamento de gerenciamento de instância depende da configuração da zona de disponibilidade usada pelo gateway.

  • Com redundância de zona: A plataforma tenta manter a capacidade do gateway criando instâncias temporárias em outras zonas de disponibilidade.

    Internamente, o Gateway de Aplicativo usa conjuntos de dimensionamento de máquinas virtuais, que executam o balanceamento de zona de melhor esforço [balanceamento de zona de melhor esforço]. Devido a esse comportamento, as operações de dimensionamento podem não ocorrer quando a capacidade não pode ser dividida uniformemente entre zonas (+/- 1 instância).

  • Zonal: Você será responsável por criar instâncias em zonas íntegras se precisar delas.

• Redirecionamento de tráfego: O comportamento de redirecionamento de tráfego depende da configuração da zona de disponibilidade usada pelo gateway.

  • Com redundância de zona: O Gateway de Aplicativo redistribui imediatamente o tráfego para as instâncias em zonas íntegras, incluindo todas as instâncias que são criadas temporariamente.

  • Zonal: Quando uma zona não está disponível, o gateway não está disponível. Se você tiver um gateway secundário em outra zona de disponibilidade, será responsável por redirecionar o tráfego para esse gateway secundário.

Recuperação de zona

O comportamento de recuperação de zona depende da configuração da zona de disponibilidade que o gateway usa:

• Com redundância de zona: Quando a zona de disponibilidade afetada se recupera, o Gateway de Aplicativo executa automaticamente as seguintes ações:

  • Restaura instâncias na zona recuperada

  • Remove todas as instâncias temporárias que foram criadas em outras zonas durante a interrupção

  • Retorna à distribuição de tráfego normal em todas as zonas disponíveis

• Zonal: Você é responsável por redirecionar o tráfego para o gateway na zona de disponibilidade original após a recuperação da zona de disponibilidade.

Teste de falhas de zona

As opções de teste para falhas de zona dependem da configuração da zona de disponibilidade usada pelo gateway.

• Com redundância de zona: A plataforma gateway de aplicativo gerencia totalmente o roteamento de tráfego, o failover e o failback para gateways com redundância de zona. Como a Microsoft gerencia esse recurso, você não precisa iniciar nem validar processos de falha de zona de disponibilidade. A plataforma lida com todos os cenários de falha de zona de forma transparente.

• Zonal: Você pode simular alguns aspectos da falha de uma zona de disponibilidade interrompendo explicitamente um gateway. Ao parar o gateway, você pode testar como outros sistemas e balanceadores de carga lidam com uma interrupção no gateway. Para obter mais informações, consulte Como parar e iniciar o Gateway de Aplicativo.

Suporte para várias regiões

O Gateway de Aplicativo v2 é um serviço de região única. Se a região ficar indisponível, o gateway também ficará indisponível.

Abordagens alternativas de várias regiões

Para obter resiliência de várias regiões usando o Gateway de Aplicativo v2, você precisa implantar gateways separados em cada região desejada e implementar o gerenciamento de tráfego entre regiões. Você é responsável por implantar e configurar cada um dos gateways, bem como roteamento de tráfego e failover. Considere os seguintes pontos:

• Configure regras e políticas consistentes do Gateway de Aplicativo entre regiões. Você pode definir a infraestrutura como código (IaC) usando ferramentas como Bicep ou Terraform para simplificar suas implantações e configurações entre regiões.

• Implante uma solução global de balanceamento de carga que possa enviar tráfego entre seus gateways regionais. Os serviços globais de balanceamento de carga no Azure são o Gerenciador de Tráfego do Azure e o Azure Front Door. Cada serviço roteia o tráfego com base em verificações de integridade, proximidade geográfica ou métricas de desempenho. O Azure Front Door também fornece uma série de outros recursos, incluindo proteção contra ataque de DDoS (negação de serviço distribuído), recursos de WAF e regras avançadas e recursos de roteamento.

• Além do gateway, considere replicar aplicativos de back-end e dados entre regiões. Consulte os guias de confiabilidade de cada serviço do Azure para entender as abordagens de implantação de várias regiões.

Para obter uma abordagem de exemplo, consulte Usar o Gateway de Aplicativo com o Gerenciador de Tráfego.

Cópias de segurança

O Gateway de Aplicativo v2 é um serviço sem estado que não requer operações tradicionais de backup e restauração. Todos os dados de configuração são armazenados no Resource Manager e podem ser reimplantados usando abordagens IaC, como arquivos Bicep ou modelos do ARM.

Para gerenciamento de configuração e recuperação de desastre, você deve executar as seguintes ações:

• Defina a configuração da implantação do Gateway de Aplicativo usando arquivos Bicep ou modelos do ARM ou exporte a configuração de um gateway existente.

• Armazene certificados TLS (segurança de camada de transporte) no Azure Key Vault para gerenciamento seguro e replicação.

• Políticas, regras e configurações personalizadas de controle de documento e versão.

• Implemente pipelines de implantação automatizados para provisionamento de gateway consistente.

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte Redundância, replicação e backup.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Conteúdo relacionado

• Visão geral da confiabilidade do Azure