Con Hyperion 8.0.0 il KNN di Meteo Gesualdo cambia architettura. Non nasce un algoritmo completamente diverso da quello utilizzato fino a oggi: nasce invece un nuovo modo di farlo lavorare, pensato per superare un limite che negli ultimi mesi era diventato sempre più evidente.

Il sistema era cresciuto. La ricerca dei vicini storici era diventata più articolata, i controlli più numerosi e le operazioni necessarie per ottenere una correzione di qualità sempre più pesanti.

A un certo punto il problema non era più capire come ottimizzare ancora il KNN, ma decidere quanto fosse ancora sensato comprimere il suo lavoro per farlo entrare nei limiti di un piccolo server.

Da questa domanda nasce Hyperion 8.0.0.

Quando ottimizzare non basta più

Il KNN di Meteo Gesualdo non è arrivato improvvisamente a questo punto.

Prima di pensare a Hyperion sono state provate diverse strategie per ridurre il peso computazionale del sistema.

Le elaborazioni sono state distribuite maggiormente nel tempo, sono stati introdotti momenti di pausa e checkpoint tra le varie fasce di calcolo ed è stata progressivamente ridotta la quantità di vicini candidabili prima delle fasi più costose della ricerca.

Queste ottimizzazioni hanno permesso al sistema di continuare a funzionare nonostante una complessità crescente, ma hanno anche mostrato un limite.

Ogni ulteriore riduzione avrebbe significato iniziare a rinunciare a operazioni che potevano ancora avere valore per la previsione.

In altre parole, si stava arrivando al punto in cui guadagnare prestazioni avrebbe richiesto di sacrificare troppa qualità.

I fault del server hanno accelerato la decisione

Il problema era particolarmente evidente durante le fasi più pesanti della ricerca.

Un server web deve gestire contemporaneamente molti compiti: sito, API, database, cache, processi programmati e tutte le altre componenti che permettono a Meteo Gesualdo di rimanere disponibile.

Il KNN, invece, durante alcuni passaggi ha bisogno di concentrare una quantità importante di lavoro computazionale in periodi relativamente brevi.

Con l'aumento della complessità, i limiti della CPU disponibile sul server hanno iniziato quindi a produrre anche alcuni fault durante le elaborazioni.

La soluzione più semplice sarebbe stata continuare a ridurre il lavoro del KNN.

Hyperion nasce dalla scelta opposta:

se il server non può più sostenere il calcolo più pesante senza sacrificare la qualità, allora una parte del calcolo può essere portata dove esistono più risorse disponibili.

Hyperion: un KNN, due volti

La versione 8.0.0 introduce quindi quella che possiamo definire un'architettura duplex.

Hyperion è il livello superiore del nuovo sistema e ha due figli:

• Selene, orientata alla qualità della ricerca;
• Helios, orientato alle prestazioni e alla continuità.

La differenza fondamentale è importante: non stiamo parlando di due algoritmi completamente diversi.

Helios e Selene condividono la stessa logica di base del KNN, gli stessi principi di ricerca e la stessa filosofia previsionale.

Ciò che cambia è il contesto nel quale possono lavorare e, di conseguenza, quanto profondamente possono spingersi nella ricerca.

Selene: più libertà per cercare il vicino migliore

Selene viene eseguita su un worker locale dedicato.

La macchina utilizza un sistema Debian ridotto al minimo indispensabile e non deve sostenere il peso dell'intera infrastruttura web di Meteo Gesualdo.

Il suo compito principale è il KNN.

Questo permette di utilizzare una parte molto maggiore delle risorse disponibili per la ricerca dei vicini storici e per le operazioni necessarie a confrontarli.

Il vantaggio non consiste nella promessa che un numero maggiore di candidati produca automaticamente una previsione migliore.

Il vantaggio è soprattutto statistico: una ricerca più ampia aumenta la possibilità che tra i dati storici emergano vicini particolarmente adatti alla situazione atmosferica che si sta analizzando.

Selene può quindi permettersi di essere più paziente e più selettiva nelle fasi successive della ricerca.

Helios: fare bene con meno risorse

