Architettura infrastrutturale dell'e-commerce Initpc

Un e-commerce con oltre 280.000 prodotti a catalogo e più di un milione di immagini non è un sito web: è un sistema che deve restare in piedi mentre i fornitori aggiornano i listini, i clienti comprano, i crawler passano e le esportazioni verso i marketplace girano in sottofondo. Per Initpc, di cui siamo il partner tecnico dal 2006, abbiamo scelto di non appoggiare tutto su un'unica macchina, ma di costruire un'infrastruttura a strati, ciascuno con un compito preciso e sostituibile.

Qui descriviamo com'è fatta quell'infrastruttura oggi, in produzione: Proxmox VE su Ubuntu Server, HAProxy davanti a tutto, Varnish e Redis per la cache, MariaDB per i dati, Docker per i servizi ausiliari, pfSense e Hector LIS sul perimetro. Spieghiamo anche cosa succede quando un pezzo si ferma: è lì che si vede se un'architettura è stata progettata o solo installata. È l'approfondimento infrastrutturale dell'architettura completa del progetto Initpc, che copre anche piattaforma, ricerca, gestionale e AI.

Perché virtualizzare: Proxmox VE su Ubuntu Server

Un WooCommerce con questo catalogo ha carichi di lavoro molto diversi fra loro: il web serve pagine e gestisce PHP, il database esegue query pesanti su prodotti e meta, la cache in memoria vuole RAM e latenza bassa, la ricerca ha un motore a sé, le importazioni lavorano a lotti di notte. Sulla stessa macchina, il picco di uno diventa il rallentamento di tutti.

Abbiamo quindi scelto Proxmox VE installato sopra Ubuntu Server: un hypervisor open source con gestione centralizzata delle macchine virtuali, snapshot, backup integrato e un modello di rete adatto alla segmentazione, sopra una base che aggiorniamo con gli stessi strumenti che usiamo su tutti i sistemi dei nostri clienti, senza dipendere da un'appliance chiusa.

La conseguenza pratica è che ogni ruolo vive nella sua VM: frontend web, database, cache, ricerca, servizi. Ognuna ha risorse assegnate e può essere aggiornata, clonata o spostata senza toccare le altre. È lo stesso approccio che applichiamo nei progetti di virtualizzazione dei server aziendali: separare per ruolo prima ancora che per potenza.

La mappa degli strati e cosa succede se uno cade

La tabella riassume gli strati, il componente che li realizza e l'effetto della sua caduta: è la mappa che usiamo anche noi quando interveniamo.

Strato	Componente	Ruolo	Se cade
Perimetro	pfSense	Firewall e segmentazione di rete	Il traffico esterno non entra: sito irraggiungibile, dati protetti
Monitoraggio	Hector LIS	Rilevamento intrusioni, analisi del traffico	Il sito funziona; si perde visibilità sugli eventi fino al ripristino
Ingresso	HAProxy	Bilanciamento e terminazione TLS	Nessuna richiesta raggiunge il web: da ripristinare per primo
Cache HTTP	Varnish	Serve le pagine già generate	Le richieste vanno ai backend web: sito su, con più carico
Applicazione	VM web con WooCommerce	Genera pagine, carrello, checkout	Varnish serve ciò che ha in cache; le pagine dinamiche si fermano
Cache oggetti	Redis	Object cache e sessioni	WooCommerce legge tutto da MariaDB: più lento, funzionante
Dati	MariaDB	Catalogo, ordini, clienti	Niente ordini: il punto da proteggere con backup
Ricerca	Elasticsearch in Docker	Indice di ricerca e autosuggest	La ricerca torna alle query native; il resto è indipendente
Servizi	Docker, gestionale, importazioni	Sincronizzazione listini e marketplace	Il sito vende con l'ultima sincronizzazione riuscita

La colonna "Se cade" è il criterio di progettazione: nessun componente non essenziale deve trascinare giù la vendita.

Ingresso: HAProxy fra Internet e il web

Tutte le richieste che superano il firewall passano da HAProxy, che svolge due compiti tenuti volutamente fuori dalle VM web.

Il primo è la terminazione TLS: certificati e cifratura sono gestiti in un unico punto. I backend ricevono traffico già decifrato sulla rete interna segmentata, non si occupano di rinnovi, e ogni cambio di policy si fa una volta sola.

Il secondo è il bilanciamento: HAProxy distribuisce le richieste sui backend web e verifica che rispondano; chi smette di rispondere esce dalla rotazione senza intervento umano e rientra quando torna sano. È ciò che rende la crescita orizzontale del web un'operazione di routine: clonare una VM web in Proxmox, aggiungerla ai backend, ricaricare la configurazione.

