Lo stato vivo, e perché un bilanciatore non basta

Il caso d'usoL'applicativo che resta aperto

Il primo documento descrive un server che riceve una richiesta, risponde e dimentica. Per una API è il modello giusto, ed è il modello su cui è costruito tutto il web moderno.

Ma c'è una famiglia di applicativi per cui quel modello è sbagliato: il gestionale che una persona tiene aperto per otto ore. Una pagina di quel tipo non è una richiesta — è una sessione di lavoro. Accumula contesto: una griglia filtrata su seicentomila righe, un documento in composizione, un albero di selezioni, un calcolo intermedio. Riceve aggiornamenti quando un collega modifica un dato che quella pagina sta guardando. E dialoga col server in continuazione, non ogni tanto.

La domanda che decide l'architettura è una sola: dove vive quel contesto fra un messaggio e il successivo?

La risposta ortodossa è: da nessuna parte nel processo — lo si scrive su un archivio condiviso, tipicamente Redis, e lo si rilegge a ogni colpo. È la risposta che rende i processi intercambiabili, e per moltissimi casi è quella giusta. Per questo caso non lo è, e vale la pena spiegare esattamente perché.

Finché il dialogo è HTTP, la frequenza è bassa: una manciata di richieste al minuto per utente. Pagare una serializzazione e una deserializzazione a ogni richiesta è un costo trascurabile — è rumore rispetto al resto.

Con un canale WebSocket aperto l'aritmetica cambia di ordine di grandezza. Una pagina viva non fa richieste: conversa. Ogni tasto in un campo con completamento, ogni movimento in una griglia, ogni cambio di selezione, ogni notifica che scende, ogni battito di presenza è un messaggio. Il traffico diventa continuo e minuto: tanti messaggi piccoli, non pochi messaggi grandi.

Con lo stato fuori dal processo, ogni messaggio paga il costo di ricostruire il mondo prima di poter fare la cosa piccola che gli è stata chiesta.

E il costo non è la rete: è la serializzazione. Ricomporre l'oggetto, deserializzarlo, rimetterlo insieme, e poi riserializzarlo per riscriverlo. Su un messaggio ogni pochi secondi non lo noti; su un dialogo continuo moltiplicato per il numero di utenti collegati diventa la voce di costo dominante del server — e il paradosso è che più l'applicazione è reattiva, più paga.

Questa è la prima ragione per cui, in questo scenario, teniamo lo stato dove serve: in memoria, nel processo che sta servendo quella pagina.

C'è un secondo argomento, indipendente dal primo e più tagliente: ci sono oggetti che semplicemente non si serializzano a ogni giro.

Un dataframe con un milione di righe caricato per un'analisi. Una struttura calcolata a caro prezzo su cui l'utente sta iterando. Una connessione già aperta, un cursore, un contesto di calcolo. Sono oggetti grossi e mutabili: l'utente li modifica un pezzetto alla volta, e ogni modifica è piccola rispetto all'oggetto.

Con lo stato esterno, quella modifica piccola costa quanto l'oggetto intero: rileggi tutto, cambi una colonna, riscrivi tutto. Non è una questione di ottimizzazione — l'operazione è strutturalmente sproporzionata al lavoro che compie. E per alcuni di questi oggetti la serializzazione non è nemmeno possibile in modo sensato.

La conseguenza pratica, nei sistemi che scelgono comunque la via senza stato, è che quegli oggetti finiscono per non esistere: l'architettura respinge il caso d'uso. L'utente riceve una pagina che ricarica invece di una che lavora, e la funzionalità viene riprogettata per stare dentro il vincolo tecnico.

Non abbiamo scelto lo stato per comodità. Lo abbiamo scelto perché senza, certe funzionalità non si possono nemmeno proporre.

Una volta deciso che il contesto di una sessione di lavoro vive nella memoria di un processo, tutto il resto discende per necessità, non per gusto.

