Un portale musicale legato a un’emittente radiofonica genera traffico molto irregolare, e da questo vincolo discende la sua architettura. La home page editoriale produce richieste prevedibili; la community — chat, forum, webmail — produce picchi legati a ciò che va in onda. Quando in radio passa un brano e il conduttore invita ad andare sul sito, le connessioni simultanee salgono in pochi secondi. Dimensionare per il traffico medio vuol dire cadere proprio quando il sito serve davvero.

Contesto

Il modello di riferimento è il portale costruito attorno al marchio musicale di un’emittente: contenuti editoriali (schede artisti, recensioni, palinsesto) e un insieme di servizi che trasformano l’ascoltatore passivo in utente registrato. Sono questi ultimi a pesare. Una pagina editoriale statica o quasi-statica si serve in millisecondi; una chat con qualche centinaio di utenti collegati tiene aperte le connessioni, fa polling di continuo e tocca il database a ogni messaggio. Su un portale di community il rapporto fra richieste di lettura e richieste di interazione pende verso le seconde molto più di quanto lasci pensare il conteggio delle pagine viste.

La piattaforma tipica del 2004 sta su Linux, Apache e un linguaggio server-side — per questo tipo di sito PHP è la scelta più diffusa — con dietro un database relazionale (MySQL o PostgreSQL). Sopra c’è un sistema di gestione dei contenuti, custom o semi-custom, che separa la redazione editoriale dal markup. Le pagine si generano conformi a XHTML 1.0 (W3C Recommendation, Second Edition, agosto 2002) e la presentazione passa ai CSS: un modello già percorribile nel 2004 sui browser diffusi, salvo le note differenze di resa.

Architettura

L’unità di servizio è una server farm, non una macchina singola: più nodi applicativi identici dietro un bilanciatore, con database e storage condivisi a valle. Il motivo è doppio. Il primo è la capacità: nessun singolo nodo Apache regge i picchi descritti sopra, e affiancare nodi paralleli scala in orizzontale meglio che ingrossare una macchina sola. Il secondo è la continuità: con due o più nodi, la caduta di uno non porta giù il sito.

Il bilanciamento, a questa data, si fa a livelli diversi. La forma più semplice è il round-robin DNS: più record A per lo stesso nome host, e il resolver del client ne sceglie uno. Funziona, ma distribuisce male, perché la cache DNS sul client e sui risolutori intermedi tiene gli utenti incollati a un nodo e non sa nulla dello stato dei server (Red Hat, Virtual Server Administration). La forma più solida è un bilanciatore a livello di rete davanti alla farm: il progetto Linux Virtual Server, con i moduli IPVS nel kernel, instrada i pacchetti verso i nodi reali con schedulazione round-robin o round-robin pesato, e sa togliere dalla rotazione un nodo caduto. Sposta il carico a livello di pacchetto, e costa in CPU molto meno dell’inoltro a livello applicativo.

Per i servizi di community, dove si può, ci si appoggia a software già maturo. Per il forum lo standard di fatto è phpBB 2.0, uscito nell’aprile 2002 (phpBB History) e adottato ovunque. Per la webmail degli account utente le opzioni mature sono SquirrelMail — la 1.4.0 del 3 aprile 2003 ha aggiunto l’autenticazione CRAM-MD5/DIGEST-MD5 e il TLS per IMAP e SMTP (SquirrelMail ChangeLog, v1.4.0) — e Horde/IMP, entrambe interfacce su un server IMAP/POP3 sottostante. La chat, invece, di rado si trova pronta nella forma che serve: la community di un portale radiofonico vuole una chat agganciata al login del sito e moderabile dalla redazione, e quella di solito te la scrivi.

Punto critico

Il punto in cui questi sistemi si rompono è lo stato di sessione. Se un utente autenticato passa da un nodo all’altro fra una richiesta e l’altra — cosa che il bilanciatore può fare a ogni colpo — la sua sessione deve essere visibile sul nuovo nodo. Tenere le sessioni nei file locali di ciascun nodo non regge: l’utente perde il login appena viene instradato altrove. Al 2004 le strade praticabili sono due. La prima è la sticky session: configurare il bilanciatore perché inchiodi un client allo stesso nodo per tutta la visita; semplice, ma peggiora la distribuzione e rimette in gioco il problema della continuità se quel nodo cade. La seconda è centralizzare lo stato — sessioni nel database condiviso, o in un archivio dedicato — così che ogni nodo veda la stessa verità; costa una scrittura in più per richiesta, ma rende i nodi davvero intercambiabili.

La chat acuisce proprio questo problema, perché è il servizio più stateful del portale: connessioni longeve, aggiornamenti frequenti, un ordinamento dei messaggi che deve restare coerente fra utenti serviti da nodi diversi. Per questo la chat, più del forum o della webmail, condiziona le scelte sul resto della farm.

Implicazioni

Una conseguenza pratica riguarda le statistiche. Con il traffico distribuito su più nodi, i log non stanno più in un posto solo, e contare visite e audience vuol dire raccoglierli e consolidarli — un lavoro tutt’altro che leggero quando i picchi legati alla messa in onda gonfiano i volumi. La misura dell’audience, che per un portale legato alla radio ha valore commerciale diretto, dipende quindi dalla disciplina con cui i log della farm vengono centralizzati e deduplicati.

Una seconda conseguenza riguarda la cache. Le pagine editoriali, che cambiano di rado, si possono servire da copie in cache senza toccare l’applicazione a ogni richiesta; separare la parte cacheabile (editoriale) da quella non cacheabile (community autenticata) è ciò che fa reggere i picchi ai nodi senza moltiplicare le macchine. La separazione fra contenuto e community, che sul piano editoriale è una scelta di prodotto, sul piano dell’infrastruttura è la leva principale di scalabilità.

Limiti

Queste note descrivono ciò che si tiene in piedi con gli strumenti diffusi al marzo 2004, non un’architettura ottimale in assoluto. Il bilanciamento a livello di rete con IPVS chiede competenze di sistema non banali e un nodo bilanciatore che a sua volta va reso ridondante, altrimenti si sposta soltanto il punto unico di guasto. Centralizzare lo stato di sessione sul database condiviso sposta il collo di bottiglia sul database, che diventa la risorsa da proteggere. E il software di community pronto — phpBB, SquirrelMail, Horde — porta con sé la propria superficie di manutenzione e di sicurezza, che su un sito molto visibile non è trascurabile. Ogni scelta qui sopra è uno scambio, e quale ramo convenga dipende dal profilo reale del traffico, che su un portale legato a una radio lo conosci davvero solo dopo i primi picchi.

Un caso concreto di questa architettura — il portale unitedmusic.it costruito da noze per il gruppo Radio 105 attorno al CMS InFlow, con chat, forum, webmail e gestione della server farm — è ripreso in un insight pubblicato da noze: https://www.noze.it/insights/united-music-portale/.

https://www.w3.org/TR/xhtml1/ https://www.phpbb.com/about/history/ https://squirrelmail.org/docs/phpdoc14/ric_ChangeLog.html https://www.horde.org/apps/imp/ https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/4/html/virtual_server_administration/s1-lvs-scheduling-vsa https://www.unitedmusic.it

Immagine di copertina: Rack metallico pieno di server Compaq impilati con cavi e un array di storage NAS in una sala macchine — foto di Jemimus, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Compaq_server_rack_-_IMG_0146.jpg