Ridimensionamento dell'hardware del sito Web

Question

Quindi stavo ascoltando l'ultimo podcast Stackoverflow (episodio 19) e Jeff e Joel hanno parlato un po' della scalabilità dell'hardware del server man mano che un sito web cresce.Da quello che Joel stava dicendo, i primi passaggi sono piuttosto standard:

1. Un server che esegue sia il server web che il database (l'attuale configurazione di Stackoverflow)
2. Un server web e un server database
3. Due server Web con carico bilanciato e un server database

Tuttavia non hanno parlato molto di ciò che verrà dopo.Aggiungi più server web?Un altro server di database?Replicare questo cluster di tre macchine in un data center diverso per la ridondanza?Dove va una startup web da qui nel dipartimento hardware?

Answer 1

Una configurazione ragionevole che supporti un'applicazione web "media" potrebbe evolversi come segue:

1. Singolo server applicazione/database combinato
2. Database separato su un computer diverso
3. Secondo server applicativo con DNS Round-Robin (bilanciamento del carico dei poveri) o ad es. Perlbal
4. In secondo luogo, server di database replicato (per i carichi di lettura, richiede alcune modifiche alla logica dell'applicazione in modo che le letture del database idonee vadano a uno slave)

A questo punto, valutare lo stato attuale delle cose aiuterebbe a determinare un percorso di ridimensionamento migliore.Ad esempio, se il carico di lettura è elevato e il contenuto non cambia troppo spesso, potrebbe essere meglio enfatizzare la memorizzazione nella cache e introdurre cache front-end dedicate, ad es. Calamaro per evitare letture non necessarie del database, anche se sarà necessario considerare come mantenerle coerenza della cache, in genere nell'applicazione.

D'altra parte, se il contenuto cambia abbastanza spesso, probabilmente preferirai una soluzione più articolata;introdurre alcuni altri server applicativi e slave di database per contribuire a mitigare gli effetti e utilizzare la memorizzazione nella cache degli oggetti, come ad esempio memcached per evitare di colpire il database per il contenuto meno volatile.

Per la maggior parte dei siti, questo è probabilmente sufficiente, anche se se diventi un fenomeno globale, probabilmente vorrai iniziare a considerare di avere hardware nei data center regionali e utilizzare trucchi come il bilanciamento del carico geografico per indirizzare i visitatori al "cluster" più vicino ".A quel punto, probabilmente sarai in grado di assumere ingegneri che possano davvero mettere a punto le cose.

Probabilmente il consiglio di ridimensionamento più prezioso a cui riesco a pensare sarebbe quello di evitare di preoccuparmene troppo presto;concentrarsi sullo sviluppo di un servizio che le persone vorranno utilizzare e sul rendere l'applicazione ragionevolmente robusta.Alcune semplici ottimizzazioni iniziali consistono nell'assicurarsi che la progettazione del database sia abbastanza solida e che gli indici siano impostati in modo da non fare nulla di terribilmente pazzo;inoltre, assicurati che l'applicazione emetta intestazioni di controllo della cache che indichino ai browser come memorizzare nella cache i dati.Eseguire questo tipo di lavoro nelle prime fasi della progettazione può produrre vantaggi in seguito, soprattutto quando non è necessario rielaborare l'intero progetto per gestire i problemi di coerenza della cache.

Il secondo consiglio più prezioso che voglio darti è che non dovresti dare per scontato che ciò che funziona per qualche altro sito web funzionerà anche per te;controlla i tuoi log, esegui alcune analisi sul tuo traffico e profila la tua applicazione: scopri dove sono i colli di bottiglia e risolvili.

Answer 2

abbondanza di pesci Architettura

alcuni video interessanti:

Scalabilità di YouTube

Intervista con Dan Farino, System Architect presso Myspace

Answer 3

Joel ha menzionato l'aggiunta di un secondo data center, con la stessa configurazione, e l'assegnazione casuale degli utenti a ciascuno.Le modifiche ai dati vengono registrate e inviate da una posizione all'altra, in modo che entrambe le posizioni contengano tutti i dati.

Answer 4

Il discorso di Cal Henderson (Yahoo) su Scalable Web Architectures Common Patterns & Approaches al Web 2.0 Expo è stato piuttosto interessante.Pensavo ci fosse un video, ma non sono riuscito a trovarlo.Ma ecco le slide:

http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches

Answer 5

Un certo passo successivo sarebbe un cluster di server web (una web farm) e un sistema cluster di server di database (replica o Oracle RAC ecc.eccetera.)

Answer 6

Se sei interessato alla memorizzazione nella cache e all'utilizzo di .Net, esamina il file blocco della memorizzazione nella cache dell'applicazione nella libreria aziendale (ovviamente usalo insieme agli altri punti sopra).