Multiinquilinato y Azure Cosmos DB

  • Artículo

En esta página, describimos algunas de las características de Azure Cosmos DB que resultan útiles cuando se trabaja con sistemas multiinquilino. También se proporcionan vínculos a instrucciones y ejemplos sobre cómo usar Azure Cosmos DB en una solución multiinquilino.

Características de Azure Cosmos DB que admiten multiinquilinato

Creación de particiones

Mediante el uso de particiones con los contenedores de Azure Cosmos DB, puede crear contenedores que se compartan entre varios inquilinos. Normalmente se usa el identificador de inquilino como clave de partición, pero también puede considerar la posibilidad de usar varias claves de partición para un solo inquilino. Una estrategia de creación de particiones bien planeada implementa eficazmente el patrón de particionamiento. Con los contenedores grandes, Azure Cosmos DB distribuye los inquilinos entre varios nodos físicos para lograr un alto grado de escala.

Se recomienda explorar el uso de claves de partición jerárquicas para mejorar el rendimiento de la solución multiinquilino. Las claves de partición jerárquicas permiten crear una clave de partición que incluya varios valores. Por ejemplo, puede usar una clave de partición jerárquica que incluya el identificador de inquilino y el tipo de datos que va a almacenar. Este enfoque permite escalar más allá del límite de partición lógica de 20 GB por valor de clave de partición.

Más información:

Administración de unidades de solicitud

El modelo de precios de Azure Cosmos DB se basa en el número de unidades de solicitud por segundo que aprovisiona o consume. Una unidad de solicitud es una abstracción lógica del costo de una operación o consulta de base de datos. Normalmente, se aprovisiona un número definido de unidades de solicitud por segundo para la carga de trabajo, lo que se conoce como rendimiento. Azure Cosmos DB proporciona varias opciones para aprovisionar el rendimiento. En un entorno multiinquilino, la selección que realice afecta al rendimiento y el precio de los recursos de Azure Cosmos DB.

Un modelo de inquilinato para Azure Cosmos DB implica la implementación de contenedores independientes para cada inquilino dentro de una base de datos compartida. Azure Cosmos DB permite aprovisionar unidades de solicitud para una base de datos y todos los contenedores comparten las unidades de solicitud. Si normalmente las cargas de trabajo de inquilinos no se superponen, este enfoque puede ayudar a reducir los costos operativos. No obstante, este enfoque es susceptible del problema de vecino ruidoso porque el contenedor de un solo inquilino podría consumir una cantidad desproporcionada de las unidades de solicitud aprovisionadas compartidas. Para mitigar este problema, primero identifique los inquilinos ruidosos. A continuación, puede establecer opcionalmente el rendimiento aprovisionado en un contenedor específico. Los demás contenedores de la base de datos siguen compartiendo su rendimiento, pero el inquilino ruidoso consume su propio rendimiento dedicado.

Azure Cosmos DB también proporciona un nivel sin servidor, que es adecuado para cargas de trabajo con tráfico intermitente o impredecible. Como alternativa, el escalado automático permite configurar directivas para especificar el escalado del rendimiento aprovisionado. Además, puede aprovechar la capacidad de ráfaga de Azure Cosmos DB, maximizando el uso de la capacidad de rendimiento aprovisionada, que habría sido limitada de otra manera. En una solución multiinquilino, puede combinar todos estos enfoques para admitir diferentes tipos de inquilino.

Nota

Al planear la configuración de Azure Cosmos DB, asegúrese de tener en cuenta las cuotas y los límites del servicio.

Para supervisar y administrar los costos asociados a cada inquilino, todas las operaciones que usan la API de Azure Cosmos DB incluyen las unidades de solicitud consumidas. Puede usar esta información para agregar y comparar las unidades de solicitud reales consumidas por cada inquilino y, después, puede identificar inquilinos con diferentes características de rendimiento.

Más información:

Claves administradas por el cliente

Es posible que algunos inquilinos necesiten usar claves de cifrado propias. Azure Cosmos DB proporciona una característica de clave administrada por el cliente. Esta característica se aplica en el nivel de una cuenta de Azure Cosmos DB, por lo que los inquilinos que necesiten sus propias claves de cifrado tendrán que implementarse mediante cuentas de Azure Cosmos DB dedicadas.

Más información:

Modelos de aislamiento

