Partilhar via


Opções de balanceamento de carga

O termo balanceamento de carga refere-se à distribuição do processamento entre vários recursos de computação. Você equilibra a carga para otimizar o uso de recursos, maximizar a taxa de transferência, minimizar o tempo de resposta e evitar sobrecarregar qualquer recurso. O balanceamento de carga também pode melhorar a disponibilidade compartilhando uma carga de trabalho entre recursos de computação redundantes.

O Azure fornece vários serviços de balanceamento de carga que você pode usar para distribuir suas cargas de trabalho entre vários recursos de computação. Esses serviços incluem o Gerenciamento de API do Azure, o Gateway de Aplicativo do Azure, o Azure Front Door, o Azure Load Balancer e o Azure Traffic Manager.

Este artigo descreve considerações para ajudá-lo a determinar uma solução de balanceamento de carga apropriada para as necessidades da sua carga de trabalho.

Serviços de balanceamento de carga do Azure

Os seguintes serviços principais de balanceamento de carga e serviço com recursos de balanceamento de carga estão disponíveis no Azure:

  • O Gerenciamento de API é um serviço gerenciado que você pode usar para publicar, proteger, transformar, manter e monitorar APIs HTTP(S). Ele oferece um gateway para suas APIs e pode ser configurado para distribuir o tráfego entre os nós em um pool de back-end com balanceamento de carga designado. Você pode escolher entre três métodos diferentes de balanceamento de carga: round-robin, ponderado e baseado em prioridades.

    Importante

    O Gerenciamento de API não é um balanceador de carga tradicional de uso geral. Ele foi projetado especificamente para APIs HTTP e seus recursos de balanceamento de carga são opcionais dentro de sua funcionalidade mais ampla de gerenciamento de API. O Gerenciamento de API está incluído neste artigo para completude porque fornece recursos de balanceamento de carga para topologias de hospedagem de API específicas. No entanto, seu objetivo principal é a funcionalidade do gateway de API em vez do balanceamento de carga.

  • O Application Gateway é um balanceador de carga de proxy. Ele fornece a funcionalidade do controlador de entrega de aplicativos como um serviço gerenciado. Ele oferece várias funcionalidades de balanceamento de carga Layer-7, roteamento, descarregamento TLS e firewall de aplicativos da Web. Como um balanceador de carga de terminação, ele também oferece balanceamento de carga de camada 4 para protocolos TCP e TLS. Use o Application Gateway para fazer a transição do tráfego do espaço de rede pública para seus servidores Web hospedados em espaço de rede privada dentro de uma região.

  • O Application Gateway for Containers é um produto de balanceamento de carga e gerenciamento de tráfego dinâmico da camada de aplicativo (camada 7) para cargas de trabalho executadas em um cluster Kubernetes.

  • O Azure Front Door é uma rede de entrega de aplicativos que fornece balanceamento de carga global e aceleração de site para aplicativos Web. Fornece funcionalidades de Camada 7 para a sua aplicação, tais como alívio de carga SSL (Secure Sockets Layer), roteamento baseado em caminhos, failover rápido e cache, para melhorar o desempenho e a alta disponibilidade.

  • O Balanceador de Carga é um serviço de Camada 4 que lida com o tráfego de entrada e saída em todos os protocolos UDP (User Datagram Protocol) e TCP (Transmission Control Protocol). Ele foi projetado para alto desempenho e latência ultrabaixa. Ele foi criado para lidar com milhões de solicitações por segundo, garantindo que sua solução esteja altamente disponível. O Load Balancer tem redundância a nível de zona, o que garante alta disponibilidade entre zonas geográficas. Ele suporta uma topologia de implantação regional e uma topologia entre regiões.

  • O Gestor de Tráfego é um balanceador de carga de tráfego baseado no Sistema de Nomes de Domínio (DNS) que lhe permite distribuir o tráfego de forma otimizada para serviços em regiões globais do Azure, ao mesmo tempo que fornece alta disponibilidade e capacidade de resposta. Como o Gerenciador de Tráfego é um serviço de balanceamento de carga baseado em DNS, ele equilibra a carga somente no nível do domínio. Por esse motivo, ele não pode falhar tão rapidamente quanto o Azure Front Door. O cache de DNS e os sistemas que ignoram os valores de tempo de vida (TTL) do DNS geralmente causam esse atraso.

Observação

As tecnologias de clustering, como os Aplicativos de Contêiner do Azure ou o Serviço Kubernetes do Azure (AKS), contêm construções de balanceamento de carga. Essas estruturas operam principalmente dentro dos limites do seu próprio cluster. Eles roteiam o tráfego para instâncias de aplicativos disponíveis com base em testes de prontidão e integridade. Este artigo não aborda todas essas opções de balanceamento de carga.

Categorizações de serviços

