Entrega e desempenho da aplicação

Este artigo ajuda-o a selecionar o serviço de balanceamento de carga Azure adequado para a sua carga de trabalho. Compara o Balanceador de Carga do Azure, Application Gateway e Azure Front Door para a distribuição regional e global do tráfego. Também explica quando os combinar. Para uma visão geral mais breve, serviço por serviço, veja O que é equilíbrio de carga e distribuição de conteúdos?

O que este artigo aborda

A entrega de aplicações inclui a forma como a sua rede distribui o tráfego através dos recursos backend depois de este chegar ao perímetro da rede. Este artigo aborda o balanceamento de carga das Camada 4 e 7 e a aceleração global do tráfego. Também cobre os critérios de decisão para escolher entre os três principais serviços de balanceamento de carga do Azure.

Note

Este artigo complementa o ingresso da Internet: expõe a tua aplicação à Internet, que se centra em como o tráfego chega à tua rede. Este artigo foca-se em como equilibrar e entregar esse tráfego para os backends da sua aplicação.

Quem precisa deste artigo

Leia este artigo se:

  • Aloje aplicações web ou APIs que necessitem de elevada disponibilidade em múltiplas instâncias de back-end.
  • Precisa de descarregamento SSL/TLS, encaminhamento baseado em URL ou proteção contra Firewall de Aplicações Web (WAF) para tráfego HTTP/HTTPS.
  • Distribuir o tráfego por várias regiões do Azure para desempenho ou recuperação de desastres.
  • Executar cargas de trabalho não-HTTP (TCP/UDP) que exijam balanceamento de carga regional com sondas de saúde.
  • Quero perceber qual o balanceador de carga que se adequa ao seu tipo de tráfego, âmbito geográfico e requisitos de segurança.

Foco em levantar e deslocar: Muitas aplicações internas realojadas precisam apenas de um balanceador de carga regional. Adicione serviços de entrega com acesso à internet quando publicar uma aplicação para os clientes.

Modernizar o foco: Escolha a entrega por tipo de aplicação: Azure Front Door para aplicações web globais e Traffic Manager para aplicações não-web, com acesso a endpoints regionais ativo-ativo.

Foco multicloud: Mapeie os balanceadores de carga de outras clouds para os equivalentes do Azure (por exemplo, AWS ALB para Application Gateway, NLB para Balanceador de Carga do Azure) e encaminhe através da spoke atrás da firewall do hub.

Serviços e funcionalidades do Azure

A tabela seguinte resume os três principais serviços de balanceamento de carga do Azure.

Serviço O que oferece Quando usar Principais restrições
Azure Balanceador de Carga Standard Camada 4 (TCP/UDP) balanceamento de carga dentro de uma região. Sondas de saúde, redundância de zonas, regras SNAT de saída e portas HA para dispositivos virtuais de rede. Conjuntos de dimensionamento de máquinas virtuais, tráfego interno do AKS, cargas de trabalho regionais não HTTP/HTTPS e alta disponibilidade de NVA. Sem terminação SSL/TLS; sem WAF; sem encaminhamento baseado em URL; Apenas âmbito regional.
Gateway de Aplicação do Azure Balanceamento regional de carga da Camada 7 (HTTP/HTTPS). Terminação SSL/TLS, encaminhamento baseado em caminhos de URL, alojamento multisite, afinidade de sessão baseada em cookies e integração opcional com WAF. Aplicações web regionais que necessitam de descarregamento SSL, encaminhamento de URLs, suporte a WebSocket ou proteção WAF. Apenas regionais; requer uma sub-rede dedicada; não é adequado para encaminhamento global ou cenários de CDN.
Azure Front Door Distribuição de carga com anycast global e CDN. Terminação TLS na borda, WAF integrado, sondas de estado da origem, divisão de tráfego e armazenamento em cache em mais de 190 pontos de presença (PoPs) globais. Aplicações web globais, implementações ativas-ativas multirregionais, CDN e cache, e aplicação global de WAF. HTTP/HTTPS apenas; as origens devem ser publicamente acessíveis ou acessíveis através do Private Link (nível Premium).

Redundância entre zonas

