Quando um servidor deixa de bastar

Balanceamento de carga é a resposta a uma pergunta que você deveria conseguir formular como um número, e formulá-la é mais da metade do trabalho.

Os dois motivos para adicionar um servidor

Capacidade: as requisições chegam mais rápido do que uma máquina consegue atendê-las.

Disponibilidade: a falha de uma máquina derruba o site, e isso deixou de ser aceitável.

São problemas diferentes com a mesma solução, e confundi-los leva a adicionar um segundo servidor que não ajuda em nenhum dos dois.

Como a capacidade fica em número

Pegue um exemplo: um Puma com dois workers e três threads cada tem seis vagas de requisição.

A resposta aquecida e logada do roadmap desta aplicação leva cerca de 72 milissegundos. Seis vagas a 72 milissegundos cada dão cerca de 83 requisições por segundo, se toda requisição fosse essa página e nada mais disputasse.

O roadmap anônimo leva cerca de 20 milissegundos, então as mesmas seis vagas atendem cerca de 300 por segundo dele.

São tetos de aritmética, não medições, e a diferença importa. Uma máquina real tem pausas de coleta de lixo, disputa no banco e jobs rodando no mesmo processo.

flowchart TB
  S["6 vagas de requisição, como exemplo"] --> A["a 72ms cada: cerca de 83 por segundo"]
  S --> B["a 20ms cada: cerca de 300 por segundo"]
  A --> C["teto aritmético, não uma medição"]
  B --> C
  C --> D["o número real é menor e não medido aqui"]

A ordem das respostas mais baratas

Antes de um segundo servidor, deixe cada requisição mais barata. A página de roadmap deste projeto passou de cerca de 310 milissegundos e 311 queries para cerca de 72 milissegundos e 46 queries. Essa mudança quase quadruplicou a capacidade da mesma máquina para essa página, e não custou hardware nenhum.

Depois vem uma máquina maior. Mais núcleos significam mais workers, e continua sendo uma máquina para operar.

Depois vem o cache. Uma resposta em cache que nunca chega ao Ruby não ocupa vaga nenhuma.

Só então vem um segundo servidor, que é a primeira opção que acrescenta um compromisso operacional em vez de uma mudança de configuração.

A disponibilidade é outro limite

Nenhuma otimização faz uma máquina sobreviver à própria falha.

Se a exigência é "o site continua no ar quando uma máquina morre", o segundo servidor é necessário independentemente da carga, e ele precisa ser um segundo servidor, não um maior.

Ter clareza sobre qual dos dois problemas você tem define o desenho inteiro, porque uma resposta de capacidade e uma de disponibilidade parecem idênticas num diagrama e se comportam de formas totalmente diferentes.

Pontos-chave

• Capacidade e disponibilidade são problemas diferentes que apontam para um segundo servidor.
• No exemplo, seis vagas a 72 milissegundos dão cerca de 83 requisições por segundo, pela aritmética.
• Requisições mais baratas, uma máquina maior e cache vêm antes de um segundo servidor.
• A otimização do roadmap quase quadruplicou a capacidade dessa página sem hardware.
• Nenhuma otimização faz uma máquina sobreviver à própria falha.