¿Qué es el scalability testing? Prueba de escalabilidad
La prueba de escalabilidad mide cómo cambia el rendimiento al añadir recursos. Método, métricas clave, errores comunes y diferencia con la prueba de carga.
¿Qué es el scalability testing (prueba de escalabilidad)?
La prueba de escalabilidad mide cómo cambia el rendimiento de un sistema al añadir o quitar recursos: más pods, más nodos, instancias más grandes, más réplicas de base de datos. Su objetivo es saber si duplicar la infraestructura duplica aproximadamente el rendimiento (escalado lineal), o si la mejora se aplana (sublineal) o incluso se invierte por la sobrecarga de coordinación. Te dice qué compra realmente la capacidad extra.
Prueba de escalabilidad vs prueba de carga
Una prueba de carga mide el comportamiento con un tamaño de infraestructura fijo. Una prueba de escalabilidad repite la misma prueba de carga con varios tamaños y compara los resultados. Relacionada pero distinta, la prueba de capacidad pregunta cuánta carga aguanta una configuración antes de incumplir sus objetivos.
Ejemplo con cifras ilustrativas: con 1 nodo el sistema atiende 1.000 peticiones por segundo con una latencia p95 de 600 ms. Con 8 nodos, el escalado lineal daría 8.000 peticiones por segundo con la misma latencia. Si mides 6.000, el escalado es sublineal; si con 4.000 la latencia sube a 1.200 ms, la coordinación se come la mejora.
Escalado horizontal y vertical
- Horizontal: añadir instancias. Lanza la misma carga contra 1, 2, 4 y 8 instancias tras un balanceador.
- Vertical: dar más CPU, memoria o rendimiento de disco a una instancia. Lanza la misma carga contra tamaños pequeño, mediano y grande.
Las capas web sin estado suelen escalar bien en horizontal. Las bases de datos y otras piezas con estado suelen escalar primero en vertical y necesitar después réplicas o sharding, y son justo las que conviene probar.
Cómo hacer una prueba de escalabilidad
- Elegir una carga fija. Una mezcla de recorridos programada, un conjunto de datos y las mismas regiones de carga, de modo que la infraestructura sea la única variable.
- Elegir los puntos de escala. Por ejemplo 1, 2, 4 y 8 nodos, o tres tamaños de instancia.
- Llevar cada punto a régimen estable. Para cada tamaño, busca la mayor carga que aún cumple tus objetivos de tiempo de respuesta y errores.
- Dibujar la curva. Rendimiento, rendimiento por nodo y latencia p95 frente al tamaño.
- Buscar el cuello de botella donde la curva se dobla. Revisa conexiones de base de datos, bloqueos, cachés compartidas, red y balanceador.
Qué medir
- Factor de escalado: rendimiento con 2N entre rendimiento con N. Cerca de 2,0 es lineal.
- Rendimiento por nodo: debería mantenerse más o menos constante. Una caída indica sobrecarga.
- Latencia p95 por tamaño: debería mantenerse o mejorar, no subir.
- Coste por petición: el resultado práctico, porque una curva sublineal significa que cada nodo extra cuesta más por unidad de trabajo.
- Comportamiento del autoescalado: cuánto tardan en ayudar las instancias nuevas, algo que expone la prueba de picos.
Errores frecuentes
- Cambiar la prueba entre ejecuciones. Otro script, otras regiones u otro volumen de datos vuelven inútil la curva.
- Escalar solo la capa de aplicación. La base de datos o una caché compartida se convierte en el techo y la curva se aplana pronto.
- Empezar con el sistema frío. Calienta antes cachés y pools de conexiones, o el primer punto parecerá peor de lo que es.
- Límites del generador de carga. Si el generador se satura, mides el generador y no el sistema.
- Muy pocos puntos. Dos tamaños dan una proporción, pero no dónde se dobla la curva.
Herramientas y siguientes pasos
Los mismos scripts se ejecutan en cada punto de escala, así que sirve cualquier herramienta de pruebas de carga; lo habitual es JMeter y k6. LoadFocus ejecuta ambos desde 25 regiones en la nube, de modo que la generación de carga se mantiene constante en toda la serie. Para consejos según la arquitectura, consulta la guía de pruebas de carga de microservicios en la nube (más sobre microservicios) y el resumen de tipos de pruebas de rendimiento.
Preguntas frecuentes: scalability testing
¿Qué diferencia hay entre prueba de escalabilidad y prueba de carga?
La prueba de carga comprueba el rendimiento con un tamaño fijo. La de escalabilidad lanza una serie de pruebas de carga con tamaños distintos para ver cómo cambia el rendimiento con los recursos.
¿Qué es la escalabilidad lineal?
Que el rendimiento crece en proporción a los recursos: el doble de nodos, aproximadamente el doble de peticiones por segundo con la misma latencia.
Escalabilidad horizontal o vertical: ¿cuál pruebo?
La de la que dependa tu arquitectura. Muchos sistemas usan ambas: horizontal para servicios sin estado, vertical (y luego réplicas o sharding) para bases de datos.
¿La prueba de escalabilidad valida el autoescalado?
En parte. Muestra si la capacidad añadida sirve de algo. Para ver con qué rapidez reacciona el autoescalado, combínala con una prueba de picos y observa la latencia mientras arrancan las instancias nuevas.
¿Cuántos puntos de escala necesito?
Al menos tres o cuatro, por ejemplo 1, 2, 4 y 8 nodos, para ver la forma de la curva y no solo una proporción.
Términos relacionados
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus, la misma plataforma que potencia todo lo que acabas de leer.