En desarrolloSaaS & Tecnología

Simulador de capacity planning de servidores

Cada minuto de downtime le cuesta a un SaaS promedio $5,600 en revenue perdido y confianza destruida.

Problema y enfoque

Tus servidores se caen en picos de tráfico pero pagar por capacidad ociosa el resto del mes destruye tu margen.

Simula el crecimiento de tu tráfico y encuentra la estrategia de escalamiento que balancea performance con costo.

Variables que analizará

  • Tráfico actual
  • Tasa de crecimiento
  • Capacidad por servidor
  • Costo por instancia

Preguntas frecuentes

¿Cómo determino la capacidad máxima de mis servidores?
Considera uso de CPU (no más del 70% sostenido), RAM disponible y throughput de red/disco. El simulador calcula el punto real de saturación.
¿Contempla estrategias de auto-scaling?
Sí, puedes modelar capacidad fija, auto-scaling con límites o modelos híbridos, con costos y tiempos de respuesta para cada uno.
¿Y si mi tráfico tiene patrones irregulares?
Permite configurar patrones estacionales, semanales y por hora para modelar picos como lanzamientos o campañas de marketing.

Guía completa

Calculadora de capacity planning para Kubernetes y cloud

En equipos DevOps, SRE y platform engineering hispanohablantes, el capacity planning de Kubernetes sigue siendo una de las disciplinas donde la terminología técnica se mantiene casi íntegra en inglés — requests, limits, HPA, VPA, bin-packing, headroom — porque la documentación canónica (Google SRE Book, Kubernetes Docs, CNCF) vive en inglés y la comunidad práctica conversa mezclando ambos idiomas. Esta calculadora traduce la operación práctica al español, pero conserva los términos técnicos que usarías en un PR review o un postmortem.

Fórmulas base

Utilización = Demanda ÷ Capacidad Headroom objetivo = 30% (estándar SRE) Ley de Little: L = λ × W (concurrencia = tasa de llegada × tiempo en el sistema) Costo por unidad de trabajo = Costo cloud mensual ÷ Requests servidos al mes

La regla operacional del Google SRE Book es mantener la utilización P95 de CPU de un servicio por debajo de 70% en régimen sostenido, con headroom del 30% reservado para picos sostenidos, tolerancia a caída de zona (fail-over), deployments rolling y HPA reaccionando sin tail-latency spike. Esto aplica a workloads con latencia crítica (request/response). Para workloads batch asíncronos se puede operar más cerca del 85-90% sin degradar SLO.

Rightsize de requests y limits

El error más común — y el más caro — es definir requests con el valor pico observado en load test y limits con 2× o 3× ese valor 'por seguridad'. Eso reserva CPU y memoria que el scheduler no podrá usar para bin-packing y duplica la factura de EKS, GKE o AKS sin mejorar el servicio.

Protocolo práctico, alineado al post de Sysdig Kubernetes Capacity Planning (citado ampliamente en la comunidad SRE LatAm) y a las mejores prácticas de Datadog y Grafana Cloud:

  1. Mide el uso real de CPU y memoria P95 en los últimos 7 días por contenedor. No uses P50 ni el pico absoluto.
  2. Define request = P95 observado.
  3. Define limit = request × 1.5 para CPU (throttle tolerable) y limit = request × 1.5–2.0 para memoria (recuerda: superar el limit de memoria dispara OOMKill, no throttling).
  4. Suma los requests totales del cluster × 1.3 como overhead para kube-system, daemonsets, coredns, cni, monitoring agent.
  5. Divide entre la capacidad asignable por nodo (ej. m5.xlarge en AWS entrega ~3.8 vCPU y ~14.5 GiB asignables) para estimar nodos.
  6. Suma 20-30% de buffer para HPA, spikes y mantenimiento de nodos (drain durante upgrades).

