Opções de balanceamento de carga

O termo balanceamento de carga refere-se à distribuição do processamento em vários recursos de computação. Você faz o balanceamento de carga para otimizar o uso de recursos, maximizar o desempenho, minimizar o tempo de resposta e evitar sobrecarregar qualquer recurso individual. 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 em 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 Gerenciador de Tráfego do Azure.

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

Serviços de balanceamento de carga do Azure

Os principais serviços de balanceamento de carga e serviços com capacidades de balanceamento de carga disponíveis no Azure são:

• O Gerenciamento de API é um serviço gerenciado que você pode usar para publicar, proteger, transformar, manter e monitorar APIs HTTP(S). Ele fornece um gateway para suas APIs e pode ser configurado para balancear o tráfego de carga entre 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 com base em prioridade.

  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 de gerenciamento de API mais ampla. O Gerenciamento de API está incluído neste artigo para fins de integridade, pois fornece recursos de balanceamento de carga para topologias de hospedagem de API específicas. No entanto, sua principal finalidade é a funcionalidade de gateway de API em vez de balanceamento de carga.

• O Gateway de Aplicativo é 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 da Camada 7, como balanceamento de carga, roteamento, descarregamento de TLS e firewall de aplicativo web. Como um balanceador de carga de encerramento, ele também oferece balanceamento de carga de Camada 4 para protocolos TCP e TLS. Use o Gateway de Aplicativo para fazer a transição do tráfego do espaço de rede pública para os servidores Web hospedados no espaço de rede privado em uma região.

• O Gateway de Aplicativo para Contêineres é um balanceamento de carga de camada de aplicativo (camada 7) e um produto de gerenciamento de tráfego dinâmico para cargas de trabalho em execução em um cluster do 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. Ele fornece recursos de Camada 7 para seu aplicativo, como descarregamento SSL (Secure Sockets Layer), roteamento baseado em caminho, failover rápido e cache para melhorar o desempenho e a alta disponibilidade.

• Load Balancer é um serviço de Camada 4 que lida com o tráfego de entrada e saída em todos os protocolos UDP (Protocolo de Datagrama de Usuário) e Protocolo de Controle de Transmissão (TCP). Ele foi projetado para alto desempenho e latência ultra baixa. Ele foi criado para lidar com milhões de solicitações por segundo, garantindo que a sua solução esteja altamente disponível. O Load Balancer possui redundância de zona, o que garante alta disponibilidade através de zonas de disponibilidade. Ele dá suporte a uma topologia de implantação regional e a uma topologia entre regiões.

• O Gerenciador de Tráfego é um balanceador de carga de tráfego baseado em DNS (Sistema de Nomes de Domínio) que permite distribuir o tráfego de maneira ideal para serviços em regiões globais do Azure, fornecendo alta disponibilidade e capacidade de resposta. Como o Gerenciador de Tráfego é um serviço de balanceamento de carga baseado em DNS, ele balanceia a carga apenas no nível do domínio. Por esse motivo, ele não consegue realizar o failover tão rapidamente quanto o Azure Front Door. O cache DNS e os sistemas que ignoram valores de TTL (vida útil) DNS geralmente causam esse atraso.

Categorizações de serviço

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 alterações na confiabilidade ou no desempenho do serviço para maximizar a disponibilidade e o desempenho. Você pode pensar neles como sistemas que fazem balanceamento de carga entre clusters de aplicativo, pontos de extremidade ou unidades de escala hospedadas em diferentes regiões geográficas.

• Regional: Esses serviços de balanceamento de carga distribuem o tráfego em redes virtuais entre VMs (máquinas virtuais) ou pontos de extremidade de serviço zonais e com redundância de zona dentro de uma região. Você pode considerá-los como sistemas que equilibram a carga entre VMs, contêineres ou clusters em 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 foram projetados para aplicativos Web ou outros pontos de extremidade HTTP(S). Os recursos incluem descarregamento de SSL, firewall do aplicativo 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 da 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.

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

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

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

• Global versus regional: Esclareça se você precisa balancear 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 ambas.

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

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

• Recursos e limites: Identifique os recursos compatíveis com 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ê por um conjunto de critérios principais de decisão para alcançar uma recomendação.

Cada aplicativo tem requisitos exclusivos não capturados em árvores de decisão simples. Trate esse fluxograma ou a recomendação copilot como um ponto de partida. Em seguida, execute 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 carga de trabalho para atender funções ou funções exclusivas.

Definições

• O 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 de Camada 7, como um caminho de URL
  • Dá suporte à inspeção da carga de comunicação, como um corpo de solicitação HTTP
  • Manipula a funcionalidade do TLS (Transport Layer Security)

• O aplicativo não HTTP(S) refere-se a um aplicativo que precisa de suporte à Camada 4 (protocolos TCP ou UDP) ou protocolo TLS (Transport Layer Security). Tanto o Azure Load Balancer quanto o Gateway de Aplicativo do Azure fornecem recursos para lidar com esse tráfego. No entanto, seus recursos e comportamentos diferem, conforme descrito neste artigo de comparação.

• O aplicativo voltado para a Internet refere-se a um aplicativo acessível publicamente pela Internet. Como prática recomendada, os proprietários de aplicativos aplicam políticas de acesso restritivo ou protegem o aplicativo configurando ofertas como firewall de aplicativo Web e proteção de negação de serviço distribuída.

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

  Observação

  Você pode usar um serviço regional, como o Gateway de Aplicativo, 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.

  Esse cenário não é o ponto principal dessa decisão.

  O uso de um recurso regional como roteador para back-ends distribuídos globalmente introduz um ponto único regional de falha. 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 PaaS (plataforma como serviço) fornece um ambiente de hospedagem gerenciada em que você pode implantar seu aplicativo sem a necessidade de gerenciar VMs ou recursos de rede. Nesse caso, PaaS refere-se aos 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 implantar e gerenciar aplicativos em contêineres. O AKS fornece o Kubernetes sem servidor, uma experiência integrada de CI/CD (integração contínua e entrega contínua) e segurança e governança de nível empresarial. Essas cargas de trabalho do AKS são conhecidas como back-ends do AKS. Para obter mais informações, consulte o design da arquitetura do AKS.

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

• O processamento de camada de aplicativo refere-se ao roteamento especial em uma rede virtual. 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 por trás do Azure Front Door.

• Somente APIs referem-se à necessidade de balancear 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 a carga de trabalho não usar o Gerenciamento de API, não utilize o Gerenciamento de API apenas para balanceamento de carga.

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

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

• Terminando o balanceador de carga é onde um cliente estabelece uma conexão com o balanceador de carga (proxy) e uma conexã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 seu cenário de balanceamento de carga:

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

Recursos de descarregamento para o balanceador de carga

Algumas opções de balanceamento de carga no Azure permitem descarregar recursos dos nós de back-end para o balanceador de carga. Essas opções implementam o padrão de design de nuvem de Descarregamento de Gateway . Por exemplo, o Gateway de Aplicativo pode descarregar o TLS, de modo que o certificado voltado para o público da carga de trabalho seja gerenciado em um local, em vez de em nós de back-end. O Gerenciamento de API pode ser configurado para aliviar algumas preocupações básicas de autorização, como validar declarações em tokens de acesso JWT. Descarregar preocupações entre cortes 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.

Próximas etapas

• Criar um balanceador de carga público para balancear carga de VMs
• Direcionar o tráfego da Web com o Gateway de Aplicativo
• Configurar o Gerenciador de Tráfego para balanceamento de carga global baseado em DNS
• Configurar o Azure Front Door para um aplicativo Web global altamente disponível