SentiOne

Riconosciuta da Deloitte come una delle aziende tecnologiche con la crescita più rapida in Europa centrale, SentiOne offre un'esclusiva piattaforma di IA conversazionale che consente di monitorare le discussioni online, entrare in contatto con il pubblico e automatizzare il servizio clienti su tutti i canali Web.

Mentre la maggior parte delle aziende di IA che forniscono chatbot compiono notevoli sforzi per l’apprendimento delle risorse, SentiOne addestra la propria piattaforma di NLU (Natural Language Understanding) utilizzando le discussioni reali presenti online. Grazie a un ampio dataset raccolto durante lo sviluppo di uno tool di ascolto sociale approfondito, SentiOne è in grado di addestrare motori di Deep Learning in modo eccezionalmente accurato.

“Negli anni di collaborazione con OVHcloud, siamo riusciti a far evolvere la nostra attività facilmente ed elaborare terabyte di dati per fornire ai nostri clienti analisi di qualità.”

Michał Brzezicki, Cofondatore e CTO di SentiOne

Con un’enorme quantità di dati da raccogliere e analizzare in tempo reale, l'azienda si è trovata ad affrontare numerose sfide infrastrutturali e software. Da un lato la diminuzione delle prestazioni del cluster Elasticsearch, cruciale per una buona customer experience durante l’utilizzo della piattaforma; dall’altro un bilanciamento sproporzionato dei cluster, con alcune macchine sovraccariche e altre totalmente inattive.

Per migliorare la velocità della propria piattaforma di IA conversazionale, SentiOne ha studiato un enorme piano di manutenzione per migrare l'hardware e aggiornare contemporaneamente il software. Michał Brzezicki, cofondatore e CTO di SentiOne, ha condiviso i dettagli della gestione di questo complesso progetto da parte dei suoi team.

Per prima cosa gli esperti IT hanno individuato le potenziali cause del degrado di un cluster Elasticsearch: potenza insufficiente della CPU, storage con rendimento inferiore al previsto, malfunzionamenti hardware, configurazione software, connettività, problemi di rete...

Rete

Elasticsearch è molto incline ai problemi di connettività e in caso di instabilità di rete tra due nodi l'intero cluster rallenta. Per mantenere connessioni affidabili e sicure tra i nodi, SentiOne ha quindi deciso di utilizzare la vRack, la rete privata progettata da OVHcloud.

Questa soluzione ha risolto quasi permanentemente il problema grazie alla possibilità di creare connessioni stabili tra i nodi, indipendenti dalla rete pubblica.

Per disporre di una visione dettagliata dello stato di salute della propria infrastruttura, il team SentiOne ha deciso di memorizzare tutti i valori relativi allo stato del sistema e di Elasticsearch utilizzando Grafana con il plugin Sensu. Di fronte all’assenza di anomalie registrate dalle interfacce pubbliche e della vRack, il team ha escluso la rete come fonte dei problemi prestazionali.

CPU

Continuando a indagare sulle potenziali cause dei problemi di performance, il team ha esaminato anche l'utilizzo della CPU e la gestione dei thread. Nonostante il consumo generale della CPU nel cluster, pari a circa l'80%, risultasse appropriato in quanto corrispondente a un corretto utilizzo delle risorse in termini di costi, il team aveva notato un considerevole rallentamento nel momento in cui era in corso il bilanciamento.

Durante questi episodi l'utilizzo della CPU era basso, limitato a un singolo core e, da un'analisi più approfondita, era risultato circoscritto a operazioni di I/O. Poiché il team aveva già escluso la rete dalle possibili cause, ha iniziato a indagare sullo storage.

Storage

La creazione di una dashboard Grafana per la metrica I/O Time di Sensu ha fornito al team SentiOne le risposte che cercava: il grafico generato mostrava chiaramente il tempo dedicato dalla CPU alle operazioni di I/O in un dato periodo, e in alcuni casi la cifra si avvicinava moltissimo al 100%!

Questi dati spiegavano anche il rallentamento del cluster durante il bilanciamento. Se un nodo casuale da cui era stato copiato un frammento presentava un carico I/O elevato, copiare il frammento avrebbe ulteriormente peggiorato la situazione.

Configurazione del cluster Elasticsearch

L'infrastruttura SentiOne era basata su nodi "caldi e freddi". I nodi caldi ospitavano gli indici più diffusi e richiesti regolarmente, quelli freddi contenevano i dati non consultati frequentemente. L'aggiunta di più repliche per gli indici caldi per bilanciare il carico sarebbe stata la soluzione più ovvia, ma in questo caso non adeguata. Prima di tutto perché le query venivano assegnate ai frammenti in modo casuale, quindi se una query pesante veniva ripetuta più volte (ad esempio diverse aggregazioni della stessa query), tutte le repliche venivano sovraccaricate con calcoli simili o identici. Inoltre, la versione di Elasticsearch installata sul cluster di SentiOne all'epoca non forniva l'Adaptive Replica Selection (ARS). Presto divenne chiaro che aggiungere nuovi nodi al cluster non avrebbe apportato miglioramenti alle prestazioni senza l’aggiornamento del software.

Dopo aver identificato i colli di bottiglia all’origine del degrado delle performance del cluster Elasticsearch, il team IT poteva iniziare a pianificare le modifiche a software, architettura e hardware per migliorare la reattività della piattaforma.