Helios rimane invece sul server di Meteo Gesualdo.

Qui l'obiettivo cambia.

Il server deve continuare a rispondere alle richieste del sito e delle applicazioni e non può dedicare tutta la propria CPU a una singola elaborazione.

Helios deve quindi mantenere il KNN all'interno di un profilo più leggero.

La ricerca viene contenuta maggiormente e alcune operazioni devono essere affrontate con maggiore attenzione alle prestazioni.

Questo non significa che Helios sia una versione di qualità insufficiente.

Il suo obiettivo è ottenere comunque un risultato considerato valido e utilizzabile, rispettando però le risorse che il server può realmente mettere a disposizione.

È proprio questa caratteristica a renderlo fondamentale all'interno di Hyperion.

Perché non utilizzare soltanto Selene?

Se il nodo locale può effettuare una ricerca più profonda, potrebbe sembrare naturale affidargli completamente il KNN.

Ma una macchina installata in un'abitazione non offre necessariamente le stesse garanzie operative di un server professionale disponibile in un'infrastruttura dedicata.

Possono esserci:

• riavvii;
• manutenzioni;
• interruzioni della connessione domestica;
• problemi elettrici;
• errori durante una singola elaborazione;
• interventi manuali durante lo sviluppo.

Affidare completamente il KNN al nodo locale avrebbe quindi semplicemente spostato il punto debole da un'infrastruttura all'altra.

Hyperion nasce proprio per evitare questo.

Quando Selene non può rispondere, entra Helios

Il server e il worker locale comunicano costantemente.

Quando Selene può svolgere il proprio lavoro, Hyperion può sfruttare la maggiore profondità della sua ricerca.

Se invece un'elaborazione locale non viene completata correttamente, Helios può assumere il compito sul server.

Questo comportamento non è soltanto teorico.

Durante i primi giorni di prova ci sono stati alcuni errori e anche alcuni riavvii manuali del nodo locale che hanno compromesso singole esecuzioni di Selene.

In quelle occasioni il calcolo è passato a Helios, come previsto dalla nuova architettura.

Selene cerca il risultato migliore quando può. Helios permette a Hyperion di avere comunque una risposta quando Selene non può.

0% di down nei primi due giorni di test

La telemetria dei primi due giorni di funzionamento ha fornito anche un primo dato interessante: il nodo di Selene ha registrato uno 0% di down nei controlli di disponibilità.

È però importante interpretare correttamente questo numero.

Zero down non significa che ogni singola elaborazione sia stata completata senza errori.

Durante una fase di test possono verificarsi problemi applicativi, riavvii manuali o modifiche che interrompono un determinato ciclo pur lasciando la macchina e il collegamento normalmente raggiungibili.

Ed è esattamente ciò che è avvenuto in alcune occasioni.

La distinzione è importante perché evidenzia due livelli differenti di affidabilità:

• la disponibilità del nodo;
• la riuscita della singola elaborazione KNN.

Hyperion deve tenere conto di entrambi.

Il fallback è già stato provato sul campo

Uno degli aspetti più interessanti di questi primi test è quindi che il fallback non è rimasto soltanto una funzione progettata sulla carta.

Le interruzioni volontarie e gli errori avvenuti durante lo sviluppo hanno permesso di vedere il comportamento dei due figli in una situazione reale.

Selene non completa il ciclo?

Hyperion può affidarlo a Helios.

La previsione può nascere da una ricerca meno estesa rispetto a quella disponibile sul worker locale, ma la catena non deve fermarsi semplicemente perché uno dei due rami non è riuscito a completare il proprio lavoro.

Due figli quasi gemelli, almeno per ora

Alla nascita Helios e Selene sono volutamente molto simili.

Questo permette di confrontare i due ambienti mantenendo stabile la logica principale.

Se le differenze fossero state enormi fin dal primo giorno, sarebbe diventato molto più difficile capire se un cambiamento nel risultato dipendesse dalle risorse disponibili oppure da modifiche nell'algoritmo.

La versione 8.0.0 preferisce quindi partire da una base comune e lasciare che siano i dati e la telemetria a indicare progressivamente dove i due rami devono differenziarsi.

