Escalado de hardware del sitio web

Question

Estaba escuchando el último podcast de Stackoverflow (episodio 19), y Jeff y Joel hablaron un poco sobre cómo escalar el hardware del servidor a medida que crece un sitio web.Por lo que decía Joel, los primeros pasos son bastante estándar:

1. Un servidor que ejecuta tanto el servidor web como la base de datos (la configuración actual de Stackoverflow)
2. Un servidor web y un servidor de base de datos
3. Dos servidores web con carga equilibrada y un servidor de base de datos

Aunque no hablaron mucho sobre lo que viene después.¿Agregáis más servidores web?¿Otro servidor de base de datos?¿Replicar este clúster de tres máquinas en un centro de datos diferente para lograr redundancia?¿A dónde va una startup web desde aquí en el departamento de hardware?

Answer 1

Una configuración razonable que admita una aplicación web "promedio" podría evolucionar de la siguiente manera:

1. Servidor único combinado de aplicación/base de datos
2. Base de datos separada en una máquina diferente
3. Segundo servidor de aplicaciones con DNS round-robin (equilibrio de carga de los pobres) o, p. Perlbal
4. Segundo, servidor de base de datos replicado (para cargas de lectura, requiere algunos cambios en la lógica de la aplicación para que las lecturas de bases de datos elegibles vayan a un esclavo)

En este punto, evaluar la situación actual ayudaría a determinar un mejor camino de ampliación.Por ejemplo, si la carga de lectura es alta y el contenido no cambia con demasiada frecuencia, podría ser mejor enfatizar el almacenamiento en caché e introducir cachés frontales dedicados, p. Calamar para evitar lecturas innecesarias de la base de datos, aunque deberá considerar cómo mantener coherencia de caché, normalmente en la aplicación.

Por otro lado, si el contenido cambia con una frecuencia razonable, probablemente preferirá una solución más amplia;introducir algunos servidores de aplicaciones y esclavos de bases de datos más para ayudar a mitigar los efectos y utilizar el almacenamiento en caché de objetos, como memcached para evitar acceder a la base de datos en busca de contenido menos volátil.

Para la mayoría de los sitios, esto probablemente sea suficiente, aunque si se convierte en un fenómeno global, entonces probablemente querrá comenzar a considerar tener hardware en centros de datos regionales y utilizar trucos como el equilibrio de carga geográfico para dirigir a los visitantes al "clúster" más cercano. ".En ese momento, probablemente estará en condiciones de contratar ingenieros que realmente puedan ajustar las cosas.

Probablemente el consejo de escalamiento más valioso que se me ocurre sea el de evitar preocuparse demasiado pronto;Concéntrese en desarrollar un servicio que la gente quiera utilizar y en hacer que la aplicación sea razonablemente sólida.Algunas optimizaciones tempranas fáciles son asegurarse de que el diseño de su base de datos sea bastante sólido y que los índices estén configurados para que no esté haciendo nada dolorosamente loco;Además, asegúrese de que la aplicación emita encabezados de control de caché que indiquen a los navegadores cómo almacenar en caché los datos.Hacer este tipo de trabajo desde el principio del diseño puede generar beneficios más adelante, especialmente cuando no es necesario volver a trabajar todo para solucionar los problemas de coherencia de la caché.

El segundo consejo más valioso que quiero darte es que no debes asumir que lo que funciona para otro sitio web funcionará para ti;verifique sus registros, ejecute algunos análisis de su tráfico y perfile su aplicación; vea dónde están sus cuellos de botella y resuélvalos.

Answer 2

muchos peces Arquitectura

algunos videos interesantes:

Escalabilidad de Youtube

Entrevista con Dan Farino, arquitecto de sistemas de Myspace

Answer 3

Joel mencionó agregar un segundo centro de datos, con la misma configuración, y luego asignar usuarios aleatoriamente a cada uno.Los cambios en los datos se registran y envían de una ubicación a otra, de modo que ambas ubicaciones contengan todos los datos.

Answer 4

La charla sobre patrones y enfoques comunes de arquitecturas web escalables de Cal Henderson (Yahoo) en Web 2.0 Expo fue bastante interesante.Pensé que había un vídeo, pero no lo encontré.Pero aquí están las diapositivas:

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

Answer 5

El siguiente paso sería un grupo de servidores web (una granja web) y un sistema agrupado de servidores de bases de datos (replicación u Oracle RAC, etc.).etc.)

Answer 6

Si está interesado en almacenar en caché y utilizar .Net, consulte la bloque de almacenamiento en caché de aplicaciones en la biblioteca empresarial (por supuesto, use esto junto con los otros puntos anteriores).