Al trabajar con un sistema multiinquilino en el que se usa Azure Cosmos DB, debe tomar una decisión sobre el nivel de aislamiento que quiere usar. Negocio a negocio (B2B) hace referencia a la venta a una empresa. Negocio a consumidor (B2C) hace referencia a la venta directa a un cliente individual que utiliza el producto o servicio. Azure Cosmos DB admite varios modelos de aislamiento:

Necesidad de carga de trabajo Clave de partición por inquilino Contenedor por inquilino (rendimiento compartido) Contenedor por inquilino (rendimiento dedicado) Base de datos por inquilino Cuenta de base de datos por inquilino
Consultas entre inquilinos Fácil (el contenedor actúa como límite para las consultas) Difícil Difícil Difícil Difícil
Densidad de inquilinos Alta (costo más bajo por inquilino) Media Bajo Bajo Bajo
Eliminación de datos de inquilinos Difícil Fácil (eliminar contenedor cuando el inquilino sale) Fácil (eliminar contenedor cuando el inquilino sale) Fácil (eliminar base de datos cuando el inquilino sale) Fácil (eliminar base de datos cuando el inquilino sale)
Aislamiento de la seguridad del acceso a datos Debe implementarse dentro de la aplicación RBAC de contenedor RBAC de contenedor RBAC de base de datos RBAC
Replicación geográfica No es posible la replicación geográfica por inquilino Agrupación de inquilinos en cuentas de bases de datos según los requisitos Agrupación de inquilinos en cuentas de bases de datos según los requisitos Agrupación de inquilinos en cuentas de bases de datos según los requisitos Agrupación de inquilinos en cuentas de bases de datos según los requisitos
Prevención del problema de vecino ruidoso None None Sí Sí Sí
Latencia en la creación de nuevo inquilino Inmediata Rápido Rápido Media Lento
Ventajas del modelado de datos Ninguno coubicación de entidades coubicación de entidades Varios contenedores para modelar entidades de inquilino Varios contenedores y bases de datos para modelar inquilinos
Clave de cifrado Igual para todos los inquilinos Igual para todos los inquilinos Igual para todos los inquilinos Igual para todos los inquilinos Número de claves administradas por el cliente por inquilino
Requisitos de rendimiento >0 RU por inquilino >100 RU por inquilino >100 RU por inquilino (solo con escalabilidad automática, de lo contrario >, 400 RU por inquilino) >400 RU por inquilino >400 RU por inquilino
Ejemplo de casos de uso Aplicaciones B2C Oferta Estándar para aplicaciones B2B Oferta Premium para aplicaciones B2B Oferta Premium para aplicaciones B2B Oferta Premium para aplicaciones B2B

Clave de partición por inquilino

Cuando use un único contenedor para varios inquilinos, puede utilizar la compatibilidad con la creación de particiones de Azure Cosmos DB. Al usar claves de partición independientes para cada inquilino, puede consultar fácilmente los datos de un solo inquilino. También puede realizar consultas en varios inquilinos, incluso si están en particiones independientes. Pero las consultas entre particiones tienen un costo de unidad de solicitud (RU) mayor que las consultas de partición única.

Este enfoque suele funcionar bien cuando la cantidad de datos almacenados para cada inquilino es pequeña. Puede ser una buena opción para crear un modelo de precios que incluya un nivel gratis y para soluciones de negocio a consumidor (B2C). En general, mediante el uso de contenedores compartidos se logra la mayor densidad de inquilinos y, por tanto, el precio más bajo por inquilino.

Es importante tener en cuenta el rendimiento del contenedor. Todos los inquilinos compartirán el rendimiento del contenedor, por lo que el problema de vecino ruidoso puede causar desafíos de rendimiento si los inquilinos tienen cargas de trabajo elevadas o superpuestas. A veces, este problema se puede mitigar mediante la agrupación de subconjuntos de inquilinos en contenedores diferentes y asegurándose de que cada grupo de inquilinos tenga patrones de uso compatibles. Como alternativa, puede considerar un modelo híbrido entre el modelo multiinquilino y el de un solo inquilino. Agrupe los inquilinos más pequeños en contenedores compartidos con particiones y proporcione a los clientes grandes contenedores dedicados. Además, hay características que pueden ayudar a controlar el problema del vecino ruidoso al modelar los inquilinos por partición, como la reasignación de rendimiento, la capacidad de ráfaga y el control de rendimiento en el SDK de Java.

