Compartir a través de

Multiinquilinato y Azure Cosmos DB

  • Artículo

En este artículo se describen las características de Azure Cosmos DB que puede usar para sistemas multiinquilino. Proporciona instrucciones y ejemplos sobre cómo usar Azure Cosmos DB en una solución multiinquilino.

Requisitos multiinquilino

Al planear una solución multiinquilino, tiene dos requisitos clave:

  • Ayude a garantizar un aislamiento sólido entre los inquilinos y a cumplir los estrictos requisitos de seguridad para aquellos que los necesiten.
  • Mantenga un bajo costo por inquilino. Como proveedor, asegúrese de que el costo para ejecutar la aplicación sigue siendo sostenible a medida que se escala.

Estas dos necesidades a menudo pueden entrar en conflicto e introducir un equilibrio en el que debe priorizar uno sobre el otro. Las instrucciones de este artículo pueden ayudarle a comprender mejor las ventajas que debe realizar para satisfacer estas necesidades. Este artículo le ayuda a navegar por estas consideraciones para que pueda tomar decisiones informadas al diseñar la solución multiinquilino.

Modelos de aislamiento

Determine el nivel de aislamiento que necesita entre los inquilinos. Azure Cosmos DB admite una gama de modelos de aislamiento, pero para la mayoría de las soluciones se recomienda usar una de las estrategias siguientes:

  • Una clave de partición por inquilino se usa a menudo para soluciones totalmente multiinquilino, como soluciones de software como servicio (SaaS de negocio a consumidor).
  • A menudo se usa una cuenta de base de datos por inquilino para soluciones SaaS de negocio a negocio (B2B).

Para elegir el modelo de aislamiento más adecuado, tenga en cuenta el modelo de negocio y los requisitos de los inquilinos. Por ejemplo, el aislamiento de rendimiento seguro podría no ser una prioridad para algunos modelos B2C en los que una empresa vende un producto o servicio directamente a un cliente individual. Sin embargo, los modelos B2B podrían priorizar el aislamiento de seguridad y rendimiento sólidos y podrían requerir que los inquilinos tengan su propia cuenta de base de datos aprovisionada.

También puede combinar varios modelos para adaptarse a diferentes necesidades de los clientes. Por ejemplo, supongamos que crea una solución SaaS B2B que vende a los clientes empresariales y proporciona una evaluación gratuita para los clientes nuevos potenciales. Puede implementar una cuenta de base de datos independiente para los inquilinos empresariales de pago que necesitan garantías de seguridad y aislamiento sólidas. Y podría compartir una cuenta de base de datos y usar claves de partición para aislar a los clientes de prueba.

El modelo partition-key-per-tenant y el modelo database-account-per-tenant son los modelos de aislamiento más comunes para las soluciones multiinquilino. Estos modelos proporcionan el mejor equilibrio entre el aislamiento de inquilinos y la rentabilidad.

Modelo de clave de partición por inquilino

Si aísla los inquilinos por clave de partición, el rendimiento se comparte entre inquilinos y se administra dentro del mismo contenedor.

Nota:

Una unidad de solicitud (RU) 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 (RU/s) para la carga de trabajo, lo que se conoce como rendimiento.

Ventajas

  • Rentabilidad: coloca todos los inquilinos en un contenedor, que es particionado por el identificador de inquilino. Este enfoque solo tiene un recurso facturable que aprovisiona y comparte RU entre varios inquilinos. Este modelo suele ser más rentable y fácil de administrar que tener cuentas independientes para cada inquilino.

  • Administración simplificada: tiene menos cuentas de Azure Cosmos DB que administrar.