A redundância por zonas protege a sua camada de entrega de aplicações contra falhas em centros de dados. Cada serviço gere as zonas de disponibilidade de forma diferente:

  • O Balanceador de Carga Standard (público) tem, por predefinição, redundância entre zonas porque os endereços IP públicos Standard têm, por predefinição, uma configuração com redundância entre zonas. O tráfego continua a fluir mesmo que uma zona de disponibilidade falhe. O Balanceador de Carga Standard (interno) requer uma configuração explícita de redundância de zonas na interface: deve selecionar múltiplas zonas ao criar o IP da interface.
  • O Application Gateway v2 suporta redundância de zonas quando se implementam instâncias em várias zonas de disponibilidade. Especifique as zonas durante a implantação. Um Gateway de Aplicação redundante por zona distribui as instâncias pelas zonas selecionadas, mantendo a disponibilidade caso uma única zona fique offline.
  • Azure Front Door é, por natureza, um serviço com redundância entre zonas enquanto serviço anycast global. Os seus mais de 190 PoPs de borda abrangem várias regiões a nível mundial, pelo que a falha de uma única zona ou região não afeta o encaminhamento global do tráfego.

Autoscaling

Cada serviço lida com a escala de forma diferente:

  • O Application Gateway v2 (escalões Standard_v2 e WAF_v2) suporta o dimensionamento automático com base na carga de tráfego. Configuras o número mínimo e máximo de instâncias, e o gateway escala dentro desses limites. Os preços baseiam-se em unidades de capacidade: uma medida composta por novas ligações por segundo, ligações persistentes e débito. Defina um número mínimo de instâncias de pelo menos duas para cargas de produção para evitar a latência de arranque a frio durante picos de tráfego.
  • O Azure Front Door escala automaticamente como um serviço global gerido. Não precisas de planeamento de capacidade nem de dimensionamento das instâncias.
  • O Balanceador de Carga Standard escala para milhões de fluxos TCP/UDP sem intervenção manual ou alterações de configuração. É um serviço totalmente gerido de plataforma, sem conceito de instância.

Sondas de saúde

Os três serviços utilizam sondas de estado de funcionamento para detetar backends com problemas e deixar de encaminhar tráfego para os mesmos:

  • O Balanceador de Carga Standard suporta sondas de saúde TCP, HTTP e HTTPS. Configure intervalos de sonda e limiares pouco saudáveis para controlar a velocidade de failover. Intervalos mais curtos detetam falhas mais rapidamente, mas geram mais tráfego de sonda.
  • O Application Gateway utiliza sondas de saúde HTTP/HTTPS com caminhos, nomes de host e correspondência de respostas personalizáveis. Sondas personalizadas permitem-te validar a lógica da aplicação (por exemplo, verificar um /health endpoint que verifica a conectividade da base de dados).
  • Front Door utiliza sondas de estado HTTP/HTTPS nas origens. Suporta caminhos de sonda configuráveis, intervalos e correspondência de código de resposta. As sondas da Porta Frontal originam-se de múltiplos PoPs, fornecendo verificação distribuída de saúde.

Como escolher

O fluxograma seguinte resume o principal caminho de decisão para selecionar um serviço de balanceamento de carga Azure.

Fluxograma que seleciona um serviço de balanceamento de carga Azure através de ramificações entre tráfego HTTP vs. não-HTTP, depois escopo de região única vs. global.

Use as seguintes tabelas de decisão para selecionar o serviço de balanceamento de carga adequado para o seu cenário.

De que balanceador de carga preciso?

Preciso de... Use
Balanceamento de carga do tráfego TCP/UDP dentro de uma única região Azure Balanceador de Carga Standard: Distribuição da camada 4 com sondas de saúde, redundância de zonas e portas de HA.
Terminar SSL/TLS, encaminhar por caminho de URL ou nome de host, e adicionar WAF para uma aplicação web regional Gateway de Aplicação do Azure: Distribuição de carga regional da camada 7 com WAF integrado (SKU v2).
Encaminhe o tráfego HTTP/HTTPS globalmente, reduza a latência com cache nas bordas ou faça failover entre regiões Azure Front Door: Anycast global com sondas de saúde CDN, WAF e origem multirregional.

Comparação de restrições de chave

Serviço Camada Scope Limitação de chaves
Balanceador de Carga Standard Camada 4 (TCP/UDP) Regional Sem consciência da aplicação: não é possível inspecionar cabeçalhos HTTP, URLs ou cookies.
Gateway de Aplicação Camada 7 (HTTP/HTTPS) Regional Requer uma sub-rede dedicada (/24 recomendado); Não é possível encaminhar o tráfego globalmente.
Front Door Camada 7 (HTTP/HTTPS) Global O Origins deve ser público ou acessível através do Private Link (apenas no nível Premium); não há suporte TCP/UDP.

Combinação de serviços

