Estimador de capacidade

De quantos servidores precisa realmente? Responda com aritmética em vez de impressões: dê ao estimador a sua taxa de pedidos, o tempo de CPU que cada pedido queima e o tempo de resposta que os utilizadores veem, e ele devolve os núcleos que o tráfego mantém ocupados, os servidores inteiros a aprovisionar — com a sua política de redundância aplicada —, a concorrência que os seus conjuntos de ligações têm de sobreviver e o aspeto do mesmo serviço com duas, cinco e dez vezes o tráfego.

As fórmulas, em linguagem simples

Núcleos. Multiplique a taxa de pedidos pelos segundos de CPU que cada pedido consome: é esse o número de núcleos que o tráfego mantém ocupados a 100%. Depois divida pela sua utilização-alvo — a 70%, cada núcleo que aprovisiona conta apenas como 0,7 de um núcleo de plano, e os outros 0,3 são a margem que mantém as filas curtas quando o tráfego oscila. Núcleos necessários = pedidos/s × segundos de CPU por pedido ÷ utilização-alvo.

Servidores. Divida os núcleos pelos núcleos por servidor e arredonde para cima — não existe tal coisa como 0,4 de um servidor, e arredondar para baixo é como um plano que funciona em média falha no pico. A redundância é aplicada depois: N+1 acrescenta um servidor suplente à contagem arredondada; 2N duplica toda a frota. A concorrência é um número separado, vindo de Little's law: pedidos em curso = pedidos/s × tempo de resposta em segundos. Dimensiona os conjuntos de threads, as ligações à base de dados e os descritores de ficheiros — os limites que os serviços realmente atingem enquanto as suas CPU ainda estão a descansar. A saída, quando indica um tamanho de resposta, é pedidos/s × tamanho × 8, os bits de que é feita a sua fatura de rede. O artigo complementar, de quantos servidores precisa realmente, explica de onde vem cada entrada e porque é que os benchmarks dos fornecedores discordam de tudo isto.

Companheiros de planeamento: a calculadora de orçamento de erros de SLA transforma em minutos a meta de disponibilidade que esta capacidade defende, e a calculadora de retenção de cópias de segurança dimensiona o lado do armazenamento do mesmo sistema.

Perguntas frequentes

Porque planear para 70% de utilização em vez de 100%?

Porque as filas explodem antes da saturação, não nela. Uma CPU ocupada a 95% em média é uma CPU cuja fila cresce sem limite sempre que o tráfego oscila — e o tráfego oscila sempre. A meta de utilização é a margem que absorve picos, implementações, novas tentativas e uma dependência lenta. Setenta por cento é o padrão da indústria para serviços sensíveis à latência; os trabalhadores em lote que toleram atrasos podem funcionar mais quentes, e qualquer coisa voltada para o utilizador e com picos deve funcionar mais fria.

Qual é a diferença entre núcleos e pedidos em curso?

Respondem a perguntas diferentes. Os núcleos vêm do tempo de serviço de CPU: quanto processador cada pedido consome. Os pedidos em curso vêm de Little's law: a taxa multiplicada pelo tempo de resposta, e medem a concorrência — ligações, threads, memória mantida aberta — e não a carga do processador. Um serviço com chamadas lentas a jusante pode manter 500 pedidos em curso enquanto usa dois núcleos, e esgotará o conjunto de ligações muito antes de esgotar a CPU. Dimensione ambos, ou aquele que ignorou torna-se a falha.

O meu teste de carga diz que um servidor trata 2.000 pedidos por segundo. Porque é que este estimador discorda?

Os testes de carga medem normalmente um serviço quente, estável e com a cache bem quente a responder a uma única forma de pedido a partir de um cliente generoso. A produção acrescenta arranques a frio, handshakes TLS, novas tentativas, uma longa cauda de pedidos lentos, vizinhos ruidosos e a implementação que reduz a capacidade para metade durante dez minutos. O estimador é deliberadamente conservador — tempo médio de CPU, um teto de utilização, servidores inteiros, redundância acrescentada. Trate o teste de carga como o teto do que é possível e este número como o piso do que aprovisionar; a verdade para planear é o piso.

Contra o que é que N+1 protege realmente?

Contra uma falha: um anfitrião morto, uma má implementação retirada da rotação, um evento de zona de disponibilidade que leva uma única instância. Com N+1, os restantes N servidores continuam a cumprir a meta — é esse o sentido de dimensionar primeiro N a partir do tráfego e acrescentar o suplente depois. 2N é uma promessa diferente: duas cópias completas, normalmente entre regiões, para serviços que têm de sobreviver à perda de uma cópia inteira. Duplica a fatura, por isso compra-se para os serviços cuja ausência se mede em manchetes.

Como obtenho o meu tempo de serviço de CPU por pedido?

Meça-o, não o adivinhe. Num serviço em funcionamento: o total de segundos de CPU consumidos numa janela, dividido pelos pedidos servidos na mesma janela. As ferramentas de monitorização de desempenho de aplicações reportam-no diretamente como CPU por pedido; em Linux, pode derivá-lo do tempo de CPU do processo em /proc ou das métricas dos seus contentores. Use o número da sua hora realista mais ocupada, não a média de todo o dia — a capacidade planeada a partir de médias falha precisamente no pico para o qual foi comprada.