Os serviços de balanceamento de carga do Azure podem ser categorizados em duas dimensões: global versus regional e HTTP(S) versus não-HTTP(S).

Global versus regional

  • Global: Esses serviços de balanceamento de carga distribuem o tráfego entre back-ends regionais, nuvens ou serviços locais híbridos. Eles fornecem um único plano de controle que roteia o tráfego do usuário para back-ends disponíveis globalmente. Esses serviços reagem a mudanças na confiabilidade ou no desempenho do serviço para maximizar a disponibilidade e o desempenho. Você pode pensar neles como sistemas que equilibram a carga entre carimbos de aplicativos, pontos de extremidade ou unidades de escala hospedadas em diferentes regiões ou geografias.

  • Regionais: Esses serviços de balanceamento de carga distribuem o tráfego dentro de redes virtuais entre máquinas virtuais (VMs) ou pontos de extremidade de serviço com redundância zonal e de zona dentro de uma região. Você pode pensar neles como sistemas que equilibram a carga entre VMs, contêineres ou clusters dentro de uma região em uma rede virtual.

HTTP(S) versus não-HTTP(S)

  • HTTP(S): Esses serviços de balanceamento de carga são balanceadores de carga de Camada 7 que aceitam apenas tráfego HTTP(S). Eles são projetados para aplicativos da Web ou outros pontos de extremidade HTTP(S). Os recursos incluem descarga de SSL, firewall de aplicações web, balanceamento de carga baseado em caminho e afinidade de sessão.

  • Não-HTTP(S): Esses serviços de balanceamento de carga incluem serviços TCP e UDP de camada 4 ou serviços de balanceamento de carga baseados em DNS.

A tabela a seguir resume os serviços de balanceamento de carga do Azure.

Serviço Global ou regional Tráfego recomendado
API Management Regional ou global Somente APIs HTTP(S)
Gateway de Aplicação Regionais HTTP(S), TCP, & TLS
Porta de entrada de aplicativos para contentores Regionais HTTP(S)
Azure Front Door A nível mundial HTTP(S)
Balanceador de Carga Regional ou global Non-HTTP(S)
Gestor de Tráfego A nível mundial Non-HTTP(S)

Observação

O Gerenciador de Tráfego e o Balanceador de Carga podem distribuir qualquer tipo de tráfego, incluindo HTTP(S). No entanto, esses serviços não fornecem recursos de camada 7. Ao contrário do Load Balancer, o Traffic Manager não lida diretamente com o tráfego. O Gerenciador de Tráfego usa o DNS para direcionar os clientes para os pontos de extremidade apropriados.

Escolha uma solução de balanceamento de carga para o seu cenário

Considere os seguintes fatores ao selecionar uma solução de balanceamento de carga:

  • Tipo de tráfego: Determine se é um aplicativo HTTP(S) da Web e se é voltado para o público ou um aplicativo privado.

  • Global versus regional: Esclareça se você precisa balancear a carga de VMs ou contêineres em uma única rede virtual, unidades de escala de balanceamento de carga ou implantações entre regiões, ou ambos.

  • Disponibilidade: Analise o contrato de nível de serviço (SLA).

  • Custo: Contabilize o custo do serviço em si, bem como o custo operacional de gerenciar uma solução construída sobre esse serviço. Para obter mais informações, consulte Preços do Azure.

  • Características e limites: Identifique os recursos suportados por cada serviço e os limites de serviço aplicáveis.

O fluxograma a seguir ajuda você a escolher uma solução de balanceamento de carga para seu aplicativo. O fluxograma orienta você através de um conjunto de critérios-chave de decisão para chegar a uma recomendação.

Sugestão

Pode usar o Azure Copilot para o ajudar a tomar esta decisão, de forma semelhante ao diagrama de fluxo descrito aqui. Para mais informações, consulte Trabalhar com o Azure Load Balancer usando o Microsoft Azure Copilot.

Cada aplicativo tem requisitos exclusivos não capturados em árvores de decisão simples. Trate este fluxograma ou recomendação do Copilot como um ponto de partida. Em seguida, realize uma avaliação mais detalhada.

Diagrama que mostra uma árvore de decisão para balanceamento de carga no Azure.