Muitas arquiteturas de produção combinam múltiplos serviços de balanceamento de carga numa cadeia. Cada serviço trata do que faz melhor:

  • Front Door + Gateway de Aplicação: Use o Front Door para distribuição global de tráfego e WAF na borda e, em seguida, encaminhe para instâncias regionais de Gateway de Aplicação para encaminhamento baseado no caminho do URL e gestão de conjuntos de servidores de back-end. O Front Door Premium pode ligar-se ao Application Gateway através do Private Link, mantendo o Application Gateway privado. Este padrão adequa-se a implementações multirregional onde cada região tem requisitos complexos de encaminhamento de URLs.
  • Front Door + Balanceador de Carga: Utilize o Front Door para distribuição global de HTTP/HTTPS, com um Balanceador de Carga Standard interno atrás deste para distribuir o tráfego entre Conjuntos de Dimensionamento de Máquinas Virtuais ou NVAs numa região. O Front Door faz a gestão do encaminhamento global e da colocação em cache, enquanto o Balanceador de Carga fornece distribuição na Camada 4 pelas instâncias de computação.
  • Application Gateway + Balanceador de Carga: Use o Application Gateway para gestão de tráfego HTTP/HTTPS no frontend e o Balanceador de Carga para camadas backend não-HTTP (bases de dados, filas de mensagens) na mesma implementação. Este padrão mantém a inteligência de Camada 7 no limite da rede, com uma distribuição interna de Camada 4 mais ligeira.

Capacidades de encaminhamento

Compreender as capacidades de roteamento ajuda a restringir a sua escolha:

Capacidade Balanceador de Carga Standard Gateway de Aplicação Front Door
Roteamento baseado em caminho de URL No Sim Sim
Encaminhamento de vários sites (host-header) No Sim Sim
Afinidade de sessão baseada em cookies No Sim Sim
Divisão ponderada do tráfego No No Sim
Roteiro geográfico No No Sim
Descarregamento de SSL/TLS No Sim Sim
Suporte do WebSocket Repercussão Sim Sim
Suporte HTTP/2 No Sim Sim

Dica

O Application Gateway v2 escala automaticamente entre um número mínimo e um máximo de instâncias, e paga-se pelo menos pela capacidade mínima mesmo quando o tráfego está inativo. Defina o número mínimo de instâncias de acordo com a sua carga de base, não com a carga de pico, e deixe a escalabilidade automática acomodar os picos. Sobredimensionar o mínimo é uma causa comum de custos evitáveis no Application Gateway.

Considerações de design

Foco na conceção da disponibilização de aplicações lift-and-shift

  • Utilize um Balanceador de Carga do Azure interno para o tráfego Este-Oeste entre camadas de uma aplicação realojada, mantendo a mesma distribuição de carga de que a aplicação já dependia.
  • Adicione serviços públicos de disponibilização apenas para as aplicações que disponibiliza na Internet; muitas cargas de trabalho internas migradas não necessitam desses serviços.
  • Mantenha o design de entrega simples e de região única durante o realojamento inicial.
  • Encaminhe qualquer tráfego de internet de entrada através do firewall do hub antes de chegar à carga de trabalho.

Modernizar o foco do design da entrega de aplicações

  • Escolha por tipo de aplicação: Azure Front Door para aplicações web globais (terminação de borda, WAF) e Gestor de Tráfego do Azure para aplicações não web que necessitam de distribuição regional baseada em DNS.
  • Implementar uma configuração ativo-ativo entre regiões e distribuir o tráfego para o endpoint público de cada região, protegido pela firewall do hub, que atua como SNAT e DNAT.
  • Utilize o Application Gateway para encaminhamento regional de Camada 7 e terminação de TLS, atrás do Front Door quando precisar de distribuição global.
  • Não implemente tanto o Front Door como o Traffic Manager para o mesmo fluxo; Escolhe uma com base se a aplicação é web ou não.

Foco na conceção da disponibilização de aplicações multicloud

  • Mapear serviços de entrega de outras clouds para Azure: AWS Application Balanceador de Carga ou Google Cloud Application Load Balancing para Gateway de Aplicação do Azure, e balanceadores de carga de rede para Balanceador de Carga do Azure.
  • Aloje a entrega de Camada 7 (o Application Gateway, com WAF) no spoke e evite associar IPs públicos diretamente às máquinas virtuais.
  • Encaminhe o tráfego de entrada público através do firewall seguro do hub antes de chegar às cargas de trabalho migradas.
  • Utilize o Front Door ou o Traffic Manager para distribuição multirregional quando as cargas de trabalho forem executadas em mais de uma região do Azure.

Pré-requisitos

