Extensão dinâmica do GRID à nuvem
Um grande grupo financeiro espanhol precisava de absorver os picos de cálculo de risco da sua Sala de Tesouraria sem ampliar o hardware. Estendemos o seu GRID à nuvem com escalamento automático transparente: −35 % nos tempos de execução, +200 % de capacidade e −20 % de custo mensal de computação.
Desafio
Infraestrutura on-premise saturada nos picos diários de cálculo de risco (exigências de Basileia e do Banco de Espanha). Escalar por meios tradicionais era lento e dispendioso e, em períodos de baixa ocupação, a plataforma ficava sobredimensionada.
Solução
Grupos de escalamento automático que criam e destroem nós cloud consoante a carga detetada pelos gestores de cálculo, integrados de forma transparente no cluster GRID existente: primeiro usam-se os recursos internos e, se não bastarem, ativam-se nós na nuvem que se desligam ao terminar.
Tecnologias
- HPC / Grid Computing
- Cloud bursting com Auto Scaling Groups
- Arquitetura híbrida on-premise + cloud
- Automatização do ciclo de vida dos nós
Contexto
A Sala de Tesouraria de um grande grupo financeiro espanhol executa cálculos de risco cada vez mais complexos e frequentes, em resposta a exigências regulatórias como as de Basileia ou as do Banco de Espanha. Esses cálculos correm sobre um sistema GRID corporativo (grelha de cálculo) que reparte as tarefas por milhares de núcleos on-premise.
O problema não era a falta de tecnologia, mas uma infraestrutura que não escalava sob pressão: os picos diários saturavam a capacidade disponível e, fora deles, a plataforma ficava sobredimensionada. A organização precisava de uma solução flexível, escalável e compatível com o GRID já implantado, sem o substituir.
O desafio
Quatro fricções concentravam o custo, o prazo e o risco regulatório:
- Sobrecarga em momentos críticos: os picos de cálculo diário, sobretudo da Tesouraria, saturavam a infraestrutura disponível.
- Escalabilidade lenta e dispendiosa: ampliar o hardware não era uma solução viável a curto prazo nem eficiente a longo prazo.
- Baixa eficiência operacional: em períodos de baixa carga a infraestrutura estava sobredimensionada, com um custo pouco otimizado.
- Dependência do ambiente local: a arquitetura GRID existente limitava a adoção de soluções mais flexíveis sem uma integração adequada.
Abordagem por fases
O projeto foi executado em cinco fases, assegurando uma adoção progressiva, controlada e alinhada com os requisitos operacionais do banco.
-
01
PoC e arquitetura híbrida
Validação técnica inicial e desenho de uma arquitetura compatível com o GRID existente e com a nuvem.
-
02
Definição do escalamento automático
Estabelecimento das métricas de carga que ativam nós consoante a procura real dos gestores de cálculo.
-
03
Integração e testes
Validação do funcionamento dos nós cloud como parte transparente do cluster de computação.
-
04
Automatização e monitorização
Orquestração completa do ciclo de vida dos nós e supervisão contínua com alertas preventivos.
-
05
Cargas reais e ajustes
Execução de cargas produtivas e afinação das políticas de escalamento.
Arquitetura e estratégia
A chave foi estender, não substituir. Configuraram-se grupos de escalamento automático (Auto Scaling Groups) que criam e destroem nós cloud automaticamente em função da carga detetada pelos gestores de cálculo. Esses nós integram-se no cluster de computação do banco, de modo que os processos de risco e de tesouraria os utilizam como se fizessem parte do ambiente on-premise.
O fluxo é simples: as tarefas de cálculo são geridas a partir do sistema central GRID; primeiro usam-se os núcleos fixos internos, que funcionam sempre; se forem insuficientes, ativam-se automaticamente núcleos adicionais na nuvem; quando as tarefas terminam, esses nós desligam-se sozinhos. Compatibilidade total com a infraestrutura existente, escalabilidade adaptada à carga real, automatização do ciclo de vida dos recursos cloud e monitorização contínua com capacidade de reação imediata.
Resultados mensuráveis
A arquitetura híbrida transformou um gargalo operacional numa vantagem competitiva: não só resolveu o problema de carga, como melhorou o desempenho dos sistemas de risco e de tesouraria.
| Indicador | Antes | Depois |
|---|---|---|
| Tempo total de execução das cargas de cálculo de risco | Janelas saturadas nos picos | −35 % |
| Capacidade de computação | Limitada ao hardware on-premise | +200 % sem investimento físico |
| Custo operacional mensal de computação | Sobredimensionamento permanente | −20 % em média (pay-per-use) |
| Escalabilidade validada | Ampliação manual de hardware | +1.500 núcleos simultâneos |
Números agregados e anonimizados por acordo de confidencialidade. Fonte: projetos da Vermont Solutions.
Lições aplicáveis
- Estender antes de substituir: obtêm-se as vantagens da cloud sem disrupção nem risco para a operação da Tesouraria.
- Escalar automaticamente a pedido elimina o sobredimensionamento e converte o custo fixo em variável.
- A integração transparente no cluster evita alterar os processos de negócio: para o gestor de cálculo, um nó cloud é um nó como os outros.
- A monitorização contínua com alertas preventivos é o que permite confiar no escalamento automático num ambiente regulado.
Enquadramento regulatório
O cálculo de risco de uma instituição bancária está sujeito a prazos e a exigências do supervisor; a capacidade de computação é, por isso, um requisito de conformidade e não apenas de eficiência.
- Basileia III/IV e os requisitos do Banco de Espanha: cálculos de capital e de risco mais frequentes e exigentes.
- DORA (art. 28.º): a extensão à nuvem é desenhada como risco de terceiros TIC, com controlo do fornecedor e resiliência operacional digital.
- NIS2: segurança das redes e dos sistemas de informação num setor essencial; encaminhamento seguro entre o centro de dados e a nuvem (balanceadores de carga, VPN, regras de failover).
Perguntas frequentes
Foi necessário modificar os processos de risco ou de tesouraria para usar a nuvem?
Não. Os nós cloud integram-se no cluster GRID existente e os gestores de cálculo tratam-nos como núcleos próprios. Os processos de negócio não mudam; muda a capacidade disponível por trás.
O que acontece ao custo quando não há picos de carga?
Os nós cloud desligam-se sozinhos ao terminar as tarefas. O modelo pay-per-use elimina o sobredimensionamento: o custo operacional mensal de computação baixou 20 % em média.
É aplicável a um GRID sobre IBM Spectrum Symphony ou TIBCO DataSynapse?
Sim. O desenho é independente do gestor de cálculo: a extensão faz-se ao nível dos nós do cluster. A Vermont mantém uma equipa especializada em ambos os produtos e na sua migração.
Posso conhecer a instituição e os números completos?
O caso está anonimizado por acordo de confidencialidade. O detalhe da arquitetura e os números completos são partilhados após assinatura de um NDA.
Conteúdo relacionado
Última atualização: 2026-09-12