A imagem mostra um fluxograma ramificado onde cada caminho leva a uma solução de balanceamento de carga ou entrega de aplicativos. O caminho um começa na aplicação web (HTTP/HTTPS), vai para a aplicação voltada para a Internet através da seta "Não", e depois para o Balanceador de Carga. O caminho dois começa no aplicativo Web (HTTP/HTTPS), vai para o aplicativo voltado para a Internet através da seta Sim, depois para Global/implantado em várias regiões através da seta Não e termina no Application Gateway. O caminho três começa no aplicativo Web (HTTP/HTTPS), vai para o aplicativo voltado para a Internet via Sim, depois para Global/implantado em várias regiões via Sim, depois para Você precisa de aceleração de desempenho via Sim e termina na Porta da Frente do Azure. O caminho quatro começa na aplicação Web (HTTP/HTTPS), segue para aplicação voltada para a Internet via Sim, depois para Global/implantada em várias regiões via Sim, depois para Você precisa de aceleração de desempenho via Não, depois para Você precisa de alívio de SSL ou processamento na camada de aplicação por solicitação via Sim e termina em Azure Front Door e Application Gateway. O caminho cinco começa no aplicativo Web (HTTP/HTTPS), vai para o aplicativo voltado para a Internet via Sim, depois para Global/implantado em várias regiões via Sim, depois para Você precisa de aceleração de desempenho via Não, depois para Você precisa de descarregamento SSL ou processamento da camada de aplicativo por solicitação via Sim, e termina em Azure Front Door e Gerenciamento de API para hospedagem somente API. O caminho seis começa no aplicativo Web (HTTP/HTTPS), vai para o aplicativo voltado para a Internet via Sim, depois para Global/implantado em várias regiões via Sim, depois para Você precisa de aceleração de desempenho via Não, depois para Você precisa de descarregamento SSL ou processamento da camada de aplicativo por solicitação via Não, depois para Tipo de hospedagem e termina no Azure Front Door for PaaS, Azure Front Door and Load Balancer para VMs IaaS ou controlador de entrada do Azure Front Door e Application Gateway para AKS. Cada caminho é concluído com um ou mais serviços do Azure — Balanceador de Carga, Gateway de Aplicativo, Porta da Frente do Azure ou Gerenciamento de API — selecionados com base no escopo do aplicativo, alcance global, necessidades de desempenho, requisitos de SSL e ambiente de hospedagem.

Quando sua carga de trabalho incluir vários serviços que exigem balanceamento de carga, avalie cada serviço individualmente. Uma configuração eficaz geralmente usa mais de um tipo de solução de balanceamento de carga. Você pode incorporar essas soluções em locais diferentes na arquitetura da sua carga de trabalho para servir funções ou funções exclusivas.

Definições

  • Aplicativo Web (HTTP/HTTPS) refere-se a um aplicativo que requer pelo menos um dos seguintes recursos:

    • Toma uma decisão de roteamento para dados da Camada 7, como um caminho de URL
    • Suporta a inspeção do conteúdo da comunicação, por exemplo, de um corpo de solicitação HTTP
    • Lida com a funcionalidade Transport Layer Security (TLS)
  • Aplicativo não-HTTP(S) refere-se a um aplicativo que precisa de suporte à Camada 4 (protocolos TCP ou UDP) ou Transport Layer Security (protocolo TLS). O Azure Load Balancer e o Azure Application Gateway fornecem recursos para lidar com esse tráfego. No entanto, suas características e comportamentos diferem, conforme descrito neste artigo de comparação.

  • Aplicação voltada para a Internet refere-se a uma aplicação que é acessível publicamente a partir da Internet. Como prática recomendada, os proprietários de aplicativos aplicam políticas de acesso restritivas ou protegem o aplicativo configurando ofertas como firewall de aplicativos da Web e proteção distribuída contra negação de serviço.

  • Global ou implantado em várias regiões significa que o balanceador de carga deve ter um único plano de controle altamente disponível que roteie o tráfego para pontos de extremidade públicos em seu aplicativo distribuído globalmente. Essa configuração pode oferecer suporte a topologias ativo-ativo ou ativo-passivo entre regiões.

    Observação

    Você pode usar um serviço regional, como o Application Gateway, para balancear a carga entre back-ends que abrangem várias regiões e controlar o roteamento por meio de um único plano de controle. Ele funciona usando um link privado entre regiões, emparelhamento de rede virtual global ou até mesmo endereços IP públicos de serviços em outras regiões.

    Este cenário não é o ponto principal desta decisão.

    O uso de um recurso regional como um roteador para back-ends distribuídos globalmente introduz um único ponto de falha regional. Ele também incorre em latência extra porque o tráfego é forçado através de uma região antes de ir para outra e depois voltar novamente.

  • A plataforma como serviço (PaaS) fornece um ambiente de hospedagem gerenciado onde você pode implantar seu aplicativo sem precisar gerenciar VMs ou recursos de rede. Nesse caso, PaaS refere-se a serviços que fornecem balanceamento de carga integrado dentro de uma região. Para obter mais informações, consulte Escolher um serviço de computação para escalabilidade.

  • O AKS permite que você implante e gerencie aplicativos em contêineres. O AKS fornece Kubernetes sem servidor, uma experiência integrada de integração contínua e entrega contínua (CI/CD) e segurança e governança de nível empresarial. Essas cargas de trabalho do AKS são chamadas de back-ends do AKS. Para obter mais informações, consulte Projeto de arquitetura AKS.

  • A infraestrutura como serviço (IaaS) é uma opção de computação em que você provisiona as VMs de que precisa, juntamente com os componentes de rede e armazenamento associados. Os aplicativos IaaS exigem balanceamento de carga interno dentro de uma rede virtual usando o Load Balancer.

  • O processamento da camada de aplicativo refere-se ao roteamento especial dentro de uma rede virtual. Os exemplos incluem roteamento baseado em caminho entre VMs ou conjuntos de dimensionamento de máquinas virtuais. Para obter mais informações, consulte Implantar um gateway de aplicativo atrás da porta frontal do Azure.

  • Somente APIs refere-se à necessidade de balancear a carga de APIs HTTP(S) que não são aplicativos Web. Nesse caso, se sua carga de trabalho já usa o Gerenciamento de API para seus recursos de gateway, você pode considerar seu recurso opcional de balanceamento de carga para direcionar o tráfego entre back-ends de API que ainda não estão com balanceamento de carga por meio de outro mecanismo. Se sua carga de trabalho não usa o Gerenciamento de API, não o use apenas para balanceamento de carga.

  • A rede de distribuição de conteúdo (CDN) refere-se a um recurso que acelera os tempos de carregamento de páginas da Web por meio de sua rede de servidores geograficamente distribuída. A CDN permite a aceleração do desempenho ou entrada otimizada em um ponto de presença para uma integração acelerada do cliente na rede de destino. O Azure Front Door suporta redes de entrega de conteúdo e aceleração de tráfego Anycast. Você pode obter os benefícios de ambos os recursos com ou sem o Application Gateway na arquitetura.

  • O balanceador de carga de passagem é um balanceador de carga em que um cliente estabelece diretamente uma conexão com um servidor back-end selecionado pelo algoritmo de distribuição do balanceador de carga.

  • O balanceador de carga de terminação é aquele em que um cliente estabelece uma ligação com o balanceador de carga (proxy) e uma ligação separada é iniciada do balanceador de carga para o servidor de back-end.

