Architettura Multi-Server: Separazione delle Competenze

Questo articolo spiega come la nostra infrastruttura utilizzi server specializzati per ottenere scalabilità, affidabilità e prestazioni attraverso la separazione delle competenze.

Il Problema: Limitazioni del Server Monolitico

Eseguire tutto su un unico server causa:

  • Contesa delle risorse: Il server web compete con il servizio di ricerca per CPU/memoria

  • Difficoltà di scalabilità: Impossibile scalare i componenti in modo indipendente

  • Punto singolo di guasto: Un server down = intero sistema down

  • Inefficienza dei costi: Impossibile ottimizzare i tipi di istanza per carico di lavoro

  • Rischio di deployment: Il deployment di un componente influisce su tutti gli altri

Abbiamo bisogno della separazione delle competenze su più server.

La Soluzione: Ruoli Specializzati dei Server

Utilizziamo server specializzati, ciascuno ottimizzato per il proprio carico di lavoro:

graph TB
    subgraph prod[Server ERP di Produzione]
        erp[Gestione interna
HR, Finanza, Produzione
Uptime 24/7
Storage condiviso & email]
    end
    
    subgraph web[Server Sito Web Pubblico]
        www[Sito Web Pubblico
Catalogo prodotti, blog
Uptime 24/7
Dietro CDN]
    end
    
    subgraph dev[Server di Sviluppo/Staging]
        devenv[Dev & Staging
Campagne email
Si spegne di notte/nei weekend]
    end
    
    subgraph search[Server Servizio di Ricerca]
        searchsvc[Ricerca Vettoriale
Estrazione filtri
Ricerche correlate
Uptime 24/7]
    end
    
    subgraph cache[Server Cache - Valkey]
        valkey[Indici RediSearch
Embeddings delle query
Autocompletamento
Uptime 24/7]
    end
    
    www --> searchsvc
    searchsvc --> valkey

Perché Server Separati?

1. Isolamento delle Risorse

Ogni server esegue un tipo di carico di lavoro:

Server Web: Ottimizzato per la gestione di richieste HTTP

  • Alta larghezza di banda di rete

  • CPU moderata

  • Memoria moderata

  • Disco veloce per la cache

Servizio di Ricerca: Ottimizzato per operazioni vettoriali

  • Alta CPU (similarità coseno)

  • Alta memoria (cache degli embedding)

  • Basso I/O su disco

Server Cache: Ottimizzato per l'accesso in memoria

  • Memoria molto alta

  • Bassa CPU

  • Rete veloce

Vantaggio: Nessuna contesa di risorse tra i carichi di lavoro.

2. Scalabilità Indipendente

Possiamo scalare ogni componente in modo indipendente:

  • Traffico elevato? Aggiungi più server web dietro un load balancer.

  • Ricerca lenta? Aggiorna la CPU del server di ricerca o aggiungi repliche.

  • Cache miss? Aumenta la memoria del server cache.

  • Vantaggio: Scala solo ciò che ha bisogno di scalare, non tutto.

3. Isolamento dei Guasti

I guasti sono contenuti:

Servizio di ricerca down? Il sito web serve ancora risultati in cache.

Server cache down? Il servizio di ricerca calcola senza cache (più lento ma funzionale).

Server web down? L'ERP interno non è influenzato.

Vantaggio: I guasti parziali non si propagano a cascata all'intero sistema.

4. Sicurezza del Deployment

Effettuiamo il deployment attraverso ambienti:

Sviluppo → Testa le modifiche con strumenti di debug

Staging → Testa in un ambiente simile alla produzione

Produzione → Effettua il deployment con sicurezza

Vantaggio: Rileva i problemi prima che raggiungano gli utenti.

5. Ottimizzazione dei Costi

Ottimizziamo i costi per server:

  • Server di sviluppo: Si spegne di notte/nei weekend (riduzione del 50% dei costi)

  • Server solo IPv6: Nessun costo per IP elastici (risparmio di $5/mese per istanza)

  • Istanze dimensionate correttamente: Paghi solo per le risorse necessarie per carico di lavoro

  • Vantaggio: Costi infrastrutturali più bassi senza sacrificare le prestazioni.

Flusso dei Dati tra i Server

Comprendere come fluiscono i dati aiuta a spiegare perché la separazione è importante:

Flusso di una Richiesta Utente

Richiesta Pagina Prodotto:

sequenceDiagram
    participant User
    participant CDN
    participant Web as Web Server
    participant Search as Search Service
    participant Cache as Cache Server
    
    User->>CDN: Richiesta pagina prodotto
    CDN->>CDN: Controlla cache
    alt Cache hit
        CDN->>User: Restituisce pagina in cache
    else Cache miss
        CDN->>Web: Inoltra richiesta
        Web->>Search: Ottieni prodotti correlati
        Search->>Cache: Query embeddings
        Cache->>Search: Restituisce risultati
        Search->>Web: Prodotti correlati
        Web->>CDN: Pagina renderizzata
        CDN->>CDN: Cache risposta
        CDN->>User: Restituisce pagina
    end

Flusso Query di Ricerca:

sequenceDiagram
    participant User
    participant Web as Web Server
    participant Search as Search Service
    participant Cache as Cache Server
    
    User->>Web: Invia query di ricerca
    Web->>Search: Inoltra query
    Search->>Search: Estrai filtri
    Search->>Search: Calcola embedding
    Search->>Cache: Ricerca vettoriale
    Cache->>Search: Risultati classificati
    Search->>Web: Corrispondenze prodotti
    Web->>User: Renderizza risultati

