Planificación de Capacidad

Overview

La planificación de capacidad asegura que tu infraestructura pueda manejar la demanda actual y futura sin desperdiciar recursos. Cierra la brecha entre la extinción de incendios reactiva y el escalado proactivo, ayudando a los equipos a entregar servicios confiables mientras controlan costos.

A continuación: el pronóstico de demanda, pruebas de carga, estrategias de escalado y decisiones de capacidad conscientes de costos para entornos cloud y on-premise.

When to Use

• For alternatives, see Blue-Green Deployment.

• Estás preparando un lanzamiento de producto, campaña de marketing o pico de tráfico estacional

• Tu servicio experimenta degradación de rendimiento recurrente durante horas pico

• Quieres reducir costos de infraestructura cloud sin impactar la confiabilidad

• Necesitas justificar presupuestos de infraestructura con proyecciones basadas en datos

• Estás migrando de on-premise a cloud y necesitas dimensionar correctamente los recursos

Core Concepts

Concepto	Descripción
Capacidad Actual	Rendimiento máximo que tu sistema puede manejar con recursos existentes
Margen	Buffer sobre el pico de uso para absorber picos inesperados (típicamente 20-30%)
Punto de Saturación	Nivel de utilización de recursos donde el rendimiento se degrada (usualmente >70% CPU, >80% memoria)
Tiempo de Escalado	Tiempo requerido para aprovisionar y desplegar capacidad adicional
Pronóstico de Demanda	Carga futura proyectada basada en tendencias históricas y eventos de negocio

Step-by-Step Capacity Planning Process

1. Medir la Línea Base Actual

Antes de planificar el crecimiento, entiende tu estado actual:

# Recopilar métricas durante un período representativo (2-4 semanas)
# Métricas clave: CPU, memoria, disco I/O, red, latencia de requests, tasa de errores

# Ejemplo: Consulta Prometheus para utilización de CPU
avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100

Métricas a rastrear:

• Métricas de recursos: CPU, memoria, disco, red
• Métricas de aplicación: Requests por segundo, percentiles de latencia (p50, p95, p99), tasas de error
• Métricas de negocio: Usuarios activos, transacciones por minuto, crecimiento de volumen de datos

2. Identificar Cuellos de Botella

Encuentra el primer recurso que se saturará bajo carga:

# Ejemplo: Analizar qué recurso alcanza límites primero
from dataclasses import dataclass

@dataclass
class ResourceLimit:
    name: str
    current_usage: float
    max_capacity: float
    saturation_threshold: float

    def headroom(self) -> float:
        return (self.saturation_threshold - self.current_usage) / self.saturation_threshold * 100

# Evaluar margen para cada recurso
resources = [
    ResourceLimit("CPU", 45, 100, 70),
    ResourceLimit("Memory", 60, 100, 80),
    ResourceLimit("Disk IOPS", 75, 100, 85),
    ResourceLimit("Network", 30, 100, 70),
]

bottleneck = min(resources, key=lambda r: r.headroom())
print(f"Cuello de botella: {bottleneck.name} con {bottleneck.headroom():.1f}% de margen")

3. Pronosticar Demanda

Usa datos históricos más contexto de negocio para proyectar carga futura:

Técnicas:

• Extrapolación de tendencias: Extender curvas de crecimiento históricas
• Ajuste estacional: Considerar patrones semanales, mensuales o anuales
• Pronóstico basado en eventos: Factorizar eventos de tráfico conocidos (lanzamientos, campañas)
• Correlación de negocio: Vincular capacidad a métricas de negocio (nuevos clientes, ingresos)

# Ejemplo: Pronóstico de demanda con margen
peak_qps_current: 5000
weekly_growth_rate: 0.05  # 5% por semana
headroom_percent: 0.30    # 30% de buffer

# Pronóstico para 3 meses (13 semanas)
peak_qps_forecast: 5000 * (1.05 ** 13) ≈ 9440
required_capacity: 9440 * 1.30 ≈ 12272 QPS

4. Pruebas de Carga para Validar

Verifica tus suposiciones con pruebas de carga controladas:

