Balanceamento de carga (L4 × L7, sticky); escalabilidade vertical × horizontal

A ideia que organiza o assunto

Quando a carga cresce além do que um servidor aguenta, existem exatamente dois caminhos, e o tópico inteiro gira em torno deles.

Aumentar a máquina. Mais CPU, mais memória, disco mais rápido, tudo no mesmo equipamento. É a escalabilidade vertical, o escalar para cima. Simples, porque nada na aplicação muda — e limitada, porque existe um teto físico, o preço cresce mais rápido que a capacidade e a máquina continua sendo uma, ou seja, um ponto único de falha.

Acrescentar máquinas. Mais instâncias equivalentes atendendo em conjunto. É a escalabilidade horizontal, o escalar para fora. Não tem teto prático, e de quebra traz disponibilidade: com várias instâncias, a queda de uma não derruba o serviço.

A palavra que decide é o verbo: aumentar, ampliar, tornar maior um componente é vertical; adicionar, incluir, acrescentar servidores ou nós é horizontal. Nada mais é preciso para resolver a maioria dos itens do tópico, e inverter esses dois é a armadilha número um aqui.

O segundo eixo vem em seguida, como consequência. Acrescentar máquinas só adianta se alguém repartir o trabalho entre elas: esse alguém é o balanceador de carga. Ele é o mecanismo que torna a escalabilidade horizontal efetiva, e por isso os dois assuntos vivem juntos — mas não são sinônimos. Escalabilidade horizontal é o objetivo; balanceamento é o meio.

E, quando o item falar de balanceador, a pergunta que o decide é sempre a mesma: que informação ele lê para escolher o destino? Se lê endereço IP e número de porta, está na camada de transporte e é um balanceador de camada 4. Se precisa abrir a requisição e olhar URL, cabeçalho, cookie ou nome de host, está na camada de aplicação e é de camada 7. Toda a diferença entre os dois cabe nessa pergunta.

Por fim, distinga com rigor três verbos que a banca embaralha: distribuir requisições é balanceamento; repartir dados entre nós é particionamento ou fragmentação; copiar dados entre nós é replicação. Cada um resolve um problema diferente.

Por que se usa (e o que custa)

O ganho do balanceamento é duplo — mais capacidade de atendimento e menos sensibilidade à queda de um nó —, mas ele cobra em três frentes.

Estado. Distribuir requisições entre instâncias só é trivial se a aplicação não guardar nada entre uma chamada e outra. Havendo sessão, é preciso ou externalizá-la (banco, cache distribuído), ou replicá-la entre os nós, ou prender o cliente ao servidor que o atendeu primeiro — a afinidade de sessão, o chamado sticky session. Prender é o mais simples e o pior: desequilibra a carga, atrapalha a retirada de um nó para manutenção e devolve o problema na falha do nó, quando a sessão presa se perde.

O próprio balanceador. Ele concentra todo o tráfego e, se for único, é o ponto único de falha que se pretendia eliminar. Daí os balanceadores viverem em par, em espera ativa (ativo-passivo) ou em ativo-ativo com endereço virtual compartilhado.

Inteligência custa processamento. Um balanceador de camada 4 só examina cabeçalhos de IP e de transporte, encaminha e é rápido. Um de camada 7 precisa terminar a conexão, ler a requisição inteira e, no caso do HTTPS, decifrar o tráfego para poder inspecioná-lo — o que custa CPU e latência, e paga em roteamento por conteúdo, compressão, cache e regras finas.

Como funciona

Os eixos da escalabilidade. A vertical amplia o recurso de um nó existente; a horizontal soma nós ao conjunto. Bancos distribuídos e sistemas de nuvem elástica assumem a horizontal como premissa, e é por isso que os modelos NoSQL — a começar pelos de chave-valor — são desenhados para particionar: a chave é o critério natural de fragmentação, e a facilidade de particionar é justamente o que sustenta o crescimento por adição de nós. Ligada à horizontal está a elasticidade: acrescentar e retirar instâncias conforme a demanda, automaticamente. Em um cluster escalável, o nó novo precisa ser incorporado ao agendamento sem reconfiguração manual — se for preciso intervir a cada inclusão, o conjunto não é escalável no sentido que a prova cobra.

