Modelos de multiinquilinato para una solución multiinquilino

Hay muchas maneras de considerar cómo trabajar con inquilinos en la solución. El enfoque depende de si y cómo comparte recursos entre los inquilinos. De forma intuitiva, es posible que quiera evitar compartir los recursos, pero ese enfoque se vuelve costoso a medida que la empresa se escala y incorpora más inquilinos.

Cuando considere los distintos modelos de multiinquilinato, es útil tener en cuenta primero cómo se definen los inquilinos de su organización, cuáles son los motores de la empresa y cómo planea escalar la solución. En este artículo se proporcionan instrucciones para ayudar a los responsables técnicos a evaluar los modelos de arrendamiento y sus ventajas.

Definición de un inquilino

Primero debe definir un inquilino para su organización. Tenga en cuenta quién es su cliente o quién recibe sus servicios. Hay dos modelos comunes:

• Negocio a negocio (B2B): Si los clientes son otras organizaciones, es probable que asigne sus inquilinos a esos clientes. Sin embargo, considere si los clientes tienen divisiones, como equipos o departamentos, y si tienen presencia en varios países o regiones. Puede que tenga que asignar un solo cliente a varios inquilinos si estos subgrupos tienen requisitos diferentes. Del mismo modo, es posible que un cliente quiera mantener dos instancias del servicio para que puedan mantener separados entre sí sus entornos de desarrollo y producción. Normalmente, un solo inquilino tiene varios usuarios. Por ejemplo, todos los empleados del cliente son usuarios de un solo inquilino.

• Negocio a consumidor (B2C): Si los clientes son consumidores, a menudo es más complicado relacionar clientes, inquilinos y usuarios. En algunos escenarios, cada consumidor podría constituir un inquilino independiente. Sin embargo, analice si la solución la van a usar familias, grupos de amigos, clubs, asociaciones u otras agrupaciones que puede que deban acceder y administrar juntos los datos. Por ejemplo, un servicio de streaming de música podría admitir usuarios individuales y familias, y podría tratar cada uno de estos tipos de cuenta de forma diferente, en lo que se refiere a la separación en inquilinos.

La definición de inquilino afecta a algunos de los elementos que debe tener en cuenta o enfatizar al diseñar la solución. Por ejemplo, considere los siguientes tipos de inquilinos:

• Si sus inquilinos son personas o familias individuales, es posible que tenga que tener en cuenta cómo administra los datos personales y sobre las leyes de soberanía de datos en cada jurisdicción que atienda.

• Si los inquilinos son empresas, es posible que deba tener en cuenta los requisitos de los clientes para el cumplimiento normativo y el aislamiento de sus datos. Asegúrese de cumplir un objetivo de nivel de servicio (SLO) especificado, como el tiempo de actividad o la disponibilidad del servicio.

Decidir qué modelo se va a usar

Seleccionar un modelo de tenencia no es únicamente una decisión técnica. También es una decisión comercial. Debe tener en cuenta las siguientes preguntas:

• Objetivos empresariales: Considere si reduce el costo de cada inquilino o maximiza la experiencia del inquilino se alinea más estrechamente con los objetivos estratégicos.

• Conformidad: Considere si sus clientes están dispuestos a aceptar todas las formas de multiinquilinato. ¿Cómo afecta cada modelo de multitenencia a sus requisitos de cumplimiento o a los de sus clientes?

• Escalabilidad: Considere si una solución de un solo inquilino puede escalar a sus aspiraciones de crecimiento futuras.

• Automatización: Tenga en cuenta el tamaño del equipo de operaciones y la cantidad de administración de la infraestructura que puede automatizar.

• Contratos de nivel de servicio (ANS): Tenga en cuenta si los clientes esperan que cumpla los ANS o si tiene objetivos de nivel de servicio (SLO) a los que se dirige.

Si espera que su negocio se escale para incorporar a un gran número de clientes, es muy importante implementar una infraestructura compartida. De lo contrario, tendrá que mantener un conjunto de instancias de recursos grande y en crecimiento. Es probable que la implementación de recursos individuales de Azure para cada cliente sea inestable, a menos que aprovisione y use una suscripción dedicada para cada inquilino. Al compartir la misma suscripción de Azure en varios inquilinos, se pueden aplicar cuotas y límites de recursos de Azure , y los costos operativos para implementar y volver a configurar estos recursos aumentan con cada nuevo cliente.

