Cosa sono, a cosa servono e utilizzo dei Servizi Web Replicati

Servizi Web Replicati

Sin dalla nascita del web si è cercato di sviluppare tecniche capaci di soddisfare la richiesta di accessi alle risorse sempre più veloci ed efficienti. Una tra le tecniche utilizzate che ha avuto maggiore successo è la replicazione dei servizi web (in inglese web service replication), la quale consiste nel mettere a disposizione degli utenti più server contenenti in maniera ridondante le stesse informazioni.

La replicazione può essere di due tipi:

1. Locale: si parla di replicazione locale o cluster-based se tutte le repliche sono collocate fisicamente nello stesso luogo.
2. Geografica: si parla di replicazione geografica se le repliche sono situate in luoghi differenti.

L’obiettivo di tali tecnologie è la minimizzazione dell’URT (User Response Time), ottenuta tramite una diminuzione del carico dei server e, per quanto riguarda le soluzioni geograficamente distribuite, anche della rete; inoltre così facendo si ottiene anche un aumento del grado di affidabilità del servizio: quest’ultimo infatti rimane disponibile anche nel caso in cui uno dei server dovesse avere dei problemi o dovesse diventare irraggiungibile a causa di un distacco temporaneo dalla rete.

Diverse sono le architetture che permettono di gestire servizi web replicati in maniera ottimale. Possiamo distinguerne sostanzialmente due categorie: architetture server-side ed architetture client-side.
Sono stati inoltre studiati diversi algoritmi finalizzati all’ottimizzazione della gestione dei servizi web replicati. Gli algoritmi deterministici o statici operano in base a parametri statici, senza raccogliere dati o eseguire elaborazioni. Gli algoritmi probabilistici o dinamici sono invece più complessi, poiché si adattano alle situazioni esterne della rete modificando il proprio comportamento in base ai dati ottenuti.

Gestione server-side

Le architetture server-side sono studiate per poter gestire la scelta della replica a livello server; il funzionamento dei relativi algoritmi è quindi completamente invisibile al client. La più semplice architettura server-side è quella basata sul DNS, con un algoritmo di Round Robin per poter gestire la scelta della replica da utilizzare: in pratica viene utilizzato il DNS per permettere una rotazione nelle repliche utilizzate.

Gli indirizzi IP di tutte le repliche vengono fatti corrispondere ad un unico nome di dominio. Quando un client richiede di tradurre il nome di dominio in indirizzo IP, effettua una richiesta al DNS il quale, in base ad una politica di Round Robin, ad ogni richiesta fornisce un indirizzo IP differente. La scelta dell’indirizzo IP da ritornare al client viene fatta tra quelli relativi a tutte le repliche, in maniera da distribuire le richieste sui vari server.

Tale soluzione è senz’altro vantaggiosa per quanto riguarda la semplicità di implementazione e, nel caso in cui tutte le repliche abbiano capacità computazionali analoghe, fornisce una buona distribuzione di carico. Tuttavia questa soluzione presenta anche alcuni difetti. Il DNS non effettua alcun controllo, e non è quindi capace di eseguire una gestione probabilistica delle richieste: di conseguenza l’algoritmo che viene utilizzato deve essere deterministico, e non può adattarsi allo stato attuale della rete. Inoltre i meccanismi di caching degli indirizzi IP (che possono essere sia client-side che implementati nella gerarchia dei server DNS) possono compromettere la distribuzione del carico stravolgendo la politica di Round-Robin, oltre che minare l’affidabilità del sistema nel caso in cui venisse a mancare proprio la replica il cui indirizzo IP è stato memorizzato nella cache.

Uno sviluppo del DNS Round Robin, prevede una politica leggermente differente, in cui viene utilizzato il campo TTL (Time To Live) nelle risposte inviate dal DNS così da forzare il client a richiedere nuovamente la traduzione del nome di dominio in indirizzo IP, una volta trascorso il lasso di tempo specificato proprio nel campo Time To Live. In questo modo è possibile anche gestire algoritmi probabilistici ed il risultato complessivo è un sistema più robusto e più prestante nel caso in cui i server non siano omogenei in termini di posizione geografica e capacità di calcolo.

Un’altra architettura utilizzabile è quella che sfrutta il metodo Redirect del protocollo HTTP. L’idea di fondo consiste nell’utilizzare una risposta HTTP di tipo 301 o 302 in modo da forzare il client ad effettuare nuovamente la richiesta della risorsa ad un altro server. Lo svantaggio di questa soluzione sta nel fatto che il client deve effettuare due connessioni e due richieste distinte per ottenere la risorsa, provocando un decadimento delle prestazioni. Inoltre, il server principale deve comunque essere contattato da tutti i client, e questo può portare a blocchi del servizio o a vistosi rallentamenti nel caso di molte richieste contemporanee. Infine va fatto notare che con questo modello il server principale (quello che si occupa di redirigere le richieste verso le altre repliche) rappresenta un unico punto di guasto (single point of failure in letteratura), abbassando di molto il grado di affidabilità e la robustezza dell’intero sistema. Questo metodo si rivela quindi buono solo se l’obbiettivo che ci si prefigge consiste unicamente nel distribuire il carico tra i server e non nel diminuire l’URT.