También es importante tener en cuenta la cantidad de datos que se almacenan en cada partición lógica. Azure Cosmos DB permite que cada partición lógica tenga un tamaño de hasta 20 GB. Si tiene un único inquilino que necesita almacenar más de 20 GB de datos, considere la posibilidad de distribuir los datos entre varias particiones lógicas. Por ejemplo, en lugar de tener una sola clave de partición de Contoso, podría cifrar con sal las claves de partición mediante la creación de varias claves de partición para un inquilino, como Contoso1, Contoso2, etc. Al consultar los datos de un inquilino, puede usar la cláusula WHERE IN para que coincida con todas las claves de partición. Las claves de partición jerárquica también se pueden usar para que admitan inquilinos grandes, con almacenamiento superior a 20 GB, sin tener que usar claves de partición sintéticas ni varios valores de clave de partición por inquilino.

Tenga en cuenta los aspectos operativos de la solución y las distintas fases del ciclo de vida del inquilino. Por ejemplo, cuando un inquilino se mueve a un plan de tarifa dedicado, es probable que tenga que mover los datos a otro contenedor. Cuando se desaprovisiona un inquilino, debe ejecutar una consulta de eliminación en el contenedor para quitar los datos y, en el caso de los inquilinos grandes, esta consulta podría consumir una cantidad de rendimiento significativa mientras se ejecuta.

Un contenedor por inquilino

Puede aprovisionar contenedores dedicados para cada inquilino. Los contenedores dedicados son una buena opción cuando los datos que almacena para el inquilino se pueden combinar en un único contenedor. Este modelo proporciona un mayor aislamiento de rendimiento que el modelo de clave de partición por inquilino anterior y también proporciona un mayor aislamiento de la seguridad del acceso a datos a través de RBAC de Azure.

Al usar un contenedor para cada inquilino, puede considerar la posibilidad de compartir el rendimiento con otros inquilinos mediante el aprovisionamiento del rendimiento en el nivel de base de datos. Tenga en cuenta las restricciones y los límites en torno al número mínimo de unidades de solicitud para la base de datos y el número máximo de contenedores de la base de datos. Además, considere si los inquilinos necesitan un nivel garantizado de rendimiento y si son susceptibles al problema de vecino ruidoso. Al compartir el rendimiento en el nivel de base de datos, la carga de trabajo o el almacenamiento en todos los contenedores debe ser relativamente uniforme. De lo contrario, es posible que tenga un problema de vecino ruidoso, si hay uno o varios inquilinos grandes. Si es necesario, planee agrupar estos inquilinos en bases de datos diferentes basadas en patrones de carga de trabajo.

Como alternativa, puede aprovisionar un rendimiento dedicado para cada contenedor. Este enfoque es una buena elección para los inquilinos más grandes y para los inquilinos que están en riesgo de sufrir el problema de vecino ruidoso. Pero el rendimiento de línea de base para cada inquilino es mayor, por lo que debe tener en cuenta los requisitos mínimos y las implicaciones de costo de este modelo.

Si el modelo de datos de inquilino requiere más de una entidad, siempre y cuando todas las entidades puedan compartir la misma clave de partición, se pueden colocar en el mismo contenedor. Sin embargo, si el modelo de datos de inquilino es más complejo y requiere entidades que no puedan compartir la misma clave de partición, considere la posibilidad de usar los siguientes modelos de base de datos por inquilino o cuenta de base de datos por inquilino. Eche un vistazo a nuestro artículo sobre cómo modelar y crear particiones de datos en Azure Cosmos DB mediante un ejemplo real para obtener más instrucciones.

La administración del ciclo de vida suele ser más sencilla cuando los contenedores están dedicados a los inquilinos. Puede mover fácilmente los inquilinos entre los modelos de rendimiento compartido y dedicado y, al desaprovisionar un inquilino, puede eliminar rápidamente el contenedor.

Base de datos por inquilino

Puede aprovisionar bases de datos para cada inquilino, en la misma cuenta de la base de datos. Al igual que en el modelo anterior de contenedor por inquilino, este modelo proporciona un mayor aislamiento de rendimiento que el modelo de clave de partición por inquilino y también proporciona un mayor aislamiento de la seguridad del acceso a datos a través de RBAC de Azure.