Por el contrario, si espera que su negocio solo tenga unos cuantos clientes, puede que valga la pena considerar la posibilidad de tener recursos de un solo inquilino dedicados a cada cliente. Asimismo, si los requisitos de aislamiento de los clientes son muy exigentes, un modelo de infraestructura de un solo inquilino podría ser adecuado, aunque mucho más costoso.

Inquilinos e implementaciones

A continuación, debe determinar si debe distinguir entre inquilinos lógicos e implementaciones.

Por ejemplo, considere un servicio de streaming de música. Inicialmente, puede crear una solución que pueda controlar fácilmente miles o incluso decenas de miles de usuarios. Sin embargo, a medida que su organización sigue creciendo, es posible que tenga que duplicar la solución o algunos de sus componentes para escalar a la nueva demanda de clientes. Para realizar esta tarea, debe determinar cómo asignar clientes específicos a instancias específicas de la solución. Puede asignar clientes aleatoriamente, geográficamente o rellenando una sola instancia y, a continuación, iniciando otra instancia, también conocida como empaquetado de contenedores. Sin embargo, es probable que tenga que mantener un registro de los clientes y la infraestructura donde residen sus datos y aplicaciones para que pueda enrutar su tráfico a la ubicación correcta. En este ejemplo, podría representar a cada cliente como un inquilino independiente y asignar usuarios a la implementación que contiene sus datos. Este enfoque crea una relación de uno a varios entre clientes e implementaciones, y puede mover clientes entre implementaciones como prefiera.

En cambio, analice una empresa que crea software en la nube para despachos jurídicos. Es posible que los clientes insistan en tener su propia infraestructura dedicada para mantener el cumplimiento de los requisitos normativos. Por lo tanto, debe estar preparado para implementar y administrar muchas instancias diferentes de la solución desde el principio. En este ejemplo, una implementación siempre contiene un solo inquilino y un inquilino se asigna a su propia implementación dedicada.

Una diferencia clave entre inquilinos e implementaciones es cómo se aplica el aislamiento. Cuando varios inquilinos comparten una única implementación (conjunto de infraestructura), se suele confiar en el código de la aplicación y en un identificador de inquilino que está en una base de datos, para mantener separados los datos de cada inquilino. Cuando los inquilinos tienen sus propias implementaciones dedicadas, tienen su propia infraestructura, por lo que puede ser menos importante que el código tenga en cuenta un entorno multiinquilino.

A veces, se hace referencia a las implementaciones como superinquilinos o stamps.

Cuando reciba una solicitud para un inquilino específico, debe asignarla a la implementación que contiene los datos de ese inquilino, como se muestra en el diagrama siguiente:

El diagrama se divide en tres secciones principales, inquilinos, la solución y el identificador de inquilino e identificador de implementación. Las flechas apuntan de los inquilinos A, B, C y D a un cuadro con la etiqueta de asignación de inquilinos dentro de la sección de la solución. Esta sección también incluye un servidor web y una base de datos para la implementación 1 y la implementación 2. Otra flecha apunta desde el cuadro de asignación de inquilinos a la sección que contiene los identificadores de inquilino e implementación. Los inquilinos A y B tienen un identificador de implementación de 1, y los inquilinos C y D tienen identificadores de implementación de 2.

Para más información, consulte Asignación de solicitudes a inquilinos.

Aislamiento de inquilinos

Una de las consideraciones más importantes en el diseño de arquitectura multiinquilino es el nivel de aislamiento que necesita cada inquilino. El aislamiento puede hacer referencia a las siguientes configuraciones:

• Tener una sola infraestructura compartida que incluya instancias independientes de la aplicación y bases de datos independientes para cada inquilino.

• Compartir algunos recursos comunes, a la vez que se mantienen separados otros recursos para cada inquilino.

• Conservar los datos en una infraestructura física independiente. En la nube, esta configuración puede requerir recursos de Azure independientes para cada inquilino. En escenarios extremos, incluso puede requerir implementar una infraestructura física independiente mediante hosts dedicados.