Cache su due livelli: Varnish e Redis

Su un catalogo così la cache non è un'ottimizzazione, è parte del modello di funzionamento, e i due livelli hanno ruoli diversi.

Varnish sta davanti alle VM web e conserva le pagine già generate: una scheda prodotto o una categoria, una volta prodotte da WordPress, vengono servite alle richieste successive senza far girare PHP né interrogare il database. Carrello, checkout e area cliente sono esclusi per regola. Quando il gestionale aggiorna prezzo o disponibilità di un prodotto, la pagina corrispondente viene purgata e rigenerata alla prima richiesta.

Redis lavora dentro l'applicazione: fa da object cache per WordPress, conservando i risultati delle query più frequenti su opzioni, termini e meta dei prodotti, e gestisce le sessioni. Su WooCommerce, dove una pagina può richiedere decine di letture dal database, alleggerisce MariaDB in modo strutturale. In sintesi: Varnish evita di generare la pagina, Redis rende meno costoso generarla quando è inevitabile.

Dati e servizi: MariaDB e Docker

MariaDB vive in una VM dedicata, dimensionata per tenere in memoria la parte calda delle tabelle di prodotti e meta. È l'unico componente il cui stato non è ricostruibile da altri: per questo ha backup propri, indipendenti da quelli dell'hypervisor.

Sulla VM dei servizi usiamo Docker per tutto ciò che è ausiliario all'applicazione: qui gira Elasticsearch, interrogato dal sito tramite ElasticPress, e qui si appoggiano i processi di importazione e sincronizzazione del gestionale. Il container ci consente di aggiornare o ricostruire un servizio da un'immagine nota senza che un componente rotto trascini gli altri. Il ruolo del motore lo raccontiamo nell'approfondimento su Elasticsearch per la ricerca dell'e-commerce; il flusso dei dati di prodotto in quello sul gestionale e la sincronizzazione dei magazzini.

Storage e backup per oltre un milione di media

Le immagini di prodotto sono il dato più voluminoso e quello che cresce più in fretta: le teniamo su uno storage separato dal disco di sistema delle VM, montato dalle macchine web: un ripristino del web non deve ricopiare i media e un ampliamento dello spazio non richiede di rifare le VM. Il backup segue lo stesso principio: VM salvate come immagini dall'hypervisor, database con dump propri, media con copie incrementali dei soli file nuovi o modificati. Il ripristino viene provato, non solo configurato, perché un backup mai restaurato è un'ipotesi. È il metodo che offriamo anche come servizio di backup Proxmox.

Disponibilità e scalabilità, strato per strato

Il punto più importante non è la potenza, ma il fatto che ogni strato scala per conto suo. Il web scala in orizzontale, con più VM identiche dietro HAProxy. Varnish scala prima aumentando la quota di pagine servite dalla cache, poi aggiungendo memoria. Redis scala sulla RAM e, se serve, separando le sessioni dalla object cache. MariaDB scala in verticale sulla VM e, in prospettiva, con una replica in sola lettura per le query di catalogo. Elasticsearch scala aggiungendo nodi al cluster in Docker. I servizi a lotti si spostano su una VM propria quando cominciano a pesare.

Sul fronte della disponibilità la regola è degradare invece di fermarsi, come mostra la tabella: solo HAProxy e MariaDB spengono davvero il negozio, ed è su quelli che concentriamo monitoraggio e procedure di ripristino. La gestione ordinaria rientra nella nostra assistenza sui server aziendali.

Perimetro e monitoraggio: pfSense e Hector LIS

Un e-commerce espone al pubblico un'applicazione PHP, un checkout e delle API: la difesa non può ridursi ad aggiornare i plugin.

pfSense è il firewall di perimetro e lo strumento con cui abbiamo segmentato la rete. Il web è raggiungibile da HAProxy, il database solo dal web e dai servizi, la gestione di Proxmox solo dalla rete di amministrazione: una compromissione del livello pubblico non deve dare accesso diretto ai dati. Le regole sono poche, esplicite e revisionate quando cambia l'architettura, come nel nostro servizio di gestione e installazione firewall.

Hector LIS è il nostro prodotto di rilevamento intrusioni e monitoraggio del traffico. Osserva ciò che passa dal perimetro e fra i segmenti, riconosce schemi anomali — scansioni, tentativi ripetuti sull'autenticazione, traffico verso destinazioni inattese — e li segnala prima che diventino un incidente. Su un sito con tanto traffico automatico legittimo, crawler e integrazioni comprese, il valore sta nel distinguere il rumore normale da ciò che merita un intervento; ne parliamo nella pagina di Hector LIS.