Hace algún tiempo, en un libro de certificación de Arquitecto J2EE, leí una definición de arquitecto que me gustó por lo simple y lo gráfica que es:

“un analista se preocupa de que la aplicación funcione para un usuario, un arquitecto se preocupa de que la aplicación funcione para 1000 usuarios”.

En efecto unas de las preocupaciones de un arquitecto es garantizar que la aplicación pueda dar servicio a un gran número de usuarios de manera simultánea.

Esta preocupación se acentúa  con la explosión del web 2.0. Los usuarios de una aplicación ya no se cuentan por miles, ni por cientos de miles… se cuentan ya por millones como el caso de Facebook (más de 700 millones) o de Twitter (más de 200 millones).

Y para lograr este objetivo de escalabilidad las aplicaciones web ofrecen una gran ventaja como es que  los usuarios no tienen los recursos en exclusiva (como la conexión con base de datos) sino que se establecen mecanismos como pools de recursos para poder dar servicio a muchos más usuarios de los que nominalmente se podría. Partiendo de la evidencia empírica de que no todos los usuarios potenciales están usando a la vez la aplicación.

¿qué es lo que impide una alta escalabilidad de las aplicaciones?

Por supuesto, puede haber muchos motivos que limitan la capacidad de la aplicación para dar servicio a un grán número de usuarios. Sin embargo, quiero detenerme en las que considero las dos más importantes:

  • el uso de memoria de sesión
  • el uso de base de datos




Por lo tanto, si queremos una arquitectura altamente escalable por lo tanto deberíamos atacar de raíz estos dos aspectos:

Uso de la memoria de sesión

La memoria de sesión se guarda transitoriamente en los servidores de la aplicación. Son datos propios de cada usuario conectado que se mantienen durante la navegación.

Precisamente la memoria es el recurso más vital de un servidor de aplicaciones (y más escaso) por lo que hay que mantener el tamaño de sesión al mínimo. Un número entorno a 40 Kb debería bastar para esto. Sin embargo, a poco que multipliquemos estos 40 Kb por 30.000 o 40.000 usuarios estaremos hablando ya de unas cifras considerables.

Además, debido a la necesidad de alta disponibilidad de las aplicaciones web, es necesario que el servidor replique el contenido de la sesión a los otros servidores gastando un tiempo precioso en CPU y en uso de la red.

Una forma de mejorar esto, de forma radical, es eliminar totalmente la memoria de sesión. Es decir, que el servidor no guarde el estado de la negación del usuario. ¿y cómo se logra esto? está claro que hay que guardarla en algún lado. ¿donde entonces? pues en la máquina del cliente, que normalmente irá sobrada de memoria.

Una posible implementación de una aplicación de este tipo, es una desarrollo de cliente rico (RIA) con un framework javascript que contenga la presentación y el controlador de la aplicación, y por tanto, la memoria de la sesión.

En el servidor únicamente se expondrán los servicios (sin estado) que consumirá el cliente. Una implementación tipo REST para este tipo de servicios encajará muy bien ya que puede devolver datos en modo XML o en JSON (más fácil de procesar desde el javascript).

Accesos a base de datos

Las bases de datos relaciones que se usan normalmente entornos corporativos (como Oracle y DB2) no están pensadas para tan gran cantidad de clientes (miles o cientos de miles). Se necesitan muchos recursos de la máquina para dar servicio a un cliente.

Una posible solución a esto es evitar en lo posible los accesos a la base de datos usando memorias caché distribuidas. Oracle Coherence y SoftwareAG Terracotta son buenos ejemplos de esto.

Con el uso de estos cachés distribuidos, de lectura y escritura, a la que pueden acceder todos los servidores de la aplicación se puede reducir hasta un 90% los accesos a la base de datos.

Conclusiones

El uso de la memoria de sesión y los accesos a la base de datos son los grandes enemigos de la escalabilidad de las aplicaciones web.

Debemos hacer todo lo posible por limitarlos al máximo. Incluso si es posible, eliminarnos totalmente o reducirlos a la mínima expresión.

Por primera vez, tenemos herramientas potentes, con soporte y respaldados por grandes fabricantes. No nos descuidemos en esto.

Comparte esta entrada:
Share