Adrián Ribao - Blog

Según el número de usuarios de una web crece, los recursos del servidor disminuyen rápidamente. ¿Qué pasos debemos tomar para garantizar el acceso a la web?
Como estamos a punto de ver, si hemos planeado esta situación de antemano, se puede resolver el problema con bastante rapidez y eliminar de esta forma los cuellos de botella.

Debemos tener en cuenta siempre la arquitectura shared nothing. Esta arquitectura se basa en el concepto que los distintos servidores necesarios para que funcione la web no deben compartir el hardware. Debemos tener por lo menos dos máquinas, una para el servidor web y otro para la base de datos. Ambos efectúan un intenso trabajo bajo fuertes cargas, y disfrutan comiéndose toda la RAM que el servidor le pueda proporcionar. Por este motivo es mejor que cada uno conviva en su propia máquina donde puedan aprovechar el 100% del hardware. Es una buena idea que el tamaño de la RAM del servidor de bases de datos sea superior a la base de datos utilizada.
También es buena idea servir el contenido estático (fotos, videos...) por un servidor web ligero. lighthttpd y Tux, llevan a cabo esta taréa de forma excelente (entre otras cosas por supuesto). Generalmente no es una buena idea tener un solo servidor web para servir el contenido dinámico y el contenido estático, especialmente cuando existen miles de pequeños archivos, como por ejemplo avatars de usuarios, ya que con toda probabilidad aparecerán problemas de lectura/escritura en los discos y se generarán importantes cuellos de botella.

Hasta ahora disponemos de tres servidores, uno para servir el contenido dinámico de la web, otro para el contenido estático y el último para las bases de datos. Con esta arquitectura resulta más sencillo comprobar el estado de cada uno de ellos de forma separada, y observar la cantidad de recursos que consumen. Si vemos que el rendimiento de la base de datos baja podemos añadir mas RAM al servidor o comprar uno nuevo y configurar un pool de servidores. Lo mismo con el servidor web, donde podemos añadir un balanceador de carga y mejorar a la vez la seguridad y el rendimiento.
Cuando se añade un nuevo servidor de bases de datos, se requieren varios pasos extra para hacerlo funcionar correctamente. Obviamente todos los servidores deben contener los mismos datos y devolver lo mismo por cada consulta. Es interesante pgpool II para postgreSQL, realiza un buen trabajo y tiene unas características muy interesantes tales como replicación de la base de datos, balanceo de carga, consultas paralelas, y pooling de conexiones. Con esta configuración, la aplicación web se debe conectar a pgpool y pgpool se encarga de gestionar y hablar con los distintos servidores de BBDD.
Cuando sea el servidor web el que está sufriendo fuertes cargas, se añade un balanceador de carga que distribuya las peticiones entre los diferentes servidores web disponibles. Existen varios balanceadores de carga disponibles bajo una licencia de código abierto.

La escalabilidad web es bonita e incluso divertida, pero según el sistema crece, no solamente el hardware es importante. Una de las cosas que no debemos olvidar y que tiene una importancia vital en el rendimiento son los sistemas de caché. Se pueden configurar uno o varios servidores de caché para ayudar a la BBDD y al servidor web a reducir considerablemente su carga de trabajo. Entre ellos memcache, es un gran servidor con un excelente rendimiento.
Con un buen sistema de caché y servidores optimizados, se pueden servir mas de 10 millones de páginas al día con solamente tres servidores, uno para contenido dinámico, otro para contenido estático y otro para la BBDD. Esto equivale aproximadamente a 115 peticiones por segundo.

Hay que tener siempre en cuenta la escalabilidad desde las primeras etapas de diseño de la web. Es muy recomendable dedicar tiempo a minimizar el número de peticiones que se realizan al servidor. Por ejemplo, si una web tiene muchas imágenes, archivos de javascript, CSS, etc... el navegador realizará una petición al servidor por cada archivo, y estas peticiones son relativamente lentas. Por decirlo de alguna forma, es mejor descargar una sola imagen de 100Kb que que cuatro de 25Kb.

Podéis obtener más información y casos de estudio en: http://highscalability.com/