O balanceador em camada 4. Decide com base em endereço IP de origem e destino e em número de porta, sem abrir o conteúdo da aplicação. É o comutador de camada 4, que trabalha por conexão: escolhido o servidor, toda a conexão vai para ele. Rápido, indiferente ao protocolo de aplicação e incapaz de decidir por conteúdo.

O balanceador em camada 7. Termina a conexão com o cliente, lê a requisição e decide por URL, caminho, método, cabeçalho, cookie ou nome de host — encaminhando /api para um conjunto de servidores e /imagens para outro, por exemplo. É onde vivem a terminação TLS, a reescrita de cabeçalhos, a compressão, o cache e a afinidade por cookie. Proxies reversos como NGINX, HAProxy e Apache atuam nesse nível, e um mesmo produto acumula os papéis de servidor web, proxy reverso e balanceador.

Os algoritmos. O rodízio (round-robin) percorre os servidores em sequência e é o padrão da maioria das implementações, inclusive do bloco upstream do NGINX. O rodízio ponderado dá a cada servidor fatia proporcional à sua capacidade. O menor número de conexões (least connections) manda a nova requisição ao nó com menos conexões ativas, e serve a sessões de duração desigual. O menor tempo de resposta usa a latência observada. O hash de IP de origem (ip_hash, no NGINX) sempre leva o mesmo cliente ao mesmo servidor, sendo a forma mais simples de afinidade. Nenhum deles é universal: o padrão vale enquanto nenhuma diretiva o substitui.

A afinidade de sessão (sticky). Pode ser obtida por hash do IP de origem — o que falha com clientes atrás do mesmo NAT — ou por cookie inserido pelo balanceador, que exige camada 7 e é mais preciso. Em qualquer das formas, a afinidade quebra a distribuição uniforme e não substitui a replicação de sessão.

Verificação de saúde. O balanceador consulta periodicamente cada servidor (conexão TCP, requisição HTTP a uma rota de saúde) e retira do rodízio o que falha, devolvendo-o quando volta a responder. Sem isso, ele continuaria enviando requisições a um servidor morto — e é a verificação de saúde que faz do balanceamento também um instrumento de disponibilidade.

Os três tipos de cluster. O de alta disponibilidade existe para manter o serviço no ar por longos períodos; o de balanceamento de carga existe para repartir requisições e atender mais; o de alto desempenho existe para dividir um cálculo entre os nós. Um cluster, em qualquer dos três casos, é formado por nós dedicados e acoplados que se apresentam como sistema único — o que o separa da computação em grade, que aproveita recursos ociosos de máquinas dispersas e heterogêneas. No Windows, os dois primeiros tipos correspondem a produtos distintos: NLB para balanceamento de cargas sem estado e Failover Clustering para alta disponibilidade de cargas com estado.

O que decide os itens

Horizontal × vertical — o par que decide mais itens do tópico:

	horizontal (scale out)	vertical (scale up)
o que se faz	adicionar nós / instâncias	aumentar CPU, RAM, disco do nó
limite	prático, quase sem teto	físico e financeiro
disponibilidade	melhora: vários nós equivalentes	não melhora: a máquina continua única
exige da aplicação	tratamento de estado e sessão	nada
típico de	nuvem, NoSQL, bancos distribuídos	banco relacional monolítico, sistema legado

Camada 4 × camada 7:

	camada 4	camada 7
lê	IP e porta	URL, cabeçalho, cookie, host
unidade	conexão	requisição
custo	baixo, muito rápido	alto: termina conexão, decifra TLS
permite	encaminhamento simples	roteamento por conteúdo, cache, compressão, afinidade por cookie
nome que a banca usa	comutador de camada 4	proxy reverso, ADC

Distribuir × repartir × copiar — balanceamento distribui requisições entre servidores; particionamento (sharding) reparte dados distintos entre nós; replicação copia os mesmos dados para vários nós. A banca aplica o nome de um ao objeto do outro — em especial, chama de balanceamento a distribuição de dados.

Balanceamento × failover — balanceamento reparte carga entre nós que estão de pé; failover cobre a queda de um nó. Item que peça ao balanceador o papel de recuperar falha troca os dois.