Ejemplo numérico. Cluster EKS con 200 pods, requests totales 380 vCPU y 1,200 GiB. Factor overhead 1.3 → 494 vCPU, 1,560 GiB. Nodos m5.xlarge (3.8 vCPU, 14.5 GiB asignables): 494 ÷ 3.8 = 130 nodos por CPU y 1,560 ÷ 14.5 = 108 nodos por memoria. El bottleneck es CPU → 130 nodos + buffer 25% = 163 nodos a régimen actual. Factura AWS on-demand: ~18,000 USD/mes. Migración a 40% Reserved Instances + 30% Savings Plans + 30% on-demand baja la factura a ~11,500 USD/mes, un ahorro anual de 78 KUSD sin tocar el workload.

HPA, VPA y cluster autoscaler

Los tres autoscalers de Kubernetes resuelven problemas distintos y se usan en capas:

  • HPA (Horizontal Pod Autoscaler). Escala el número de réplicas del pod basándose en CPU, memoria o métricas custom (RPS, queue length vía Prometheus Adapter o KEDA). Umbral típico: 70% CPU o 70% de la métrica target.
  • VPA (Vertical Pod Autoscaler). Recomienda o aplica automáticamente nuevos requests/limits basándose en uso histórico. Útil para workloads con patrón de uso estable pero mal dimensionados inicialmente.
  • Cluster Autoscaler (o Karpenter en AWS). Agrega o quita nodos cuando los pods pendientes (pending) no caben o cuando hay nodos sub-utilizados que se pueden consolidar.

Regla práctica: HPA para elasticidad horaria, VPA para corrección de rightsize (en modo 'recommend' para evitar restarts en horas pico), Karpenter para manejo del pool de nodos. Combinar los tres sin coordinación produce oscilación (thrashing); por eso VPA típicamente se deja en modo Off o Recreate con ventana de mantenimiento, no en Auto.

Costo por request y unit economics cloud

FinOps — la disciplina que emergió 2020-2025 con presión del CFO sobre cloud spend — mide costo cloud por unidad de trabajo: costo por request, por transacción, por usuario activo. Si el costo por request sube mientras el tráfico cae, tu cluster tiene waste. Kubecost, OpenCost, Vantage, CloudHealth y Cast AI exponen estas métricas; la calculadora las estima con inputs de tu factura mensual y tu RPS promedio.

Según el State of Cloud Costs 2025 de Datadog y el State of FinOps 2025 de la FinOps Foundation, entre 30% y 45% del gasto en compute cloud es waste — capacidad reservada pero no usada, instancias sobredimensionadas, ambientes dev que nunca se apagan, snapshots huérfanos. El rightsize sistemático + reserved instances + spot para workloads tolerantes a interrupción suele recortar el 20-35% de la factura en 90 días sin impacto en SLO.

Caso real

Caso: plataforma SaaS B2B Serie B en Ciudad de México. Un SaaS de procurement con 180 clientes mid-market en LatAm operaba sobre EKS en us-east-1 con 200 pods distribuidos en 180 nodos m5.xlarge en modalidad 100% on-demand. Factura AWS de compute: 18,200 USD/mes. El equipo de platform engineering, dos SRE y un platform lead, recibió del CFO la directiva de recortar 30% del cloud spend antes del cierre del siguiente trimestre tras la última ronda. La utilización P95 de CPU en el cluster promediaba 38% — un indicador inequívoco de sobredimensionamiento.

El platform lead ejecutó tres escenarios en la calculadora. Status quo: 180 nodos, 18.2 KUSD/mes, waste estimado 44%. Rightsize en 2 pasos (VPA en modo recommend aplicado a los 30 deployments top consumidores de CPU + ajuste manual de requests al P95 observado en 7 días): 125 nodos, 12.6 KUSD/mes, ahorro de 67 KUSD/año. Rightsize + migración 40% Reserved 1yr + 30% Savings Plans + Karpenter para pool spot de workloads batch: 95 nodos efectivos (mix RI/SP/spot), 9.8 KUSD/mes, ahorro anual de 101 KUSD.