Se lo stato di Maria è nel processo 3, ogni messaggio di Maria deve arrivare al processo 3. Non alla macchina meno carica, non a rotazione: a quello. La chiave con cui si partiziona il carico non è più la richiesta — è l'utente.

Da qui il nome: user sticky. L'utente è appiccicato al proprio processo, e il processo è l'unità che possiede una porzione della popolazione.

La seconda unità è la pagina. Una persona apre più schede, e ognuna è una sessione di lavoro a sé, con il proprio contesto. Quindi lo stato vivo si organizza su tre livelli annidati: l'utente possiede le sue connessioni, ogni connessione possiede le sue pagine, ogni pagina possiede il proprio albero di dati.

È la prima domanda che riceve chiunque proponga questa architettura, ed è una domanda giusta. Traefik, nginx, HAProxy sanno tutti fare sticky session: emettono un cookie, e le richieste che lo portano tornano allo stesso backend. Perché costruire qualcosa quando esiste già?

Perché instradare è la parte facile, ed è l'unica che un bilanciatore può fare. Un bilanciatore vede pacchetti e connessioni TCP; non sa nulla di ciò che sta dentro il processo a cui li consegna. In particolare:

Nessuna di queste è una critica ai bilanciatori: fanno benissimo il lavoro per cui sono costruiti, e nella nostra architettura uno di essi sta davanti comunque. Il punto è che quel lavoro non è questo lavoro. Il bilanciatore instrada verso una macchina; ciò che decide dove vive una persona, e come ce la si sposta, deve stare dentro l'applicazione, perché solo lì si sa cosa sia una persona.

C'è un modo sbagliato di fare esattamente questa cosa, ed è il modo in cui viene fatta di solito: si attiva la sticky session sul bilanciatore, si tiene lo stato in memoria, e funziona. Funziona finché non devi cambiare qualcosa.

Il giorno del rilascio scopri che non puoi sostituire un processo senza scollegare chi ci sta sopra. Il giorno in cui un processo comincia a gonfiarsi scopri che non puoi riavviarlo. Il giorno in cui il carico si sbilancia scopri che non puoi ribilanciare, perché spostare un utente significa perderne il lavoro.

La stickiness senza mobilità dello stato non è un'architettura: è un vincolo che ti impedisce di toccare il sistema mentre è vivo.

La soluzione tipica a quel punto è rassegnarsi: si rilascia di notte, si accetta di scollegare tutti, si sovradimensiona per non dover mai ribilanciare. Sono compromessi che si pagano ogni settimana per sempre.

Per questo la primitiva fondante del nostro piano non è l'instradamento appiccicato — quello è la parte facile — ma lo spostamento a caldo di un utente con tutto il suo stato. È ciò che rende la stickiness sostenibile invece che paralizzante, ed è la ragione per cui il file di test più esercitato dell'intero progetto è quello che verifica lo spostamento: 119 casi, perché è l'operazione da cui dipende tutto il resto.

Vale la pena essere espliciti sul costo, perché è la parte che si sottovaluta sempre. «Sposta l'utente da un processo all'altro» è una frase breve che nasconde una quantità di problemi reali.

Tutto quanto sopra ha una forma concreta. Tre pezzi, un principio.

Il front è un'applicazione ordinaria che si monta come qualunque altra: le sue rotte rispondono da sé, e ciò che appartiene al sito ospitato viene inoltrato al processo giusto. Non conserva stato proprio — legge quello che il supervisore già sa.

In sviluppo tutto questo gira in un solo processo: il worker vive dentro il supervisore, attaccato allo stesso canale, che in quel caso è una coppia di code in memoria invece di un socket — ma codifica ogni messaggio esattamente allo stesso modo. Se il protocollo funziona nel ruolo singolo, passare a molti processi cambia solo il filo.

Lo stato vivo e la sua consegna