Os três tipos de cluster:

tipo	finalidade
alta disponibilidade	manter o serviço no ar, com o mínimo de interrupção
balanceamento de carga	repartir requisições, atender mais, com desempenho
alto desempenho	dividir um cálculo entre os nós

Cluster × grade — cluster é dedicado, acoplado e homogêneo, com imagem única de sistema; grade é disperso, heterogêneo e oportunista, aproveitando recursos ociosos. Aproveitamento de ociosidade descrito como característica de cluster é troca de termo.

NLB × Failover Clustering — NLB balanceia aplicações sem estado (web); Failover Clustering dá disponibilidade a aplicações com estado (banco, arquivos, Exchange).

Algoritmos:

algoritmo	critério
round-robin	sequência circular — é o padrão (inclusive no NGINX)
round-robin ponderado	peso por capacidade do servidor
least connections	menor número de conexões ativas — exige least_conn
menor tempo de resposta	latência observada
ip_hash	hash do IP de origem — afinidade simples

NGINX — upstream declara o grupo de servidores e proxy_pass aponta para ele; esse par já basta para haver balanceamento. Sem diretiva de método, vale o round-robin.

Afinidade de sessão — por IP de origem (simples, falha atrás de NAT) ou por cookie (exige camada 7). Não substitui replicação de sessão e prejudica a uniformidade da distribuição.

Números que caem

camada 4	camada de transporte — decide por IP e porta
camada 7	camada de aplicação — decide por URL, cabeçalho, cookie
método padrão do upstream (NGINX)	round-robin
NLB (Windows)	até 32 servidores por cluster
portas típicas do tráfego balanceado	80 (HTTP) e 443 (HTTPS)
capacidade útil do escalonamento vertical	limitada ao teto de uma máquina

Como a CEBRASPE derruba você aqui

Medido sobre os 22 itens do assunto: 8 são Errados, e a concentração é extrema — 7 dos 8 são troca de termo, 88%. Lido o texto dos itens, o oitavo também é: todos os 8 itens errados dão a uma técnica a definição ou a finalidade da técnica vizinha. Nenhum erra por número, nenhum erra por absoluto, nenhum inventa uma causa. O assunto inteiro se defende com uma única pergunta — o nome que está escrito combina com a definição que está colada nele? — e as duas metades quase sempre são verdadeiras separadas.

Antes disso, o recorte. O título promete L4 × L7 e sticky, e o corpus não cobra nem um nem outro: afinidade de sessão aparece em zero dos 22 itens, e a distinção entre camadas aparece em um — “comutador da camada 4”, e é Certo. O par que de fato decide é outro: horizontal × vertical, em 5 itens, 3 deles errados, mais os tipos de cluster. E 3 dos 22 itens não são de balanceamento — paginação em sombra, striping de disco e escalabilidade de banco chave-valor entraram por dividirem enunciado com um item do assunto (“a respeito de balanceamento de carga e conceitos de falhas e recuperação”). Estude os eixos e os vizinhos; o bloco de L4, L7 e sticky é fundamento, não é onde o item cai.

Os eixos de escalabilidade trocados — 3 dos 8, o bloco mais pesado. O item nomeia um eixo e cola nele a definição do outro. “A escalabilidade em nuvem computacional, em sua dimensão horizontal, significa tornar um componente maior ou mais rápido”: isso é vertical. “Bancos de dados distribuídos trabalham com escalabilidade horizontal, na qual ocorre a expansão da capacidade de armazenamento de um nó específico”: de novo a definição do vertical sob o nome do horizontal. E bancos chave-valor descritos como proporcionando “escalabilidade vertical de forma mais fácil”, quando a família NoSQL inteira existe para crescer por adição de nós. Defesa: leia o verbo antes do adjetivo. Aumentar, ampliar, tornar maior um componente é vertical; adicionar, incluir, acrescentar nós é horizontal. Confira sempre as duas metades — só uma costuma estar adulterada.