# Ejemplo: Script de prueba de carga k6
# capacity-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
  stages: [
    { duration: '5m', target: 100 },   # Aumento gradual
    { duration: '10m', target: 100 },  # Estado estable
    { duration: '5m', target: 200 },   # Prueba de estrés
    { duration: '5m', target: 0 },    # Reducción gradual
  ],
  thresholds: {
    http_req_duration: ['p(95)<200'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function() {
  let res = http.get('https://api.example.com/health');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

5. Elegir Estrategia de Escalado

Estrategia	Cuándo Usar	Pros	Contras
Escalado vertical	Crecimiento predecible y estable; cargas de trabajo de base de datos	Simple, sin cambios de código	Límite duro, riesgo de downtime, caro
Escalado horizontal	Tráfico variable y con picos; servicios sin estado	Elástico, tolerante a fallos	Complejidad agregada, consistencia de datos
Auto-escalado	Demanda impredecible o cíclica	Eficiente en costos, sin intervención	Latencia de inicio en frío, complejidad de configuración
Capacidad reservada	Carga base predecible	Ahorros significativos	Menos flexible, compromiso anticipado

6. Planificar el Margen

Mantén siempre capacidad de buffer para eventos inesperados:

• Margen mínimo: 20% sobre el pico esperado
• Servicios críticos: 30-40% de margen
• Entornos con restricciones de costos: 15% con triggers de escalado más rápidos
• Negocios estacionales: Planificar margen alrededor de picos estacionales conocidos

7. Documentar y Revisar

Crea un documento de plan de capacidad que incluya:

• Métricas de línea base y cuellos de botella actuales
• Pronóstico de demanda con suposiciones
• Estrategia de escalado y triggers
• Proyecciones de costos
• Calendario de revisión (mensual o trimestral)

Lo que funciona

• Empieza con datos, no con suposiciones. Recopila al menos 2 semanas de métricas de producción antes de pronosticar.
• Prueba a escala. Prueba de carga a 2-3x el pico esperado para entender modos de falla.
• Dimensiona continuamente. Revisa tipos de instancia y capacidad reservada trimestralmente.
• Correlaciona con eventos de negocio. Vincula capacidad a lanzamientos de producto, marketing y estacionalidad.
• Automatiza el monitoreo. Configura alertas cuando la utilización cruza umbrales de revisión (ej. 60% sostenido).
• Planifica para degradación. Define estrategias de degradación elegante cuando se excede la capacidad.

Common Mistakes

• Planificar para promedios en lugar de picos. La carga promedio oculta comportamiento de ráfagas.
• Ignorar el tiempo de escalado. Si toma 10 minutos escalar, planifica para el tráfico 10 minutos antes.
• Sobreaprovisionar “por si acaso.” El exceso de capacidad es dinero desperdiciado; usa auto-escalado para cargas variables.
• Olvidar dependencias posteriores. Escalar frontend sin escalar la base de datos crea nuevos cuellos de botella.
• No volver a probar después de cambios. Los cambios de arquitectura invalidan suposiciones de capacidad previas.

Variants

• Planificación de capacidad cloud-native: Usar auto-escalado administrado, instancias spot y serverless para cargas de trabajo elásticas.
• Planificación de capacidad on-premise: Enfocarse en ciclos de adquisición de hardware, densidad de virtualización y restricciones de energía/refrigeración.
• Planificación de capacidad de base de datos: Monitorear rendimiento de consultas, límites de conexión, crecimiento de almacenamiento y retraso de replicación.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Conclusion

La planificación de capacidad es una práctica continua, no un ejercicio de una sola vez. Mide, pronostica, prueba y revisa regularmente para mantener tu infraestructura alineada con el crecimiento del negocio mientras controlas costos.

Temas Avanzados

Escenario: Planificacion de Capacidad para SaaS

Sistema: SaaS, 10K usuarios activos, crecimiento 15% mensual
Objetivo: Planear infraestructura para 6 meses

Datos actuales:
  | Metrica | Actual | Crecimiento | Proyeccion 6m |
  |---------|--------|-------------|---------------|
  | Usuarios activos | 10K | 15% mes | 23K |
  | Requests/min | 50K | 15% mes | 115K |
  | CPU promedio | 45% | 15% mes | 85% |
  | Memoria | 60% | 10% mes | 95% |
  | Storage | 500GB | 20% mes | 1.5TB |
  | Bandwidth | 200GB/mes | 15% mes | 460GB/mes |

Capacidad actual vs proyectada:
  | Recurso | Capacidad actual | Uso actual | Uso proyectado | Accion |
  |---------|-----------------|-----------|----------------|--------|
  | CPU (8 cores) | 8 cores | 3.6 cores | 6.8 cores | Agregar 4 cores mes 4 |
  | Memoria (32GB) | 32GB | 19.2GB | 30.4GB | Agregar 16GB mes 3 |
  | Storage (1TB) | 1TB | 500GB | 1.5TB | Agregar 2TB mes 2 |
  | Bandwidth | 1TB/mes | 200GB | 460GB | OK hasta mes 6 |
  | DB connections | 200 | 80 | 184 | Agregar pool mes 5 |

Plan de accion:
  | Mes | Accion | Costo estimado |
  |-----|--------|---------------|
  | 1-2 | Storage +2TB | $100/mes |
  | 3 | Memoria +16GB | $80/mes |
  | 4 | CPU +4 cores | $150/mes |
  | 5 | DB pool +100 connections | $0 (config) |
  | 6 | Evaluar cluster upgrade | $500/mes |

Strategias de scaling:
  - Vertical: mas CPU/RAM en nodo existente (simple, downtime)
  - Horizontal: mas nodos (complejo, sin downtime)
  - Auto-scaling: HPA en K8s, auto-scaling groups en cloud
  - Read replicas: para DB read-heavy
  - Caching: Redis para reducir carga de DB

Metricas para monitorear:
  - CPU utilization > 70% por 10 min -> escalar
  - Memory utilization > 80% -> escalar
  - Disk usage > 75% -> expandir
  - DB connection pool > 80% -> aumentar pool
  - Response time p99 > 500ms -> investigar

Lecciones:
  - Planifica con datos, no con suposiciones
  - El crecimiento compuesto es enganoso (15% mes = 2.3x en 6m)
  - El storage crece mas rapido que CPU/memoria
  - Auto-scaling absorbe picos, no crecimiento sostenido
  - Revisa el plan mensualmente, no semestralmente

Como calculo el crecimiento compuesto?

Usa la formula: F = P * (1 + r)^n, donde P es el valor actual, r es la tasa de crecimiento mensual, y n es el numero de meses. Ejemplo: 10K usuarios, 15% mensual, 6 meses: 10000 * (1.15)^6 = 23,133 usuarios. Siempre redondea hacia arriba y anade un 20% de buffer para imprevistos.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica planificación de capacidad cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.