8 núcleos de CPU, un servidor FHIR. ¿Asignar todos los núcleos a una única instancia de Aidbox o distribuirlos entre varias? Hemos realizado pruebas comparativas de ambos enfoques: escalado vertical (más núcleos por instancia) y escalado horizontal (más instancias con menos núcleos).
En nuestro artículo anterior «Game of Pools», demostramos que Aidbox escala de forma casi lineal a medida que se añaden núcleos de CPU. Sin embargo, el crecimiento vertical lineal es solo la mitad de la historia. ¿Qué ocurre cuando se distribuyen esos mismos núcleos entre múltiples instancias?
Cómo Funciona Aidbox en un Clúster
Aidbox hace un uso intensivo de cachés: motor de validación, enrutamiento, suscripciones y más. Con el escalado horizontal, el principal reto consiste en mantener estas cachés sincronizadas entre instancias. La solución habitual es un servicio externo como Redis.
Aidbox adopta un enfoque diferente: no requiere caché externa. La sincronización entre instancias funciona a través del mecanismo LISTEN/NOTIFY de PostgreSQL: cuando una instancia actualiza datos, las demás reciben una notificación e invalidan su caché. PostgreSQL, que ya es necesario para el funcionamiento, actúa también como bus de eventos. No se necesita infraestructura adicional.
Si su instancia es completamente estática (no crea recursos del sistema en tiempo de ejecución), puede desactivar la sincronización de caché por completo. Esto proporciona una pequeña mejora de rendimiento al eliminar la sobrecarga de LISTEN/NOTIFY.
Configuración de las Pruebas
Todas las pruebas se ejecutaron en una única máquina. Las instancias de Aidbox se sitúan detrás de nginx (least_conn). Base de datos: una única instancia de PostgreSQL 18. La carga fue generada por k6 (5 minutos, escenario CRUD con 9 tipos de recursos FHIR). Antes de cada ejecución: calentamiento de 30 segundos + enfriamiento de 60 segundos. El número de VU escala proporcionalmente a los núcleos de CPU (37 VU por núcleo, 300 VU para 8 núcleos) para mantener la latencia comparable entre configuraciones.
Escalado Vertical: Una Instancia con 1, 2, 4 y 8 Núcleos
Antes de distribuir los núcleos entre instancias, conviene establecer una línea base: cómo escala Aidbox verticalmente cuando todos los núcleos se asignan a una única instancia:
| CPUs | VUs | RPS | P95 ms | Multiplicador |
|---|---|---|---|---|
| 1 | 37 | 813 | 88,1 | 1,0 X |
| 2 | 75 | 1617 | 76,3 | 2,0 X |
| 4 | 150 | 3176 | 73,3 | 3,9 X |
| 8 | 300 | 5645 | 78,3 | 7,0 X |
Doblar los núcleos de CPU duplica el RPS. La latencia se mantiene estable (media de 70–90 ms) porque la carga crece proporcionalmente a la capacidad. Con 8 núcleos, el multiplicador es 7,0× en lugar del ideal de 8×: las pérdidas se deben a la contención de recursos compartidos (memoria, GC, PostgreSQL, red). Un resultado sólido: el escalado vertical de Aidbox es predecible y eficiente.
Escalado Horizontal: Distribución de 8 Núcleos entre Instancias
El experimento clave. Se toman los mismos 8 núcleos y se distribuyen de forma diferente:
| Instancias | CPUs | RPS | Avg ms | P95 ms | P99 ms |
|---|---|---|---|---|---|
| 8 | 1 | 3926 | 76,1 | 125,7 | 197,3 |
| 4 | 2 | 5004 | 59,7 | 80,5 | 98,5 |
| 2 | 4 | 5412 | 55,2 | 73,9 | 80,5 |
| 1 | 8 | 5747 | 52,0 | 75,9 | 87,4 |
Eficiencia del Escalado Horizontal
La degradación es gradual hasta 4×2 y brusca en 8×1:
- 1×8 → 2×4: −5,8% (5747 → 5412)
- 2×4 → 4×2: −7,5% (5412 → 5004)
- 4×2 → 8×1: −21,5% (5004 → 3926)
- 1×8 → 8×1: −31,7% en total
La columna «Eficiencia» muestra qué fracción del máximo teórico (8 × 813 = 6.500 RPS) alcanza cada configuración, ordenadas por eficiencia:
| Estrategia | Config | RPS | P99 ms | Eficiencia |
|---|---|---|---|---|
| Horizontal | 1×8 CPU | 5747 | 87,4 | 88,4% |
| Horizontal | 2×4 CPU | 5412 | 80,5 | 83,2% |
| Horizontal | 4×2 CPU | 5004 | 98,5 | 76,9% |
| Horizontal | 8×1 CPU | 3926 | 197,3 | 60,4% |
Uso de Memoria
El escalado horizontal tiene un coste oculto: cada instancia de JVM conlleva su propia sobrecarga de memoria. Ocho instancias de un solo núcleo consumen significativamente más RAM que una instancia de ocho núcleos. Con el encarecimiento del hardware (impulsado por el auge de la IA), esto puede aumentar de forma notable el coste de ejecución de Aidbox.
| Config | Media (GB) | Máx. (GB) |
|---|---|---|
| 8×1 CPU | 5,5 | 10,4 |
| 4×2 CPU | 3,0 | 5,6 |
| 2×4 CPU | 1,6 | 2,6 |
| 1×8 CPU | 1,1 | 2,1 |
- Pasar de 1×8 a 2×4 añade solo +0,5 GB de media, pero 8×1 requiere aproximadamente 5× más memoria tanto en media como en pico.
- Conclusión práctica: 2×4 suele ser el punto óptimo entre tolerancia a fallos y presupuesto de RAM, mientras que 8×1 solo tiene sentido bajo requisitos de aislamiento muy específicos.
Conclusiones Principales
- El escalado vertical gana en RPS bruto. Una única instancia con 8 núcleos aprovecha al máximo el hardware. La distribución horizontal siempre implica una sobrecarga.
- El escalado horizontal resulta rentable cuando se necesita tolerancia a fallos. 2×4 pierde solo un 6% de RPS respecto a 1×8, pero ofrece redundancia y el mejor P99 (80,5 ms frente a 87–90 ms). Si una instancia cae, la otra sigue atendiendo las solicitudes.
- El punto de inflexión está en 2 CPU por instancia. Las configuraciones con 2 o más CPU (2×4, 4×2) mantienen una eficiencia del 79–85%. Por debajo de 2 CPU, la sobrecarga de la JVM se vuelve crítica: 8×1 pierde ~40% de eficiencia y presenta el peor P99 de todas las configuraciones.
- El coste del aislamiento. El RPS total de una configuración horizontal siempre es inferior al del escalado vertical con el mismo número de núcleos. Cada JVM lleva su propia sobrecarga: inicio de caché, GC, red y consumo base de memoria. Cuanto más pequeñas son las instancias, mayor es la proporción de sobrecarga en el presupuesto total de recursos.
Nuestra recomendación: no fragmente en exceso. Si dispone de 8 núcleos, la configuración 2×4 es el punto óptimo: se obtiene alta disponibilidad con mínimas concesiones, pérdida de rendimiento mínima y sobrecarga de memoria mínima. Bajar de 2 CPU por instancia no merece la pena: la sobrecarga de la JVM consume rápidamente el presupuesto de rendimiento.
Próximos Pasos
En el próximo artículo, saldremos del banco de pruebas y veremos cómo se comporta Aidbox en un entorno de producción real. También calcularemos el coste real de ejecutar Aidbox en la nube.
Véase también: Health Samurai Lab: Game of Pools.
