¿Qué es scalability testing?

¿Qué es scalability testing?

Scalability testing mide cómo cambia el rendimiento de un sistema al añadir recursos: más pods, más nodes, instancias más grandes, más réplicas de base de datos. El objetivo es validar que añadir 2× infraestructura produce cerca de 2× throughput (escalado lineal), no 1,2× (sub-lineal, escalado caro) o 0,5× (escalado negativo por overhead de coordinación).

Scalability testing vs load testing

Un load test mide rendimiento a un tamaño fijo de infraestructura. Scalability testing mide rendimiento a través de múltiples tamaños de infraestructura:

• Load test a 1.000 RPS en 1 node → p95 latency 600 ms.
• Scalability test a través de 1, 2, 4, 8 nodes → ¿manejan 8 nodes 8.000 RPS a 600 ms (lineal), 6.000 RPS a 600 ms (sub-lineal) o 4.000 RPS a 1.200 ms (overhead de coordinación domina)?

El scalability test no es un solo run. Es una serie de load tests a capacidad creciente, con los datos graficados para mostrar la curva de escalado.

Escalabilidad horizontal vs vertical

• Escalabilidad horizontal: añadir más nodes / pods / containers. Test ejecutando la misma carga contra 1, 2, 4, 8, 16 instancias.
• Escalabilidad vertical: aumentar los recursos de un node (CPU, memoria, disk IOPS). Test ejecutando la misma carga contra instancias small, medium, large, xlarge.

La mayoría de sistemas modernos deberían escalar horizontalmente de forma limpia. Los sistemas stateful (especialmente bases de datos) suelen escalar verticalmente hasta que tocan límites de hardware, luego necesitan sharding o read-replicas para más scale.

Cuándo ejecutar scalability tests

• Antes de comprometer presupuesto de infraestructura. Si necesitas 10.000 RPS y cada node maneja 1.000, ¿necesitas 10 nodes o 15? Scalability testing te dice el ratio real.
• Validar autoscaling. Autoscaling asume que añadir pods añade capacidad proporcional. Scalability testing confirma (o encuentra el overhead de coordinación que rompe la suposición).
• Pre-cambio-arquitectura. ¿Migrando de monolito a microservicios? Las características de scaling de la nueva arquitectura son desconocidas hasta testear.
• Validación de scaling de BD. ¿Añadir read replicas, sharding o ir a un managed scaling service? Validar que la nueva topología escala como anunciado.
• Evaluación de vendor. ¿Comparando Aurora vs RDS vs DynamoDB? Ejecuta el mismo workload contra cada uno a scale creciente y compara.

Métricas clave de scalability test

1. Factor de escalado. Throughput a 2N nodes / throughput a N nodes. Debería ser ~2,0 para escalado lineal.
2. Throughput por node. Throughput a scale dividido por número de nodes. Debe mantenerse constante; si baja, estás golpeando overhead de coordinación.
3. Latencia por node. Latencia a scale vs latencia en single-node. Debe mantenerse constante o mejorar; si sube, la coordinación es cara.
4. Desglose de overhead de coordinación. ¿Dónde va el tiempo al crecer scale? ¿Llamadas cross-node de red? ¿Distributed locks? ¿Protocolos de consenso? Identificar la fuente de overhead te dice qué arreglar.

Cómo ejecutar un scalability test

La mecánica: ejecuta el mismo load test contra el sistema a múltiples tamaños de infraestructura. Plotea throughput, throughput por node y p95 latency a través de los tamaños.

En JMeter o k6, el script se mantiene idéntico entre runs. Cambia solo la infraestructura (escala el deployment, cambia la clase de instancia, añade read replicas). El load test entonces mide el rendimiento resultante.

Ejecuta desde LoadFocus para generación consistente de carga a través de la serie de tests. Usar las mismas regiones y el mismo VU count asegura que la única variable es tu infraestructura, no el test harness.

Para scalability tests que informan planificación de infraestructura plurianual, LoadFocus ofrece load testing services donde los ingenieros diseñan los puntos de scale, ejecutan la serie de tests y producen el análisis de curva de escalado con implicaciones de coste-por-RPS.