El patrón del “desastre del éxito”

El momento más peligroso para una startup no es el fracaso. Es Éxito. Imagina este escenario: Lanzas una nueva campaña de marketing. O apareces en TechCrunch. O un influencer con 5 millones de seguidores publica sobre tu producto. El tráfico aumenta 100 veces durante la noche. Estás listo para ganar millones. Y luego… el sitio se carga en blanco. 504 Tiempo de espera de puerta de enlace. Servicio 503 no disponible. La CPU de su base de datos alcanza el 100%. Su grupo de conexiones está agotado. Los usuarios actualizan la página y agregan más carga. El sistema entra en una espiral de muerte. Entras en pánico. Intenta actualizar la base de datos en AWS, pero la solicitud tarda 30 minutos. Cuando el sitio vuelve a funcionar, el tráfico desaparece. Los usuarios están enojados. La reputación está dañada.

Este es un desastre de éxito. Tuviste éxito en Marketing, pero fracasaste en Ingeniería. Las pruebas de carga obligan a que este escenario suceda en un entorno controlado, días o semanas antes del evento real. Simulamos el accidente. Encontramos el cuello de botella. Lo arreglamos. Repetimos.

Por qué Maison Code analiza esto

En Maison Code nos especializamos en comercio electrónico de “Alta Presión”. Nuestros clientes no son los típicos blogs. Son marcas que lanzan zapatillas de edición limitada a las 10:00 a.m. Pasan de 0 visitantes a 50.000 visitantes en 3 segundos. Hemos aprendido por experiencia que **La escalabilidad no es mágica; son matemáticas **. Si no ha probado su sistema a 10 veces su carga esperada, no tiene un sistema robusto; tienes una oración. Escribimos sobre esto porque queremos salvar a los fundadores de la angustia de ver cómo su “Gran Momento” se convierte en un apagón público.

La herramienta: k6 (Grafana)

Durante mucho tiempo, el estándar fue JMeter. Fue poderoso pero doloroso (GUI basada en XML). Entonces Locust (Python) se hizo popular. Pero hoy en día, el estándar de la industria es k6. ¿Por qué k6?

JavaScript: las pruebas están escritas en JS/TS. Los desarrolladores se sienten cómodos con eso.
Rendimiento: el motor está escrito en Go. Una computadora portátil puede simular 30.000 usuarios simultáneos.
CI/CD: se ejecuta fácilmente en una canalización de GitHub Actions.
Métricas: se integra de forma nativa con Grafana/InfluxDB para una hermosa visualización en tiempo real.

Implementación: escribir un script k6

Veamos un script de prueba de carga robusto.

importar http desde 'k6/http';
importar {dormir, verificar} desde 'k6';

// Configuración: el perfil de carga
exportar opciones constantes = {
  etapas: [
    {duración: '30s', objetivo: 20 }, // Aumentar hasta 20 usuarios (calentamiento)
    {duración: '1m', objetivo: 50 }, // Aumentar hasta 50 usuarios (Cargar)
    {duración: '2m', objetivo: 50 }, // Permanecer en 50 usuarios (Mantener)
    {duración: '30s', objetivo: 100 }, // Aumento a 100 usuarios (estrés)
    {duración: '30s', objetivo: 0 }, // Desaceleración (enfriamiento)
  ],
  umbrales: {
    // Condiciones de falla
    http_req_failed: ['rate<0.01'], // La tasa de error debe ser <1%
    http_req_duration: ['p95<500'], // el 95% de las solicitudes deben ser < 500 ms
  },
};

exportar función predeterminada () {
  const BASE_URL = 'https://staging.maisoncode.paris';
  
  // 1. Visita la página de inicio
  const resHome = http.get(BASE_URL);
  comprobar(resHome, { 
    'Estado de inicio 200': (r) => r.status === 200,
    'Casa rápido': (r) => r.timings.duration < 200, 
  });
  
  dormir(1); // El usuario piensa...

  // 2. Búsqueda de producto (CPU intensivo)
  const resSearch = http.get(`${BASE_URL}/api/search?q=camisa`);
  comprobar(resBuscar, { 
    'Estado de búsqueda 200': (r) => r.status === 200 
  });

  dormir(2);
}

Los 4 tipos de pruebas de rendimiento

Comprenda la diferencia o probará algo incorrecto.

Prueba de humo:
- Objetivo: Garantizar que el sistema maneje una carga mínima.
- Carga: 1-5 Usuarios Virtuales (VU).
- Cuándo: Después de cada implementación. “¿Rompimos el servidor por completo?”
Prueba de carga:
- Objetivo: Verificar que el sistema maneje el tráfico esperado.
- Carga: el tráfico promedio de su sitio de producción (por ejemplo, 50 VU).
- Cuándo: Antes de lanzamientos menores.
Prueba de estrés:
- Objetivo: encontrar el punto de ruptura.
- Cargar: aumenta infinitamente hasta que el sistema falla.
- Resultado: “Podemos manejar 2500 usuarios. En 2501, la base de datos falla”.
- Cuándo: Antes de cambios arquitectónicos importantes.
Prueba de remojo:
- Objetivo: encontrar pérdidas de memoria.
- Carga: Carga moderada (80 % de la capacidad) durante 24 horas.
- Resultado: “Ah, el uso de memoria aumenta un 1 % cada hora. Tenemos una fuga”.

Identificar cuellos de botella

Encontraste el punto de ruptura. Ahora pregúntate ¿Por qué? El “por qué” rara vez es el código en sí. Suele ser la infraestructura.

La base de datos (el sospechoso habitual):
- Agotamiento de la conexión: “FATAL: las ranuras de conexión restantes están reservadas para roles de superusuario que no son de replicación”.
  - Solución: Agrupación de conexiones (PgBouncer).
