Extensión dinámica del GRID a la nube
Un gran grupo financiero español necesitaba absorber los picos de cálculo de riesgo de su Sala de Tesorería sin ampliar hardware. Extendimos su GRID a la nube con autoescalado transparente: −35 % en tiempos de ejecución, +200 % de capacidad y −20 % de coste mensual de cómputo.
Reto
Infraestructura on-premise saturada en los picos diarios de cálculo de riesgo (exigencias de Basilea y del Banco de España). Escalar por medios tradicionales era lento y costoso y, en periodos de baja ocupación, la plataforma quedaba sobredimensionada.
Solución
Grupos de autoescalado que crean y destruyen nodos cloud según la carga detectada por los gestores de cálculo, integrados de forma transparente en el clúster GRID existente: primero se usan los recursos internos y, si no bastan, se activan nodos en la nube que se apagan al terminar.
Tecnologías
- HPC / Grid Computing
- Cloud bursting con Auto Scaling Groups
- Arquitectura híbrida on-premise + cloud
- Automatización del ciclo de vida de los nodos
Contexto
La Sala de Tesorería de un gran grupo financiero español ejecuta cálculos de riesgo cada vez más complejos y frecuentes, en respuesta a exigencias regulatorias como las de Basilea o las del Banco de España. Esos cálculos corren sobre un sistema GRID corporativo que reparte las tareas entre miles de núcleos on-premise.
El problema no era la falta de tecnología, sino una infraestructura que no escalaba bajo presión: los picos diarios saturaban la capacidad disponible y, fuera de ellos, la plataforma quedaba sobredimensionada. La organización necesitaba una solución flexible, escalable y compatible con el GRID ya implantado, sin sustituirlo.
El reto
Cuatro fricciones concentraban el coste, el plazo y el riesgo regulatorio:
- Sobrecarga en momentos críticos: los picos de cálculo diario, especialmente desde Tesorería, saturaban la infraestructura disponible.
- Escalado lento y costoso: ampliar hardware no era una solución viable a corto plazo ni eficiente a largo.
- Baja eficiencia operativa: en periodos de baja carga la infraestructura estaba sobredimensionada, con un coste poco optimizado.
- Dependencia del entorno local: la arquitectura GRID existente limitaba la adopción de soluciones más flexibles sin una integración adecuada.
Enfoque por fases
El proyecto se ejecutó en cinco fases, asegurando una adopción progresiva, controlada y alineada con los requisitos operativos del banco.
-
01
PoC y arquitectura híbrida
Validación técnica inicial y diseño de una arquitectura compatible con el GRID existente y con la nube.
-
02
Definición del autoescalado
Establecimiento de las métricas de carga que activan nodos según la demanda real de los gestores de cálculo.
-
03
Integración y testing
Validación del funcionamiento de los nodos cloud como parte transparente del clúster de cómputo.
-
04
Automatización y monitorización
Orquestación completa del ciclo de vida de los nodos y supervisión continua con alertas preventivas.
-
05
Cargas reales y ajustes
Ejecución de cargas productivas y ajuste fino de las políticas de escalado.
Arquitectura y estrategia
La clave fue extender, no reemplazar. Se configuraron grupos de autoescalado (Auto Scaling Groups) que crean y destruyen nodos cloud automáticamente en función de la carga detectada por los gestores de cálculo. Esos nodos se integran en el clúster de cómputo del banco, de modo que los procesos de riesgo y tesorería los utilizan como si fueran parte del entorno on-premise.
El flujo es simple: las tareas de cálculo se gestionan desde el sistema central GRID; primero se usan los núcleos fijos internos, que funcionan siempre; si resultan insuficientes, se activan automáticamente núcleos adicionales en la nube; cuando las tareas terminan, esos nodos se apagan solos. Compatibilidad total con la infraestructura existente, escalabilidad adaptada a la carga real, automatización del ciclo de vida de los recursos cloud y monitorización continua con capacidad de reacción inmediata.
Resultados medibles
La arquitectura híbrida transformó un cuello de botella operativo en una ventaja competitiva: no solo resolvió el problema de carga, sino que mejoró el rendimiento de los sistemas de riesgo y tesorería.
| Indicador | Antes | Después |
|---|---|---|
| Tiempo total de ejecución de las cargas de riesgo | Ventanas saturadas en picos | −35 % |
| Capacidad de cómputo | Limitada al hardware on-premise | +200 % sin inversión física |
| Coste operativo mensual de cómputo | Sobredimensionamiento permanente | −20 % de media (pay-per-use) |
| Escalabilidad validada | Ampliación manual de hardware | +1.500 núcleos simultáneos |
Cifras agregadas y anonimizadas por acuerdo de confidencialidad. Fuente: proyectos de Vermont Solutions.
Lecciones aplicables
- Extender antes que reemplazar: se obtienen las ventajas del cloud sin disrupción ni riesgo para la operativa de Tesorería.
- Autoescalar por demanda elimina el sobredimensionamiento y convierte el coste fijo en variable.
- La integración transparente en el clúster evita cambiar los procesos de negocio: para el gestor de cálculo, un nodo cloud es un nodo más.
- La monitorización continua con alertas preventivas es lo que permite confiar en el escalado automático en un entorno regulado.
Marco regulatorio
El cálculo de riesgo de una entidad bancaria está sujeto a plazos y a exigencias del supervisor; la capacidad de cómputo es, por tanto, un requisito de cumplimiento y no solo de eficiencia.
- Basilea III/IV y los requerimientos del Banco de España: cálculos de capital y riesgo más frecuentes y exigentes.
- DORA (Art. 28): la extensión a la nube se diseña como riesgo de tercero tecnológico, con control del proveedor y resiliencia operativa digital.
- NIS2: seguridad de redes y sistemas en un sector esencial; enrutamiento seguro entre el CPD y la nube (balanceadores, VPN, reglas de failover).
Preguntas frecuentes
¿Hubo que modificar los procesos de riesgo o tesorería para usar la nube?
No. Los nodos cloud se integran en el clúster GRID existente y los gestores de cálculo los tratan como núcleos propios. Los procesos de negocio no cambian; cambia la capacidad disponible detrás.
¿Qué ocurre con el coste cuando no hay picos de carga?
Los nodos cloud se apagan solos al terminar las tareas. El modelo pay-per-use elimina el sobredimensionamiento: el coste operativo mensual de cómputo bajó un 20 % de media.
¿Es aplicable a un GRID sobre IBM Spectrum Symphony o TIBCO DataSynapse?
Sí. El diseño es independiente del gestor de cálculo: la extensión se hace a nivel de nodos del clúster. Vermont mantiene equipo especializado en ambos productos y en su migración.
¿Puedo conocer la entidad y las cifras completas?
El caso está anonimizado por acuerdo de confidencialidad. El detalle de arquitectura y las cifras completas se comparten previa firma de NDA.
Contenido relacionado
Última actualización: 2026-09-12