Vantaggio: Ogni server fa ciò per cui è ottimizzato.

Strategia di Storage per Server

Server diversi utilizzano strategie di storage diverse:

Server Web

File statici su S3: Immagini, CSS, JS serviti da S3

  • Alta disponibilità

  • Nessun utilizzo di disco locale

  • Compatibile con CDN

Cache locale: Nginx memorizza in cache le pagine renderizzate

  • Accesso rapido ripetuto

  • Invalidazione automatica

Servizio di Ricerca

Array NumPy: Embeddings dei prodotti memorizzati come array binari

  • Operazioni vettoriali veloci

  • Memory-mapped per efficienza

  • 65K prodotti × 768 dimensioni = ~190 MB

File JSON: Mappature filtri, tabelle frasi

  • Leggibili dall'uomo

  • Facili da aggiornare

  • Dimensione ridotta (<10 MB)

Server Cache

Valkey (Redis): Embeddings delle query, query popolari, autocompletamento

  • In memoria per velocità

  • RediSearch per indici vettoriali

  • Persistenza per durabilità

Perché storage diversi?

  • NumPy: Ottimizzato per calcoli vettoriali (similarità coseno)

  • JSON: Ottimizzato per la modifica umana (regole filtri)

  • Valkey: Ottimizzato per ricerche chiave-valore (cache query)

Architettura CDN

Il sito web pubblico si trova dietro una Content Delivery Network:

Cosa Viene Memorizzato in Cache

Asset statici (TTL lungo):

  • Immagini, CSS, JavaScript

  • Font, icone

  • In cache per 1 anno

Pagine prodotto (TTL medio):

  • Descrizioni prodotto

  • Specifiche

  • In cache per 1 ora

Pagine query (TTL breve):

  • Risultati di ricerca

  • Combinazioni di filtri

  • In cache per 5 minuti

Non in cache:

  • Contenuti specifici utente

  • Endpoint API

  • Ricerca dinamica

Perché la CDN è Importante

  • Latenza globale: Le posizioni edge servono i contenuti più vicini agli utenti

  • Protezione origine: La CDN assorbe picchi di traffico, protegge il server origine

  • Mitigazione DDoS: La CDN filtra il traffico malevolo prima che raggiunga l'origine

  • Riduzione costi: Meno richieste all'origine = costi di calcolo inferiori

Pipeline di Deployment

Effettuiamo il deployment attraverso ambienti per rilevare i problemi in anticipo:

Ambiente di Sviluppo

Scopo: Iterazione rapida con strumenti di debug Caratteristiche:

  • Riavvio automatico alle modifiche del codice

  • Pagine di errore dettagliate

  • Barra strumenti di debug

  • Nessuna cache

Vantaggio: Ciclo di feedback rapido per gli sviluppatori.

Ambiente di Staging

Scopo: Test in ambiente simile alla produzione Caratteristiche:

  • Stessa configurazione della produzione

  • Stessa configurazione server (Gunicorn, Nginx)

  • Stesso comportamento di cache

  • Isolato dai dati di produzione

Vantaggio: Rileva problemi specifici della produzione prima del deployment.

Ambiente di Produzione

Scopo: Servire utenti reali Caratteristiche:

  • Ottimizzato per le prestazioni

  • Cache completa abilitata

  • Monitoraggio e allerta

  • Riavvio automatico in caso di crash

Vantaggio: Servizio stabile e affidabile.

Riferimenti

Concetti Tecnici

Servizi AWS

  • CloudFront - Documentazione CDN AWS

  • S3 - Documentazione object storage AWS

  • DynamoDB - Documentazione database NoSQL AWS

Articoli Correlati

Riepilogo

La nostra architettura multi-server separa le competenze su server specializzati:

Server ERP di Produzione:

  • Sistema di gestione interno

  • Uptime 24/7

  • Storage condiviso ed email

Server Sito Web Pubblico:

  • Sito web rivolto ai clienti

  • Uptime 24/7

  • Dietro CDN con file statici su S3

Server di Sviluppo/Staging:

  • Ambienti di test sicuri

  • Elaborazione campagne email

  • Ottimizzato sui costi (si spegne di notte/nei weekend)

Server Servizio di Ricerca:

  • Ricerca per similarità vettoriale

  • Estrazione filtri

  • Embeddings basati su NumPy

Server Cache (Valkey):

  • Cache embeddings delle query

  • Indici vettoriali RediSearch

  • Classificazione query popolari

Vantaggi Chiave:

  • ✅ Isolamento risorse: Nessuna contesa tra carichi di lavoro

  • ✅ Scalabilità indipendente: Scala solo ciò che serve

  • ✅ Isolamento guasti: I guasti non si propagano a cascata

  • ✅ Sicurezza deployment: Testa prima della produzione

  • ✅ Ottimizzazione costi: Istanze dimensionate correttamente, pianificazioni spegnimento

  • ✅ Prestazioni: Cache CDN, strategie di storage specializzate

Questa architettura ci permette di servire milioni di richieste mantenendo alta disponibilità, bassa latenza e costi gestibili.

← Torna all'Indice della Documentazione