La fase 1 (rightsize) se ejecutó en 3 sprints: VPA en modo recommend por 2 semanas, PR de ajuste de requests/limits por equipo, validación con load test sintético a 2× RPS actual. Resultado medido al día 45: cluster a 130 nodos, factura 12.9 KUSD/mes, tail latency p99 sin degradación, ahorro anualizado real de 63 KUSD. La fase 2 (Reserved Instances + Savings Plans + Karpenter para pool spot en workers batch del procesamiento nocturno de catálogos) terminó en el día 80. Factura final: 10.1 KUSD/mes, ahorro anualizado de 97 KUSD, headroom mantenido en 32%. El CFO obtuvo el recorte del 44% del spend solicitado — mejor que el 30% inicial — sin un solo incidente de SLO reportado en ese trimestre.

Benchmarks de la industria

MétricaValorFuente
Utilización CPU P95 objetivo para servicios latencia-crítica< 70% sostenidoGoogle SRE Book (Beyer et al., 2016, cap. 18)
Waste típico en gasto cloud compute30-45%FinOps Foundation State of FinOps 2025
Reducción de factura cloud con rightsize sistemático + RI/SP en 90 días20-35%Datadog State of Cloud Costs 2025
Adopción de Kubernetes en producción (CNCF survey 2024)84%CNCF Annual Survey 2024
Overhead kube-system + daemonsets + CNI sobre requests totales25-35%Sysdig Kubernetes Capacity Planning 2024
Ratio limits/requests recomendado CPU1.5× (throttle tolerable)Kubernetes Documentation / SRE best practices
Ratio limits/requests recomendado memoria1.5-2.0× (cuidado OOMKill)Kubernetes Documentation / Sysdig Best Practices
Umbral HPA típico70% CPU targetKubernetes HPA docs + DORA Accelerate State of DevOps 2024

Preguntas frecuentes

