Blog/Artigos · Cloud e Plataforma
Escala horizontal e vertical, HPA e Karpenter, escala reativa e preditiva, right-sizing e a compensação entre custo e saturação.
O profeta diz: alarga o lugar da tua tenda, estende as cortinas das tuas moradas, não poupes. A tenda é a moradia que se ajusta: cresce quando a família cresce, recolhe quando diminui, ao contrário da casa de pedra, fixa para sempre no tamanho do dia em que foi construída. Capacidade na nuvem devia ser tenda, e por décadas foi pedra. Comprava-se servidor para o pico, e ele ficava ocioso no vale, caro e parado; ou comprava-se para a média, e ele saturava no pico, derrubando o sistema quando mais se precisava dele. Autoscaling é a tenda: alarga o espaço quando a demanda sobe e o recolhe quando ela cai, pagando pelo que de fato se usa, e nunca mais pela pedra parada.
A demanda de quase todo sistema varia: sobe de dia, cai de madrugada, dispara na promoção, recolhe no feriado. Capacidade fixa, dimensionada para um número só, erra em toda hora que não é aquela. Dimensionada para o pico, ela desperdiça o dia inteiro fora do pico, pagando por servidor ocioso que só serve nas poucas horas de maior movimento. Dimensionada para a média, ela satura no pico, e a saturação chega no pior momento, quando há mais usuário do que nunca, transformando o dia de maior oportunidade no dia da queda. Não existe número fixo certo para uma demanda que varia.
Autoscaling resolve isso ajustando a capacidade à demanda em tempo real. Quando a métrica que representa a carga sobe, uso de CPU, requisições por segundo, tamanho de fila, o sistema adiciona capacidade; quando ela cai, remove. A promessa é dupla e rara: melhor experiência no pico, porque há capacidade quando se precisa, e menor custo no vale, porque não se paga pelo que não se usa. É a tenda que se alarga na cheia da família e se recolhe quando ela sai, em vez da pedra que fica do mesmo tamanho enquanto a vida muda ao redor dela.
| Hora do dia | Demanda real | Capacidade fixa (pico) | Capacidade que escala |
|---|---|---|---|
| 0 | 20 | 95 | 28 |
| 6 | 25 | 33 | |
| 9 | 70 | 80 | |
| 12 | 85 | 95 | |
| 15 | 80 | 90 | |
| 18 | 90 | 100 | |
| 21 | 45 | 55 | |
| 24 | 22 | 95 | 30 |
Há duas direções de escala e elas resolvem coisas diferentes. Escala horizontal adiciona mais cópias iguais: mais réplicas do serviço, mais nós no cluster. É a preferida, porque distribui a carga e aumenta a resiliência ao mesmo tempo, e no Kubernetes é o trabalho do HPA, o Horizontal Pod Autoscaler, que ajusta o número de pods pela métrica. Escala vertical dá mais recurso à mesma instância, mais CPU e memória a um pod, trabalho do VPA, útil quando o serviço não paraleliza bem, mas limitada pelo tamanho da maior máquina e por exigir, muitas vezes, reiniciar.
No nível da infraestrutura, o cluster autoscaler adiciona e remove nós conforme os pods precisam de lugar, e o Karpenter, da AWS, modernizou isso escolhendo o tipo de instância mais adequado e barato para a carga pendente, em vez de só ligar mais do mesmo. E há o corte mais radical: escalar a zero, desligar completamente o que não tem demanda, pagando nada quando não há uso, o que serverless faz por padrão e o Kubernetes alcança com ajuda. A tenda que se recolhe até sumir quando ninguém a habita é o extremo da economia, e o sonho de toda carga intermitente que hoje paga por ficar de pé sem ninguém dentro.
O autoscaling clássico é reativo: espera a métrica subir, e então adiciona capacidade. Funciona, mas tem um atraso embutido que dói. Entre a demanda subir, a métrica refletir, a decisão disparar e a nova capacidade ficar pronta, passam segundos ou minutos, e nesse intervalo o sistema já está saturado. Para uma onda gradual, o reativo dá conta; para um pico súbito, uma promoção que começa às dez em ponto, uma notificação enviada a milhões, o reativo escala atrasado e o usuário sente a lentidão antes de a tenda terminar de alargar.
A resposta é antecipar. A escala programada liga capacidade antes do evento conhecido: se a promoção começa às dez, a capacidade sobe às nove e meia, sem esperar a métrica. E a escala preditiva usa o histórico para prever a demanda e se preparar para o padrão recorrente, o pico de toda segunda de manhã, a queda de todo feriado, escalando antes de a onda chegar. É a diferença entre alargar a tenda quando a chuva já começou e alargá-la vendo a nuvem no horizonte. O maduro combina: preditivo e programado para o que se conhece, reativo como rede de segurança para o que surpreende, para nunca ser pego nem desprevenido nem escalando tarde demais.
Autoscaling ajusta quantas unidades você tem; right-sizing ajusta o tamanho de cada unidade. De nada adianta escalar bem o número de instâncias se cada instância é grande demais para o que roda nela: você escala desperdício. Right-sizing é medir o consumo real de cada carga e ajustar o recurso pedido ao que ela de fato usa, com uma folga sã. É onde autoscaling encontra o FinOps: a maior economia de nuvem quase nunca é uma negociação de desconto, é parar de pagar por recurso que ninguém usa, seja a instância ociosa que o autoscaling deveria ter recolhido, seja o pod que pede o dobro da memória que consome.
A camada final de economia é o tipo de compra. Instâncias spot, capacidade ociosa da nuvem vendida barata mas que pode ser retomada a qualquer momento, cortam custo drasticamente para cargas tolerantes a interrupção, e o autoscaling moderno as usa por padrão onde cabe. Reservas e planos de economia cobrem a base previsível de demanda com desconto, enquanto o autoscaling cobre a variação por cima. A tenda madura tem uma base reservada e barata para o que sempre está lá, e uma borda elástica e spot para o que varia. Dimensionar cada unidade, escolher o tipo de compra e escalar o número, os três juntos, é o que dá a tenda do tamanho exato da família, sem pedra ociosa nem aperto no pico.
| Alavanca | O que ajusta | Ganho | Cuidado |
|---|---|---|---|
| Autoscaling | quantas unidades, conforme a demanda | não paga o ocioso no vale | escalar na hora certa, nem tarde nem cedo |
| Right-sizing | o tamanho de cada unidade | para de pagar recurso que ninguém usa | manter folga sã, não apertar até saturar |
| Instância spot | o tipo de compra da borda elástica | corte grande para carga interrompível | só para o que tolera ser retomado |
| Reserva e savings plan | o tipo de compra da base | desconto na demanda sempre presente | só para a base previsível, não o pico |
A capacidade amadurece da pedra à tenda inteligente. No começo é capacidade fixa, dimensionada no chute e paga cheia o tempo todo. Depois vem o autoscaling reativo básico, seguindo a métrica com atraso. No meio vem o right-sizing e o uso de spot, ajustando tamanho e tipo de compra. No topo é a escala preditiva guiada por IA, com base reservada e borda elástica, right-sizing contínuo e a tenda sempre do tamanho exato da demanda. Cada degrau aproxima o que se paga do que se usa, e afasta tanto o desperdício quanto a saturação.
Autoscaling fecha este eixo porque toca todos os outros. Ele é o que o Kubernetes executa com HPA e Karpenter; é o que dá elasticidade ao que o IaC provisiona; é a expressão operacional do pilar de eficiência de custo do Well-Architected; é irmão do FinOps na caça ao ocioso. A tenda que se alarga e se recolhe é a metáfora da nuvem bem usada: pagar pelo que se habita, quando se habita, e não pela pedra parada. Alargar o lugar da tenda, como diz o profeta, sem poupar quando a família cresce, e recolher as cortinas quando ela sai, é o que separa a nuvem que custa o que vale da nuvem que só reproduz, mais cara, o desperdício do datacenter.
Autoscaling é a tenda que se alarga na cheia da demanda e se recolhe no vale, contra a pedra da capacidade fixa que desperdiça no vale e satura no pico. Escala horizontal, vertical, cluster autoscaler e Karpenter dão os mecanismos; reativo reage à onda e preditivo a antecipa; e right-sizing com spot e reserva dão a tenda do tamanho e do custo certos. A IA torna a escala de fato preditiva e o right-sizing contínuo. Mas decidir a folga de segurança, o quanto se aceita arriscar saturação para economizar, continua sendo julgamento de quem equilibra custo e confiabilidade, o mesmo trade-off que abre o Well-Architected e fecha este eixo.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaחוֹבֵל
Kubernetes é grego para timoneiro, e é isso que ele faz: você declara o estado desejado e ele conduz a frota de contêineres até lá, corrigindo sozinho o que sai da rota. O poder é real, e a complexidade também, e a maturidade começa em saber quando não içar essa vela.
Governançaפְקוּדֵי
O ciclo do FinOps, por que custo por transação importa mais que a fatura total, onde o dinheiro escorre e como a IA detecta e explica anomalia de custo.
