Articulo de referencia

Multitenencia

La arquitectura multiusuario de software es aquella en la que una única instancia de software se ejecuta en un servidor y presta servicio a múltiples usuarios. Los sistemas dise...

La arquitectura multiusuario de software es aquella en la que una única instancia de software se ejecuta en un servidor y presta servicio a múltiples usuarios. Los sistemas diseñados de esta manera son "compartidos" (en lugar de "dedicados" o "aislados"). Un usuario es un grupo de usuarios que comparten un acceso común con privilegios específicos a la instancia de software. Con una arquitectura multiusuario, una aplicación de software está diseñada para proporcionar a cada usuario una parte dedicada de la instancia, incluyendo sus datos, configuración, gestión de usuarios, funcionalidad individual del usuario y propiedades no funcionales . La arquitectura multiusuario contrasta con las arquitecturas de múltiples instancias, donde diferentes instancias de software operan en nombre de distintos usuarios. [ 1 ] Algunos expertos consideran la arquitectura multiusuario una característica importante de la computación en la nube . [ 2 ] [ 3 ]

Adopción

Historia de las aplicaciones multiusuario

Las aplicaciones multiusuario han evolucionado a partir de tres tipos de servicios y combinan algunas características de los mismos:

  1. Tiempo compartido : Desde la década de 1960, las empresas alquilaban espacio y capacidad de procesamiento en ordenadores centrales ( tiempo compartido ) para reducir los gastos informáticos. A menudo, también reutilizaban aplicaciones existentes, simplemente añadiendo un campo en la pantalla de inicio de sesión para especificar el ID de la cuenta del cliente. Con base en este ID, los contables del ordenador central podían facturar a cada cliente el uso real de CPU, memoria y disco/cinta.
  2. Aplicaciones alojadas: Desde la década de 1990, los proveedores de servicios de aplicaciones (ASP) tradicionales alojaban aplicaciones (ya existentes) en nombre de sus clientes. Dependiendo de las limitaciones de la aplicación subyacente, los ASP se veían obligados a alojar las aplicaciones en máquinas separadas (si no se podían ejecutar varias instancias de las aplicaciones en la misma máquina física) o como procesos separados . Las aplicaciones multiusuario representan una arquitectura más madura [ 4 ] que permite un servicio similar con un menor coste operativo.
  3. Aplicaciones web : Las aplicaciones web populares orientadas al consumidor (como Hotmail ) se desarrollan con una única instancia de aplicación que da servicio a todos los clientes. Las aplicaciones multiusuario representan una evolución natural de este modelo, ya que ofrecen personalización adicional a grupos de usuarios dentro de (por ejemplo) la misma organización cliente.

Relación con la virtualización

En un entorno multiusuario, varios clientes comparten la misma aplicación, que se ejecuta en el mismo sistema operativo , en el mismo hardware y con el mismo mecanismo de almacenamiento de datos. La distinción entre los clientes se establece durante el diseño de la aplicación, de modo que no comparten ni acceden a los datos de los demás.

Esto contrasta con la virtualización , donde los componentes se transforman de manera que cada aplicación del cliente parece ejecutarse en una máquina virtual independiente.

La virtualización ofrece una alternativa para la multitenencia que evita cambios arquitectónicos significativos: en lugar de rediseñar una aplicación para dar servicio a múltiples usuarios desde una única instancia, un proveedor puede utilizar la tecnología de virtualización para alojar múltiples instancias aisladas de la aplicación en uno o más servidores. Esto resulta atractivo porque rediseñar una aplicación para la multitenencia puede ser costoso, especialmente para los proveedores de software que también siguen ofreciendo una versión local de su producto para un solo usuario y que, de otro modo, tendrían que mantener dos productos distintos. Cuando las aplicaciones se empaquetan como dispositivos virtuales , la misma imagen del dispositivo se puede implementar en ubicaciones alojadas por el ISV, en las instalaciones del cliente o en ubicaciones de terceros de confianza, y migrarse de un sitio de implementación a otro con el tiempo.

Economía de la multitenencia

Ahorro de costes