En lugar de ver el aislamiento como una propiedad discreta, considere un espectro. Puede implementar componentes de la arquitectura que están más aislados o menos aislados que otros componentes de la misma arquitectura, según sus requisitos. En el diagrama siguiente se muestra un continuo de aislamiento:

El diagrama muestra una flecha de totalmente aislado (nada compartido) a totalmente compartido (todo compartido). En el lado totalmente aislado, los cuadros azules contienen un proceso independiente, bases de datos independientes, redes independientes y nombres de dominio independientes. En el centro de la flecha, los cuadros verdes contienen cómputo compartido, redes compartidas y nombres de dominio compartidos. Un cuadro azul contiene bases de datos independientes. En el lado totalmente compartido, los cuadros verdes contienen el proceso compartido, la base de datos compartida, las redes compartidas y los nombres de dominio compartidos.

El nivel de aislamiento afecta a muchos aspectos de la arquitectura:

• Seguridad: Si comparte la infraestructura entre varios inquilinos, tenga cuidado de no acceder a los datos de un inquilino cuando devuelva respuestas a otra. Necesita una base sólida para su estrategia de identidad y debe tener en cuenta la identidad de inquilino y de usuario en el proceso de autorización.

• Costar: Varios inquilinos pueden usar la infraestructura compartida, por lo que es menos costoso.

• Rendimiento: Si comparte la infraestructura, el rendimiento del sistema podría degradarse a medida que más clientes lo usen, ya que es posible que los recursos se consuman más rápido. Los inquilinos que tienen patrones de uso inusuales pueden empeorar los problemas de rendimiento.

• Fiabilidad: Si usa un único conjunto de infraestructura compartida, un problema con un componente puede provocar una interrupción para todos los clientes.

• Capacidad de respuesta a las necesidades individuales del inquilino: Al implementar la infraestructura dedicada a un inquilino, es posible que pueda adaptar la configuración de los recursos a los requisitos de ese inquilino específico. Incluso puede considerar esta funcionalidad en el modelo de precios para permitir que los clientes paguen más por implementaciones aisladas.

La arquitectura de la solución puede influir en las opciones disponibles del aislamiento. Por ejemplo, considere una arquitectura de solución de tres niveles:

• La capa de interfaz de usuario podría ser una aplicación web multiinquilino compartida. Todos los inquilinos acceden a un único nombre de host.

• El nivel intermedio puede ser una capa de aplicación compartida que tenga colas de mensajes compartidos.

• La capa de datos pueden ser bases de datos aisladas, tablas o contenedores de blobs.

Puede usar distintos niveles de aislamiento para cada nivel. Debe basar su decisión sobre qué compartir y qué aislar en varios factores, como el costo, la complejidad, los requisitos de los clientes y el número de recursos que puede implementar antes de alcanzar los límites y cuotas de Azure.

Modelos de inquilinato comunes

Una vez que haya establecido los requisitos, evalúelos en comparación con algunos modelos de inquilinato comunes y los patrones de implementación correspondientes.

Implementaciones automatizadas de inquilino único

En un modelo de implementación de un solo inquilino automatizado, se implementa un conjunto dedicado de infraestructura para cada inquilino, como se muestra en el ejemplo siguiente:

El diagrama se divide en tres secciones, una para el inquilino A, una para el inquilino B y otra para el inquilino C. Una flecha apunta del inquilino A a un cuadro con la etiqueta Implementación A. Ese cuadro contiene un servidor web para el inquilino A. Otra flecha apunta del inquilino B a un cuadro con la etiqueta Deployment B. Ese cuadro contiene un servidor web para el inquilino B. Otra flecha apunta del inquilino C a un cuadro con la etiqueta Deployment C. Ese cuadro contiene un servidor web para el inquilino C.

La aplicación es responsable de iniciar y coordinar la implementación de los recursos de cada inquilino. Normalmente, las soluciones que usan este modelo usan la infraestructura como código o las API de Azure Resource Manager ampliamente. Puede usar este enfoque cuando necesite aprovisionar infraestructuras completamente independientes para cada uno de los clientes. Piense en usar el patrón de stamps de implementación cuando tenga prevista la implementación.