Antes de implementar serviços de entrega de aplicações:

  • Rede virtual implementada: Precisas de pelo menos uma rede virtual com sub-redes. Consulte Design de redes virtuais e sub-redes para orientações sobre planeamento de sub-redes.
  • Tipo de tráfego de carga de trabalho identificado: Saiba se a sua carga de trabalho usa HTTP/HTTPS (Camada 7) ou TCP/UDP (Camada 4). Este tipo de tráfego determina a sua escolha principal de balanceador de carga.
  • Âmbito geográfico definido: Determine se os seus utilizadores estão numa única região ou distribuídos globalmente. As bases de utilizadores a nível global beneficiam da aceleração Anycast do Front Door.
  • Capacidade de sub-redes para o Application Gateway: O Application Gateway requer uma sub-rede dedicada sem outros recursos. Uma sub-rede /24 suporta até 125 instâncias mais cinco endereços reservados no Azure.

Considerações de segurança

Os serviços de balanceamento de carga fazem parte do seu perímetro de segurança. São os primeiros componentes a processar o tráfego recebido, o que torna a sua configuração de segurança crítica. Siga estas práticas para proteger o seu nível de entrega de candidaturas.

Firewall de Aplicações Web (WAF)

Ative o WAF em modo de Prevenção no Application Gateway ou Front Door para todas as cargas de trabalho web de produção. O modo de deteção apenas regista ameaças sem as bloquear. Utilize-o durante o ajuste inicial para identificar falsos positivos e, em seguida, mude para o modo Prevenção antes de o tráfego de produção começar a circular.

O WAF protege contra vulnerabilidades comuns da Web, incluindo:

  • Injeção SQL e cross-site scripting (XSS)
  • Anomalias de protocolo e contrabando de pedidos
  • Bots e rastreadores (com regras de proteção contra bots)
  • Principais 10 vulnerabilidades do OWASP através de conjuntos de regras geridas

Tanto o Application Gateway WAF como o Front Door WAF usam o mesmo motor de regras, mas diferem no âmbito. O WAF do Application Gateway protege uma implementação regional, enquanto o WAF do Front Door aplica políticas no perímetro global antes de o tráfego chegar a qualquer origem. Para ajustes detalhados de WAF e configuração do conjunto de regras, consulte Firewall de Aplicações Web.

proteção contra DDoS

Ative a Proteção DDoS do Azure em todos os endereços IP públicos associados aos seus serviços de balanceamento de carga. Os endereços IP públicos de front-end do Balanceador de Carga Standard e os endereços IP públicos do Application Gateway são os principais alvos de ataques volumétricos. Estes IPs representam os pontos de entrada da sua aplicação.

O Azure DDoS Protection fornece:

  • Monitorização de tráfego sempre ativa com afinação adaptativa.
  • Mitigação automática de ataques quando o tráfego ultrapassa um limiar.
  • Telemetria de ataque e alertas através do Azure Monitor.
  • Proteção contra custos (crédito de serviço) para o escalamento de recursos desencadeado por ataques DDoS.

Para o planeamento e configuração da proteção DDoS, veja proteção DDoS.

O Azure Front Door Premium suporta conectividade Private Link para origins. Esta capacidade elimina a necessidade de servidores backend acessíveis publicamente. O Front Door liga-se à sua origem através da rede Azure backbone em vez da internet pública. Use origens do Private Link quando:

  • Os seus backends são serviços internos que não deveriam ter endereços IP públicos.
  • Tens de bloquear o acesso de origem apenas ao tráfego da Porta Principal.
  • Os requisitos de conformidade proíbem endpoints públicos nos servidores de aplicação.
  • Queres remover a superfície de ataque de uma origem publicamente exposta.

Origens suportadas pelo Private Link incluem App Service, Armazenamento do Azure, Application Gateway, Balanceador de Carga Standard interno e origens personalizadas com serviço Private Link.

Para padrões de arquitetura Private Link, veja Acesso privado aos serviços Azure PaaS.

Importante

O nível Standard do Front Door não suporta o Private Link para origens. Apenas o Front Door Premium oferece esta capacidade.

TLS mútuo (mTLS)

O Application Gateway v2 suporta TLS mútuo para autenticação de back-end. Usa mTLS quando os teus servidores backend requerem autenticação de cliente baseada em certificados a partir do gateway. Esta autenticação adiciona uma camada de verificação de confiança. O backend pode confirmar que o tráfego provém da instância legítima do Application Gateway, e não de um agente malicioso que contornou o Application Gateway.

Saiba mais

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Controle o tráfego de saída para a Internet: Centralize o acesso de saída através da firewall do hub e desative a saída predefinida.

Próximo passo na sua jornada de modernização:

Configure conectividade privada a serviços PaaS: Crie subredes Private Link em cada VNet spoke para as suas cargas de trabalho AKS, ASE e bases de dados geridas.

A seguir na sua jornada através da cloud:

Proteja a sua rota de trânsito entre clouds: Implemente o Azure Firewall no seu hub virtual seguro para inspecionar todo o tráfego entre clouds e com destino à Internet.

  • Last updated on