Capitolo 10 Progettazione dell’architettura

1. Capitolo 10 Progettazione dell’architettura

2. INDICE Indice • Introduzione • Valutazione delle architetture • Configurazioni architetturali • Ottimizzazione delle prestazioni • Web caching

3. INTERNET Valutazione delle architetture • Ogni scelta architetturale va valutata in base a dimensioni critiche: • Obiettivo di un’architettura: massimizzare queste dimensioni • Prestazioni • Scalabilità • Disponibilità • Mantenimento dello stato • Sicurezza

4. INTERNET Obiettivi (1) • Prestazioni: garanzia di sopportazione del carico di lavoro previsto, in termini di: • N° utenti concorrenti • N° pagine servite/secondo • Tempo di risposta all’utente • Scalabilità: possibilità di aggiungere potenza computazionale al crescere del carico di lavoro, per mantenere elevate prestazioni

5. INTERNET Obiettivi (2) • Disponibilità: garanzia di continuità del servizio anche a fronte di errori e/o malfunzionamenti • Mantenimento dello stato: capacità di memorizzazione delle interazioni e dello stato dell’utente, anche in ambiente distribuito • Sicurezza: protezione delle informazioni, identificazione dell’utente, accesso controllato ai dati

6. INTERNET Vincoli:limitazioni nella scelta • Le scelte architetturale sono vincolate da limiti fisici, economici ed organizzativi: • Costi: il prezzo delle risorse tecnologiche richieste (macchine, reti, software) • Complessità: difficoltà e costi di installazione, gestione e manutenzione • Standard aziendali: risorse pre-esistenti, esperienza pregressa, integrazione con i sistemi aziendali

7. INTERNET Scenari di installazione • Tendenza generale: OUTSOURCING. • Possibili scenari: • Interno: architettura interna all’azienda, gestita dalla divisione IT • Hosting: applicazione installata su architettura di provider esterno, che la gestisce completamente • Housing: applicazione installata internamente su macchine aziendali, gestita poi da un fornitore di servizi esterno

8. INTERNET I componenti essenziali dell’architettura: • Web Server • Script Engine • Application Server • Database Server • Scelte architetturali per decidere: • Quali componenti vanno su macchine separate • Quante macchine servono per ogni componente • Come collegare tra loro componenti

9. INTERNET Configurazione 1: SERVER SINGOLO • Una sola macchina(Host 1) ospita: • Web Server • Script execution engine • Database

10. Il router/ firewall • Router: • Punto di connessione Internet/ Intranet • Consente a browser esterni di connettersi al Web Server • Firewall: • Separa il mondo esterno (Internet) dalla rete aziendale (Intranet) • Blocca i tentativi di intrusione e le richieste non autorizzate (attraverso Access Control Rules) • Può essere un unico dispositivo che svolge le due funzioni Internet Intranet

11. INTERNET SERVER SINGOLO: valutazione • Prestazioni:legata alle caratteristiche della macchina (velocità CPU, HDD, connessione di rete, DBMS). • Criticità: Database e Web Server sulla stessa macchina. Sono due processi che occupano molte risorse (RAM, tempo-CPU) • Scalabilità:unica possibilità è upgrade della macchina (aggiunta RAM, cambio CPU o dischi, …) • Disponibilità:se cade un componente, tutto il sistema è fermo • Mantenimento dello stato:semplice perché su macchina singola (memorizzato nello script engine e/o nel database) • Sicurezza:dati non difesi se il firewall viene superato • Costo:basso, se non serve hw ad alte prestazioni • Complessità:soluzione più semplice da installare e mantenere

12. INTERNET Host 2 Host 1 HTTP HTTP Router / firewall Client Web server + Database (browser) Execution engine Internet Config. 2: SEPARAZIONE DEL DB SERVER Firewall Intranet Demilitarized zone (DMZ) • Web Server e Script execution engine sono ospitati su una macchina (Host 1) • Il Database Server è ospitato su un altro calcolatore (Host 2) • L’aggiunta di un firewall intermedio aumenta la sicurezza dei dati

13. INTERNET SEPARAZIONE DEL DB: valutazione • Prestazioni:dimensionamento migliore delle due macchine • Es.: potenziamento accesso/mirroring dei dischi del DB server • Scalabilità:possibilità di intervenire separatamente su middle tier e data tier • In genere è il middle tier che raggiunge per primo la saturazione; richiede potenziamento per appieno le potenzialità del data tier • Disponibilità:un componente fermo blocca ancora il sistema • Sicurezza:dati su macchina separata sono più sicuri; un firewall tra middle e data tier può bloccare le richieste HTTP (attacchi) e consentire solo le richieste al DB