- Saturación de CPU: consultas complejas que realizan escaneos completos de tablas.
  - Solución: Indexación. Leer réplicas. Utilice Redis para almacenar en caché consultas comunes.
Puentes (API):
- Su sitio es rápido, pero llama a la API de envío para calcular las tarifas.
- La API de envío se agota bajo carga.
- Tus solicitudes hacen cola esperando la API de envío.
- Tu servidor se queda sin RAM.
- Solución: Tiempos de espera. Disyuntores.
El bucle de eventos (Node.js):
- El nodo es de un solo subproceso. Si realiza muchos cálculos de CPU (cifrado, cambio de tamaño de imagen) en el hilo principal, bloquea a todos los usuarios.
- Solución: Descarga a subprocesos de trabajo o funciones sin servidor.

La semántica de los percentiles (p95, p99)

Nunca juzgues el desempeño por el Promedio. Los promedios ocultan mentiras.

Usuario A: 100 ms
Usuario B: 100 ms
Usuario C: 10.000 ms (10 segundos)
Promedio: ~3,4 s. (Se ve bien).
p99: 10s. (Espantoso).

p95 (percentil 95) significa: “Ignora los valores atípicos del 5% más lentos. ¿Cuál es la velocidad para todos los demás?” p99 (percentil 99) significa: “La experiencia del 1% de las solicitudes más lentas”.

Por qué es importante p99: En el comercio electrónico, las “solicitudes más lentas” suelen ser las de los usuarios con los carritos más grandes. Usuario con 1 artículo -> Consulta rápida. Usuario con 50 elementos -> Consulta lenta. El usuario de p99 es su Cliente de alto valor. Si ignora p99, está optimizando para los compradores de escaparates e ignorando a las ballenas.

¿Pruebas en producción?

PELIGRO. Realizar una prueba de estrés en producción es arriesgado.

Estás arruinando Analytics: Google Analytics mostrará 10,000 visitas de “bots”, arruinando tus datos de marketing.
Usted genera costos: si usa Serverless/Vercel, pagará por las 10 millones de solicitudes que acaba de enviar como spam.
Alertas de fraude: Stripe podría prohibirte por patrones de ataque de “Prueba de tarjetas”.

La regla de oro: utilice un entorno de preparación de paridad de datos. La preparación debe ser idéntica a Prod (mismo tamaño de instancia de AWS, mismo tamaño de base de datos). Si Staging es un pequeño t2.micro y Prod es un enorme m5.large, los resultados de su prueba no tienen sentido.

14. Ingeniería del caos (romper cosas a propósito)

Desenchufe el cable de la base de datos. ¿Lo que sucede? ¿El sitio falla? ¿O muestra una versión en caché? Usamos Chaos Mesh o scripts genéricos Pumba para eliminar contenedores aleatoriamente durante la prueba de carga. Si 1 réplica muere, el Load Balancer debería redireccionarse instantáneamente. Si Redis Cache muere, la base de datos debería asumir la carga (o incendiarse). Saber esto antes de las 9 a.m. del día del lanzamiento no tiene precio.

15. Pruebas de carga basadas en navegador (navegador k6)

Las pruebas de protocolo (HTTP) no representan JavaScript. No detectan “Errores de hidratación” ni “Reaccionar retraso en el procesamiento”. El navegador k6 activa instancias reales de Chrome sin cabeza. Mide CLS (cambio de diseño acumulativo) y FID (retraso de la primera entrada) bajo carga. “El servidor es rápido (API de 200 ms), pero el Cliente es lento (ejecución de JS de 3 segundos) porque enviamos 5 MB de JSON”. Sólo las pruebas del navegador revelan esto.

16. Automatización de pruebas de carga en CI/CD (Acciones de GitHub)

No ejecute k6 desde su computadora portátil. Ejecútelo en cada solicitud de extracción. Agregamos un flujo de trabajo load-test.yml.

Implemente la rama en la URL provisional.
Ejecute k6 run smoke-test.js (compruebe si hay 500).
Si falla, bloquee la fusión. Esto evita “regresiones de rendimiento”. “El desarrollador junior agregó un bucle de consulta N+1. La prueba lo detectó porque la latencia pasó de 200 ms a 2000 ms”.

17. Pruebas de picos versus pruebas de remojo

Conozca la diferencia. Prueba de picos:

Simula un “Sneaker Drop” o un “Anuncio del Super Bowl”.
0 -> 10.000 usuarios en 10 segundos.
Objetivo: probar los activadores de escalado automático (¿los servidores AWS giran lo suficientemente rápido?). Prueba de remojo:
Simula “Fin de semana de Black Friday”.
Carga alta durante 48 horas.
Objetivo: Probar fugas de recursos (memoria, espacio en disco, descriptores de archivos). Necesitas ambos.

18. Conclusión

El rendimiento no es algo “agradable tenerlo”. Es una característica. La escalabilidad no es mágica. Es ingeniería. Las pruebas de carga son la disciplina de validar su ingeniería. No esperes al apagón. Rompe la bombilla tú mismo, mientras tienes una de repuesto en el bolsillo.

¿Preparándote para el Black Friday?

No espere hasta noviembre. Maison Code ofrece servicios de “Pruebas de estrés de infraestructura”. Simulamos picos de tráfico 100 veces mayores, identificamos sus cuellos de botella e implementamos políticas de Auto-Scaling que funcionan.

¿Espera mucho tráfico?

Realizamos pruebas de carga y estrés utilizando k6 para validar la capacidad de la infraestructura y verificar las políticas de Auto-Scaling. Contrata a nuestros Arquitectos.