Projetar um load balancer

01 · CONTEXTO E REQUISITOS

O que um balanceador de carga precisa fazer

Um balanceador de carga aceita o tráfego que chega dos clientes e o encaminha para alvos registrados, como instâncias de servidor, em uma ou mais zonas de disponibilidade. Ele também monitora a saúde dos alvos: ao detectar um alvo não saudável, deixa de rotear tráfego para ele e só volta a fazê-lo quando detecta que o alvo está saudável de novo.

O balanceador recebe conexões por meio de listeners. Um listener é um processo que verifica pedidos de conexão, configurado com protocolo e porta para as conexões que vêm dos clientes.

Para uma entrevista, os requisitos funcionais se resumem a distribuir pedidos entre vários servidores, parar de enviar tráfego a servidores com problema e permitir adicionar ou remover servidores. Os não funcionais que mandam no desenho são a alta disponibilidade, inclusive do próprio balanceador, a distribuição uniforme da carga e pouca latência adicionada.

1. Os clientes enviam pedidos ao balanceador, que os recebe por meio de um listener.

2. O nó do balanceador seleciona um alvo registrado saudável e encaminha o pedido a ele.

3. O balanceador também envia periodicamente pedidos de teste aos alvos registrados; são as verificações de saúde.

4. Quando um alvo falha nas verificações além do limite configurado, o balanceador o tira de serviço e deixa de rotear tráfego para ele.

5. Depois de sucessos consecutivos acima do limite configurado, o balanceador devolve o alvo ao serviço.

02 · ESCOLHER O SERVIDOR

Algoritmos de distribuição

Com os servidores saudáveis identificados, falta decidir qual recebe cada pedido. A documentação do NGINX, que faz balanceamento na camada de aplicação para tráfego HTTP e HTTPS, lista cinco métodos na edição de código aberto: round robin, least connections, least time, IP hash e hash genérico.

Round robin, least connections e random distribuem pedidos conforme os pesos dos servidores. Um servidor marcado como backup não recebe pedidos, a menos que os outros estejam indisponíveis.

No Application Load Balancer da AWS, o algoritmo é uma propriedade do grupo de alvos e pode ser round_robin, least_outstanding_requests ou weighted_random. O padrão é round robin, e o roteamento é feito de forma independente para cada grupo de alvos.

03 · SAÚDE E ZONAS

Saúde dos alvos e zonas de disponibilidade

A verificação de saúde impede o balanceador de mandar tráfego a um alvo quebrado. Na AWS, cada nó do balanceador roteia pedidos só para os alvos saudáveis das zonas habilitadas, e o estado vem de pedidos de teste enviados periodicamente. Depois de falhas consecutivas acima do limite configurado o alvo sai de serviço; depois de sucessos consecutivos acima do limite, ele volta.

O NGINX Plus oferece o slow start, que evita que um servidor recém-recuperado seja sobrecarregado por conexões: o servidor recupera o peso gradualmente, de zero até o valor nominal. A documentação diz que esse recurso só está disponível no NGINX Plus.

Cada zona de disponibilidade habilitada recebe um nó do balanceador. A AWS recomenda habilitar várias zonas em todo balanceador e, no Application Load Balancer, exige duas ou mais. Assim, se uma zona fica indisponível ou sem alvos saudáveis, o balanceador pode rotear tráfego para alvos saudáveis de outra zona.

1. O cliente resolve o nome do balanceador; o servidor DNS devolve um ou mais endereços IP, que são os dos nós do balanceador.

2. Cada zona habilitada tem o seu próprio nó do balanceador.

3. Com cross-zone desligado, cada nó distribui o tráfego apenas entre os alvos da sua própria zona.

4. Com cross-zone ligado, cada nó distribui o tráfego entre os alvos registrados de todas as zonas habilitadas.

5. Se a zona A fica indisponível ou sem alvos saudáveis, o balanceador pode rotear o tráfego para alvos saudáveis de outra zona.

O cross-zone load balancing define o escopo de cada nó: ligado, o nó distribui o tráfego entre os alvos de todas as zonas habilitadas; desligado, apenas entre os alvos da própria zona. No Application Load Balancer ele está sempre ligado no nível do balanceador.

