Load balancing sem caixa preta

O problema

Load balancer aparece em quase todo diagrama de system design.

O problema e que ele costuma entrar como caixinha automática:

“coloca um load balancer aqui”

Só que isso ainda não explica quase nada.

Fica faltando responder:

• o que esta sendo distribuido
• com qual critério
• o que acontece com sessao
• o que acontece quando uma instancia fica ruim

“Dividir igualmente” parece bom, mas muitas vezes nem e o problema certo.

Modelo mental

Load balancer e o componente que decide para qual instancia cada request ou conexão vai.

O jeito mais útil de pensar não e pelo nome do algoritmo primeiro.

E por quatro perguntas:

1. estou distribuindo request curto ou conexão longa?
2. existe estado preso na instancia?
3. como eu detecto que uma instancia ficou ruim?
4. qual critério de roteamento combina com esse tráfego?

Se você responde isso, a escolha do balanceador fica bem menos misteriosa.

Porque no fundo essa decisão mexe com:

• latência
• distribuição de carga
• estado de sessao
• tolerância a falha

Quebrando o problema

Primeiro: request curto ou conexão longa?

Essa diferença muda bastante o resto.

Se o tráfego e request curto, como uma API HTTP comum, distribuir por request costuma ser suficiente.

Se o tráfego e conexão longa, como WebSocket, a conversa muda.

Porque uma instancia pode segurar muito mais conexões abertas por muito tempo do que outra.

Entao a primeira pergunta senior geralmente e:

estou distribuindo requests ou conexões?

Depois: o estado esta preso na instancia?

Esse ponto costuma separar resposta boa de resposta decorada.

Se a sessao, o carrinho ou o contexto do usuário vivem na memória local da instancia, você tende a cair em afinidade.

E ai aparece sticky session.

Isso pode funcionar como alivio rápido.

Mas também costuma cobrar caro:

• hotspot
• failover pior
• escala horizontal menos previsivel

Em muitos casos, a resposta mais saudavel e:

• tirar o estado crítico da instancia
• deixar o balanceamento mais livre

Só agora faz sentido falar em algoritmo

Os nomes mais comuns sao estes:

• round robin
• least connections
• hash ou afinidade por alguma chave

Mas o valor deles não esta no nome. Esta no comportamento.

Round robin funciona bem quando os requests sao parecidos e curtos.

Least connections costuma ser melhor quando a conexão pode durar muito tempo.

Algum tipo de hash ajuda quando você realmente precisa afinidade por usuário, sessao ou recurso.

O ponto e:

algoritmo bom e o que combina com o formato do tráfego e com o estado da aplicação

Health check e parte do desenho

Sem health check, o balanceador continua mandando tráfego para quem já esta ruim.

Só que health check ruim também atrapalha:

• se for superficial, aprova instancia quebrada
• se for agressivo demais, remove instancia saudavel em pico

Isso importa porque o load balancer pode espalhar um problema em vez de conter o problema.

Layer 4 vs Layer 7 só importa quando muda a decisão

Essa parte costuma ser tratada como prova de rede, mas da para manter simples.

• L4 decide mais cedo, com menos contexto
• L7 decide com mais contexto de aplicação

Se você precisa rotear por host, path, header ou regra de aplicação, L7 entra mais forte.

Se o problema e mais direto e o foco e conexão simples e rápida, L4 pode bastar.

Não precisa transformar isso em aula longa em toda entrevista.

Exemplo simples

Imagine um sistema de chat com WebSocket.

Se você usar round robin puro, pode parecer correto no papel.

Mas algumas instancias podem ficar cheias de conexões longas e outras não.

Uma resposta melhor seria:

“Como tenho conexões longas, eu olharia primeiro para distribuição de conexões, não só de requests. Least connections provavelmente faz mais sentido do que round robin. Se eu ainda estiver prendendo estado na instancia, sticky session pode aparecer como alivio rápido, mas eu trataria isso como solução temporária. Também preciso de health check para parar de mandar tráfego para no ruim.”

Isso já mostra critério sem transformar o tema em módulo de rede.

Erros comuns

• Colocar load balancer no diagrama e parar por ai.
• Escolher algoritmo antes de explicar o tipo de tráfego.
• Usar sticky session sem falar do custo.
• Ignorar health check.
• Tratar conexão longa e request curto como se fossem iguais.

Como um senior pensa

Quem tem mais experiência costuma ir em uma ordem parecida com esta:

O que estou distribuindo? Existe estado preso? Como detecto no ruim? Qual critério combina com esse tráfego?

Maturidade aqui também e entender que load balancer não corrige aplicação mal desenhada.

Se a instancia segura estado demais, se uma maquina responde muito pior que outra ou se o health check mente, o balanceador só distribui um problema mal resolvido.

O que o entrevistador quer ver

Em entrevista, o entrevistador normalmente quer ver se você:

• entende o tipo de tráfego
• sabe diferenciar algoritmo por comportamento
• considera sessao e estado
• lembra do comportamento em falha

Load balancing não e uma caixa bonita no diagrama. E uma decisão sobre como repartir tráfego sem criar novo gargalo no caminho.