Gestire dati e crediti deteriorati con tecnologie cloud

Dic 29, 2020

Cherry Bit nasce da una visione, che deriva dalla crescente digitalizzazione in Italia del patrimonio informativo utile al mondo NPL avvenuta negli ultimi 10 anni.

Si parla sempre dell’importanza della digitalizzazione dei dati e dei processi, senza spesso avere chiaro quanto sia abilitante. Ma abilitante per cosa? Nuove opportunità.

Opportunità che fanno nascere realtà come Cherry Bit, un gruppo di ingegneri che cercano di  utilizzare la tecnologia per  creare efficienza attraverso l’ innovazione a servizio del settore del credito.

Basti pensare a come 10 anni fa una realtà di questo tipo non sarebbe potuta esistere, nonostante la maggior parte della tecnologia a supporto che utilizziamo tutt’oggi, esistesse già.

Questo patrimonio informativo digitale, per quanto ancora acerbo e poco sviluppato, è sempre in crescita, e genera una grande mole di dati che costituisce un valore potenziale enorme per chi sa interpretarli.

La sfida quindi è rappresentata dal poter sfruttare al meglio questo mare di dati (dai un occhio al nostro osservatorio Cherry Sea), grazie alle più recenti tecnologie cloud, che permettano di processarli, trasformarli ed analizzarli in poco tempo.

In un precedente blog post abbiamo parlato dell’importanza e dei vantaggi dell’utilizzo di un’architettura a microservizi. Tutti i vantaggi però comportano inevitabilmente un costo: complessità.

Complessità in termini sicuramente di gestione, dovendo padroneggiare componenti come orchestratori (Kubernetes) e associati. Ma anche in termini architetturali.

Lo spostamento da un’architettura monolitica consistente, fortemente accoppiata tra le diverse componenti e con unica sorgente persistente del dato, ad una a microservizi, crea la necessità di dover gestire efficacemente la comunicazione tra i diversi servizi.

Ciascuno dei microservizi deve garantire:

  • unico scopo: ogni servizio dovrebbe concentrarsi su un unico scopo e farlo bene.
  • disaccoppiamento: i servizi sanno poco l’uno dell’altro. Una modifica a un servizio non dovrebbe richiedere la modifica degli altri. La comunicazione tra i servizi dovrebbe avvenire solo attraverso le interfacce (REST API) esposte pubblicamente dal servizio.
  • forte coesione: ogni servizio racchiude insieme tutti i comportamenti e i dati correlati. Se è necessario creare una nuova funzionalità, tutte le modifiche dovrebbero essere localizzate in un unico servizio.

 

Bisogna a questo punto fare chiarezza rispetto a due tipologie di servizi:

 

  • microservizi: non è un servizio che dispone di un numero limitato di righe di codice o esegue attività “micro”, come si può immaginare dal nome “microservizio”. L’obiettivo di un’architettura a microservizi non è avere il maggior numero possibile di piccoli servizi. I servizi possono essere anche complessi purché soddisfino le tre proprietà di cui sopra. Nel caso in cui abbia necessità di persistenza del dato (stateful), dovrà aver un database proprio, indipendente e unico al servizio.
  • nanoservizi: rappresentano proprio servizi orientati al “micro/nano” task. Spesso espongono un’unica API e hanno uno scopo ben preciso. Sono paragonabili a singole “funzioni stateless”, e spesso rappresentate da soluzioni “serverless”, che non necessitano di stato persistente (e quindi senza database in assoluto).

 

La piattaforma Cherry Bit ingloba una moltitudine di microservizi e nanoservizi che comunicano tra loro. Questi servizi hanno spesso un ruolo preciso, e molti di essi si occupano di recuperare informazioni digitalizzate disponibili online. 

Ad Esempio: partendo da un codice fiscale, si collegano al catasto e estraggono tutta la consistenza catastale del soggetto, trasformando e rappresentando il dato secondo un modello proprietario.

Già un flusso come il precedente, per quanto banale, sulla piattaforma viene implementato tramite l’orchestrazione di più di 5 servizi, sfruttando una pipeline che porti dal codice fiscale al modello di consistenza catastale. Ogni passo della pipeline utilizza un preciso servizio che, a partire da un input ricevuto tramite API, esegue una funzione e produce un risultato per il prossimo passo della pipeline tramite API.

Molto spesso questa pipeline può essere molto complessa e comprendere più passi. In più potrebbe contenere in più punti delle operazioni che non possono essere completate in breve tempo. Questo porta a delle pipeline che nascono da una chiamata API e generano un risultato in alcuni (pochi) minuti.

Ci sono due modi di gestione: il primo è il modello sincrono REST, in cui ogni passo della catena effettua una chiamata esterna al servizio del passo seguente e attende la risposta; il secondo è un modello asincrono basato su messaggi e argomenti (topics).

Il primo in una configurazione come quella descritta precedentemente risulterebbe fallace: potrebbe esserci un’enorme quantità di richieste – un portafoglio massivo ad esempio – e se per ogni richiesta si effettuasse una chiamata sincrona, si causerebbe un’ occupazione di risorse fino all’ottenimento di una risposta – eventuale.

Potrebbero inoltre verificarsi casi in cui il servizio esterno è inattivo, causando sensibili ritardi di risposta (es. servizi di giustizia telematica non rispondono per una manutenzione dei sistemi programmata).