Ventajas: una ventaja clave de este enfoque es que los datos de cada inquilino están aislados, lo que reduce el riesgo de pérdida accidental. Esta protección puede ser importante para los clientes que tienen una sobrecarga de cumplimiento normativo elevada. Además, es poco probable que los inquilinos afecten al rendimiento del sistema del otro, también conocido como problema de vecino ruidoso . Las actualizaciones y los cambios se pueden implantar progresivamente en los inquilinos, lo que reduce la probabilidad de una interrupción en todo el sistema.

Riesgos: Si usa este enfoque, la rentabilidad es baja porque no comparte la infraestructura entre los inquilinos. Si un solo inquilino requiere un costo de infraestructura específico, es probable que 100 inquilinos requieran 100 veces ese costo. Además, el mantenimiento continuo, como la aplicación de nuevas configuraciones o actualizaciones de software, puede llevar mucho tiempo. Considere la posibilidad de automatizar los procesos operativos y de aplicar cambios progresivamente en los entornos. También debe tener en cuenta otras operaciones entre implementaciones, como informes y análisis en todo la flota. Planee cómo puede consultar y manipular datos en varias implementaciones.

Implementaciones totalmente multiinquilino

En el extremo opuesto, puede considerar una implementación totalmente multiinquilino, donde se comparten todos los componentes. Solo tiene un conjunto de infraestructura para implementar y mantener, y todos los inquilinos lo usan, como se muestra en el diagrama siguiente:

En este diagrama, las flechas apuntan desde cuadros con la etiqueta Inquilino A, Inquilino B y Inquilino C a un cuadro etiquetado como recursos compartidos. Ese cuadro contiene un servidor web para los inquilinos A, B y C.

Beneficios: Este modelo es atractivo porque el funcionamiento de una solución que tiene componentes compartidos es menos costoso que usar recursos individuales para cada inquilino. Aunque necesite implementar niveles o SKU superiores de recursos para justificar la carga incrementada, lo normal es que el coste general de esta implementación sea menor que el de un conjunto de recursos de un solo inquilino. Además, si un usuario o inquilino necesita mover sus datos a otro inquilino, es posible que pueda actualizar los identificadores y las claves del inquilino, y es posible que no tenga que migrar datos entre dos implementaciones independientes.

Riesgos:

• Asegúrese de separar los datos de cada inquilino y evite la pérdida de datos entre los inquilinos. Es posible que tenga que administrar los datos de particionamiento. Es posible que también tenga que tener en cuenta los efectos que pueden tener los inquilinos individuales en el sistema general. Por ejemplo, si un inquilino grande intenta realizar una consulta o una operación grande, esto podría afectar a otros inquilinos.

• Determine cómo realizar el seguimiento y asociar los costos de Azure a los inquilinos si esta información le resulta importante.

• Puede simplificar el mantenimiento mediante una sola implementación porque solo tiene que actualizar un conjunto de recursos. Sin embargo, también suele ser más arriesgado porque los cambios pueden afectar a toda la base de clientes.

• También es posible que tenga que tener en cuenta el escalado. Es más probable que se alcancen los límites de escalado de los recursos de Azure cuando se tiene un conjunto compartido de infraestructura. Por ejemplo, si usa una cuenta de almacenamiento como parte de la solución, a medida que aumenta el escalado, el número de solicitudes para esa cuenta de almacenamiento podría alcanzar el límite de lo que esa cuenta puede administrar. Para evitar alcanzar un límite de cuota de recursos, puede implementar un grupo de varias instancias de los recursos, como varios clústeres de AKS o cuentas de almacenamiento. Incluso puede considerar la posibilidad de distribuir los inquilinos entre los recursos que va a implementar en varias suscripciones de Azure.

• Es probable que haya un límite en cuanto se pueda escalar una sola implementación y los costos de escalado pueden aumentar de forma no lineal. Por ejemplo, si tiene una base de datos compartida única que se ejecuta a gran escala, es posible que agote su rendimiento y tenga que pagar cada vez más por un mayor rendimiento para mantenerse al día con la demanda.

