Sharding (sic!) Livello Web al fine di prevenire un collo di bottiglia del bilanciamento del carico?

Question

In che modo i siti Web di grandi dimensioni che non possono essere completamente apolidi raggiungono un'estrema scalabilità a livello Web?

Ci sono siti come eBay e Amazon, che non possono essere completamente apolidi, in quanto hanno un carrello o qualcosa del genere. Non è possibile codificare tutti gli articoli nel carrello nell'URL, né è possibile codificare tutti gli articoli in un cookie e inviarlo ad ogni connessione. Quindi Amazon memorizza semplicemente l'ID di sessione nel cookie che viene inviato. Quindi capisco che la scalabilità del livello Web di eBay e Amazon dovrebbe essere molto più difficile della scalabilità del motore di ricerca di Google, dove tutto può essere codificato riposante nell'URL.

D'altra parte, sia eBay che Amazon si sono ridimensionati in modo assolutamente massiccio. Si dice che ci siano circa 15000 server di applicazioni J2EE su eBay.

In che modo questi siti gestiscono entrambi: estrema scalabilità e stato? Poiché il sito è stato, non è possibile eseguire un semplice bilanciamento DNS. Quindi si potrebbe presumere che queste aziende abbiano un bilanciamento del carico basato su hardware come BigIP, Netscaler o qualcosa del genere, che è l'unico dispositivo dietro il singolo indirizzo IP di quel sito. Questo bilanciamento del carico decodificherebbe SSL (se codificato), ispezionerebbe il cookie e deciderebbe in base all'ID sessione di quel cookie quale server delle applicazioni tiene la sessione di quel cliente.

Ma questo non può proprio funzionare poiché nessun singolo bilanciamento del carico è in grado di gestire il carico di migliaia di server applicazioni? Immagino che anche questi bilanciatori del carico hardware non si adattino a tale livello.

Inoltre, il bilanciamento del carico viene eseguito in modo trasparente per l'utente, ovvero gli utenti non vengono inoltrati a indirizzi diversi, ma rimangono tutti collettivamente su www.amazon.com per tutto il tempo.

Quindi la mia domanda è: c'è qualche trucco speciale con il quale si può ottenere qualcosa di simile allo sharding trasparente del livello Web (non il livello del database come si fa comunemente)? Finché il cookie non viene ispezionato, non è possibile sapere quale server delle applicazioni tiene questa sessione.

Modifica: Mi sono reso conto che c'è solo bisogno di trasparenza, se è necessario che il sito sia sottoposto a spidering e preferito. Per esempio. se il sito è una semplice app Web, qualcosa come un sistema di prenotazione di biglietti aerei o ferroviari, non dovrebbe esserci alcun problema nel reindirizzare gli utenti a specifici cluster di server Web dietro URL diversi, ad es. a17.ticketreservation.com. In questo caso specifico, sarebbe possibile utilizzare solo più cluster di server delle applicazioni, ognuno dietro il proprio bilanciamento del carico. È interessante notare che non ho trovato un sito che utilizza questo tipo di concetto. Modifica: ho trovato questo concetto discusso su highscalability.com , dove la discussione si riferisce a un articolo di Lei Zhu chiamato " Bilanciamento del carico lato client per applicazioni Web 2.0 " . Lei Zhu utilizza il cross scripting per eseguire questo bilanciamento del carico lato client in modo trasparente.

Anche se ci sono degli svantaggi, come il bookmarking, xss, ecc., Penso che ciò sembri un'ottima idea per certe situazioni speciali, vale a dire applicazioni web quasi prive di contenuti, che non devono essere controllate o contrassegnate ( es. sistemi di prenotazione dei biglietti o qualcosa del genere). Quindi non è necessario eseguire il bilanciamento del carico in modo trasparente.

Potrebbe esserci un semplice reindirizzamento dal sito principale al server, ad es. un reindirizzamento da www.ticketreservation.com a a17.ticketreservation.com. Da lì in poi l'utente rimane sul server a17. a17 non è un server, ma un cluster stesso, mediante il quale è possibile ottenere la ridondanza.

Il server di reindirizzamento iniziale potrebbe essere esso stesso un cluster dietro un bilanciamento del carico. In questo modo, è possibile ottenere una scalabilità davvero elevata, poiché il bilanciamento del carico principale dietro www viene colpito solo una volta all'inizio di ogni sessione.

Ovviamente, il reindirizzamento a diversi URL sembra estremamente sgradevole, ma con semplici applicazioni web (che non devono essere comunque ragionate, deep-bookmark o deep-bookmark), questo dovrebbe essere solo un problema ottico per l'utente?

Il cluster di reindirizzamento potrebbe eseguire il polling del carico dei cluster dell'applicazione e adattare di conseguenza i reindirizzamenti, ottenendo così un bilanciamento e non una semplice distribuzione del carico.

Answer 1

Facile. I server Web, che sono apolidi, sono bilanciati in base al carico. I server delle applicazioni (livello intermedio), che contengono i dati della sessione, non lo sono. I server Web possono utilizzare il cookie ID sessione per determinare quale server delle app contattare.

Memcached e Microsoft Velocity sono prodotti che risolvono esattamente questa esigenza.

Modifica: come fa un web server a sapere quale app server contattare? Questo è incorporato nell'hash dell'ID sessione e può essere fatto genericamente come preferisci. Potrebbe essere semplice come il tuo ID di sessione essendo server: guid. Memcached basa comunque l'hash.

Il bit importante è che il client deve essere in grado di capire quale server delle app contattare in modo apolide. Il modo più semplice per farlo è incorporarlo nella chiave, anche se un registro (forse sul proprio livello) funzionerebbe anche e potrebbe fornire una certa tolleranza d'errore.

