Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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 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 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 |
| 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
Você pode usar o Microsoft Copilot no Azure para ajudar a guiá-lo nessa decisão, semelhante ao fluxograma descrito aqui. Para obter mais informações, consulte Trabalhar com o Azure Load Balancer usando o Microsoft Copilot no Azure.
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.
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. 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 aceleração de desempenho refere-se a recursos que aceleram o acesso à Web. A aceleração de desempenho pode ser alcançada usando redes de entrega de conteúdo ou entrada otimizada no ponto de presença para 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.
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. |