Outras considerações

Cada serviço de balanceamento de carga também tem suporte de capacidade ou detalhes de implementação que você deve considerar. Aqui estão alguns exemplos que podem ser relevantes para o seu cenário de balanceamento de carga:

  • Suporte ao WebSockets
  • Suporte a eventos enviados pelo servidor
  • Suporte a HTTP/2 (recebendo e continuando para nós de back-end)
  • Suporte a sessões adesivas
  • Mecanismo de monitoramento da integridade do nó de back-end
  • Experiência do cliente ou atraso entre a deteção de nó defeituoso e a remoção da lógica de encaminhamento

Recursos de descarregamento para seu balanceador de carga

Algumas opções de balanceamento de carga no Azure permitem transferir funcionalidades dos nós de back-end para o balanceador de carga. Essas opções implementam o padrão de design de nuvem Gateway Offloading. Por exemplo, o Application Gateway pode descarregar o TLS, para que o certificado voltado para o público da sua carga de trabalho seja gerenciado em um local em vez de entre nós back-end. O Gerenciamento de API pode ser configurado para descarregar algumas preocupações básicas de autorização, como a validação de declarações em tokens de acesso JSON Web Token (JWT). Descarregar preocupações transversais pode ajudar a reduzir a complexidade da lógica em seus back-ends e melhorar seu desempenho.

Exemplos

A tabela a seguir lista vários artigos com base nos serviços de balanceamento de carga usados na solução.

Serviços Artigo Descrição
Balanceador de Carga Balancear carga de VMs por zonas de disponibilidade Balanceie a carga de VMs em zonas de disponibilidade para ajudar a proteger seus aplicativos e dados de uma falha ou perda improvável de um datacenter inteiro. Com a redundância de zona, uma ou mais zonas de disponibilidade podem falhar e o caminho de dados sobrevive enquanto uma zona na região permanecer íntegra.
Gestor de Tráfego Aplicativo Web multicamadas criado para alta disponibilidade e recuperação de desastres Implante aplicativos resilientes de várias camadas criados para alta disponibilidade e recuperação de desastres. Se a região primária ficar indisponível, o Gestor de Tráfego passará para a região secundária.
Gateway de aplicativos e gerenciamento de API Arquitetura da zona de receção da Gestão de API Use o Application Gateway para descarregar o firewall e o TLS do aplicativo Web. Use o Gerenciamento de API para balancear a carga entre back-ends de API.
Gerenciador de Tráfego e Gateway de Aplicativo Balanceamento de carga multirregião com o Gerenciador de Tráfego e o Application Gateway Saiba como atender cargas de trabalho da Web e implantar aplicativos resilientes de várias camadas em várias regiões do Azure para obter alta disponibilidade e uma infraestrutura robusta de recuperação de desastres.

Próximos passos