No exemplo da documentação há duas zonas habilitadas, com dois alvos na zona A e oito na zona B; com round robin, cada nó do balanceador recebe metade do tráfego dos clientes.

04 · O BALANCEADOR TAMBÉM FALHA

Escalar sem ponto único de falha

Um único balanceador seria ele mesmo um ponto único de falha e um limite para a capacidade. Por isso vale olhar como um balanceador de grande escala se replica.

O Maglev, balanceador de carga de rede do Google descrito em um artigo técnico, é um sistema distribuído de software que roda em servidores comuns, e sua capacidade se ajusta com facilidade adicionando ou removendo servidores. Roteadores de rede distribuem os pacotes de forma uniforme entre as máquinas do Maglev por ECMP, a sigla de multipath de custo igual.

Cada serviço tem um ou mais endereços IP virtuais (VIPs), diferentes de um IP físico: um VIP é atendido por vários endpoints de serviço atrás do Maglev. O DNS atribui o usuário a um local de frontend próximo e devolve um VIP desse local.

1. O navegador consulta o DNS, que o atribui a um local de frontend próximo e devolve um VIP desse local.

2. Os pacotes para o VIP chegam ao roteador, que os encaminha a uma das máquinas Maglev do cluster por ECMP.

3. A máquina Maglev consulta a tabela de conexões; se não há entrada utilizável, consulta o hash consistente e escolhe um novo backend.

4. O pacote é encapsulado com GRE e enviado ao endpoint escolhido; a resposta é enviada diretamente ao roteador, de modo que o Maglev não precisa tratar os pacotes de retorno.

5. Numa atualização, as máquinas são reiniciadas em sequência com o tráfego drenado antes; o ECMP embaralha o tráfego e conexões passam a outras máquinas no meio do caminho, onde as entradas da tabela de conexões não estão corretas.

6. Pela propriedade de perturbação mínima do hash consistente, a conexão provavelmente continua indo ao mesmo backend de antes.

Escolher o endpoint depende de um requisito: o sistema precisa garantir persistência de conexão, isto é, pacotes da mesma conexão devem ir sempre ao mesmo endpoint. O Maglev guarda numa tabela de conexões a escolha de backend das conexões recentes e, se há entrada e o backend segue saudável, reaproveita o resultado.

Só a tabela não basta, por dois motivos apontados no artigo. O acompanhamento local pressupõe que todos os pacotes com a mesma tupla de cinco campos sejam sempre enviados à mesma máquina Maglev, o que deixa de valer quando o conjunto de máquinas muda; numa atualização do cluster, por exemplo, as máquinas são reiniciadas em sequência. Além disso, a tabela tem espaço finito e pode encher sob carga alta ou ataque de SYN flood.

A segunda defesa é o hash consistente local. Compartilhar o estado de conexões entre todas as máquinas seria uma abordagem possível, mas prejudicaria o desempenho do encaminhamento, e o artigo prefere uma solução local. Entre as propriedades desejadas estão o balanceamento, em que cada backend recebe um número quase igual de conexões, e a perturbação mínima, em que a conexão provavelmente continua indo ao mesmo backend quando o conjunto muda.

05 · CAMADAS E FECHAMENTO

Pacote ou pedido: onde o balanceador decide

A AWS mostra duas formas de decidir. No Application Load Balancer, o nó avalia as regras do listener em ordem de prioridade e o algoritmo padrão é round robin. No Network Load Balancer, o nó escolhe o alvo com um algoritmo de hash de fluxo e roteia cada conexão TCP a um único alvo durante toda a vida dela.

Dois exemplos usam hash para escolher o destino. O IP hash do NGINX escolhe o servidor a partir do endereço IP do cliente e garante o mesmo servidor para o mesmo endereço, a menos que ele esteja indisponível. O hash de fluxo do Network Load Balancer usa, entre outros campos, o IP e a porta de origem.

Para fechar uma entrevista, junte as peças: o DNS entrega os endereços dos nós, os nós ficam em mais de uma zona, cada nó escolhe só entre alvos saudáveis, o algoritmo depende do tipo de tráfego e a camada de balanceadores é replicada para não virar ponto único de falha.