• Un albero di dati per pagina. Ogni scheda aperta ha il proprio stato sul server, e ciò che cambia le viene consegnato al primo giro utile. La consegna è a richiesta, non spinta: se una pagina tace, i suoi aggiornamenti l'aspettano nel collettore invece di perdersi.
• Aggiornamenti dai dati. Una pagina sottoscrive le tabelle che la interessano; una modifica raggiunge tutti i sottoscrittori ovunque siedano. Chi ha originato il cambiamento serve prima i propri, poi il resto viaggia: una modifica su una tabella che nessuno guarda non costa un solo invio.
• Cache invalidata da sé. Un valore memorizzato in una pagina porta il segno della tabella da cui viene; quando quella tabella cambia, il valore viene invalidato con una scrittura vera, che la pagina riceve come ogni altro aggiornamento.
• Store globale condiviso. Un albero comune a tutti i processi, con un solo scrittore e una replica locale per ciascuno: le letture non costano un giro di rete. Le modifiche in lettura-e-scrittura passano da una concessione ordinata, tutto-o-niente, che viene rilasciata da sé se chi la teneva muore.

Il governo dei processi

• Spostamento a caldo. Tutto ciò che appartiene a una persona viaggia da un processo all'altro e rinasce nell'ordine giusto. La mappa si aggiorna per ultima: finché l'installazione non è confermata, la persona continua a essere servita dove si trova, e se la destinazione muore le si offre un altro posto.
• Bilanciamento sulla risorsa giusta. Si osserva la saturazione per componente, non un carico medio: un processo oltre soglia su una sola risorsa cede utenti anche se tutto il resto sembra tranquillo. Chi va via viene scelto in proporzione a quanto ha consumato di recente.
• Ricambio prima del limite. Il sistema tiene memoria di come cresce la memoria di ogni processo e ne sostituisce uno prima che raggiunga il tetto, portando i suoi utenti su un processo fresco. Il problema classico dei processi che si gonfiano diventa un'operazione pianificata invece di un incidente.
• Compattazione. Quando il carico cala, il pool si restringe: si drena il processo meno carico e lo si ritira. Un processo che tiene ancora qualcosa non viene mai ritirato.
• Sorveglianza che serve a due cose. Una sonda periodica chiede a ogni processo i suoi numeri: la risposta porta i dati e la prova che il processo è ancora vivo per produrli. Il silenzio è esso stesso l'informazione, e un processo muto viene abbattuto e rilanciato.
• Un riavvio completo non perde le sessioni. Andando giù, il pool raccoglie ogni utente e lo scrive su file; risalendo, li ripiazza prima che qualcosa possa essere instradato.

Il ponte con l'esistente

• Un sito già scritto può salire a bordo. Il processo sa sintetizzare l'ambiente standard di un'applicazione WSGI e invocarla al proprio interno, su un pool di thread dedicato e separato da quello delle operazioni di servizio — così una raffica di richieste al sito non affama la macchina di orchestrazione. WSGI come adattatore, mai come trasporto: un applicativo esistente entra nel piano senza essere riscritto, e guadagna sessione appiccicata, stato per pagina e spostamento a caldo.
• Il monitor. Una chiamata sola compone la popolazione viva: per ogni processo i suoi utenti, le sue connessioni, le sue pagine, con i consumi cumulativi di ciascuno; e per ogni processo lo stato nel ciclo di vita, quando è nato e, se è morto, quando e come. Un processo irraggiungibile non fa cadere la lettura: compare con il proprio stato di irraggiungibilità.

Tutto quanto descritto finora produce informazione, e quell'informazione ha una forma. Le illustrazioni che seguono non sono schermate di un prodotto finito: mostrano quali dati la superficie di supervisione già possiede, e come si leggono insieme.

La cosa da notare è che le due viste rispondono a due domande diverse. La prima guarda i processi: come stanno, quanto reggono, cosa conviene fare. La seconda guarda le persone: chi c'è, dove sta, quanto pesa.

