Estensione dinamica del GRID al cloud
Un grande gruppo finanziario spagnolo doveva assorbire i picchi di calcolo del rischio della sua Sala Tesoreria senza ampliare l'hardware. Abbiamo esteso il suo GRID al cloud con autoscaling trasparente: −35 % nei tempi di esecuzione, +200 % di capacità e −20 % di costo mensile di calcolo.
Sfida
Infrastruttura on-premise satura nei picchi giornalieri di calcolo del rischio (requisiti di Basilea e della Banca di Spagna). Scalare con mezzi tradizionali era lento e costoso e, nei periodi di bassa occupazione, la piattaforma restava sovradimensionata.
Soluzione
Gruppi di autoscaling che creano e distruggono nodi cloud in base al carico rilevato dai gestori di calcolo, integrati in modo trasparente nel cluster GRID esistente: prima si usano le risorse interne e, se non bastano, si attivano nodi nel cloud che si spengono al termine.
Tecnologie
- HPC / Grid Computing
- Cloud bursting tramite Auto Scaling Groups
- Architettura ibrida on-premise + cloud
- Automazione del ciclo di vita dei nodi
Contesto
La Sala Tesoreria di un grande gruppo finanziario spagnolo esegue calcoli del rischio sempre più complessi e frequenti, in risposta a requisiti normativi come quelli di Basilea o della Banca di Spagna. Quei calcoli girano su un sistema GRID aziendale (griglia di calcolo) che distribuisce i task su migliaia di core on-premise.
Il problema non era la mancanza di tecnologia, ma un'infrastruttura che non scalava sotto pressione: i picchi giornalieri saturavano la capacità disponibile e, al di fuori di essi, la piattaforma restava sovradimensionata. L'organizzazione aveva bisogno di una soluzione flessibile, scalabile e compatibile con il GRID già in uso, senza sostituirlo.
La sfida
Quattro punti di attrito concentravano costi, tempi e rischio normativo:
- Sovraccarico nei momenti critici: i picchi di calcolo giornalieri, soprattutto quelli della Tesoreria, saturavano l'infrastruttura disponibile.
- Scalabilità lenta e costosa: ampliare l'hardware non era una soluzione praticabile nel breve periodo né efficiente nel lungo.
- Bassa efficienza operativa: nei periodi di basso carico l'infrastruttura era sovradimensionata, con un costo poco ottimizzato.
- Dipendenza dall'ambiente locale: l'architettura GRID esistente limitava l'adozione di soluzioni più flessibili senza un'integrazione adeguata.
Approccio per fasi
Il progetto è stato eseguito in cinque fasi, garantendo un'adozione progressiva, controllata e allineata ai requisiti operativi della banca.
-
01
PoC e architettura ibrida
Validazione tecnica iniziale e progettazione di un'architettura compatibile con il GRID esistente e con il cloud.
-
02
Definizione dell'autoscaling
Definizione delle metriche di carico che attivano i nodi in base alla domanda reale rilevata dai gestori di calcolo.
-
03
Integrazione e testing
Validazione del funzionamento dei nodi cloud come parte trasparente del cluster di calcolo.
-
04
Automazione e monitoraggio
Orchestrazione completa del ciclo di vita dei nodi e supervisione continua con alert preventivi.
-
05
Carichi reali e messa a punto
Esecuzione di carichi produttivi e regolazione fine delle politiche di scaling.
Architettura e strategia
La chiave è stata estendere, non sostituire. Sono stati configurati gruppi di autoscaling (Auto Scaling Groups) che creano e distruggono nodi cloud automaticamente in funzione del carico rilevato dai gestori di calcolo. Quei nodi si integrano nel cluster di calcolo della banca, in modo che i processi di rischio e tesoreria li utilizzino come se fossero parte dell'ambiente on-premise.
Il flusso è semplice: i task di calcolo sono gestiti dal sistema centrale GRID; prima si usano i core fissi interni, sempre attivi; se risultano insufficienti, si attivano automaticamente core aggiuntivi nel cloud; quando i task terminano, quei nodi si spengono da soli. Compatibilità totale con l'infrastruttura esistente, scalabilità adattata al carico reale, automazione del ciclo di vita delle risorse cloud e monitoraggio continuo con capacità di reazione immediata.
Risultati misurabili
L'architettura ibrida ha trasformato un collo di bottiglia operativo in un vantaggio competitivo: non solo ha risolto il problema di carico, ma ha migliorato le prestazioni dei sistemi di rischio e tesoreria.
| Indicatore | Prima | Dopo |
|---|---|---|
| Tempo totale di esecuzione dei carichi di calcolo del rischio | Finestre sature nei picchi | −35 % |
| Capacità di calcolo | Limitata all'hardware on-premise | +200 % senza investimenti fisici |
| Costo operativo mensile di calcolo | Sovradimensionamento permanente | −20 % in media (pay-per-use) |
| Scalabilità validata | Ampliamento manuale dell'hardware | +1.500 core simultanei |
Cifre aggregate e anonimizzate in base a un accordo di riservatezza. Fonte: progetti di Vermont Solutions.
Lezioni applicabili
- Estendere prima di sostituire: si ottengono i vantaggi del cloud senza discontinuità né rischi per l'operatività della Tesoreria.
- L'autoscaling su domanda elimina il sovradimensionamento e trasforma il costo fisso in variabile.
- L'integrazione trasparente nel cluster evita di modificare i processi di business: per il gestore di calcolo, un nodo cloud è un nodo come gli altri.
- Il monitoraggio continuo con alert preventivi è ciò che permette di fidarsi dello scaling automatico in un ambiente regolamentato.
Quadro normativo
Il calcolo del rischio di un istituto bancario è soggetto a scadenze e a requisiti dell'autorità di vigilanza; la capacità di calcolo è, quindi, un requisito di conformità e non solo di efficienza.
- Basilea III/IV e i requisiti della Banca di Spagna: calcoli di capitale e rischio più frequenti ed esigenti.
- DORA (art. 28): l'estensione al cloud è progettata come rischio di terze parti ICT, con controllo del fornitore e resilienza operativa digitale.
- NIS2: sicurezza delle reti e dei sistemi in un settore essenziale; instradamento sicuro tra il data center e il cloud (bilanciatori, VPN, regole di failover).
Domande frequenti
È stato necessario modificare i processi di rischio o tesoreria per usare il cloud?
No. I nodi cloud si integrano nel cluster GRID esistente e i gestori di calcolo li trattano come core propri. I processi di business non cambiano; cambia la capacità disponibile dietro di essi.
Cosa succede al costo quando non ci sono picchi di carico?
I nodi cloud si spengono da soli al termine dei task. Il modello pay-per-use elimina il sovradimensionamento: il costo operativo mensile di calcolo è sceso del 20 % in media.
È applicabile a un GRID su IBM Spectrum Symphony o TIBCO DataSynapse?
Sì. Il progetto è indipendente dal gestore di calcolo: l'estensione avviene a livello dei nodi del cluster. Vermont mantiene un team specializzato in entrambi i prodotti e nella loro migrazione.
Posso conoscere l'istituto e le cifre complete?
Il caso è anonimizzato in base a un accordo di riservatezza. Il dettaglio dell'architettura e le cifre complete vengono condivisi previa firma di un NDA.
Contenuti correlati
Ultimo aggiornamento: 2026-09-12