Sostituire l'hardware e scalare orizzontalmente i cluster sembrava l'opzione più logica, ma disponendo di un budget consistente ma limitato, SentiOne ha iniziato sanificando l'utilizzo del cluster.

Prima che il team fosse pronto a migrare verso una nuova infrastruttura di server dedicati, le operazioni da eseguire erano numerose.

Partizionamento dei dati più intelligente

Gli ingegneri IT di SentiOne hanno analizzato innanzitutto le richieste degli utenti e la loro influenza sulle prestazioni del cluster. Il rapporto tra il tempo di query e il numero di frammenti interrogati e la loro dimensione è semplice: più grandi sono i frammenti maggiore è la durata di ogni query e all’interrogazione di più frammenti corrisponde un processo complessivo ancora più lungo.

Per ottimizzare il tempo di query, SentiOne ha deciso di dividere i dati in frammenti più piccoli, non superiori a 30 GB. Una volta interrogati, i dati di un singolo frammento dovrebbero entrare nella cache del file system in RAM, almeno in teoria.

Dopo aver indagato sugli intervalli di tempo interrogati dagli utenti, SentiOne ha cambiato la modalità di suddivisione dei dati in indici: le informazioni vengono divise in base al comportamento dei clienti, riducendo al minimo il numero di frammenti per query e diminuendo la durata degli indici da mensili a settimanali.

Applicazione

Il team SentiOne ha rivisto i punti in cui viene interrogato il cluster, ottimizzato le query e modificato l'interfaccia in modo che gli utenti non avessero l'impressione di "freezing" del sistema. Hanno inoltre introdotto controlli basati sui tempi di esecuzione in un arco di tempo flessibile per bloccare query eccessivamente pesanti. Storicamente, una singola query pesante potrebbe degradare le prestazioni dell'intero cluster.Questo controllo di sicurezza era quindi necessario, anche se avrebbe limitato alcuni utenti.

Modifiche all'architettura

Con la nuova versione del cluster SentiOne ha abbandonato l'approccio "caldo e freddo", per diversi motivi. Prima di tutto perché è difficile distinguere chiaramente tra indici caldi e freddi: fino a che punto un indice può essere definito "caldo"? In secondo luogo perché i nodi freddi presentavano I/O molto ridotti con picchi di utilizzo della CPU, mentre i nodi caldi venivano sovraccaricati dagli I/O mantenendo le risorse CPU inutilizzate. Un evidente spreco di risorse e denaro. Infine, anche trovare il giusto equilibrio tra nodi caldi e freddi costituiva un compito arduo che comportava costi inutili.

Nuovo hardware

L'infrastruttura iniziale includeva tre nodi master, 82 nodi caldi e 42 nodi freddi, tutti dotati della stessa soluzione di storage: due dischi Intel® SSD DC S4500. Per fare in modo che la migrazione hardware producesse un miglioramento delle prestazioni di storage, per i nuovi data node SentiOne ha scelto i server della gamma Advance, nello specifico i modelli ADV-2 con dischi NVMe.

La tecnologia NVMe è una combinazione di dischi fisici, bus PCIe e protocolli NVMe, progettata per colmare il divario di prestazioni tra calcolo e storage.

L'interfaccia tra i dischi SSD può influenzare in modo significativo la latenza complessiva percepita dall'utente a livello applicativo, mentre due elementi - interfaccia fisica (PCIe) e protocollo (NVMe) - determinano le prestazioni generali. Un collegamento PCIe 3.0 x4 offre un throughput quasi cinque volte superiore rispetto al SATA più veloce e quasi tre volte maggiore della migliore interfaccia SAS. Il protocollo NVMe offre fino a 64.000 code, garantendo la capacità dell'interfaccia di gestire l'elevato numero di thread I/O generati da CPU multicore.

L’implementazione del nuovo cluster di 121 data node e 3 nodi master ha richiesto due mesi di sviluppo, test e pianificazione. Anche se il processo di migrazione e aggiornamento di Elasticsearch non è stato immune a problemi e ha causato l’irraggiungibilità del cluster per circa sei ore, ha comunque prodotto i risultati sperati.

L’infrastruttura omnicanale di SentiOne controlla miliardi di discussioni su migliaia di fonti Web. Per fornire alle imprese una visione d'insieme del pubblico e un servizio clienti automatizzato questa piattaforma raccoglie, elabora e analizza enormi quantità di dati. Le prestazioni dello storage giocano quindi un ruolo fondamentale.

Il nuovo cluster, costruito su server dedicati ADV-2 e dotato di dischi NVMe, ha cambiato le carte in tavola per SentiOne. La migrazione dell'hardware ha riportato un immediato potenziamento delle performance, aumentando la velocità del cluster di circa sei volte.

L'aggiornamento della versione Elasticsearch - che includeva l'abilitazione della funzione ARS - ha permesso al cluster di lavorare in modo più uniforme e, in caso di carico maggiore, effettuare una ripartizione equa su più nodi. Il team ha misurato che il carico si avvicina al 50% durante le operazioni regolari e non supera l'80% in condizioni di stress, garantendo riserve sufficienti per future esigenze in termini di scalabilità e nuove feature.

"Dal punto di vista del budget, il processo di migrazione si è rivelato molto vantaggioso. I costi relativi al funzionamento del cluster sono stati ridotti di circa il 5%, con un significativo miglioramento delle prestazioni."

Michał Brzezicki, Cofondatore e CTO di SentiOne