Multi-tenancy: diseñando con la escalabilidad en mente

Me ha gustado mucho un artículo que un compañero me ha pasado sobre el concepto de multi-tenancy. Se podría definir como la habilidad para ubicar varios clientes dentro de la infrastructura de una aplicación. Por otra parte, también me ha gustado una entrada de Jose Manuel Suarez en su blog en la que habla de optimización vs. hardware. Pensándolo esta tarde, me he dado cuenta de que, aunque no lo parezca a simple vista, existe bastante relación entre ambas entradas.

Como Fred Chong comenta en su blog, conseguir multi-tenancy es un trabajo duro. Por ejemplo, supongamos que tenemos una aplicación empresarial relativamente típica con un par de servidores web, un par de servidores de aplicaciones y un par de bases de datos, y que decidimos hacer nosotros el hosting de la aplicación. Realizar el hosting de la aplicación es mucho más práctico para la empresa proveedora de software ya que evita muchos problemas como el despliegue o la gestión de parches de cliente, al tiempo que hace más fácil la automatización; sin embargo, al mismo tiempo añade mucho coste en cuanto a infraestructura.

Por ejemplo el caso anterior está bien para un único cliente, ¿pero qué pasa cuando tenemos 5 clientes? En ese caso ya empezamos a hablar de 10 servidores web, 10 servidores de aplicaciones y 10 bases de datos a gestionar, y eso siempre que algún cliente no exija sistemas de demostración en cuyo caso las cifras pueden crecer todavía más. Excluyendo la administración, esto plantea dos problemas principales: el coste del hardware y el coste de las licencias de todo el software que estemos utilizando (servidores de aplicaciones, sistemas de monitorización, motores especiales como por ej. sistemas de comunicación para entornos financieros, sistemas de mensajería, etc.). ¿Qué pasa si estos 5 clientes son pequeños y no compensa el mantener esta infraestructura para ellos?

Esta es una de las razones por las que en aplicaciones complejas la aproximación "slashdot" o "youtube" de añadir servidores no funciona demasiado bien, ya que el escenario es más complejo.



El diagrama de aquí arriba muestra las diferentes técnicas que pueden aliviar el problema de multi-tenancy. Las técnicas están ordenadas por densidad, siendo las de más arriba las que permiten compartir más clientes dentro de nuestra infrastructura, y las de más abajo las que menos clientes permiten compartir.

No voy a entrar demasiado en detalle en las diferentes técnicas, porque eso es otra historia, pero básicamente cada una de esas técnicas tiene un coste asociado. Ya sea en cuanto a necesitar soluciones propietarias, o ser complejo de mantener, o ser funcionalidades específicas de un sistema operativo. Por ejemplo, la virtualización es una solución excelente para solucionar el problema de multi-tenancy pero tiene el problema de que el número de máquinas virtuales que podremos alojar en un servidor físico es limitado y a mayores tenemos el coste de las licencias (o del mantenimiento) del sistema de virtualización que utilicemos.

Y bueno, entonces, ¿cómo se puede arreglar todo este embrollo?

La solución ideal es crear aplicaciones que puedan utilizar varios clientes a la vez. Si la aplicación es muy grande, entonces se debería dividir en diferentes módulos independientes entre sí y que pudiesen ser compartidos por diferentes clientes. Por ejemplo, un sistema de trading financiero podría tener por una parte en un servidor la gestión de las carteras de los diferentes traders, en otro servidor la gestión de las órdenes de compra y venta de todos estos traders, y en otro servidor la gestión de informes para los clientes y los bancos.

Esto es lo que Fred Chong llama "Shared Application Instance", el compartir porciones de una aplicación con diferentes clientes. Esta es la aproximación que permite la mayor densidad de tenancy en un sistema, y la que ofrece la mejor escalabilidad. En estos sistemas, denominados comúnmente no-homogéneos, es mucho más sencillo gestionar los recursos del sistema. Por ejemplo, si sabemos que la gestión de órdenes necesita más recursos que la generación de informes, podemos dedicar servidores más potentes a alojar el cluster del sistema de órdenes mientras que reservaremos servidores más modestos para el reporting.

El problema, y ahora es cuando vuelvo a enlazar con el post de Jose Manuel, es que migrar una aplicación existente para que pueda dividirse y servir a diferentes clientes es algo muy complejo y muy costoso si la aplicación no se ha diseñado desde un principio para ello. En muchos casos estaríamos ante un reto casi tan complejo como el tener que reimplementar la aplicación. Ahí está la importancia de diseñar y crear una arquitectura desde un principio pensando en la escalabilidad. La optimización prematura siempre es algo malo, pero no lo es sin embargo el diseño en busca de la escalabilidad y el rendimiento. El diseño en busca de escalabilidad puede que no de frutos en los primeros meses, puede que añada complejidad lógica en el sistema (por ejemplo con desacoplamiento de APIs y módulos, uso de sistemas de mensajería, etc.), pero a largo plazo, cuando el sistema crece, y cuando hay más clientes a los que servir, es cuando se ven realmente los beneficios.

Vaya ladrillo que me ha quedado. Felicidades si has sido capaz de llegar hasta aquí :-)