Ventajas y desventajas

  • Contención de recursos: el rendimiento compartido (RU/s) entre los inquilinos que están en el mismo contenedor puede provocar contención durante el uso máximo. Esta contención puede crear problemas ruidosos vecinos y desafíos de rendimiento si los inquilinos tienen cargas de trabajo elevadas o superpuestas. Use este modelo de aislamiento para cargas de trabajo que necesitan RU garantizadas en un solo inquilino y que puedan compartir el rendimiento.

  • Aislamiento limitado: este enfoque proporciona aislamiento lógico, no aislamiento físico. Es posible que no cumpla los requisitos de aislamiento estrictos desde una perspectiva de rendimiento o seguridad.

  • Menos flexibilidad: no se pueden personalizar características de nivel de cuenta, como la replicación geográfica, la restauración a un momento dado y las claves administradas por el cliente, para cada inquilino si se aísla por clave de partición o por base de datos o contenedor.

Características de Azure Cosmos DB para multiinquilino

  • Controlar el rendimiento: explore las características que pueden ayudar a controlar el problema de vecino ruidoso al usar una clave de partición para aislar los inquilinos. Use características como la reasignación de rendimiento, la capacidad de ráfaga y el control de rendimiento en el SDK de Java.

  • Claves de partición jerárquicas: use Azure Cosmos DB para que cada partición lógica pueda aumentar el tamaño 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 , puede distribuir las claves de Contosopartición mediante la creación de varias claves de partición para un inquilino, como Contoso1 y Contoso2.

    Al consultar los datos de un inquilino, puede usar la WHERE IN cláusula para que coincida con todas las claves de partición. También puede usar claves de partición jerárquicas para proporcionar inquilinos grandes con almacenamiento superior a 20 GB si tiene una cardinalidad alta de inquilinos. No es necesario usar claves de partición sintéticas ni varios valores de clave de partición por inquilino para este método.

    Supongamos que tiene una carga de trabajo que aísla los inquilinos por clave de partición. Un inquilino, Contoso, es mayor y más pesado de escritura que otros, y sigue creciendo en tamaño. Para evitar el riesgo de no poder ingerir más datos para este inquilino, puede usar claves de partición jerárquica. Especifique TenantID como la clave de primer nivel y agregue un segundo nivel como UserId. Si prevé que la TenantID combinación y UserID genere particiones lógicas que superen el límite de 20 GB, puede crear particiones más abajo a otro nivel, como SessionID. Las consultas que especifican TenantID o ambas TenantID y UserID se enrutan de forma eficaz solo al subconjunto de particiones físicas que contienen los datos pertinentes, lo que evita una consulta de distribución completa. Si el contenedor tiene 1000 particiones físicas, pero un valor específico TenantId es solo en cinco particiones físicas, la consulta se enruta al menor número de particiones físicas pertinentes.

    Si el primer nivel no tiene una cardinalidad suficientemente alta y alcanza el límite de particiones lógicas de 20 GB en la clave de partición, considere la posibilidad de usar una clave de partición sintética en lugar de una clave de partición jerárquica.

Modelo de cuenta por inquilino de base de datos

Si aísla los inquilinos por cuenta de base de datos, cada inquilino tiene su propio rendimiento aprovisionado en el nivel de base de datos o en el nivel de contenedor.

Ventajas

  • Aislamiento alto: este enfoque evita la contención o interferencia debido a cuentas y contenedores de Azure Cosmos DB dedicados que tienen RU aprovisionadas por inquilino único.

  • Contratos de nivel de servicio personalizados (SLA): cada inquilino tiene su propia cuenta, por lo que puede proporcionar recursos personalizados específicos, acuerdos de nivel de servicio orientados al cliente y garantías, ya que puede ajustar la cuenta de base de datos de cada inquilino de forma independiente para el rendimiento.

  • Seguridad mejorada: el aislamiento de datos físicos ayuda a garantizar una seguridad sólida, ya que los clientes pueden habilitar claves administradas por cliente en un nivel de cuenta por inquilino. Los datos de cada inquilino están aislados por cuenta, en lugar de estar en el mismo contenedor.

  • Flexibilidad: los inquilinos pueden habilitar características de nivel de cuenta, como la replicación geográfica, la restauración a un momento dado y las claves administradas por el cliente según sea necesario.

