Autoscaling de Rails por CPU e tempo de resposta, não por achismo

A maioria dos conselhos sobre autoscaling parte do princípio de que você já tem um pipeline de métricas, um dashboard e uma opinião formada sobre o que “carga alta” significa pra sua aplicação específica. A maioria das aplicações Rails pequenas não tem nada disso, e é por isso que o autoscaling geralmente acaba de lado em favor de simplesmente rodar um servidor maior do que o necessário, o tempo todo, por segurança.

A versão mais simples: defina um mínimo e um máximo, e deixe os dois números que de fato se correlacionam com um processo Rails sofrendo — CPU e tempo de resposta p95 — decidirem o que acontece entre eles.

Como a decisão realmente funciona

App → Settings → General → Autoscaling recebe uma quantidade mínima e máxima de réplicas. O Railyard adiciona ou remove réplicas web entre esses dois limites com base em:

• CPU alvo por réplica (%) — a CPU média que uma réplica pode sustentar antes de outra ser adicionada.
• Tempo de resposta p95 — a meta de tempo de resposta no percentil 95; um processo Rails enfileirando requisições atrás de uma query lenta ou de uma thread bloqueada aparece aqui antes de aparecer como uma indisponibilidade.

Deixe Max em branco e nada reativo acontece — a aplicação simplesmente roda com uma quantidade fixa de réplicas, que é o padrão certo pra qualquer coisa que não vê carga de fato variável.

Uma restrição real que vale conhecer de antemão: as réplicas compartilham o próprio servidor da aplicação, então isso ajuda especificamente com carga de CPU ou requisições lentas, não com um servidor que está genuinamente sem capacidade — e ele nunca escala pra cima enquanto a memória do servidor já está alta, já que adicionar uma réplica numa máquina faminta por memória piora as coisas, não melhora.

PATCH /api/applications/:id/autoscale
{ "min": 1, "max": 4, "cpu": 70, "p95_ms": 400 }

Pré-aquecimento pra um pico que você consegue prever

O scaling reativo é bom em responder a uma carga; não é bom em responder a uma carga que vai acontecer nos próximos sessenta segundos, porque, no momento em que a CPU sobe o suficiente pra disparar um scale-up, o pico já começou a prejudicar os tempos de resposta. As janelas agendadas resolvem o caso específico em que você já sabe quando o pico vai chegar — o lançamento de um produto num horário fixo, um padrão diário de tráfego, um job em lote semanal que sempre roda na mesma hora.

mon,tue,wed,thu,fri 08:00-18:00 3

Dias, um intervalo de início e fim, e uma quantidade mínima de réplicas, no fuso horário da própria aplicação. A janela só eleva o piso — as regras normais de CPU/p95 continuam decidindo tudo acima desse mínimo, então um pico maior do que o esperado dentro da janela ainda escala além dele. Ela pré-aquece; não substitui o scaling reativo.

O que isso substitui

A alternativa que a maioria das equipes realmente roda hoje é uma quantidade fixa e sobredimensionada de servidores, escolhida uma vez e raramente revisitada, porque montar um sinal de autoscaling de verdade do zero é um projeto em si. Dois números que já se correlacionam com o esforço específico do Rails — CPU e p95 — acabam sendo suficientes pra automatizar o caso comum sem precisar acoplar um stack de métricas antes.

Referência completa, incluindo como isso interage com o failover automático: Autoscaling and failover.