Implementaciones con particiones verticales

No tiene que elegir ninguno de los extremos de estas escalas. En su lugar, puede segmentar verticalmente a sus usuarios utilizando el siguiente enfoque:

• Use una combinación de implementaciones de inquilino único y multiinquilino. Por ejemplo, es posible que tenga la mayoría de los niveles de aplicación y datos de los clientes en infraestructuras multiinquilino, pero implemente infraestructuras de inquilino único para los clientes que requieren un mayor rendimiento o aislamiento de datos.

• Implemente varias instancias de la solución geográficamente y asigne cada inquilino a una implementación específica. Este enfoque es eficaz cuando tiene inquilinos en diferentes zonas geográficas.

Este es un ejemplo que ilustra una implementación compartida para algunos inquilinos y una implementación de un solo inquilino para otro:

En este diagrama, las flechas apuntan desde el Arrendatario A y el Arrendatario B a un cuadro con la etiqueta Despliegue 1. Ese cuadro contiene un servidor web para los inquilinos A y B. Otra flecha apunta del inquilino C a un cuadro con la etiqueta Deployment 2. Ese cuadro contiene un servidor web para el inquilino C.

Beneficios: Dado que sigue compartiendo parte de la infraestructura, puede obtener algunas de las ventajas de costo de usar implementaciones multiinquilino compartidas. Puede implementar recursos compartidos menos costosos para clientes específicos, como los clientes que evalúan el servicio mediante una prueba. Puede incluso cobrar a los clientes una tarifa más alta por estar en una implementación de un solo inquilino, lo que permite recuperar de algunos de los costes.

Riesgos: es necesario diseñar el código base para admitir implementaciones multiinquilino y de un solo inquilino. Si tiene pensado habilitar la migración entre implementaciones, debe tener en cuenta cómo migrar los clientes de una implementación multiinquilino a su propia implementación de un solo inquilino. También debe saber cuáles de los inquilinos están en cada implementación para que pueda comunicar información sobre problemas del sistema o actualizaciones a los clientes pertinentes.

Implementaciones con particiones horizontales

También puede crear particiones horizontales de las implementaciones. En una implementación horizontal, tiene algunos componentes compartidos, pero mantiene otros componentes con implementaciones de un solo inquilino. Por ejemplo, puede compilar un único nivel de aplicación y, a continuación, implementar bases de datos individuales para cada inquilino, como se muestra en este diagrama:

En este diagrama, las flechas apuntan desde cuadros etiquetados Inquilino A, Inquilino B e Inquilino C a un cuadro que contiene un servidor web que inquilino A, B y C comparten.

Beneficios: Las implementaciones con particiones horizontales pueden ayudarle a mitigar un problema de vecino ruidoso. Si identifica que los componentes específicos provocan la mayor parte de la carga en el sistema, puede implementar componentes independientes para cada inquilino. Por ejemplo, las bases de datos pueden absorber la mayor parte de la carga del sistema, porque la carga de consultas es alta. Si un único inquilino envía un gran número de solicitudes a la solución, el rendimiento de una base de datos puede verse afectado negativamente, pero las bases de datos de otros inquilinos (y los componentes compartidos, como el nivel de aplicación) no se ven afectadas.

Riesgos: Con una implementación con segmentación horizontal, aún debe tener en cuenta la implementación y administración automatizadas de sus componentes, especialmente los componentes que utiliza un solo cliente.

Prueba del modelo de aislamiento

Independientemente del modelo de aislamiento que elija, asegúrese de probar la solución para comprobar que los datos de un inquilino no se filtran accidentalmente a otro y que el efecto del vecino ruidoso sea aceptable. Considere la posibilidad de usar Azure Chaos Studio para introducir deliberadamente errores que simulan interrupciones del mundo real y comprobar la resistencia de la solución incluso cuando los componentes no funcionan correctamente.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autor principal:

• John Downs | Ingeniero principal de software, Patrones y prácticas de Azure

Otros colaboradores:

• Chad Kittel | Ingeniero principal de software, Patrones y prácticas de Azure
• Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente

Considere el ciclo de vida de los inquilinos.