Diversamente, con il secondo approccio, ogni passo della catena svolgerebbe una funzione e genererebbe un messaggio/evento.

Questo evento sarebbe poi processato dal passo successivo, che riceverebbe l’evento secondo due modalità:

  • Push: l’evento viene mandato al servizio interessato che si era (o era stato) registrato all’evento (o argomento/topic).
  • Pull: il servizio interessato sta “in ascolto” aspettando che l’evento a cui è interessato sia pubblicato, prelevandolo e processando appena disponibile.

Ma chi si occupa della gestione e dove finiscono questi eventi/messaggi?

Il componente architetturale che si occupa di questa funzione viene comunemente chiamato message broker.

La figura seguente mostra come funzioni il processo di generazione e scambio messaggi.

A ogni passo un servizio può svolgere la funzione di producer (produttore) o consumer (consumatore) o di entrambi.

Il producer si occupa di generare messaggi e mandarli al message broker; il consumer si occuperà invece di registrarsi ad un evento interessato, o stare in ascolto per il suo arrivo, in modo da consumarlo, non appena esso sia disponibile. Il message broker ha come incarico la gestione di tutti i servizi registrati come producer

e consumer e smistamento dei messaggi in arrivo e in uscita. I messaggi vengono comunemente accumulati all’interno di code, in attesa che vengano consegnati a tutti gli interessati.

 

Le code ricoprono un ruolo importantissimo nella gestione di errori. Infatti molto spesso, a causa di errori di rete o applicativi, la consegna di messaggi può fallire, causando potenzialmente seri problemi: ogni passo della catena è fondamentale per quello successivo. La mancata consegna di un singolo messaggio causerebbe il fallimento della pipeline completa. Molti message broker rendono disponibili strategie di riconsegna del messaggio in caso di fallimento, in modo da poter mitigare il rischio di fallimento.

Inoltre le code offrono una soluzione al comune problema di “backpressure” (o “contropressione”), che nasce come ispirazione al concetto della fluidodinamica che lo definisce come: “resistenza o forza che si oppone al flusso desiderato di un fluido attraverso i tubi”.

Nel contesto del software dovremmo variare la precedente definizione come: “resistenza o forza che si oppone al flusso desiderato di dati attraverso il software”.

La backpressure si genera generalmente quando un producer riesce a generare più messaggi di quanti ne riesca a processare un consumer.

Questo ad esempio è una configurazione tipica, dove il producer è un servizio che genera richieste di estrazione dato, e il consumer un altro servizio che si occupa di recuperarlo da un sistema “lento” (es. sito web poco efficiente) . Per questo motivo una coda si occupa di accumulare i messaggi dei producer, in modo che il message broker li possa consegnare al consumer nella misura in cui lui li possa processare.

Ogni flusso di invio da una coda a un consumer deve essere quindi parametrizzato a dovere, per evitare backpressure. Una non curanza di questo problema può portare a numerose problematiche applicative. Il primo risultato auspicabile è il sovraccarico di un servizio, con probabile blocco di disponibilità dello stesso, vedendosi saturare le risorse.

Un secondo, e molto più problematico, è rappresentato dalla generazione di richieste duplicate: questo perchè un servizio avrebbe sempre più difficoltà a processare richieste, che si vedrebbero accumulate in memoria dell’applicativo, nell’attesa che le risorse si li liberino. Il message broker dopo lunghi timeout andrebbe a considerare la consegna del messaggio fallita. Nel caso in cui implementi logiche di riconsegna dei messaggi, andrà a consegnare i messaggi falliti. Il messaggio fallito quindi sarà riconsegnato e di nuovo inserito in memoria applicativa. Questo genera la possibilità di duplicare l’operazione richiesta.

Se immaginiamo che l’operazione richiesta includa la scrittura di un certo dato in un database, nel caso sfortunato in cui le richieste duplicate venissero eseguite nello stesso istante, vedremmo generarsi dei dati duplicati.

 

Come tutto questo ha a che fare col mondo NPL vi starete chiedendo?

Vi posso assicurare che è perfettamente attinente.

Cherry Bit, con i suoi algoritmi, offre la possibilità di verifica, arricchimento e analisi dati automatica,  di portafogli di credito deteriorato. 

Per farlo, partendo da informazioni minimali rispetto al portafoglio NPL, come una semplice lista di codici fiscali o partite iva, recupera/interroga numerose sorgenti dato, utilizzando una moltitudine di microservizi e nanoservizi interconnessi tra loro.

Ovviamente ogni sorgente e flusso dati ha una determinata performance. Questa può essere legata ad esempio alla latenza di una banca dati interrogata. Oppure ad una operazione molto esosa in termini di calcolo, come ad esempio l’utilizzo di algoritmi di lettura automatica di documenti.

Per questi motivi, Cherry Bit possiede decine di pipeline di generazione e trasformazione dato che si appoggiano a code e message broker con precisi parametri di invio, tarati a dovere sulla nostra infrastruttura e sull’esperienza maturata dalla moltitudine di portafogli analizzati nell’ultimo anno.

Questo ha portato ad una architettura in grado di processare migliaia di posizioni in pochi minuti, con un conseguente vantaggio competitivo difficile da eguagliare.

Articoli correlati