Modifica2: tornare indietro alcune Ebay interviste , potrei aver ottenuto i dettagli delle loro implementazione un po 'sbagliata. Non eseguono la memorizzazione nella cache e non indicano lo stato nel livello intermedio. Ciò che fanno è disporre di un livello intermedio bilanciato del carico (server di app) partizionato per funzione. Quindi, avrebbero un pool di server per, ad esempio, la visualizzazione di oggetti. E poi un altro pool per la vendita di articoli.

Questi server di app hanno un " intelligente " DAL che instrada verso database frammentati (partizionati sia per funzione che per dati, quindi Utenti A-L su Database1, Utenti M-Z su Database2, Articoli 1-10000 su Articoli1, ecc.)

Non hanno uno stato nel livello intermedio perché sono partizionati per funzione. Pertanto, una normale esperienza utente coinvolgerebbe più di un pool di server di app. Supponi di visualizzare un articolo (ViewAppServerPool), quindi vai a fare un'offerta per un articolo (BidAppServerPool). Tutti questi server di app dovrebbero rimanere sincronizzati, il che richiede una cache distribuita per gestire tutto. Ma la loro scala è così grande che nessuna cache distribuita potrebbe gestirla in modo efficace, né un singolo server di database. Ciò significa che devono frammentare il livello dati e qualsiasi implementazione della cache dovrebbe essere suddivisa attraverso gli stessi confini.

Questo è simile a quello che ho postato sopra, appena spostato di un livello. Invece di fare in modo che il server Web determini quale server delle app contattare, il server delle app determina quale database contattare. Solo, nel caso di Ebay, potrebbe effettivamente colpire oltre 20 server di database a causa della loro strategia di partizione. Ma, ancora una volta, il livello senza stato ha una sorta di regola (s) che utilizza per contattare il livello con stato. Le regole di Ebay, tuttavia, sono un po 'più complicate di quanto il semplice "Utente1 sia su Server10". regola che stavo spiegando sopra.

Answer 2

Potresti trovare utile il seguente documento, che presenta la progettazione e l'implementazione di un sistema di archiviazione di valore-chiave altamente disponibile che alcuni dei servizi principali di Amazon usano per fornire un & # 8220; always-on & # 8221; esperienza:

Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swami Sivasubramanian, Peter Vosshall e Werner Vogels , & # 8220; Dynamo: l'archivio valori-chiave altamente disponibile di Amazon & # 8221 ;, negli Atti del il 21 ° simposio ACM sui principi dei sistemi operativi, Stevenson, WA, ottobre 2007.

Answer 3

Probabilmente dovresti far parte del team di ingegneri in uno di questi posti per saperlo con certezza, ma ci sono persone che hanno fatto ipotesi istruite da discorsi e altre informazioni che sono uscite da entrambi i luoghi:

Ebay Architecture e Amazon Architecture

Solo un singolo bilanciamento del carico da solo nel mondo di oggi è un po 'l'equivalente del round robin DNS degli anni passati. Oggi hai cose come anycast che ti permettono di giocare a tutti i tipi di trucchi. Puoi essere abbastanza sicuro che artisti del calibro di ebay e amazon usano i bilanciatori del carico e ne usano molti.

Potresti ridurlo un po 'di più quando pensi a come potrebbe funzionare perché gran parte del traffico è apolide. In una singola richiesta per una pagina ci sono potenzialmente molti oggetti che non hanno bisogno di conoscere lo stato. Rimuovi quegli oggetti dall'immagine servendoli da un sistema senza stato (è qui che entra in gioco il anycast) e il numero di richieste diminuisce drasticamente.

Se ciò non porta al punto in cui un singolo servizio di bilanciamento del carico è in grado di gestire il carico, il passaggio successivo consiste nel interrompere le transazioni utilizzando il routing IP e / o il geo-DNS. Siti grandi come eBay e Amazon si troveranno in un numero di data center diversi con un gran numero di connessioni Internet per ciascuno. Prendi tutto ciò che arriva da internet pop quest-west e lo invii al datacenter della costa occidentale " quest " server, qualsiasi cosa da att-ovest viene inviata al datacenter della costa occidentale "att" server, tutto da quest-east e va al datacenter della costa orientale " quest " server, ecc. Ognuno di questi sistemi potrebbe essere un'isola, un unico servizio di bilanciamento del carico in grado di gestire il carico, alcuni dei sistemi di bilanciamento del carico in circolazione possono gestire centinaia di migliaia di transazioni al secondo, anche crittografate con SSL. Sul retro si replica in blocco in ogni data center costantemente ma può non essere sincronizzato.

Answer 4

Non so come lo facciano, ma ecco alcuni suggerimenti:

• Per evitare di sovraccaricare un host di bilanciamento del carico stesso, utilizzare DNS OR round-robin
• Reindirizza client diversi a indirizzi cluster diversi in base a carico, impostazioni, geolocalizzazione, ecc.

Per distribuire il carico di livello intermedio,

• Incorpora l'ID del server di sessione di livello intermedio all'interno del cookie dell'ID di sessione, come altri hanno suggerito. In questo modo la casella front-end che colpisci è irrilevante, possono essere aggiunti / rimossi senza alcun impatto.
• Se è sufficientemente importante, disporre di un meccanismo per reindirizzare i client a un server di livello intermedio alternativo durante una sessione in modo da poter essere rimosso per manutenzione ecc.
• I client iniziano a utilizzare un server di livello intermedio appena commissionato all'avvio di una nuova sessione

Per distribuire il carico del database back-end

• " " convenzionale; condivisione di "tempo reale" dati per account o per utente
• Replica asincrona di dati che cambiano lentamente o relativamente statici; gli utenti potevano vederlo obsoleto (ma non molto spesso). I server Web e di livello intermedio si collegano a un database locale nella propria posizione