14. INTERNET Soluzione:REPLICAZIONE • Replicoi processi critici (Web Server, script engine,…) • Tengo in esecuzione più copiein parallelodi ogni processo Engine Engine Engine Engine REPLICAZIONE E PARALLELISMO • prestazioni • disponibilità • scalabilità sono limitate dalla presenza di UNA SINGOLA ISTANZA DI OGNI COMPONENTE Replicazione : applicabile a qualsiasi livello dell’architettura

15. INTERNET Replicazione orizzontale e verticale Due modi di fare replicazione di applicazioni: • VERTICALE: una singola macchina server ospita più istanze di processo • ORIZZONTALE:L’intera macchina server viene replicata. Ogni macchina ospita una o più istanze di processo

16. INTERNET Vantaggi della replicazione Indipendenti dal tipo di replicazione (orizz. o vert.) • Prestazioni consente LOAD-BALANCING: distribuzione del carico di lavoro sui server/ processi in modo bilanciato • ScalabilitàSe necessario, è possibile aggiungere nuove istanze di processi (o macchine server, in cluster) • Disponibilitàconsente FAIL-OVER: se cade uno dei processi, il suo carico di lavoro viene distribuito sui processi funzionanti e il sistema continua a fornire il servizio

17. INTERNET Config. 3: REPLICAZIONE DEL WEB SERVER • Più copie del Web Server funzionanti in parallelo • Router/firewall fa da NETWORK DISPATCHER (bilancia il carico di lavoro tra i diversi Web Server) • Alcuni server possono usare SHTTP per garantire la sicurezza: il dispatcher invia tutte le richieste SHTTP al server sicuro

18. INTERNET Il problema delle sessioni utente • Bisogna garantire che lo stato dell’utente sia mantenuto • SUL LOAD-BALANCING: • STICKY SESSION:Tutte le richieste dello stesso client devono essere inviate dal dispatcher allo stesso server (lo stato utente è memorizzato sul server!) • Il dispatcher deve avere una certa “intelligenza” per riconoscere le richieste di uno stesso utente. Non basta l’IP del client: potrebbe essere usato da più utenti di una intranet • SUL FAIL-OVER: • Le sessioni memorizzate dal Web server guasto devono essere recuperate ed usate dagli altri Web server (che riceveranno le richieste seguenti degli utenti connessi al server guasto) • I dati di sessione devono essere memorizzati in modo duraturo (es. nel DB) [Soluzione costosa per le prestazioni]

19. Popolazione della cache: metodo pull PULL: • La copia in cache avviene nel momento in cui una richiesta del client scatena un avviso di assenza da cache • Usato più spesso

20. Protocolli di gestione della cache • Protocolli che raccolgono regole per l’aggiornamento della cache: • Expiration rules: definiscono la durata della validità di un oggetto in cache • Invalidation rules: criteri per stabilire se l’oggetto in cache non è conforme con l’originale corrente • Sono molto complessi per risorse dinamiche • E’ possibile inserire delle direttive di caching nelle risorse dinamiche (per esempio mediante custom tag nelle pagine JSP) • Proposta di standard: Edge Side Include (ESI) www.esi.org

21. INTERNET REPLICAZIONE DEL WEB SERVER: valutazione • Prestazioni:più elevate grazie al load-balancing • Scalabilità:possibilità di aggiungere nuovi Web server • Disponibilità:se cade un Web server, il suo traffico è ridiretto su una sua replica • Mantenimento dello stato:necessari meccanismi sticky session e memorizzazione stato per il fail-over • Sicurezza:possibilità di avere uno o più server sicuri • Complessità:accresciuta dalla replicazione

22. INTERNET Configurazione 4: CON APPLICATION SERVER • Centralizzazione della business logic nell’App. Server mediante oggetti riusabili (per esempio, Enterprise Java Beans, componenti MS DCOM) • Gli oggetti possono essere invocati da qualunque applicazione aziendale (anche non Web) • La gestione di parallelismo, replicazione, sicurezza, disponibilità è garantita dall’application server ed è trasparente al programmatore

23. INTERNET HTTP Host 2 WebServer1 Engine 1 HTTP HTTP Application Router / Firewall WebServer2 server Engine 2 SHTTP firewall Client Database (browser) Application Internet Intranet DMZ WebServer3 server Engine 3 Configurazione 4: CON APPLICATION SERVER Application server Firewall DMZ2 • Bilanciamento e failover a livello degli oggetti applicativi • Parallelismo DINAMICO: il numero di processi allocati e di istanze di oggetti è scelto a run-time in base al traffico reale • Possibilità di effettuare catene di operazioni sugli oggetti in modo transazionale • Application server isolabile con un ulteriore firewall

24. INTERNET Application Server: valutazione • Prestazioni:elevate grazie al load-balancing dinamico • Scalabilità:virtualmente illimitata replicando l’application server • Disponibilità:capacità di fail-over a livello degli oggetti eseguiti all’interno dell’application server, gestione delle transazioni • Complessità:ambienti generalmente complessi da manutenere