Al igual que el modelo siguiente de cuenta por inquilino, este enfoque proporciona el nivel más alto de aislamiento del rendimiento, pero ofrece la densidad de inquilinos más baja. Sin embargo, esta opción es mejor cuando cada inquilino requiere un modelo de datos más complicado de lo que es factible en el modelo de contenedor por inquilino. O bien, debe seguir este enfoque cuando sea un requisito para que la creación de nuevos inquilinos sea rápida y se vea libre de cualquier sobrecarga a la hora de crear cuentas de inquilino por adelantado. También puede ser el caso, para el marco de desarrollo de software específico utilizado, que la base de datos por inquilino sea el único nivel de aislamiento de rendimiento que se reconoce en ese marco. El aislamiento en el nivel de entidad (contenedor) y la coubicación de entidades no se admiten normalmente de forma nativa en tales marcos.

Cuenta de base de datos por inquilino

Azure Cosmos DB permite aprovisionar cuentas de base de datos independientes para cada inquilino, lo que proporciona el mayor nivel de aislamiento, pero la densidad más baja. Al igual que los modelos de contenedor por inquilino y base de datos por inquilino anteriores, este modelo proporciona un mayor aislamiento de rendimiento que el modelo de clave de partición por inquilino. También proporciona un mayor aislamiento de la seguridad del acceso a los datos mediante RBAC de Azure. Además, este modelo proporciona aislamiento de la seguridad del cifrado de base de datos en el nivel de inquilino mediante claves administradas por el cliente.

Una sola cuenta de base de datos está dedicada a un inquilino, lo que significa que no están sujetos al problema de vecino ruidoso. Puede configurar la ubicación de la cuenta de la base de datos según los requisitos del inquilino. También puede ajustar la configuración de las características de Azure Cosmos DB, como la replicación geográfica y las claves de cifrado administradas por el cliente, para que se adapten a los requisitos de cada inquilino. Al usar una cuenta de Azure Cosmos DB dedicada por inquilino, tenga en cuenta el número máximo de cuentas de Azure Cosmos DB por suscripción de Azure.

Si usa este modelo, debe tener en cuenta la rapidez con la que la aplicación debe poder generar nuevos inquilinos. La creación de cuentas en Azure Cosmos DB puede tardar unos minutos, por lo que es posible que tenga que crear cuentas por adelantado. Si este enfoque no es factible, considere la posibilidad de usar el modelo de base de datos por inquilino.

Si permite que los inquilinos realicen la migración desde una cuenta compartida a una cuenta de Azure Cosmos DB dedicada, considere el enfoque de migración que usará para mover los datos de un inquilino entre las cuentas antigua y nueva.

Enfoques híbridos

Puede considerar una combinación de los enfoques anteriores para adaptarse a los requisitos de los distintos inquilinos y al modelo de precios. Por ejemplo:

  • Aprovisione todos los clientes de evaluación gratuita dentro de un contenedor compartido y use el identificador de inquilino o una clave de partición de clave sintética.
  • Ofrezca un nivel Bronce de pago que implemente un contenedor dedicado por inquilino, pero con rendimiento compartido en una base de datos.
  • Ofrezca un nivel Plata superior que aprovisione el rendimiento dedicado para el contenedor del inquilino.
  • Ofrezca el nivel Oro más alto y proporcione una cuenta de base de datos dedicada para el inquilino, lo que también permite a los inquilinos seleccionar la ubicación geográfica para su implementación.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

  • Paul Burpo | Principal Customer Engineer, FastTrack for Azure
  • John Downs | Ingeniero de clientes principal, FastTrack for Azure

Otros colaboradores:

  • Mark Brown | Administrador de proyectos principal, Azure Cosmos DB
  • Deborah Chen | Administrador de programas principal
  • Theo van Kraay | Administrador de programas sénior, Azure Cosmos DB
  • Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
  • Thomas Weiss | Administrador de programas principal
  • Vic Perdana | Arquitecto de soluciones en la nube, ISV de Azure

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

Pasos siguientes

Revise los enfoques de almacenamiento y datos para multiinquilino.

Más información sobre Multiinquilinato y Azure Cosmos DB:

Consulte algunos de nuestros otros escenarios de arquitecturas de Cosmos DB: