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 è l'operazione da cui dipende tutto il resto: il ribilanciamento, la sostituzione di un processo, il versionamento e il ritorno dopo un riavvio sono quella stessa primitiva, vista da lati diversi.

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.

L'identità è una sola, ed è quella del sito. Il front non conia niente: il sito ospitato battezza la propria connessione mentre serve, la risposta riporta quel nome, e il cookie lo conserva. Non esiste una seconda identità da tradurre nella prima, quindi non esiste il punto in cui le due possono divergere — e le mappe del supervisore sono indicizzate su nomi veri, non su un identificatore inventato dal front. Il cookie vive ventiquattr'ore, la vita che il sito dà alla propria connessione.

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 nessuna replica: il master vive sul supervisore, e un processo lo legge con una chiamata sul canale che già tiene aperto. È la scelta che toglie di mezzo il problema di allineare le copie — non ci sono copie da allineare. Le modifiche in lettura-e-scrittura passano da una concessione ordinata, tutto-o-niente: la concessione porta con sé il contenuto del master, quindi chi la riceve non deve chiedersi se quello che ha in mano è aggiornato, e si libera da sé se chi la teneva muore.

Il governo dei processi

• Spostamento a caldo, per una strada sola. Tutto ciò che appartiene a una persona si congela dov'è, viene riassegnato, e rinasce al primo colpo che quella persona batte. I passi sono sempre gli stessi quattro — si alza la barriera, si congela, si riassegna, si risveglia — e servono tutti i casi: restringere il pool, sostituire un processo in modo ordinato, riportare dentro chi c'era prima di un riavvio. Il passaggio diretto da un processo all'altro è stato eliminato di proposito: una strada sola è una strada che si prova davvero. Chi arriva mentre la persona è fra due case attende sulla barriera, non fallisce.
• 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ù, ogni gruppo parcheggia i suoi utenti congelati e il supervisore scrive accanto le proprie mappe; la cartella prende il nome definitivo solo quando la fotografia è completa, quindi il nome giusto è la prova che non manca niente. Risalendo, le mappe tornano al loro posto e nessuno viene riacceso in anticipo: la prima richiesta di una persona è ciò che la risveglia. Chi torna dopo il riavvio trova il proprio cookie ancora valido, la propria identità, e nessun nuovo login da fare.
• Un gruppo può nascere da uno stampo. Un gruppo che dichiara come costruire il proprio motore possiede un processo template: lo costruisce una volta sola, ne congela la memoria, e ogni worker di quel gruppo è un suo fork. Accendere un processo in più costa un fork invece di un avvio da zero.
• Ogni gruppo sul proprio interprete. La ricetta di un gruppo dichiara con quale Python eseguirlo: il processo del supervisore sta sul suo, i worker di ogni gruppo sul proprio. Gli interpreti li porta l'immagine; il gruppo dice quale gli serve.

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: il Framework non si tocca. Quello che si costruisce e si spedisce è il bundle dell'applicazione, che pesa quanto l'applicazione e non quanto la piattaforma sotto. Non c'è un artefatto grosso da produrre 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 Framework è un'immagine, l'applicazione è un bundle

Ogni gruppo dichiara che cosa esegue. La domanda vera è chi lo costruisce e quando, e la risposta è la decisione che tiene in piedi tutto il meccanismo: le cose che cambiano con ritmi diversi viaggiano separate.

Il Framework — il server, il supervisore, gli interpreti, tutto ciò che è comune — è un'immagine sola, identica per ogni cliente. Si aggiorna come si aggiorna qualsiasi applicazione: si pubblica una versione nuova e si passa a quella. Non si aggiorna per cliente, né per gruppo, né per utente.

L'applicazione viaggia a parte, come bundle: una build esatta del codice del cliente e delle sue dipendenze, costruita dal repository dell'applicazione con la propria CI, archiviata immutabile e ritirata al momento dell'uso. Un gruppo monta un bundle. Non installa niente all'avvio: apre qualcosa che esiste già, verificato.

Una modifica piccola tocca molti repository

È il caso che decide il formato. Un cliente chiede una modifica alle fatture; lo sviluppatore interviene sull'applicativo, su un modulo del framework applicativo e su due package condivisi. Quello che va collaudato non è un file: è una combinazione precisa di quattro repository.

Per questo un bundle non si identifica con un numero di versione leggibile: il suo manifesto registra l'origine esatta di ogni pezzo, commit per commit. Un nome di ramo non basta a dire che cosa si sta provando.

La CI sta fuori dal percorso di esecuzione

È una scelta deliberata e vale la pena dichiararla: la CI pubblica il bundle sull'archivio condiviso, e finisce lì il suo compito. Chi avvia un processo lo legge da quell'archivio, in sola lettura, 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 quello che vuole eseguire, e chi avvia i processi lo realizza — ammette altri modi di confezionare un'applicazione 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ù.

Questo documento descrive il piano nella sua forma compiuta: quello che il sistema è quando il lavoro è finito. Non dichiara, riga per riga, che cosa di tutto ciò sia già scritto — perché quello cambia ogni settimana, e una pagina che lo mescola alla descrizione invecchia tutta insieme.

Lo stato di avanzamento vive in un documento suo: stato attuale, voce per voce, con la prova accanto a ciascuna — un file con la sua copertura, un test che la esercita, oppure la constatazione che non esiste una riga di codice. La parte che riguarda questo capitolo è il ramo il mondo SPA.

La divisione è deliberata. Le pagine dei quattro documenti non cambiano quando una voce di quel documento cambia stato.