Anomaly Detection System

Introduzione

La soluzione GBS, per lo specifico ambito applicativo a cui si rivolge: mondo del trading finanziario, prevede alcune fondamentali esigenze, fra queste:

• Garantire tempi di risposta rapidi ed elevate prestazioni sia al cliente finale che agli operatori della banca/finanziaria
• Garantire la continuità operativa di tutto il sistema

Questo per:

• Consentire alla banca/finanziaria di massimizzare i ricavi ed evitare perdite economiche
• Consentire al cliente finale ed all’operatore della banca di svolgere le operazioni desiderate nel momento e nei tempi opportuni, senza incappare in disservizi.
• Garantire al cliente finale elevate prestazioni delle funzionalità del sistema di trading (tempi di risposta e assenza di interruzioni), per ottenere l’adeguata ‘Customer Satisfaction’

Per far fronte a quanto sopra descritto è necessario evitare qualsiasi malfunzionamento dell’ambiente di produzione, del sistema e dell’intera architettura in cui GBS opera (server, apparecchiature e reti).
Data la complessità architetturale di GBS tale esigenza è in particolare motivata dall’estrema difficoltà che normalmente si riscontra nel trovare la root-cause nei casi di malfunzionamento e crash dei sistemi.
Per ovviare a tali difficoltà si è pensato di realizzare un software in grado di riconoscere l’inizio di potenziali situazioni critiche in modo da poter allertare il prima possibile il team di sistemisti e responsabili architetturali fornendo loro la possibilità intervenire in anticipo con interventi che possano mitigare o evitare i rischi di malfunzionamento o crash.

Anticipazione dei disservizi

Ai fini di individuare con il più ampio anticipo possibile scenari che potrebbero potenzialmente portare a funzionamenti anomali di GBS, abbiamo realizzato un watchdog basato su algoritmi di Machine Learning in grado di riconoscere comportamenti e metriche di sistema non standard (AI-powered anomaly detection).

Grazie alle sue capacità di predizione, il watchdog è in grado di inviare perentoriamente alert di vario tipo quali e-mail e SMS al personale tecnico dedito all’application management.

La Soluzione

Architettura di sistema
Sulla base delle criticità e delle esigenze sopra illustrate la soluzione si basa sulla seguente architettura:

Di seguito l’illustrazione dei moduli presenti nello schema precedente

Data Gatherer REST API
Il modulo si proccupa di fornire a GBS la possibilità di inviare dati al sistema di watchdog consentendo la raccolta di metriche di sistema ed altri parametri tramite una API REST.

Data Gatherer Load Balancer
Il modulo di load balancing si occupa di gestire il numero di istanze e il routing dei messaggi verso i moduli di data gathering in dipendenza del carico di lavoro generato dai diversi servizi registrati.

Data Gatherer Instance
Il modulo di Data Gatherer è quello che si occupa di effettuare fisicamente la collezione dei dati di log da parte dei servizi registrati ed effettuare la loro corretta registrazione all’interno della base di dati. Riveste un ruolo fondamentale all’interno dell’architettura di anomaly detection e deve essere realizzato in modo da massimizzare il throughput, minimizzando al tempo stesso il footprint a livello di risorse utilizzate in modo da poter essere facilmente istanziato all’interno di un’architettura a microservizi come quella proposta.

Reasoner
Il modulo di Reasoning si occupa di effettuare l’analisi dei dati raccolti ed eventualmente scatenare eventi di allarme e notifica. Per sua natura è un modulo di tipo sincrono, di conseguenza periodicamente si occupa di interrogare la base di dati per effettuarne un’analisi.
L’implementazione algoritmica del reasoner dipende in gran parte dai risultati della fase di analisi dati che viene effettuata nei task iniziali del progetto.

Alarm Manager
Il modulo di Alarm Management si occupa di inviare messaggi di allarmi o notifiche generati dal Reasoner ai team di sistemisti e responsabili architetturali che possono così dare il via ad eventuali azioni correttive. Una possibile implementazione è l’invio di messaggi di allerta di “system overload” al Load Balancer del Session manager che può decidere di incrementare il numero di sessioni attive.
Dato il carattere strettamente asincrono del servizio di “alarm & notification”, è implementato tramite message queues.

Reasoner REST API
Il modulo si preoccupa di fornire a GBS un punto di accesso univoco tramite il quale potersi interfacciare con il Reasoner in modo da poter effettuare azioni di:
• Configurazione del Reasoner
• Interrogazione dei dati generati dal Reasoner

Data DB
Vista la natura eterogenea dei flussi di dati in ingresso al sistema, si è realizzato un database di tipo No-SQL, eventualmente in modalità di “sharding” in modo da preservare il throughput in fase di scrittura dei flussi di dati provenienti dai differenti servizi registrati.

Click here to change this text