Helios e Selene evolveranno parallelamente

Hyperion non nasce con l'idea che i suoi due figli debbano rimanere identici per sempre.

Anzi, è probabile che con il tempo le loro strade diventino progressivamente più specializzate.

Helios continuerà a essere sviluppato ponendo soprattutto una domanda:

Quanto possiamo rendere efficiente il calcolo senza perdere la qualità necessaria per ottenere una correzione utile?

Selene avrà invece un obiettivo differente:

Quanto possiamo aumentare la profondità della ricerca e la qualità dei candidati mantenendo tempi di elaborazione e stabilità accettabili?

Le modifiche future verranno quindi valutate anche attraverso la telemetria raccolta dai due ambienti.

Non necessariamente ciò che funziona meglio per Selene sarà utile a Helios, e viceversa.

Perché Hyperion, Helios e Selene?

Come spesso accade all'interno di Meteo Gesualdo, anche i nomi fanno parte della filosofia del progetto.

Hyperion è il padre.

Helios e Selene sono i suoi due figli nella mitologia greca: il Sole e la Luna.

Due astri opposti ma complementari, entrambi parte dello stesso cielo e, naturalmente, entrambi profondamente legati alla nostra osservazione quotidiana dell'atmosfera e del tempo.

La scelta dei ruoli aggiunge poi una seconda metafora, volutamente idealizzata.

Helios rappresenta l'immediatezza, la forza e la rapidità: deve arrivare al risultato utilizzando con attenzione le risorse disponibili.

Selene rappresenta invece la cura del dettaglio e la ricerca più paziente: quando dispone del tempo e della capacità necessari può approfondire maggiormente l'analisi.

Non sono due avversari.

Sono due componenti dello stesso sistema che esistono proprio perché le rispettive differenze possono diventare complementari.

Perché una versione 8.0.0?

Hyperion non è semplicemente una nuova ottimizzazione del KNN precedente.

La logica matematica principale continua a evolvere dalla stessa famiglia di sistemi, ma cambia il modo nel quale l'intera elaborazione viene organizzata.

Per la prima volta il KNN non viene più pensato come un singolo processo legato a una sola macchina.

Diventa invece un sistema nel quale la stessa logica può essere eseguita con profili differenti su infrastrutture differenti.

È questo cambiamento architetturale a giustificare il passaggio alla generazione 8.

Un esperimento che potrebbe cambiare ancora

Hyperion 8.0.0 rappresenta l'inizio di questa architettura, non necessariamente la sua forma definitiva.

È possibile che in futuro risorse server più potenti rendano meno importante la separazione tra i due ambienti.

È altrettanto possibile che i dati dimostrino il contrario: separare un ramo orientato alla qualità da uno orientato alla continuità potrebbe rivelarsi vantaggioso anche quando i limiti hardware saranno meno stringenti.

Per adesso è troppo presto per stabilirlo.

I prossimi mesi serviranno proprio a capire quanto Selene riesca realmente a migliorare la selezione dei vicini, quanto spesso sia necessario utilizzare Helios e quale equilibrio tra profondità, velocità e stabilità produca i risultati migliori.

Lo stesso obiettivo, due strade

Il motivo per cui Hyperion è nato rimane comunque molto semplice.

Il KNN era arrivato a un livello di complessità nel quale continuare a ridurre il calcolo avrebbe significato iniziare a sacrificare ciò che rendeva utile quella complessità.

Invece di scegliere tra un algoritmo più leggero e una ricerca più approfondita, Meteo Gesualdo ha deciso di provare a mantenere entrambe le possibilità.

Helios deve essere capace di lavorare bene entro limiti precisi.

Selene deve scoprire quanto lontano può spingersi la ricerca quando quei limiti diventano molto più larghi.

Hyperion ha il compito di far convivere entrambe.

Due figli, una stessa logica e due obiettivi differenti. Hyperion 8.0.0 nasce così: non come punto d'arrivo del KNN di Meteo Gesualdo, ma come base per capire quale potrà essere il suo prossimo passo.