Ventajas y desventajas

  • Administración mejorada: este enfoque es más complejo porque administra varias cuentas de Azure Cosmos DB.

  • Mayores costos: más cuentas significan que debe aprovisionar el rendimiento en cada recurso, como bases de datos o contenedores, dentro de la cuenta de cada inquilino. Cada vez que un recurso aprovisiona RU, los costos de Azure Cosmos DB aumentan.

  • Limitaciones de consulta: todos los inquilinos están en diferentes cuentas, por lo que las aplicaciones que consultan varios inquilinos requieren varias llamadas dentro de la lógica de la aplicación.

Características de Azure Cosmos DB para multiinquilino

  • Características de seguridad: este modelo proporciona un mayor aislamiento de seguridad de acceso a datos a través de Azure RBAC. Este modelo también proporciona aislamiento de seguridad de cifrado de base de datos en el nivel de inquilino a través de claves administradas por el cliente.

  • Configuración personalizada: 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 dedicada de Azure Cosmos DB por inquilino, tenga en cuenta el número máximo de cuentas de Azure Cosmos DB por suscripción de Azure.

Lista completa de modelos de aislamiento

Necesidad de carga de trabajo Clave de partición por inquilino (recomendado) Contenedor por inquilino (rendimiento compartido) Contenedor por inquilino (rendimiento dedicado) Base de datos por inquilino Cuenta de base de datos por inquilino (recomendado)
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 Fá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 Necesidad de implementar 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 No No 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 Clave administrada 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 caso 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

Modelo de contenedor por inquilino

Puede aprovisionar contenedores dedicados para cada inquilino. Los contenedores dedicados funcionan bien cuando se pueden combinar los datos que se almacenan para el inquilino en un único contenedor. 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.

Cuando se usa un contenedor para cada inquilino, considere 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 del número mínimo de RU para la base de datos y el número máximo de contenedores de la base de datos. Considere también si los inquilinos requieren un nivel de rendimiento garantizado 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 tiene 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 funciona bien para los inquilinos más grandes y para los inquilinos que están en riesgo del problema de vecino ruidoso. Pero el rendimiento de línea base de cada inquilino es mayor, por lo que debe tener en cuenta los requisitos mínimos y las implicaciones de costos de este modelo.

Si el modelo de datos de inquilino requiere más de una entidad y todas las entidades pueden compartir la misma clave de partición, puede colocarlas en el mismo contenedor. Pero si el modelo de datos de inquilino es más complejo y requiere entidades que no puedan compartir la misma clave de partición, tenga en cuenta los modelos database-per-tenant o database-account-per-tenant. Para más información, consulte Modelado y partición de datos en Azure Cosmos DB.

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

Modelo de base de datos por inquilino

Puede aprovisionar bases de datos para cada inquilino de la misma cuenta de base de datos. Al igual que el modelo de contenedor por inquilino, este modelo proporciona un mayor aislamiento de rendimiento que el modelo partition-key-per-tenant. También proporciona un mayor aislamiento de la seguridad del acceso a los datos mediante RBAC de Azure.

De forma similar al modelo de cuenta por inquilino, este enfoque proporciona el nivel más alto de aislamiento de rendimiento, pero proporciona la densidad de inquilino más baja. Use esta opción si cada inquilino requiere un modelo de datos más complicado de lo que es factible en el modelo de contenedor por inquilino. O siga este enfoque si la creación de nuevos inquilinos debe ser rápida o libre de cualquier sobrecarga por adelantado. En algunos marcos de desarrollo de software, el modelo de base de datos por inquilino podría ser el único nivel de aislamiento de rendimiento que admite el marco. Estos marcos no suelen admitir el aislamiento de nivel de entidad (contenedor) y la coubicación de entidades.

