Gargalo no Load Balancer? Round Robin vs. Least Connections

Para qualquer arquiteto de infraestrutura, o cenário é clássico: você projeta um ambiente de alta disponibilidade (HA) impecável. Você tem múltiplos servidores de aplicação (Web App 1, 2, 3) e coloca o Load Balancer da Macromind na frente para distribuir o tráfego.

No papel, está perfeito. Mas no primeiro pico de tráfego, o sistema engasga.

Os usuários reclamam de lentidão, as conexões começam a cair e, ao checar o monitoramento, você vê o pior cenário possível: O Servidor 1 está com 100% de CPU, "fritando", enquanto os Servidores 2 e 3 estão praticamente ociosos.

O que deu errado? Seu Load Balancer está funcionando, mas ele está sendo "cego". O culpado é a configuração mais comum (e muitas vezes perigosa) do mercado: o algoritmo Round Robin.

Neste artigo, vamos dissecar tecnicamente por que o algoritmo padrão pode ser seu inimigo e como uma simples mudança de configuração para Least Connections salva a sua performance.

O que é um Load Balancer?

Antes de falarmos de algoritmos, um rápido alinhamento. O Load Balancer (Balanceador de Carga) é um componente de rede (hardware ou software) que atua como um "gerente de tráfego".

Ele recebe todas as requisições (ex: acessos ao seu site ou API) e as distribui de forma inteligente entre um pool (conjunto) de servidores de backend. O objetivo é duplo:

1. Alta Disponibilidade (HA): Se um servidor falhar, o Load Balancer para de enviar tráfego para ele, e a aplicação continua no ar.

2. Escalabilidade Horizontal: Permite que você adicione mais servidores ao pool à medida que o tráfego aumenta, sem que o usuário perceba.

O "como" ele distribui esse tráfego é definido pelo algoritmo de balanceamento. E é aí que mora o perigo.

O "Cego" - Round Robin (O Padrão)

O Round Robin é o algoritmo mais simples e, por isso, muitas vezes o "default" em várias plataformas.

• Como funciona: Ele distribui as requisições em uma fila circular simples.

  • Requisição 1 -> Vai para o Servidor 1

  • Requisição 2 -> Vai para o Servidor 2

  • Requisição 3 -> Vai para o Servidor 3

  • Requisição 4 -> Volta para o Servidor 1

  • ...e assim por diante.

• A Vantagem: É extremamente leve e rápido (para o Load Balancer), pois não consome CPU ou memória para tomar decisões.

• O Problema (A "Cegueira"): O Round Robin é stateless (não guarda estado). Ele não tem a menor ideia de quantas conexões cada servidor está gerenciando ou quão "pesada" é cada requisição.

• Cenário do Desastre (O que mostramos no Reels): Imagine que a "Requisição 1" (enviada ao S1) é um upload de um relatório pesado que demora 40 segundos. A "Requisição 2" (enviada ao S2) é um simples ping (1ms). O Round Robin não sabe disso. Quando a "Requisição 4" chegar, ele a enviará obedientemente para o S1 (que ainda está "fritando" com o upload), enquanto o S2 e S3 estão totalmente livres.

• Resultado: Você criou um gargalo artificial. Você tem 3 servidores, mas sua performance é limitada ao S1, que está sobrecarregado.

O "Inteligente" - Least Connections

Aqui é onde a arquitetura de rede brilha. O algoritmo "Least Connections" (Mínimas Conexões) é stateful (guarda estado).

• Como funciona: O Load Balancer mantém uma tabela (um "placar") em tempo real de quantas conexões ativas cada servidor do pool está gerenciando.

• A Decisão: Antes de enviar uma nova requisição, o Load Balancer faz uma pergunta simples: "Qual dos meus servidores (S1, S2, S3) tem o menor número de conexões ativas neste exato momento?"

• Cenário de Sucesso: No nosso exemplo anterior, o S1 estaria com "1" conexão (a pesada). S2 e S3 estariam com "0". O Load Balancer (Sendo inteligente) enviaria as Requisições 2, 3, 4, 5... para S2 e S3, desviando do S1 até que ele terminasse sua tarefa pesada.

• Onde é ideal? Este é o algoritmo recomendado para 90% das aplicações modernas, especialmente aquelas onde o tempo de sessão ou o "peso" das requisições varia muito (APIs, ERPs, sistemas de login, etc.).

E o "Sticky" (IP Hash)?

Para mostrar ainda mais profundidade, existe um terceiro cenário: e se sua aplicação for legada e exigir que o usuário "grude" no mesmo servidor? (Ex: um carrinho de compras antigo que só existe na memória do S1).

Nesse caso, nem Round Robin nem Least Connections funcionam (pois eles podem alternar o usuário entre servidores).

• A Solução: Usa-se o IP Hash. O Load Balancer "trava" um usuário (baseado no IP dele) para sempre cair no mesmo servidor. Isso resolve o problema da sessão, mas... pode criar gargalos se muitos usuários (ex: de uma mesma empresa) caírem todos no S1.

Não Basta Ter, é Preciso Configurar

O Load Balancer é uma das peças mais críticas da infraestrutura cloud, mas ele não é "plug-and-play". A configuração padrão (Round Robin) é raramente a ideal para aplicações de alta performance.

Na Macromind, não entregamos apenas o produto Load Balancer. Nós entregamos a arquitetura. Nossa equipe de consultoria analisa o tipo da sua aplicação (E-commerce? ERP? API?) para definir o algoritmo de balanceamento (Least Connections, IP Hash, etc.) que garante a verdadeira alta disponibilidade e performance.

Sua infraestrutura está configurada para performance máxima ou está rodando no modo "padrão"? Se você vê servidores ociosos enquanto outros estão sobrecarregados, sua arquitetura de rede precisa de uma revisão.

Fale com um arquiteto de cloud da Macromind e otimize seu balanceamento de carga.