☕ Um Café no Bellacosa Mainframe
Load Balancer: a ciência de distribuir tráfego sem transformar o servidor em pedra
Imagine que você acordou em um mundo onde toda a infraestrutura tecnológica desapareceu.
Não existem nuvens públicas, clusters Kubernetes, servidores virtuais, balanceadores de carga, dashboards coloridos nem aquele analista misterioso que sempre responde:
“Aqui na minha máquina funciona.”
Restaram apenas algumas máquinas, cabos, café, raciocínio lógico e um programador COBOL iniciante tentando reconstruir a civilização digital.
Em cima de uma mesa improvisada, encontramos três servidores:
SERVIDOR-A
SERVIDOR-B
SERVIDOR-C
Do outro lado da rede, milhares de usuários tentam acessar uma aplicação bancária.
Se todos forem enviados diretamente ao SERVIDOR-A, ele rapidamente será esmagado pela carga. Enquanto isso, os servidores B e C permanecerão tranquilos, tomando café e olhando o desastre pela janela.
Precisamos de ciência.
Precisamos de engenharia.
Precisamos de um Load Balancer.
Como diria um certo cientista de cabelos estranhamente espetados:
“Isso é dez bilhões por cento necessário para reconstruir a civilização da alta disponibilidade!”
O Load Balancer, ou balanceador de carga, é o componente responsável por receber conexões e decidir para qual servidor cada solicitação será encaminhada.
Ele funciona como um recepcionista extremamente rápido colocado na entrada de um prédio com vários atendentes.
O cliente não precisa saber qual servidor processará sua solicitação. Ele conhece apenas um endereço:
https://sistema.bellacosa.com
Por trás desse endereço, entretanto, podem existir dezenas, centenas ou milhares de servidores.
USUÁRIOS
|
v
+-----------------+
| LOAD BALANCER |
+-----------------+
| | |
v v v
SRV-A SRV-B SRV-C
O balanceador observa o ambiente, conhece os servidores disponíveis e encaminha cada solicitação para o destino mais apropriado.
Parece simples.
Porém, assim como transformar pedra em eletricidade, o conceito se torna muito mais interessante quando examinamos cada etapa.
O primeiro experimento: distribuir o tráfego
Nosso pequeno laboratório possui três servidores.
Cada servidor consegue atender aproximadamente cem requisições por segundo.
Sem um balanceador, todos os usuários acessam o primeiro servidor:
SERVIDOR-A: 290 requisições por segundo
SERVIDOR-B: 5 requisições por segundo
SERVIDOR-C: 5 requisições por segundo
O resultado será previsível:
SERVIDOR-A: CPU 100%
SERVIDOR-B: CPU 4%
SERVIDOR-C: CPU 3%
O servidor A começará a responder lentamente, algumas requisições falharão e, dependendo da aplicação, o sistema poderá cair.
O problema não é falta de capacidade total. O conjunto possui capacidade para trezentas requisições por segundo.
O problema é que essa capacidade não está sendo utilizada de maneira equilibrada.
O Load Balancer entra no fluxo e distribui as solicitações:
REQUISIÇÕES TOTAIS: 300
SERVIDOR-A: 100
SERVIDOR-B: 100
SERVIDOR-C: 100
Essa é a função mais conhecida do balanceamento de carga: Traffic Distribution.
Entretanto, “distribuir” não significa necessariamente dividir tudo de forma perfeitamente igual. Existem vários algoritmos, cada um adequado a um tipo de situação.
Round Robin: a roda da ciência
O algoritmo mais simples é o Round Robin.
O Load Balancer cria uma lista de servidores e encaminha cada nova requisição para o próximo servidor disponível.
REQUISIÇÃO 01 -> SERVIDOR-A
REQUISIÇÃO 02 -> SERVIDOR-B
REQUISIÇÃO 03 -> SERVIDOR-C
REQUISIÇÃO 04 -> SERVIDOR-A
REQUISIÇÃO 05 -> SERVIDOR-B
REQUISIÇÃO 06 -> SERVIDOR-C
Quando chega ao final da lista, ele retorna ao começo.
É como distribuir tarefas entre três pessoas:
EVALUATE WS-PROXIMO-SERVIDOR
WHEN 1
MOVE 'SERVIDOR-A' TO WS-DESTINO
WHEN 2
MOVE 'SERVIDOR-B' TO WS-DESTINO
WHEN 3
MOVE 'SERVIDOR-C' TO WS-DESTINO
END-EVALUATE
Depois da terceira escolha, o contador volta para um.
O Round Robin é simples, rápido e funciona bem quando todos os servidores possuem capacidades semelhantes.
O problema aparece quando as máquinas são diferentes.
Suponha que o servidor A possua 64 processadores, o servidor B possua 16 e o servidor C apenas 8.
Distribuir exatamente um terço do tráfego para cada um seria como pedir que três trabalhadores carregassem o mesmo peso, mesmo que um deles tivesse força oito vezes maior.
Nesse cenário utilizamos o Weighted Round Robin, ou Round Robin ponderado.
SERVIDOR-A - PESO 8
SERVIDOR-B - PESO 2
SERVIDOR-C - PESO 1
O servidor A receberá proporcionalmente mais requisições.
Essa ponderação também pode ser usada durante migrações. Um servidor antigo pode receber peso 1, enquanto os novos recebem peso 5.
Assim, a aplicação é transferida gradualmente para a nova infraestrutura.
Easter egg número um: em alguma sala esquecida de um banco existe provavelmente uma planilha chamada BALANCEAMENTO_FINAL_V7_DEFINITIVO_AGORA_VAI.xlsx contendo pesos de servidores calculados anos atrás.
Least Connections: quem está menos ocupado?
Nem todas as requisições possuem a mesma duração.
Imagine duas operações:
Consulta de saldo: 30 milissegundos
Geração de relatório anual: 20 segundos
Se usarmos apenas Round Robin, um servidor poderá receber várias operações demoradas enquanto outro recebe apenas consultas rápidas.
Por isso existe o algoritmo Least Connections.
O Load Balancer observa quantas conexões ativas cada servidor possui.
SERVIDOR-A: 120 conexões
SERVIDOR-B: 42 conexões
SERVIDOR-C: 18 conexões
A próxima conexão será enviada ao servidor C.
É um algoritmo particularmente útil quando as sessões possuem tempos de processamento diferentes.
Também existe o Least Response Time, que considera não apenas a quantidade de conexões, mas o tempo de resposta de cada servidor.
SERVIDOR-A: 150 ms
SERVIDOR-B: 60 ms
SERVIDOR-C: 25 ms
O servidor C parece ser a escolha mais eficiente.
Mas cuidado: o menor tempo de resposta atual não significa necessariamente maior capacidade permanente. Um servidor pode estar rápido apenas porque acabou de ser reiniciado e ainda não recebeu carga significativa.
Por isso sistemas maduros combinam várias métricas.
SSL Termination: separando criptografia de lógica de negócio
Quando um usuário acessa uma página usando HTTPS, existe criptografia entre o navegador e o servidor.
Antes de transmitir os dados, cliente e servidor realizam uma negociação TLS.
De maneira simplificada, ocorre algo semelhante a isto:
CLIENTE: Quem é você?
SERVIDOR: Aqui está meu certificado.
CLIENTE: Certificado validado.
AMBOS: Vamos definir as chaves de criptografia.
CONEXÃO: Protegida.
Esse processo é essencial para a segurança, mas consome recursos computacionais.
Sem SSL Termination, cada servidor da aplicação precisa:
armazenar certificados;
executar negociações TLS;
criptografar respostas;
descriptografar requisições;
renovar e controlar certificados;
manter parâmetros de segurança consistentes.
CLIENTE -> HTTPS -> SERVIDOR-A
CLIENTE -> HTTPS -> SERVIDOR-B
CLIENTE -> HTTPS -> SERVIDOR-C
Com SSL Termination, o Load Balancer assume esse trabalho:
CLIENTE
|
HTTPS
|
v
LOAD BALANCER
|
HTTP OU HTTPS INTERNO
|
+------> SERVIDOR-A
+------> SERVIDOR-B
+------> SERVIDOR-C
O certificado fica centralizado no balanceador.
Isso reduz a carga dos servidores e simplifica a administração.
Mas atenção, jovem cientista do terminal 3270: terminar o TLS no Load Balancer não significa que o tráfego interno deva obrigatoriamente circular sem criptografia.
Em ambientes sensíveis, o balanceador pode descriptografar a conexão externa e criar uma nova conexão HTTPS com o backend.
Esse modelo é conhecido como:
TLS externo + TLS interno
Também pode ser chamado de SSL Bridging ou recriptografia.
Em sistemas bancários, hospitalares ou governamentais, deixar dados sensíveis trafegando em texto claro na rede interna pode ser uma decisão perigosa.
A velha frase “mas a rede é interna” já antecedeu muitos relatórios de incidente.
Session Persistence: o mistério do carrinho desaparecido
Imagine que uma aplicação armazena a sessão do usuário na memória local do servidor.
O cliente acessa o sistema e é encaminhado ao servidor A.
CLIENTE JOÃO -> SERVIDOR-A
João adiciona um notebook ao carrinho.
A informação fica na memória do servidor A:
SESSION-ID: XYZ123
CARRINHO: NOTEBOOK
Na próxima requisição, o Load Balancer envia João ao servidor B.
CLIENTE JOÃO -> SERVIDOR-B
O servidor B procura a sessão XYZ123, mas não encontra nada.
Resultado:
CARRINHO VAZIO
João acredita que o sistema perdeu sua compra. A equipe de desenvolvimento acredita que a infraestrutura está errada. A infraestrutura acredita que a aplicação foi mal projetada. E em algum lugar um gerente começa a organizar uma reunião de duas horas.
A solução imediata é a Session Persistence, também conhecida como:
Sticky Session;
Session Affinity;
Persistência de sessão;
Afinidade de servidor.
O Load Balancer garante que as requisições daquele usuário continuem chegando ao mesmo servidor.
JOÃO -> SERVIDOR-A
MARIA -> SERVIDOR-B
CARLOS -> SERVIDOR-C
Essa associação pode ser feita por:
Um exemplo com cookie:
Set-Cookie: LB-SERVER=A
Na próxima requisição, o navegador envia o cookie e o balanceador encaminha o usuário novamente ao servidor A.
Funciona, mas possui limitações.
Se o servidor A falhar, a sessão armazenada apenas em sua memória poderá ser perdida.
Além disso, um servidor pode receber muitos usuários ativos enquanto outro fica quase vazio.
Uma arquitetura mais resiliente mantém as sessões fora dos servidores da aplicação.
+----------------+
| REDIS / CACHE |
+----------------+
^ ^ ^
| | |
CLIENTE -> LB -> SRV-A SRV-B SRV-C
Nesse modelo, qualquer servidor pode recuperar a sessão do usuário.
A aplicação se torna mais próxima do conceito de stateless, ou sem estado local.
Dica importante: Sticky Session é útil, mas não deve ser usada para esconder uma arquitetura de sessão mal planejada.
High Availability: quando o servidor vira pedra
Agora chegamos a uma das funções mais importantes: alta disponibilidade.
Suponha que existam três servidores:
SERVIDOR-A: ATIVO
SERVIDOR-B: ATIVO
SERVIDOR-C: ATIVO
Durante a madrugada, o servidor B sofre uma falha.
Sem Load Balancer, alguns clientes continuam tentando acessá-lo e recebem erros.
Com Load Balancer, o servidor é retirado do pool:
SERVIDOR-A: ATIVO
SERVIDOR-B: INDISPONÍVEL
SERVIDOR-C: ATIVO
As novas requisições seguem apenas para A e C.
LOAD BALANCER
/ \
v v
SERVIDOR-A SERVIDOR-C
Quando B se recupera, ele pode ser reintegrado automaticamente.
A aplicação continua funcionando, embora com capacidade reduzida.
Isso é alta disponibilidade: não significa que nada jamais falhará.
Significa que a arquitetura foi construída esperando que componentes falhem.
Em engenharia de sistemas, a pergunta madura não é:
“Esse servidor pode falhar?”
A pergunta correta é:
“O que acontecerá quando ele falhar?”
O próprio Load Balancer também pode falhar
Aqui encontramos uma armadilha clássica.
Você instalou vários servidores para eliminar pontos únicos de falha, mas colocou apenas um Load Balancer.
USUÁRIOS
|
LOAD BALANCER ÚNICO
|
SERVIDORES
Se o Load Balancer cair, todos os servidores se tornam inacessíveis.
Parabéns: construímos uma rodovia com dez pistas e apenas uma cabine de pedágio.
Por isso, Load Balancers também costumam operar em alta disponibilidade.
ENDEREÇO VIRTUAL
|
+--------+--------+
| |
v v
LB-ATIVO LB-STANDBY
Em outras arquiteturas, os dois trabalham simultaneamente:
ACTIVE-ACTIVE
Um protocolo de redundância pode transferir o endereço IP virtual de um balanceador para outro.
O usuário continua acessando o mesmo endereço.
Easter egg número dois: a palavra “cluster” costuma fazer todos se sentirem seguros, até alguém perguntar quem monitora o cluster que monitora o cluster.
Health Monitoring: o médico dos servidores
Para retirar um servidor defeituoso do pool, o Load Balancer precisa descobrir que ele está doente.
Essa função é executada por Health Checks.
O teste mais simples verifica se a porta responde:
TCP 443 RESPONDE?
Se sim, o servidor é considerado disponível.
Porém, responder à porta não significa que a aplicação esteja funcionando corretamente.
Um servidor pode aceitar conexões, mas apresentar:
HTTP 500
Banco indisponível
Fila travada
Disco cheio
Pool de conexões esgotado
Aplicação congelada
Por isso health checks modernos acessam um endpoint específico:
GET /health
A aplicação pode responder:
{
"status": "UP",
"database": "UP",
"cache": "UP",
"queue": "UP"
}
Um teste mais profundo poderia executar uma consulta simples ao banco.
SELECT 1
FROM SYSIBM.SYSDUMMY1;
No universo Db2, a tabela SYSIBM.SYSDUMMY1 aparece novamente como aquele personagem secundário que sobrevive a todas as temporadas.
Contudo, health checks muito pesados também são perigosos.
Imagine cem Load Balancers consultando o banco a cada segundo. O mecanismo criado para verificar a saúde pode causar a doença.
Use testes leves, objetivos e frequências razoáveis.
Um modelo comum trabalha com limites:
3 FALHAS CONSECUTIVAS -> REMOVE O SERVIDOR
2 SUCESSOS CONSECUTIVOS -> REINTEGRA O SERVIDOR
Isso evita retirar uma máquina por causa de uma falha momentânea.
Também pode existir um período de aquecimento, chamado slow start.
Quando o servidor retorna, ele não recebe imediatamente toda a carga.
PRIMEIRO MINUTO: 10%
SEGUNDO MINUTO: 30%
TERCEIRO MINUTO: 60%
DEPOIS: 100%
Isso é importante porque aplicações Java, caches, pools de conexão e estruturas internas podem precisar de algum tempo para atingir desempenho normal.
Scalability: criando novos servidores conforme a demanda
Na segunda-feira, sua aplicação recebe mil usuários.
Na Black Friday, recebe cem mil.
Comprar infraestrutura permanente para o pico máximo pode ser caro. Manter apenas a capacidade normal pode derrubar o sistema durante eventos de grande tráfego.
A solução é a escalabilidade horizontal.
Escalar verticalmente significa aumentar uma máquina:
8 CPUs -> 32 CPUs
16 GB RAM -> 128 GB RAM
Escalar horizontalmente significa adicionar máquinas:
3 servidores -> 10 servidores -> 50 servidores
O Load Balancer permite adicionar novos servidores ao pool sem alterar o endereço usado pelos clientes.
ANTES:
LB -> A, B, C
DEPOIS:
LB -> A, B, C, D, E, F
Em uma nuvem, um serviço de autoscaling pode observar métricas:
CPU > 70%
Latência > 500 ms
Fila > 10.000 mensagens
Requisições > 5.000 por segundo
Quando o limite é atingido, novas instâncias são criadas.
O Load Balancer detecta as máquinas, executa health checks e começa a enviar tráfego.
Quando a demanda cai, algumas instâncias são removidas.
Esse processo parece mágico, mas é apenas automação, telemetria e políticas cuidadosamente configuradas.
Como toda magia tecnológica, também pode gerar uma fatura assustadora quando configurada incorretamente.
DDoS Mitigation: quando milhões batem à porta
Um ataque DDoS tenta sobrecarregar o sistema com grande volume de tráfego.
BOT 01 ----\
BOT 02 -----\
BOT 03 ------> LOAD BALANCER -> APLICAÇÃO
BOT 04 -----/
BOT 05 ----/
O objetivo pode ser:
O Load Balancer pode ajudar de diversas maneiras.
Rate Limiting
Limita a quantidade de requisições por origem.
MÁXIMO: 100 REQUISIÇÕES POR SEGUNDO POR IP
Quem ultrapassa pode receber:
HTTP 429 TOO MANY REQUESTS
Connection Limiting
Controla conexões simultâneas.
MÁXIMO: 20 CONEXÕES ATIVAS POR CLIENTE
Filtragem geográfica
Pode restringir tráfego de determinadas regiões quando isso fizer sentido para o negócio.
Bloqueio por assinatura
Padrões suspeitos podem ser identificados:
Mesmo IP
Milhares de URLs por segundo
User-Agent estranho
Ausência de cookies
Comportamento repetitivo
Integração com WAF
Um Web Application Firewall pode bloquear:
SQL Injection;
Cross-Site Scripting;
padrões maliciosos;
bots conhecidos;
requisições anômalas.
Entretanto, um Load Balancer sozinho não é uma defesa completa contra DDoS volumétrico.
Se o ataque saturar o link de internet antes de chegar ao balanceador, o equipamento local não terá como resolver o problema.
Por isso grandes ambientes utilizam redes distribuídas, serviços anti-DDoS, scrubbing centers, CDNs e capacidade global de absorção.
Em outras palavras: para deter uma avalanche, não basta colocar um guarda-chuva na porta.
Layer 4 e Layer 7: dois níveis de inteligência
Load Balancers podem trabalhar em diferentes camadas da rede.
Camada 4
Um balanceador Layer 4 trabalha principalmente com:
IP;
TCP;
UDP;
portas;
conexões.
Ele não precisa compreender profundamente o conteúdo HTTP.
IP DESTINO
PORTA 443
PROTOCOLO TCP
É rápido e adequado para grandes volumes ou protocolos que não utilizam HTTP.
Camada 7
Um balanceador Layer 7 entende a aplicação.
Ele pode examinar:
URL;
caminho;
método HTTP;
cookies;
cabeçalhos;
host;
token;
conteúdo da requisição.
Isso permite roteamento inteligente.
/api/clientes -> SERVIDORES DE API
/imagens -> SERVIDORES DE CONTEÚDO
/admin -> CLUSTER ADMINISTRATIVO
/relatorios -> SERVIDORES DE RELATÓRIO
Também podemos usar domínios:
api.bellacosa.com -> API
blog.bellacosa.com -> BLOG
auth.bellacosa.com -> AUTENTICAÇÃO
Essa função é chamada de Content-Based Routing.
No mundo COBOL, imagine que requisições de consulta sejam enviadas para uma região CICS e transações financeiras para outra.
A decisão não depende apenas da existência de um servidor, mas da natureza da operação.
Blue-Green Deployment: dois mundos paralelos
Suponha que a versão atual da aplicação seja a versão azul.
BLUE = VERSÃO 1
A nova versão é instalada em um ambiente separado:
GREEN = VERSÃO 2
Os usuários continuam usando Blue enquanto Green é testada.
USUÁRIOS -> LOAD BALANCER -> BLUE
GREEN AGUARDA
Quando tudo estiver validado, o Load Balancer muda o destino:
USUÁRIOS -> LOAD BALANCER -> GREEN
Se ocorrer um problema, podemos retornar ao Blue.
Esse é o conceito de Blue-Green Deployment.
A grande vantagem é reduzir o tempo de indisponibilidade.
Mas existe uma dificuldade importante: bancos de dados.
Se a versão Green alterar estruturas de tabelas de forma incompatível, voltar para Blue poderá não ser simples.
Por isso implantações maduras utilizam mudanças compatíveis e estratégias graduais.
Canary Release: soltando o canário na mina
O nome vem da antiga prática de levar canários para minas. Se o animal apresentasse sinais de problemas, os trabalhadores sabiam que havia gases perigosos.
Em software, uma pequena parte dos usuários recebe a nova versão.
95% -> VERSÃO ANTIGA
5% -> VERSÃO NOVA
O Load Balancer observa métricas:
Taxa de erro
Latência
Uso de CPU
Conversões
Falhas de negócio
Reclamações
Se a versão nova estiver saudável:
75% antiga / 25% nova
50% antiga / 50% nova
25% antiga / 75% nova
0% antiga / 100% nova
Se os erros aumentarem, o tráfego retorna à versão anterior.
Canary Release é uma forma extremamente poderosa de reduzir riscos.
Um pequeno grupo encontra o problema antes que toda a população seja afetada.
A/B Testing: ciência aplicada ao usuário
No A/B Testing, usuários diferentes recebem versões distintas.
GRUPO A -> BOTÃO AZUL
GRUPO B -> BOTÃO VERDE
Depois medimos resultados:
VERSÃO A: 4,2% de conversão
VERSÃO B: 5,7% de conversão
O Load Balancer pode direcionar usuários para cada versão e manter a consistência da experiência.
É importante que o mesmo usuário continue vendo a mesma variante. Caso contrário, ele pode ver o botão mudar de cor a cada clique e imaginar que o sistema foi possuído por um espírito do CPD.
Observabilidade: o Load Balancer como torre de controle
Por receber grande parte do tráfego, o Load Balancer é um excelente ponto de observação.
Ele pode registrar:
REQUISIÇÕES POR SEGUNDO
CONEXÕES ATIVAS
LATÊNCIA MÉDIA
PERCENTIL P95
PERCENTIL P99
ERROS HTTP 4XX
ERROS HTTP 5XX
BYTES TRANSFERIDOS
BACKEND ESCOLHIDO
TEMPO DE CONEXÃO
TEMPO DE RESPOSTA
A média, sozinha, pode enganar.
Imagine cem requisições:
95 requisições: 50 ms
5 requisições: 10 segundos
A média não mostra bem o sofrimento dos usuários mais afetados.
Por isso usamos percentis:
P50 = metade das requisições abaixo desse tempo
P95 = 95% abaixo desse tempo
P99 = 99% abaixo desse tempo
Se o P99 estiver alto, uma pequena parcela dos usuários está enfrentando grandes atrasos.
Esses dados podem alimentar ferramentas de observabilidade, alertas e painéis.
O Load Balancer deixa de ser apenas uma porta de entrada e se torna parte da inteligência operacional.
O paralelo com o IBM Mainframe
O conceito de balanceamento de carga não nasceu com Kubernetes nem com microsserviços.
No mundo IBM Z, distribuição, priorização e roteamento de trabalho existem há décadas.
Em ambientes CICS, podemos encontrar arquiteturas com:
Uma TOR pode receber conexões e direcionar transações para diferentes AORs.
TERMINAL
|
v
TOR
/ \
v v
AOR1 AOR2
O CICS Dynamic Transaction Routing pode selecionar a região adequada para executar uma transação.
O CPSM, CICSplex System Manager, ajuda a administrar e monitorar ambientes CICSplex.
No z/OS Communications Server, o Sysplex Distributor pode distribuir conexões TCP/IP entre sistemas participantes de um Parallel Sysplex.
E o WLM, Workload Manager, observa objetivos de serviço, prioridades e capacidade.
Transação crítica: prioridade alta
Relatório diário: prioridade média
Processamento não urgente: prioridade menor
O WLM não pensa apenas em utilização técnica. Ele trabalha com importância para o negócio e metas de serviço.
Isso é extraordinariamente moderno.
Muitas arquiteturas distribuídas ainda estão tentando alcançar níveis de governança e disponibilidade que o mainframe pratica há décadas.
Easter egg número três: quando alguém disser que “o mainframe não escala”, respire fundo, tome café e pergunte se a pessoa já ouviu falar em Parallel Sysplex.
Passo a passo para projetar um balanceamento de carga
Vamos montar um roteiro prático.
Passo 1: conheça o tráfego
Descubra:
Quantas requisições por segundo?
Qual o horário de pico?
Quanto dura cada requisição?
Existem conexões longas?
Há downloads grandes?
O tráfego é HTTP, TCP ou UDP?
Sem essas informações, escolher um balanceador é como construir uma ponte sem conhecer o tamanho do rio.
Passo 2: identifique o estado da aplicação
Pergunte:
A sessão fica na memória?
Existe Redis?
O usuário precisa voltar ao mesmo servidor?
A aplicação é stateless?
Isso definirá a necessidade de Sticky Session.
Passo 3: escolha Layer 4 ou Layer 7
Use Layer 4 quando precisar de desempenho e roteamento baseado em conexão.
Use Layer 7 quando precisar examinar URLs, headers, cookies e conteúdo HTTP.
Passo 4: desenhe os health checks
Defina:
Endpoint
Intervalo
Timeout
Número de falhas
Número de sucessos
Critérios de resposta
Um exemplo:
URL: /health
INTERVALO: 10 segundos
TIMEOUT: 3 segundos
FALHAS PARA REMOVER: 3
SUCESSOS PARA RETORNAR: 2
Passo 5: elimine pontos únicos de falha
Não basta duplicar os servidores de aplicação.
Verifique:
Load Balancer
Firewall
DNS
Banco
Cache
Mensageria
Link de rede
Fonte elétrica
Região geográfica
A alta disponibilidade é tão forte quanto o componente mais fraco do caminho.
Passo 6: proteja o tráfego
Configure:
TLS moderno
Certificados válidos
Rate limiting
WAF
Limites de conexão
Logs
Bloqueios de protocolos inseguros
Passo 7: monitore
Crie alertas para:
Backends indisponíveis
Erros 5xx
Latência alta
Conexões esgotadas
Certificado próximo do vencimento
Aumento anormal de tráfego
Desequilíbrio entre servidores
Certificados possuem uma curiosa habilidade de vencer durante feriados prolongados.
Passo 8: teste falhas de propósito
Desligue um servidor em ambiente controlado.
Observe:
Quanto tempo o Load Balancer leva para detectá-lo?
As requisições em andamento são perdidas?
O servidor retorna corretamente?
As sessões sobrevivem?
Os alertas funcionam?
Esse tipo de teste faz parte da engenharia de resiliência.
Não espere o incidente real para descobrir se o failover funciona.
Erros comuns que o programador COBOL iniciante deve conhecer
O primeiro erro é acreditar que Load Balancer resolve aplicação lenta.
Se todos os servidores executam uma consulta SQL ruim, distribuir a consulta entre dez máquinas apenas cria dez lugares onde ela continua ruim.
O segundo erro é ignorar o banco de dados.
Você pode adicionar cem servidores de aplicação, mas todos continuam acessando o mesmo banco.
100 SERVIDORES
|
v
1 BANCO SATURADO
O gargalo apenas mudou de lugar.
O terceiro erro é usar Sticky Session indefinidamente.
Ela pode funcionar no início, mas dificultar escalabilidade e recuperação.
O quarto erro é health check superficial.
Uma página estática respondendo 200 OK não garante que a transação de negócio funcione.
O quinto erro é registrar dados sensíveis nos logs do balanceador.
Headers, cookies, tokens e parâmetros podem conter informações confidenciais.
O sexto erro é esquecer o tempo de drenagem.
Ao remover um servidor, talvez seja necessário permitir que conexões existentes terminem antes de desligá-lo.
Isso é conhecido como connection draining.
NOVAS CONEXÕES: BLOQUEADAS
CONEXÕES EXISTENTES: TERMINAM NORMALMENTE
Sem draining, usuários podem perder operações no meio do processamento.
Conclusão: a ciência por trás da disponibilidade
O Load Balancer começa com uma ideia simples:
Distribuir requisições entre vários servidores.
Mas rapidamente se transforma em um dos componentes mais estratégicos da arquitetura.
Ele participa de:
Em sistemas críticos, ele não é apenas um distribuidor de pacotes. É a torre de controle que observa o fluxo, identifica falhas e escolhe o melhor destino para cada conexão.
Para o programador COBOL iniciante, entender esse componente é especialmente importante.
A transação escrita em COBOL pode estar perfeita, compilada, testada e executando corretamente no CICS. Porém, antes que ela seja chamada, a requisição precisa atravessar redes, certificados, firewalls, proxies, balanceadores, gateways e vários outros elementos.
Quando o usuário diz:
“O sistema está fora.”
O programa COBOL talvez nem tenha sido executado.
A falha pode estar no DNS, no TLS, no Load Balancer, no roteamento, no health check, na autenticação ou na conexão com o backend.
O verdadeiro profissional não olha apenas para uma linha de código. Ele reconstrói o caminho completo da requisição.
USUÁRIO
|
DNS
|
FIREWALL
|
LOAD BALANCER
|
API / SERVIDOR WEB
|
CICS / IMS / MQ
|
COBOL
|
DB2 / VSAM
Cada etapa é uma peça da máquina.
Cada métrica é uma pista.
Cada log é um fragmento de evidência.
E cada incidente é uma oportunidade de aplicar o método científico:
OBSERVAR
CRIAR HIPÓTESE
TESTAR
MEDIR
CORRIGIR
DOCUMENTAR
AUTOMATIZAR
Assim reconstruímos a civilização tecnológica, uma conexão TCP, uma transação CICS e uma xícara de café por vez.
No fim, o Load Balancer nos ensina uma regra que serve tanto para computadores quanto para equipes humanas:
Nenhum servidor deve carregar sozinho o peso de todo o sistema.
Dez bilhões por cento confirmado.