La multitenencia permite ahorros de costos que van más allá de las economías de escala básicas que se logran al consolidar los recursos de TI en una sola operación. [ 3 ] Una instancia de aplicación generalmente conlleva una cierta cantidad de sobrecarga de memoria y procesamiento que puede ser sustancial cuando se multiplica por muchos clientes, especialmente si los clientes son pequeños. La multitenencia reduce esta sobrecarga al distribuirla entre muchos clientes. Otros ahorros de costos pueden provenir de los costos de licencia del software subyacente (como sistemas operativos y sistemas de administración de bases de datos). Dicho de forma sencilla, si puede ejecutar todo en una sola instancia de software, solo tiene que comprar una licencia de software . El ahorro de costos puede verse eclipsado por la dificultad de escalar la única instancia a medida que crece la demanda: aumentar el rendimiento de la instancia de un solo servidor solo se puede hacer comprando hardware más rápido, como CPU rápidas, más memoria y sistemas de disco más rápidos, y por lo general estos costos crecen más rápido que si la carga se dividiera entre varios servidores con aproximadamente la misma capacidad agregada. [ 5 ] Además, el desarrollo de sistemas multiusuario [ 5 ] es más complejo y las pruebas de seguridad son más rigurosas porque se mezclan los datos de varios clientes.

Complejidad

Debido a la complejidad adicional de personalización y la necesidad de mantener metadatos por inquilino , las aplicaciones multiinquilino requieren un mayor esfuerzo de desarrollo. Deben tenerse en cuenta aspectos como la partición de los datos de los inquilinos, el almacenamiento de las extensiones de esquema por inquilino y el aislamiento de los recursos compartidos. [ 6 ]

Gestión de lanzamientos

La arquitectura multiusuario simplifica el proceso de gestión de versiones . En un proceso tradicional, los paquetes que contienen cambios en el código y la base de datos se distribuyen a los equipos cliente o servidores; en el caso de una sola instancia, esto implicaría un servidor por cliente. Estos paquetes deben instalarse en cada equipo. Con el modelo multiusuario, el paquete generalmente solo necesita instalarse en un único servidor. Esto simplifica enormemente el proceso de gestión de versiones, y la escalabilidad ya no depende del número de clientes.

Al mismo tiempo, la arquitectura multiusuario incrementa los riesgos e impactos inherentes a la aplicación de una nueva versión. Dado que una única instancia de software da servicio a varios usuarios, una actualización en esta instancia puede provocar interrupciones del servicio para todos ellos, incluso si la actualización solo es solicitada y útil para uno. Además, algunos errores y problemas derivados de la aplicación de la nueva versión podrían manifestarse en la vista personalizada de la aplicación de otros usuarios. Debido a las posibles interrupciones del servicio , el momento de la aplicación de la versión puede estar restringido según el horario de uso de cada usuario.

Arquitectura de datos

Una decisión de diseño central en una aplicación multiusuario es cómo se aíslan los datos de cada usuario dentro del almacenamiento compartido. Se suelen describir tres enfoques: [ 7 ]

  • Bases de datos independientes: los datos de cada inquilino se almacenan en su propia base de datos. Esto proporciona el mayor aislamiento y simplifica la copia de seguridad y la restauración por inquilino, pero tiene la menor densidad y el mayor coste por inquilino.
  • Base de datos compartida, esquemas separados: los inquilinos comparten una base de datos, pero cada uno tiene su propio conjunto de tablas. Esto ofrece un nivel moderado de aislamiento en entornos de alta densidad.
  • Base de datos y esquema compartidos: todos los inquilinos comparten las mismas tablas, con una columna de identificación que distingue las filas. Esto permite alcanzar la mayor densidad y el menor coste por inquilino, pero traslada la responsabilidad del aislamiento a la capa de aplicación y es la opción más exigente en cuanto a seguridad.

Modelos de aislamiento de inquilinos

A nivel de despliegue, la forma en que se asignan los recursos a los inquilinos se describe comúnmente mediante tres patrones, extraídos de la guía de arquitectura SaaS de Amazon Web Services : [ 8 ]

  • Arquitectura en silo: cada inquilino dispone de recursos dedicados, como una infraestructura o base de datos independiente. Esto proporciona el mayor aislamiento y evita conflictos entre inquilinos, pero ofrece la menor eficiencia en el uso de recursos y el mayor coste por inquilino.
  • Pool: los inquilinos comparten recursos comunes y escalables. Esta es la forma clásica de multitenencia y ofrece las mayores economías de escala, a costa de un aislamiento más complejo y una mayor exposición al problema de los vecinos ruidosos .
  • Puente: un sistema híbrido en el que algunos componentes están aislados y otros agrupados. Por ejemplo, en un sistema descompuesto en microservicios , un servicio que maneja datos regulados puede estar aislado, mientras que otros permanecen agrupados.

Desafíos

Cuando los usuarios comparten recursos de computación, almacenamiento o red, un solo usuario que genere una carga desproporcionada puede degradar el rendimiento de los demás, una situación conocida como el problema del " vecino ruidoso ". Las medidas para mitigarlo incluyen la limitación de velocidad por usuario, las cuotas de recursos y el aislamiento de los usuarios con alta demanda en recursos dedicados.