Se il servizio è replicato localmente, si può inoltre utilizzare un router per gestire la distribuzione del carico. Chiaramente però un router può gestire solo algoritmi molto semplici, per cui può essere necessario utilizzare una macchina che funga da dispatcher a cui vengono indirizzate tutte le richieste, e che si fa carico di redirigerle alla replica ritenuta più adatta. Tale architettura permette di gestire algoritmi molto complessi con relativa semplicità, però ha nel dispatcher il punto debole. Un malfunzionamento di tale macchina, infatti, mette in crisi tutto il sistema rendendo il servizio web inaccessibile.

Gestione client-side

Scegliere un modello di gestione delle repliche client-side significa affidare interamente al client, sia esso un browser od un proxy server, la scelta delle repliche da utilizzare.
L’algoritmo più semplice per gestire l’utilizzo delle repliche client-side è l’algoritmo mirror-based, che consiste nel fornire all’utente un elenco degli URL relativi al servizio web richiesto, detti mirror, lasciando che sia l’utente stesso a scegliere quale tra questi utilizzare.
In tal modo viene impiegata una singola replica per il download e, per diminuire l’URT, si fa affidamento alla scelta dell’utente, che dovrebbe essere volta a ricercare il server tra quelli geograficamente più vicini o che in passato hanno fornito una buona ampiezza di banda. Inoltre va notato che, sempre a causa del fatto che è l’utente a scegliere la replica da utilizzare, non è possibile usare strategie efficaci per ottimizzare la distribuzione di carico. Tuttavia poiché non occorrono particolari risorse e tecnologie per mettere in pratica una soluzione di questo tipo, diversi server presenti su internet, come ad esempio ftp.debian.org, ne fanno uso.

Un modello più complesso consiste in un algoritmo capace di gestire accessi paralleli contemporaneamente su diverse repliche. Viene proposto di ottenere informazioni sulle dimensioni della risorsa oggetto della richiesta tramite una richiesta di tipo HEAD, suddividendone in seguito il corpo in parti uguali. Ognuna di tali parti verrà richiesta separatamente ad una delle repliche disponibili, l’elenco delle quali viene ottenuto tramite una interrogazione al DNS. Il tutto avviene in maniera trasparente, senza bisogno di alcun intervento da parte dell’utente.

Gli ottimi risultati ottenuti tramite tale algoritmo hanno fornito l’idea di base da cui nasce il proxy C2LD.
Il modello di C2LD si differenzia da quello proposto da Rodriguez per il fatto che i frammenti in cui viene divisa la risorsa non sono decisi a priori, ma la dimensione di ogni frammento viene calcolata dinamicamente in base alle prestazioni che la replica a cui viene richiesto ha fatto registrare nelle transazioni precedenti.
Ad ogni replica viene associato un datarate, che rappresenta la velocità con cui la replica è in grado di fornire i dati richiesti Ogni volta che una replica termina di inviare un frammento, il datarate relativo a tale replica viene aggiornato.

Inoltre il C2LD, come già in passato aveva suggerito Rodriguez, utilizza una tecnica di accodamento di richieste. Ciò significa che, sfruttando la possibilità fornita da HTTP/1.1 di avere connessioni persistenti, vengono effettuate richieste alle repliche prima che esse abbiano terminato di inviare i dati relativi alle richieste precedenti. Si cerca in tal modo di ottimizzare l’utilizzo della rete, al fine di diminuire il più possibile l’URT.
Si possono comunque classificare i modelli proposti per la gestione client-side dei servizi web replicati secondo diverse caratteristiche: criteri di valutazione delle repliche, tipologia della selezione dei server, metodi di download.

Criteri di valutazione delle repliche

Si possono distinguere sostanzialmente tre tipi di criteri per la valutazione delle repliche da utilizzare: statico, dinamico e basato su di uno storico.
Nel primo caso la valutazione viene fatta a priori e non viene modificata nel tempo. Un esempio può essere l’algoritmo mirror-based.
Se il criterio di valutazione è basato su di uno storico vengono memorizzate informazioni sulle prestazioni delle repliche ad ogni download, e su tali dati (ottenuti quindi in tempi precedenti) vengono basate le scelte attuali.

Utilizzare un criterio di valutazione dinamico significa invece tenere traccia in maniera costante della bontà delle repliche, modificando i valori relativi alle stesse anche durante la fase di download. Il C2LD, nella sua versione precedente, utilizzava proprio quest’ultimo metodo.

Scelta delle repliche

Al momento di decidere le repliche da utilizzare effettivamente per ottenere la risorsa richiesta nel più breve tempo possibile si possono fare sostanzialmente tre scelte. La prima possibilità consiste nello scegliere un’unica replica, considerata la migliore, e nell’effettuare il download unicamente da tale replica. Un’altra possibilità è quella di scegliere di utilizzare per il download tutte le repliche disponibili. Infine, si può scegliere di utilizzare un insieme limitato di repliche, scartando solo quelle che vengono considerate troppo lente o inaffidabili.

Metodi di download

Come si è potuto osservare, sono stati proposti in letteratura diversi modelli riguardanti il download. Il modello più semplice consiste nello scaricare la risorsa per intero, senza spezzarla.
I modelli più complessi utilizzano invece richieste HTTP con campo Range per distribuire il download della risorsa su diverse connessioni TCP, al fine di poter sfruttare più di una replica contemporaneamente.
Questo modello consiste nella gestione di porzioni del file di dimensioni costanti: ciò significa che tutte le transazioni scaricano la stessa quantità di dati.
Infine, il modello C2LD, effettua download di porzioni della risorsa di dimensione variabile.