Un gruppo è un insieme di processi che eseguono la stessa versione dell'applicazione con il proprio runtime. Il pool non è più una fila di processi identici: è un pool di gruppi, e ogni utente appartiene al gruppo del processo che lo tiene.

Serve per la cosa che senza di essa è impossibile: rilasciare una versione nuova mentre la gente lavora. Si porta su un gruppo con il codice nuovo, gli si spostano gli utenti a caldo — con la primitiva che già esiste, quella che porta la sessione intera senza perdere il lavoro in corso — e si ritira il gruppo vecchio quando è vuoto. Chi era collegato non se ne accorge, e chi arriva dopo entra sulla versione nuova.

Se qualcosa va storto, la stessa primitiva riporta indietro le persone: il rollback non è un ripristino, è uno spostamento nella direzione opposta.

Non solo rilasci: mandare qualcuno avanti

Il rilascio in blocco è il caso grosso, ed è il più raro. L'uso quotidiano dei gruppi è un altro, e vale la pena metterlo in evidenza perché è quello che si spende ogni settimana con i clienti.

La maggior parte delle novità non è una versione nuova del prodotto: è un bottone, un report modificato, una variante di comportamento chiesta da qualcuno. Con i gruppi si può portare quella modifica in esercizio e mandarci sopra solo chi deve provarla — un cliente, un reparto, una singola persona — mentre tutti gli altri continuano sulla versione stabile senza accorgersi di nulla.

Il costo dell'operazione è basso, ed è basso per una ragione precisa: quando la modifica non tocca le dipendenze, il lockfile è lo stesso e i due gruppi condividono l'ambiente. Quello che li distingue è il commit, che viaggia come differenza — kilobyte, non centinaia di megabyte. Non c'è un artefatto grosso da costruire e distribuire per far provare un bottone a tre persone.

Chi va sul gruppo di prova ci va con lo stesso meccanismo che assegna chiunque altro, e se la prova va male torna indietro a caldo, con la sessione di lavoro intatta. Il betatester non è una categoria speciale del sistema: è una persona assegnata a un gruppo diverso.

Il runtime di un gruppo è un artefatto, non un'installazione

Ogni gruppo dichiara il proprio runtime: quale interprete e quale codice. La domanda vera è chi lo costruisce e quando, e la risposta è la decisione che tiene in piedi tutto il meccanismo.

Il runtime non viene assemblato sulla macchina che deve servire le richieste. Lo costruisce la CI, una volta, con uv: uv sync --frozen materializza l'ambiente esattamente come il lockfile lo descrive, e la versione diventa una directory immutabile a percorso canonico che nessuno tocca più. Un gruppo non installa nulla all'avvio: apre una cartella che esiste già.

Il codice viaggia per differenza

Una versione è in realtà una coppia: l'ambiente e il commit. Le due metà cambiano con ritmi diversi — l'ambiente raramente, il codice spesso e per differenze minime, a volte tre moduli. Trattarle allo stesso modo significherebbe spedire centinaia di megabyte per cambiare tre file.

Quindi l'ambiente viaggia come archivio, e il codice come albero di lavoro git immutabile: un deposito di oggetti per macchina, e ogni versione è il suo albero al percorso canonico. Il delta si misura in kilobyte, gli oggetti comuni restano condivisi, e il rollback è ripuntare all'albero precedente. Non esiste un aggiornamento in place: quella è la strada che porta alla deriva, dove nessuno sa più con certezza quale codice stia girando.

La CI sta fuori dal percorso di esecuzione

È una scelta deliberata e vale la pena dichiararla: la CI pubblica gli artefatti su un archivio condiviso — l'ambiente e il pacchetto di codice, accanto — e finisce lì il suo compito. Chi avvia un processo li legge da quell'archivio, mai dalla forge.

La conseguenza è che il sistema si riavvia, si ribilancia e sostituisce processi anche con la piattaforma di integrazione irraggiungibile. Il momento in cui serve più affidabilità è quello in cui qualcosa è già andato storto, e in quel momento il numero di dipendenze esterne deve essere il più basso possibile.