Características de Azure Cosmos DB que admiten multiinquilinato

Creación de particiones

Use particiones con los contenedores de Azure Cosmos DB para crear contenedores que comparten 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. Cuando tiene contenedores grandes, Azure Cosmos DB distribuye los inquilinos entre varios nodos físicos para lograr un alto grado de escala.

Considere la posibilidad de tener en cuenta las claves de partición jerárquicas para ayudar a mejorar el rendimiento de la solución multiinquilino. Use claves de partición jerárquicas para 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, como un GUID de cardinalidad alta, para permitir una escala casi sin enlazar. También puede especificar una clave de partición jerárquica que incluya una propiedad que consulta con frecuencia. Este enfoque le ayuda a evitar consultas entre particiones. Use claves de partición jerárquicas para escalar más allá del límite de particiones lógicas de 20 GB por valor de clave de partición y limitar las consultas de distribución de distribución costosas.

Para obtener más información, consulte los siguientes recursos:

Administración de RU

El modelo de precios de Azure Cosmos DB se basa en el número de RU/s que aprovisiona o consume. Azure Cosmos DB proporciona varias opciones para aprovisionar el rendimiento. En un entorno multiinquilino, la selección afecta al rendimiento y el precio de los recursos de Azure Cosmos DB.

En el caso de los inquilinos que requieren aislamiento de seguridad y rendimiento garantizado, se recomienda aislar los inquilinos por cuenta de base de datos y asignar RU al inquilino. En el caso de los inquilinos que tienen requisitos menos estrictos, se recomienda aislar los inquilinos por clave de partición. Use este modelo para compartir RU entre los inquilinos y optimizar el costo por inquilino.

Un modelo de inquilinato alternativo para Azure Cosmos DB implica la implementación de contenedores independientes para cada inquilino dentro de una base de datos compartida. Use Azure Cosmos DB para aprovisionar RU para una base de datos para que todos los contenedores compartan las RU. Si normalmente las cargas de trabajo de inquilinos no se superponen, este enfoque puede ayudar a reducir los costos operativos. Pero este enfoque es susceptible al problema de vecino ruidoso, ya que el contenedor de un solo inquilino podría consumir una cantidad desproporcionada de las RU 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 se adapta a las cargas de trabajo que tienen tráfico intermitente o impredecible. Como alternativa, puede usar el escalado automático para configurar directivas que especifican el escalado del rendimiento aprovisionado. También puede aprovechar la capacidad de ráfaga de Azure Cosmos DB para maximizar el uso de la capacidad de rendimiento aprovisionada, que de lo contrario está restringido por límites de velocidad. En una solución multiinquilino, puede combinar todos estos enfoques para admitir distintos tipos de inquilinos.

Nota:

Al planear la configuración de Azure Cosmos DB, tenga en cuenta las cuotas y los límites de servicio.

Para supervisar y administrar los costos asociados a cada inquilino, recuerde que cada operación que usa la API de Azure Cosmos DB incluye las RU consumidas. Puede usar esta información para agregar y comparar las RU reales que consume cada inquilino. A continuación, puede identificar los inquilinos que tienen características de rendimiento diferentes.

Para obtener más información, consulte los siguientes recursos:

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 tanto, si los inquilinos requieren sus propias claves de cifrado, debe usar cuentas de Azure Cosmos DB dedicadas para implementar los inquilinos.

Para obtener más información, consulte Configuración de claves administradas por el cliente para la cuenta de Azure Cosmos DB con Azure Key Vault.

Colaboradores

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

Creadores de entidad de seguridad:

  • Tara Bhatia | Administrador de programas, Azure Cosmos DB
  • Paul Burpo | Principal Customer Engineer, FastTrack for Azure
  • John Downs | Ingeniero principal de software

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

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

Consulte algunos de nuestros otros escenarios arquitectónicos de Azure Cosmos DB: