Bueno, hace tiempo que no escribo un post. Asi que bien podía hablar de UNIX con todo lo que ya he hablado o dedicarme a hacer amigos, pero he preferido lo primero por eso de que me ahorro el tocho de argumentación.

A lo que venía a hablar aquí y hoy es sobre escalabilidad LAMP. Donde LAMP es obviamente Linux-Apache-MySQL-PHP (no, no voy a hablar de como escalar lampáras… aunque suena bien, sin duda).

Normalmente, cuando uno planifica un pequeño proyecto (wrrong, los pequeños proyectos carecen de planificación) no tiene vistas de futuro… Aunque si ahora alguien dice morir de éxito no sería nuevo (eso sí, sonaría irónico).

La planificación suele ser la misma, un servidor guarro que actua de servidor MySQL, Apache, etc. y la mayoría de las veces en un shared. Cuanto eso no cabe ahí, se mueve a un dedicado. Pero cuando el dedicado más caro se queda pequeño o no termina de ser rentables hay que buscar salida.

Como todo depende:

• Si tiene una gran cantidad de ficheros, tocaría externalizar bien el alojamiento (S3) o bien utilizar servidores de gama baja para alojar ficheros. Esto puede salir más caro que S3 debido a los costes de ubicación geográfica y a los costes de mantenimiento.
• Si tiene un gran consumo de CPU (ciclos), lo más probable es que se trate de una aplicación web (leerse como Meebo, por dar un ejemplo que no me vienen a la mente). Entonces se puede usar E3, aún con el riesgo de volverse demasiado caro.
• Si en los casos anteriores se decide uno por la opción de own-way, lo más económico es comprar servidores a precio de coste (por ejemplo, DELL en forma de blade) con configuraciones óptimas para cada parte de la web (las configuraciones entre filer, servidor web y backend sql varían, obviamente: en el filer y en el servidor SQL hay que evitar cuellos de botella I/O por lo que se necesitan discos rápidos y con buen rendimiento. Leerse como RAID 0 y su gran riesgo, con discos con RPM altos (o SSD, quién sabe, pero ya no RAID) o mejor aún, RAID 0+1, todo seguro y con gran rendimiento.
• Cuando la aplicación/proyecto/otros crece mucho (ver demasiado) se puede pensar en hacer load-balancing entre filers según enrutado de paquetes, con cosas del tipo RTM (real-time-monitoring) para saber que disco está más descargado. Recuerda: viva NFS y el coder que le parió.
• Los servidores Apache pueden “tirar” del filer: siempre y cuando no contengan archivos de grandes tamaños, suele ser la solución ideal. Para archivos grandes, externalizarlos en servidores de bajo coste con unidades de disco amplias, y con servidores http ligeros (ie: lighttpd).
• Se hace load-balancing mediante Squid que a su vez cachea peticiones, en este caso es recomendable redundancia, prescindir de este punto si no es posible usar n+1. No olvidarse del load-balancing (preferiblemente por hardware).
• En el backend SQL tocará bien usar la filosofía master-slave cuando se usa más de un servidor o usar replicación. De la primera manera en uno se escribirá y en otro se leerá, de la otra todos los cambios se propagarán. Para esto, MySQL Proxy puede servir (aunque todavía no lo he probado personalmente).

Eso si, nunca viene mal reescribir la aplicación como comenté en otro post muy similar a este pero con un enfoque menos brutal.