A finalidade de um vizinho dada a outro — 3 dos 8. “Balanceamento de carga é um tipo de cluster cuja função é manter o sistema em plena condição de funcionamento por longo período de tempo”: essa é a função do cluster de alta disponibilidade; o de balanceamento reparte requisições para atender mais. O cluster básico que teria por característica “permitir o aproveitamento de recursos computacionais ociosos nas máquinas”: isso é computação em grade — cluster é dedicado, homogêneo e acoplado. E o balanceamento como “método ideal de distribuição da quantidade de dados nas tabelas de um banco de dados”: distribuir dado é particionamento. Defesa: os três verbos, na ordem — requisição repartida é balanceamento, dado distinto repartido é particionamento, dado igual copiado é replicação; e cada tipo de cluster responde a uma pergunta só: ficar no ar, atender mais, calcular mais rápido.

O nome da técnica de recuperação trocado — 1 dos 8, e é o item fora do assunto que mais aparece junto com ele. “Paginação em sombra, que consiste em fazer uma cópia das operações realizadas no banco de dados em outro esquema igual ao utilizado no banco corrente”: copiar operações é registro em log; a paginação em sombra mantém a tabela de páginas sombra intacta e grava as atualizações em páginas novas. Defesa: recuperação em banco tem duas famílias, registro de operações e cópia de páginas — o verbo denuncia qual é.

O método que não está configurado — 1 dos 8, e é o único item de configuração. Dado um bloco upstream sem diretiva de método, o item afirma que o método “será least-connected”. A descrição do least-connected que vem em seguida está correta; falso é dizer que é ele que vigora ali, porque sem least_conn o NGINX usa rodízio. Defesa: procure no código a diretiva que ativaria o comportamento afirmado. Não estando escrita, vale o padrão — e o padrão do upstream é round-robin.

E a negação da propriedade que define o modelo — 1 dos 8, que é o mesmo item dos eixos trocados, contado aqui pela segunda falha que ele carrega. Bancos chave-valor apresentados como “não serem particionáveis”, quando a chave é o critério natural de fragmentação e a razão de a família existir. Defesa: quando o item negar ao produto justamente a propriedade que justifica a sua adoção, desconfie.

O item descritivo sem absoluto tende a ser Certo, e aqui isso é forte. Nenhum dos 14 itens Certos do assunto restringe por conta própria: eles descrevem a prática consagrada — o NGINX que “pode ser utilizado para balanceamento de carga”, o balanceador que distribui “de maneira uniforme ou com pesos diferenciados”, o cluster escalável que incorpora o nó novo ao agendamento, a tríade “balanceamento distribui, fail-over assegura a continuidade, replicação garante que os dados estejam duplicados”. Defesa: antes de caçar pegadinha, procure um absoluto, um número ou um dono de ação trocado. Neste assunto, praticamente só o terceiro aparece — e quase sempre como definição vizinha colada no nome errado.

Erros clássicos

Trocar horizontal por vertical. Adicionar máquinas é horizontal; engordar a máquina é vertical. É o erro mais barato e o mais cobrado do tópico.

Achar que escalabilidade vertical melhora a disponibilidade. Não melhora: a máquina ampliada continua sendo uma só, e continua sendo ponto único de falha. Disponibilidade é subproduto do eixo horizontal.

Tratar balanceamento e escalabilidade horizontal como sinônimos. Um é o objetivo, o outro é o mecanismo que o viabiliza.

Confundir o que o balanceador distribui. Ele distribui requisições ou conexões, nunca linhas, tabelas ou arquivos.

Esperar que o balanceador de camada 4 decida por URL. Para ler URL, cookie ou cabeçalho é preciso subir à camada 7 — e, em HTTPS, decifrar o tráfego.

Supor que sticky session resolve o problema de estado. Ela só adia: desequilibra a carga, dificulta a manutenção e perde a sessão quando o nó escolhido cai. Sessão compartilhada ou externalizada é a solução real.

Esquecer que o balanceador precisa de redundância. Balanceador único concentra o tráfego e vira o ponto único de falha que se queria eliminar.

Assumir um algoritmo diferente do padrão sem diretiva que o ative. No NGINX, sem least_conn ou ip_hash declarados, o método é o rodízio.

Confundir cluster com grade. Cluster é um conjunto dedicado e homogêneo com imagem única de sistema; grade aproveita a ociosidade de máquinas dispersas.