Capitolo 10 Progettazione dell’architettura

Progettazione di dati e applicazioni per il Web

S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl

Contenuto per concessione del Politecnico di Milano

Capitolo 10

Progettazione dell’architettura




IndiceINDICE

• Introduzione

• Valutazione delle architetture

• Configurazioni architetturali

• Ottimizzazione delle prestazioni

• Web caching




Valutazione delle architetture

INTERNET

• Ogni scelta architetturale va valutata in base a dimensioni critiche:

• Obiettivo di un’architettura: massimizzare queste dimensioni

•Prestazioni

•Scalabilità

•Disponibilità

•Mantenimento dello stato

•Sicurezza




Obiettivi (1)

INTERNET

• 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




Obiettivi (2)

INTERNET

• 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




Vincoli:limitazioni nella scelta

INTERNET

• 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




Scenari di installazione

INTERNET

• 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




I componenti essenziali dell’architettura:

INTERNET

ScriptEngine

Scripts

ClientsComponents

Container

Components

ApplicationServer

Web Server

Databasemanagement

systems

•Web ServerWeb Server

•Script EngineScript Engine

•Application Application ServerServer

•Database ServerDatabase ServerScelte architetturali per decidere:

•Quali componenti vanno su macchine separate

•Quante macchine servono per ogni componente

•Come collegare tra loro componenti




Configurazione 1: SERVER SINGOLO

INTERNET

•Una sola macchina (Host 1) ospita:

•Web Server

•Script execution engine

•Database

Client(browser)

Internet Intranet

° Web server

° Execution engine

° Database

Host 1

Router /firewall

HTTPHTTP




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

Router /firewall

Internet Intranet




SERVER SINGOLO: valutazione

INTERNET

•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

° Web server

° Execution engine

° Database

Host 1




Config. 2: SEPARAZIONE DEL DB SERVER

INTERNET

•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

Client(browser)

Internet

Router /firewall

HTTPHTTP

Web server +Execution engine

Host 1

Database

Host 2

Intranet

Firewall

Demilitarized zone (DMZ)




SEPARAZIONE DEL DB: valutazione

INTERNET

•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

Web server +Execution engine

Host 1

Database

Host 2

Intranet

Firewall

Demilitarized zone (DMZ)




REPLICAZIONE E PARALLELISMO

INTERNET

•prestazioni

•disponibilità

•scalabilità

sono limitate dalla presenza di

UNA SINGOLA ISTANZA DI OGNI COMPONENTE

Soluzione: REPLICAZIONE

•Replico i processi critici (Web Server, script engine,…)

•Tengo in esecuzione più copie in parallelo di ogni processo

Engine

Engine

Engine

Engine

Replicazione : applicabile a qualsiasi livello dell’architettura




Replicazione orizzontale e verticale

INTERNET

•VERTICALE: una singola macchina server ospita più istanze di processo

Vertical cloning

Host 1:

Process 1

Process 2

Process 3

Process 4

Horizontal cloning

Host 1:

Process

Host 2:

Process

Host 3:

Process

Host 4:

Process

Due modi di fare replicazione di applicazioni:

•ORIZZONTALE:L’intera macchina server viene replicata. Ogni macchina ospita una o più istanze di processo




Vantaggi della replicazione INTERNET

•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

Indipendenti dal tipo di replicazione (orizz. o vert.)




Config. 3: REPLICAZIONE DEL WEB SERVER

INTERNET

•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

Client(browser)

Internet

Router /firewall

HTTP

Database

Host 2

Intranet

Firewall

HTTP

HTTP

SHTTP

Web server + engine 1

Web server + engine 2

Web server + engine 3DMZ




Router /firewall

HTTP

HTTP

HTTP

SHTTP

Il problema delle sessioni utente

INTERNET

•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]




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

Cache

Avviso diassenza da

cache

Aggiornamentodella cache

Richiesta

Risposta dacache Server




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




REPLICAZIONE DEL WEB SERVER: valutazione

INTERNET

•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




Configurazione 4: CON APPLICATION SERVER

INTERNET

•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

Client(browser)

Internet

Router /firewall

HTTP

Database

Host 2

Intranet

Firewall

HTTP

HTTP

SHTTP

DMZ

WebServer1 Engine 1

WebServer2 Engine 2

WebServer3 Engine 3Application

server

Applicationserver

Applicationserver




Configurazione 4: CON APPLICATION SERVER

INTERNET

•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

Client(browser)

Internet

Router /firewall

HTTP

Database

Host 2

Intranet

Firewall

HTTP

HTTP

SHTTP

DMZ

WebServer1 Engine 1

WebServer2 Engine 2

WebServer3 Engine 3Application

server

Applicationserver

Applicationserver

Firewall

DMZ2




Application Server: valutazione

INTERNET

•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




Architetture software: il pattern MCV

• Come distribuire le funzionalità software tra web server e application server?

• Architettura Model View Contoller (MVC):

client controller model

view

richiede aggiorna

notificapresenta

• Scopo: separare le funzioni in moduli software ben disaccoppiati e rendere le logiche di business (model) riusabili in contesti diversi, sia Web che non




MVC su Web (MVC 2)

browserController(servlet)

Model(action classes)

View(Template JSP + custom tag

richiestaHTTP

Pagina HTML

Model(oggetti di business

EJB)

Oggetti di stato(JavaBeans)

DBClient Web server + engine

App. server

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




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 sul numero di utenti:– Semplice da stimare per siti Intranet/Extranet (B2B)– Difficilmente valutabile per siti Web pubblici (B2C)




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 parte dell’utente medio (assegnando una probabilità ad ogni pagina)




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

Definisci unaconfigurazione

Verifica performance

Rimuovi colli dibottiglia (se possib.)

Identificacolli di bottiglia

Requisitisoddisfatti?

Stop

Requisiti diperformance

Start

sì

no




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




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




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




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

Client(browser)

Cache

Internet





proxy caching

• Cache basata su proxy HTTP

• Posizionata tra Intranet e Internet

Client(browser)

Client(browser)

Cache

InternetIntranet





Content Delivery Network

• Infrastruttura di cache complessa• Composta da molti nodi anche distribuiti

geograficamente• Gestita da fornitori specializzati

Client(browser)

Client(browser)

Cache 1Cache 3

Cache 2

CDN

° Web server

° Engine

° App. server Database

Internet DMZ Intranet




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

Client(browser)

Client(browser)

Cache° Web server

° Script engine

° Application server Database

Internet DMZ Intranet




Popolazione della cache: metodo push

CacheCopia

periodicaRichiesta

Risposta dacache

server

PUSH:• La copia in cache avviene con periodicità

fissa, indipendentemente dalle richieste




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

Cache

Avviso diassenza da

cache

Aggiornamentodella cache

Richiesta

Risposta dacache Server




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

Capitolo 10 Progettazione dell’architettura

Documents

Transcript of Capitolo 10 Progettazione dell’architettura