System Design/04 - Cloud Design Patterns/Design & Implementation2 min
Compute Resource Consolidation
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Agrupar várias cargas de trabalho pequenas na mesma unidade de computação, em vez de dedicar uma instância a cada uma.
disperso: 5 serviços × 1 VM cada → 5 VMs a 8% de CPU
consolidado: 5 serviços numa VM → 1 VM a 40% de CPU
O desperdício que ele combate não é apenas a CPU ociosa: cada unidade carrega SO, agente de monitoramento, sidecar e um custo fixo que independe da utilização.
Trade-offs
O ganho é eficiência de custo — e ele pode ser grande, porque frotas dispersas costumam operar a utilização de um dígito.
O custo é perder isolamento, e todos os riscos derivam disso:
| Risco | Consequência |
|---|---|
| Noisy Neighbor | Um serviço consome CPU e prejudica os vizinhos |
| Falha compartilhada | Um crash pode derrubar os colocados |
| Deploy acoplado | Publicar um exige cuidado com os outros |
| Segurança | Menos barreiras entre cargas |
Containers com limites de recurso (CPU, memória) mitigam boa parte disso: consolidam a infraestrutura mantendo isolamento lógico. É por isso que Kubernetes é a expressão moderna do padrão — vários pods por nó, cada um com limites declarados.
O critério de agrupamento importa: consolide cargas com perfis compatíveis e criticidade semelhante. Juntar um serviço crítico com um job de lote agressivo é pedir por interferência exatamente no pior momento.
E há um limite de escala: consolidar demais recria o monolito operacional, onde nada pode ser escalado ou publicado sem afetar o resto.
O antipadrão oposto também é caro — uma instância dedicada por microserviço, cada uma a 5% de utilização, multiplicando custo fixo por dezenas.
Exemplo prático
Doze microserviços, cada um numa VM a ~8% de CPU. O custo é dominado por capacidade ociosa e por doze cópias de agente e SO.
Consolidados num cluster Kubernetes com três nós, cada pod com requests e limits declarados:
requests: 200m CPU, 256Mi ← o escalonador garante
limits: 1000m CPU, 512Mi ← teto contra noisy neighbor
O custo de infraestrutura cai substancialmente, e o isolamento é preservado pelos limites: um serviço que entra em laço não pode consumir mais que seu teto.
O que se ganha além do custo: escalar um serviço passa a ser mudar o número de réplicas, não provisionar uma VM.
Relacionado
Parte de Design & Implementation · roadmap.sh/system-design