¿Cómo calcular cuántos servidores necesita mi aplicación web?
Parte de tres números: usuarios concurrentes pico, QPS por usuario y el tiempo de respuesta objetivo. Regla de oro: cada vCPU sostiene 50-150 requests/segundo bajo 70% de utilización (por encima de 70% las colas explotan y la latencia se dispara). Para 10k usuarios concurrentes a 2 QPS promedio y 100 QPS/vCPU: 20k QPS / 100 / 0.7 ≈ 285 vCPU, redondea a 300. Reparte en 10 instancias de 32 vCPU si necesitas redundancia N+2.
¿Qué nivel de utilización de CPU es seguro para planificar capacidad?
La regla clásica de capacity planning (Gunther 1998, Microsoft Technet 2008, aún vigente) es mantener utilización promedio por debajo de 70%. Entre 70-80% la latencia percentil 95 empieza a degradarse, arriba de 80% las colas se llenan en cualquier ráfaga y el sistema se vuelve inestable. Dimensiona para que tu carga sostenida pico quede en 60-70% y deja headroom para picos sorpresa, despliegues y fallos de un nodo.
¿Cuánta memoria RAM por usuario concurrente debo reservar?
Depende del stack. Reglas aproximadas: Node.js / Go backend API REST: 2-10 MB por conexión activa. Java/Spring: 15-30 MB por request en vuelo. Rails/Django: 50-120 MB por worker proceso. PHP-FPM clásico: 20-40 MB por worker. Para 5k concurrent en Node.js: 5000 × 6MB = 30 GB, reserva 48 GB (1.6× safety factor). Si tu app cachea en proceso o mantiene sesiones grandes, mide antes de asumir.
¿Cómo dimensionar servidores para el tráfico pico sin sobredimensionar?
Regla clásica: dimensiona para el pico del percentil 95 de tu distribución de tráfico histórica, no para el máximo absoluto (que puede ser un outlier). Luego añade 20-30% de headroom y N+1 redundancia (si usas 5 nodos sostenidos, despliega 6). Para tráfico estacional estable, esto basta. Para e-commerce con Black Friday o eventos, combina dimensionamiento base + autoescalado horizontal hasta 3× la base — sobredimensionar permanentemente cuesta 5-10× más que un autoscaler bien configurado.
¿Qué es capacity planning en Kubernetes?
Capacity planning en Kubernetes es el proceso de dimensionar requests y limits por pod, proyectar cuántos nodos y qué tipo de nodo se necesitan, y anticipar crecimiento de tráfico para mantener headroom ≥ 30% sobre utilización P95. Cubre rightsize, elección de instancias, estrategia de autoscaling (HPA, VPA, cluster autoscaler) y optimización de costo cloud (Reserved, Savings Plans, spot).
¿Cómo calcular requests y limits de un pod?
Mide el uso real de CPU y memoria P95 del contenedor en los últimos 7 días. Define request = P95. Define limit = request × 1.5 para CPU y request × 1.5-2.0 para memoria. Nunca pongas limit = request en memoria (cualquier spike dispara OOMKill). Herramientas como VPA en modo recommend, Kubecost, Datadog y Goldilocks automatizan la medición.
¿Cuántos nodos necesita mi cluster Kubernetes?
Suma los requests totales del cluster, multiplica por 1.3 como overhead (kube-system, daemonsets, CNI), divide entre la capacidad asignable por nodo (ej. m5.xlarge ~3.8 vCPU y ~14.5 GiB asignables), y agrega 20-30% de buffer para HPA, spikes y mantenimiento. Bottleneck real suele ser CPU o memoria, rara vez ambos.
¿Qué diferencia hay entre requests y limits?
Request es la reserva garantizada que el scheduler usa para colocar el pod en un nodo. Limit es el techo que el runtime enforza: si un contenedor supera el limit de CPU se le hace throttle (el contenedor sigue corriendo lento); si supera el limit de memoria se le hace OOMKill (el contenedor se reinicia). Request determina cuánto pagas; limit determina cómo se comporta bajo presión.
¿Cómo hacer rightsize de un cluster Kubernetes?
1) Mide P95 de uso por contenedor en 7-14 días. 2) Aplica VPA en modo recommend. 3) Ajusta requests al P95 y limits a 1.5× (CPU) o 1.5-2× (memoria). 4) Habilita cluster autoscaler o Karpenter para consolidar nodos sub-utilizados. 5) Migra workloads batch tolerantes a interrupción a spot. 6) Reserva capacidad estable con Reserved Instances o Savings Plans.
¿Qué es HPA y cuándo usarlo?
HPA (Horizontal Pod Autoscaler) escala el número de réplicas de un deployment basándose en CPU, memoria o métricas custom (RPS, queue length). Úsalo para workloads stateless con carga variable y SLO de latencia. Umbral típico 70% CPU. Para escalar por métricas de negocio (RPS, lag de cola) integra Prometheus Adapter o KEDA.
¿Cómo estimar el costo de un cluster en AWS/GCP/Azure?
Costo = (nodos × precio por nodo/hora × 730) + control plane (EKS ~73 USD/mes, GKE Autopilot by pod, AKS gratis) + tráfico saliente + almacenamiento EBS/PD + load balancer. Kubecost, OpenCost, Vantage y CloudHealth desglosan costo por workload. Optimización: 40-60% Reserved/Savings, 20-30% spot para batch, resto on-demand para spikes.
¿Qué pasa si mi pod excede el limit de memoria (OOMKill)?
El kernel cgroup v2 dispara un OOMKill: el contenedor se termina con exit code 137 y Kubernetes lo reinicia según la restart policy. Causas típicas: memory leak, carga legítima subestimada, cache sin eviction, JVM sin -Xmx alineado al limit. Diagnóstico: kubectl describe pod, eventos, métricas container_memory_working_set_bytes.
¿Cómo planificar capacidad para tráfico pico?
Modela el pico esperado con Little's Law (L = λ × W), dimensiona para P99 de concurrencia, configura HPA con umbral 60-70% y min replicas igual al baseline sostenido × 1.3. Para picos predecibles (Black Friday, lanzamientos) considera pre-warm con cronjob de escalado programado. Load test con k6 o Locust al 2× del peak esperado antes del evento real.

Continúa explorando

Herramientas del mismo cluster temático. Úsalas en conjunto para cerrar el análisis.

Última actualización: 17 de abril de 2026 · Contenido revisado por el equipo editorial de Simúlalo.

Capacity Planning Servidores: Clásico y Kubernetes | Simúlalo