Confiabilidade no Gateway de Aplicativo do Azure v2

O Gateway de Aplicativo do Azure é 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.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Gateway de Aplicativo v2 resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também realça algumas informações importantes sobre o SLA (contrato de nível de serviço) do Gateway de Aplicativo v2.

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.

• Gateway: Ao implantar o Application Gateway, você implanta um gateway, que é o recurso do Azure com o qual você trabalha.

• Instâncias: Uma instância é uma única unidade do gateway. Um gateway tem várias instâncias. Cada instância tem seu próprio endereço IP privado, manipula o tráfego e roteia solicitações.

  Importante

  Para alta disponibilidade, cada gateway é sempre criado com um mínimo de duas instâncias. No entanto, o portal do Azure pode indicar que seu gateway tem uma única instância, mesmo que ele realmente tenha duas.

  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.

  O diagrama a seguir mostra um gateway com duas instâncias:

  

Para distribuir instâncias em várias zonas de disponibilidade e, portanto, aumentar a redundância e a disponibilidade durante falhas de datacenter, você pode habilitar a redundância de zona.

• 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 Dimensionamento de Gateway de Aplicativo 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.

Resiliência a 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:

• Implemente a 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.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma 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 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.

  Ao implantar um novo gateway, ele é configurado para ser redundante em zonas por padrão.

  O diagrama a seguir mostra um gateway com redundância de zona com três instâncias distribuídas em três 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.

  O diagrama a seguir mostra um gateway zonal com três instâncias implantadas na mesma zona de disponibilidade:

  

  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.

Requisitos

• Suporte à região: 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.

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

• Contagem de instâncias: Seu gateway deve ter pelo menos duas instâncias.

  Observação

  Todos os gateways têm no mínimo duas instâncias para alta disponibilidade. 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 preços 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.

    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 parâmetro --zones no comando az network application-gateway create. Para fixar o gateway em uma única zona, especifique o número da zona lógica.

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

    • Modelos Bicep e ARM: Configure a propriedade zones 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. Todos os gateways são redundantes de zona, a menos que você os configure para serem zonais.

  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.

Comportamento quando todas as zonas estão saudáveis

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.

Comportamento durante uma falha de 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: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas do Resource Health para notificá-lo de problemas. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.

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

Testar falhas em zonas

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.

Resiliência a falhas em toda a região

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.

Soluções personalizadas de várias regiões para resiliência

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.

Backup e restauração

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 O que são redundância, replicação e backup?.

Resiliência à manutenção do serviço

O Gateway de Aplicativo v2 executa atualizações de serviço regulares e outras tarefas de manutenção. Para manter a capacidade esperada durante uma atualização, a plataforma adiciona automaticamente instâncias extras do gateway durante o processo de atualização. No entanto, você precisa garantir que a sub-rede do gateway tenha espaço de endereço IP livre suficiente para que as instâncias temporárias sejam criadas. Para obter mais informações, consulte Como o Gateway de Aplicativo lida com a manutenção de rotina?.

Contrato de nível de serviço

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

Para que um gateway seja qualificado para o SLA de disponibilidade do Gateway de Aplicativo, ele deve atender aos seguintes critérios:

• Ele deve ser configurado corretamente para executar o balanceamento de carga HTTP.
• Ele deve ser com redundância de zonas ou deve ser configurado para usar o dimensionamento automático.

Conteúdo relacionado

• Visão geral da confiabilidade do Azure