Lo stesso meccanismo dichiarativo — il gruppo descrive il runtime che vuole, e chi avvia i processi lo realizza — ammette altri modi di confezionare un ambiente, immagini di container comprese, senza che nulla cambi nel resto del disegno: cambia l'attuatore, non il contratto.

Lo stato di lavoro attraversa le versioni

C'è una conseguenza del versionamento che riguarda proprio ciò che rende speciale questo piano, e va affrontata di petto: spostare una persona da un gruppo all'altro significa che il pacchetto del suo stato viene prodotto da una versione e installato da un'altra. È lo stesso trasferimento a caldo di sempre, ma con un codice diverso alle due estremità.

Finché i cambiamenti sono additivi — un campo nuovo nello stato di una pagina, una chiave in più — la cosa è trasparente: la versione vecchia ignora ciò che non conosce, la nuova tollera ciò che non trova. È la stessa disciplina che vale per il database, applicata alla memoria invece che al disco.

Quando invece la forma dello stato cambia davvero — una struttura riorganizzata, un oggetto che non ha più lo stesso significato — la regola è netta e vale la pena conoscerla:

Uno stato che la destinazione non riconosce non viene indovinato: la pagina riparte pulita, e lo dice.

Nessuna reidratazione approssimata, nessun tentativo di adattare al volo una struttura a un codice che si aspetta altro. Il costo è dichiarato e circoscritto: chi stava lavorando su quella pagina perde il contesto della pagina — la griglia filtrata, la selezione in corso — e la ritrova pulita. Non perde la sessione, non perde il login, non perde nulla di ciò che vive nel server: quello sopravvive, per la stessa linea di taglio che regge tutto il disegno.

Questo impone una disciplina a chi scrive una versione nuova, ed è esattamente l'analogo delle migrazioni additive: additivo è trasparente, strutturale è una ripartenza dichiarata. Un cambiamento di forma non è vietato — va saputo, perché ha un prezzo visibile per chi in quel momento sta lavorando.

Ciò che rende praticabile tutto questo è un vincolo posto all'origine: i registri contengono dati serializzabili per costruzione, mai oggetti vivi come verità. Un oggetto vivo non si può spedire e non si può versionare — e la regola esiste da prima che servisse, perché aggiungerla dopo avrebbe significato riscrivere ciò che nel frattempo si era appoggiato all'abitudine opposta.

Il primo documento descrive le metriche che un processo espone su di sé, nel formato che i raccoglitori consumano. Qui si aggiunge un livello, e con esso un problema di raccolta che vale la pena spiegare perché la soluzione è già nel disegno.

I processi di lavoro non parlano HTTP. È una conseguenza voluta: un processo che tiene stato non si affaccia sulla rete, parla solo sul canale col proprio supervisore. Quindi nessun raccoglitore può interrogarli direttamente, e non è un limite da aggirare — è la stessa proprietà che li tiene fuori dal perimetro esposto.

Il supervisore è l'unico punto di raccolta, e non ha bisogno di un meccanismo nuovo per esserlo.

La sonda che già gira — quella che ogni pochi secondi chiede a ciascun processo i suoi numeri e nel farlo ne verifica la vitalità — è la raccolta. Il supervisore archivia quelle letture per governare il pool, e le ripubblica nel formato standard etichettate per processo. Un raccoglitore interroga un solo indirizzo e ottiene la fotografia di tutti, senza che nulla debba essere esposto in più.

Il documento descrive il piano nella sua forma compiuta. Questa appendice è il solo posto dove si legge lo stato di avanzamento, e l'unico che cambia mentre l'implementazione procede.

La parte difficile è quella già fatta: lo spostamento a caldo di un utente con tutto il suo stato è operativo e verificato da 119 casi di test — è la primitiva da cui dipendono il ribilanciamento, il ricambio dei processi e il versionamento.