25. Architetture software: il pattern MCV • Come distribuire le funzionalità software tra web server e application server? • Architettura Model View Contoller (MVC): aggiorna richiede model client controller view presenta notifica • Scopo: separare le funzioni in moduli software ben disaccoppiati e rendere le logiche di business (model) riusabili in contesti diversi, sia Web che non

26. MVC su Web (MVC 2) App. server richiesta HTTP Model (oggetti di business EJB) Model (action classes) Controller (servlet) browser View (Template JSP + custom tag Pagina HTML Oggetti di stato (JavaBeans) DB Client Web server + engine Database • Il controller è configurato per dirigere ogni richiesta alla opportuna action • La action class invoca gli oggetti di business necessari • Il controller chiama un template per visualizzare i risultati • Il template traduce (in HTML) i risultati prodotti dalla action, senza neppure sapere come sono stati costruiti

27. Prestazioni delle architetture Web • Le prestazioni sono uno dei criteri più importanti per la scelta dell’architettura • Buon esempio delle considerazioni progettuali necessarie durante il progetto di un’applicazione Web • I requisiti di prestazione sono basati sulnumero di utenti: • Semplice da stimare per siti Intranet/Extranet (B2B) • Difficilmente valutabile per siti Web pubblici (B2C)

28. Metriche di performance • N° di richieste di pagine: valore medio e di picco di richieste inviate dai client [pagine/secondo] • N° di utenti concorrenti: valore medio e di picco di utenti connessi al sito contemporaneamente • Tempo di risposta: massimo intervallo di tempo di attesa di risposta del server da parte del client [time to first byte (TTFB) e time to last byte (TTLB)] • Mix di richieste: per applicazioni con pagine complesse, si definisce il mix plausibile di accessi alle differenti pagine da partedell’utente medio (assegnando una probabilità ad ogni pagina)

29. Algoritmo di ottimizzazione • Idea:rimuovere i colli di bottiglia finché i requisiti non risultano soddisfatti • Collo di bottiglia: problema che si verifica nel componente più lento del sistema

30. Ottimizzazione di prestazioni di applicazioni Web Tre possibilità di intervento: • Ottimizzazione del codice applicativo • Difficile • Potenziamento dell’architettura • Costoso • Web caching:memorizzazione temporanea di risorse in modo da garantire accesso veloce • Basso costo • Basso impatto sull’applicazione • Basse conoscenze tecniche richieste

31. Benefici del Web Caching • Riduzione della latenza di rete: una cache vicina al client consente risposte più veloci perché non è necessario trasmettere informazioni su lunghi tratti di rete • Riduzione di uso della banda e tempo di risposta • Riduzione dello sforzo computazionale: risorse dinamiche vengono recuperate immediatamente invece che ricalcolate

32. Cosa mettere in cache • Tutto ciò che contribuisce a costruire la risposta del Web Server: • Pagine statiche • Files multimediali • Fammenti di pagine dinamiche computate • Dati intermedi consumati dallo scripting per computare pagine • Risultati di queries a database o di altre computazioni

33. Cosa mettere in cache • Tutto ciò che contribuisce a costruire la risposta del Web Server: • Pagine statiche • Files multimediali • Fammenti di pagine dinamiche computate • Dati intermedi consumati dallo scripting per computare pagine • Risultati di queries a database o di altre computazioni

34. Dove mettere la cache 1: browser caching • E’ una directory dell’HD dell’utente • Memorizza pagine e risorse statiche • Annulla la latenza di rete • Non è affidabile in generale, il cliente o il fornitore di contenuti la può disabilitare

35. Dove mettere la cache 2: proxy caching • Cache basata su proxy HTTP • Posizionata tra Intranet e Internet

36. Dove mettere la cache 3: Content Delivery Network • Infrastruttura di cache complessa • Composta da molti nodi anche distribuiti geograficamente • Gestita da fornitori specializzati

37. Dove mettere la cache 4:server accelerators • Buffer posizionato di fronte alla macchina che produce risposte dinamiche • Permette di allocare minor potenza computazionale all’architettura del server

38. Popolazione della cache: metodo push PUSH: • La copia in cache avviene con periodicità fissa, indipendentemente dalle richieste

39. Popolazione della cache: metodo pull PULL: • La copia in cache avviene nel momento in cui una richiesta del client scatena un avviso di assenza da cache • Usato più spesso

40. Protocolli di gestione della cache • Protocolli che raccolgono regole per l’aggiornamento della cache: • Expiration rules: definiscono la durata della validità di un oggetto in cache • Invalidation rules: criteri per stabilire se l’oggetto in cache non è conforme con l’originale corrente • Sono molto complessi per risorse dinamiche • E’ possibile inserire delle direttive di caching nelle risorse dinamiche (per esempio mediante custom tag nelle pagine JSP) • Proposta di standard: Edge Side Include (ESI) www.esi.org