La escalabilidad es la propiedad deseable de un sistema, red, o proceso, que indica su habilidad para reaccionar y adaptarse sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida, para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.
Se podría decir qué es la capacidad de nuestro sistema para soportar mayor carga de trabajo con modificaciones o ampliaciones que sean razonables en término de costo tiempo, tiempo y complejidad.
De manera general podemos hablar de escalado vertical, y horizontal o una combinación de ambas.
Escalado Vertical
Consiste básicamente en aumentar la capacidad de uno o varios elementos concreto de nuestra arquitectura, por ejemplo ampliar la memoria de nuestro servidor central, o sustituir las CPUs por otras de mayor velocidad. En Resumen aumentar las capacidades del servidor, algo muy común cuando usamos virtualización y decimos que a tal hora el servidor tendrá disponible 30% de RAM.
Escalado Horizontal
Es el que detallaremos en el tutorial, se basa en aumentar el número de nodos que desempeñan una misma tarea, usando diferentes tipos de planificación, por ejemplo si tenemos un servidor web saturado, añadimos otro para que se balanceen la carga.
Hablaremos de arquitecturas que pueden ser aplicadas con sistemas linux, usando herramientas open-source iremos desde las más básica a algunas bastantes avanzadas ofreciendo escalabilidad horizontal y resistencia al fallo, todas estas arquitecturas pueden ser aplicadas en cualquier PaaS o con Infraestructura propia.
1. Arquitectura de un nivel
Es la más básica de todas donde solo existe un servidor con Apache y MySQL al cual puede ser accedido de manera remota. Es muy común en páginas con poco margen de visitas o entornos de prueba, no ofrece ningún margen de tolerancia al fallo y es difícil usarla para crecer de manera horizontal.
2. Arquitectura de dos Niveles
Esta vez separamos la base de datos del servidor web ofreciendo un poco de tolerancia al fallo. De esta forma si la base de datos falla el servidor web puede ofrecer contenido de manera estática que no dependa de la base de datos. Y en caso que falle el servidor web aun podemos acceder a la información levantando de nuevo un nuevo servidor Web., El diseño ofrece varias fallas al no ser un diseño muy escalable.
3. Arquitectura de tres niveles
Esta vez empezamos a usar un balanceador de carga que recibirá todas las peticiones de los usuarios. Esta vez ofrecemos un diseño más escalable de manera que si nuestra carga aumenta podemos añadir más servidores web y escalar. Incluso podemos aplicar el autoscaling de modo que se añadan servidores web de manera automática a cierto nivel de carga, o en una hora pico. El problema de este diseño es que podemos saturar a nuestra base de datos.
4. Arquitectura de cuatro niveles
Ahora hacemos uso de un balanceador de carga y un memcached haciendo el sistema más escalable. Con este diseño podemos añadir tanta base de datos y servidores web como sea necesario además de ofrecer tolerancia a fallos. Podemos dividir la carga entre las bases de datos con CASSANDRA ofreciendo una implementación multinodo. Este diseño es mucha más complejo, pero añado mucha mayor tolerancia a fallos y la habilidad de escalar todos sus niveles.
5. Arquitectura de cinco niveles
El contenido de una página web puede ser dividido en estatico y dinamico. Por ejemplo dividimos la capa web en un servidor Apache y otro con aplicaciones JAVA corriendo Jetty o JBoss. Apache ofrece el contenido estático mientras, el servidor de aplicación se encarga del contenido dinámico o generado en el momento. Un ejemplo de esto puede ser la sección FAQ de una web de soporte, al ser un contenido meramente estático puede ser manejado por APACHE/NGINX.
6. Arquitectura de seis niveles
Podemos ser un poco más elegante y añadir una red de entrega de contenidos (CDN), o lo que en AWS se le conoce como Amazon CloudFront CDN, Por ejemplo tenemos una web E-learning y nuestros usuarios descargan las Guías en PDF o Videos de nuestra web. Podemos ahorrar todo ese ancho de banda dedicado a las descargas, Al ofrecerlo desde un CDN que se encargue de ello, El resto de la web puede correr en nuestra infraestructura.
Que bien explicada esta teoría de escalabilidad, me ha gustado, gracias Jonathan