Mejores prácticas

Según Marc Brooker, en una arquitectura multiusuario, las cargas de trabajo no relacionadas ni correlacionadas deben agruparse. Esto se debe a que la mezcla de diferentes cargas de trabajo, con distintas necesidades y patrones, oculta los patrones de cada una. Agrupar las cargas de trabajo reduce la relación pico-promedio del sistema; las cargas de trabajo individuales pueden utilizar más recursos durante los picos sin aumentar significativamente la estructura de costos general del sistema, lo que contribuye a una mayor eficiencia de costos. Cabe destacar que varias cargas de trabajo de la misma aplicación, cliente o sector tienden a comportarse como una sola. [ 9 ]

Requisitos

Personalización

Las aplicaciones multiusuario suelen requerir un alto grado de personalización para satisfacer las necesidades de cada organización objetivo. La personalización generalmente incluye los siguientes aspectos:

  • Personalización de marca: permite a cada organización personalizar el aspecto de la aplicación para que coincida con su imagen corporativa (a menudo denominada " piel " distintiva).
  • Flujo de trabajo : adaptarse a las diferencias en el flujo de trabajo para que lo utilice una amplia gama de clientes potenciales.
  • Extensiones del modelo de datos : compatibilidad con un modelo de datos extensible para brindar a los clientes la capacidad de personalizar los elementos de datos administrados por la aplicación para satisfacer sus necesidades específicas.
  • Control de acceso : permite que cada organización cliente personalice de forma independiente los derechos y restricciones de acceso para cada usuario .

Calidad del servicio

Se espera que las aplicaciones multiusuario proporcionen seguridad , robustez y rendimiento adecuados [ 10 ] entre múltiples usuarios, lo cual es proporcionado por las capas inferiores a la aplicación en el caso de aplicaciones de múltiples instancias.

Referencias

  1. Krebs, Rouven (2012). "Consideraciones arquitectónicas en aplicaciones SaaS multiusuario" (PDF) . Actas de la 2.ª Conferencia Internacional sobre Computación en la Nube y Ciencia de los Servicios (CLOSER 2012) . Conferencia sobre Computación en la Nube y Ciencia de los Servicios. SciTePress. Archivado del original (PDF) el 21 de febrero de 2015. Recuperado el 21 de febrero de 2015 .
  2. Wainewright, Phil (30 de octubre de 2010). "Definiendo el verdadero significado de la nube" . ZDNet . CBS Interactive . Recuperado el 17 de marzo de 2016. Multitenencia . Compartir una única instancia operativa agrupada de toda la infraestructura de arriba a abajo es más que una simple conveniencia del proveedor; es la única manera de lograr realmente la escala de la nube.
  3. 1 2 Wilder, Bill (2012). Patrones de arquitectura en la nube: Uso de Microsoft Azure . O'Reilly Media, Inc. pág. 78. ISBN  9781449357993En la nube , los servicios multiusuario son estándar: servicios de datos, servicios DNS, hardware para máquinas virtuales, balanceadores de carga, gestión de identidades, etc.
  4. ¿Qué es el modelo de madurez de la arquitectura SaaS? Forbes, 20 de noviembre de 2019
  5. 1 2 Kleppmann, Martin (2017). «Fiabilidad, escalabilidad y mantenibilidad». Diseño de aplicaciones con gran cantidad de datos: Las grandes ideas detrás de los sistemas fiables, escalables y mantenibles (1.ª ed.). O'Reilly Media. págs. 18–19 . ISBN   978-1449373320.
  6. Aulbach, S (2011). "Extensibilidad y compartición de datos en bases de datos multiusuario en evolución". 2011 IEEE 27th International Conference on Data Engineering . pp. 99–110 . doi : 10.1109/ICDE.2011.5767872 . ISBN  978-1-4244-8959-6. S2CID 17242970 . 
  7. Chong, Frederick; Carraro, Gianpaolo; Wolter, Roger (junio de 2006). "Arquitectura de datos multiusuario" (PDF) . Biblioteca MSDN . Microsoft Corporation.
  8. "Modelos Silo, Pool y Bridge" . SaaS Lens – AWS Well-Architected Framework . Amazon Web Services . Consultado el 26 de junio de 2026 .
  9. Creación de arquitecturas SaaS multiusuario . O'Reilly Media. 2024. ISBN 9781098140601.
  10. Zeng, Jiaan (2014). Distribución equitativa de recursos entre múltiples inquilinos en almacenes de datos NoSQL . Conferencia Internacional IEEE de Computación en Clúster (CLUSTER) de 2014. IEEE. doi : 10.1109/CLUSTER.2014.6968761 .