Compartir a través de

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.

Requisitos multiinquilino

Al planificar una solución multiinquilino, es posible que tenga que diseñar dos necesidades clave:

  • Garantizar un aislamiento seguro entre los inquilinos y cumplir los estrictos requisitos de seguridad para aquellos que los necesitan.
  • Mantener un bajo coste por inquilino. Como proveedor, quiere asegurarse de que el coste de ejecutar la aplicación sigue siendo sostenible a medida que se escala.

Estas dos necesidades pueden entrar a menudo en conflicto, lo que exige hacer concesiones y dar prioridad a una sobre la otra. Hay algunas pautas que puede seguir para comprender mejor las ventajas y desventajas de satisfacer las dos necesidades descritas anteriormente. Este documento le ayuda a navegar por estas consideraciones para que pueda tomar decisiones informadas al diseñar la solución multiinquilino.

Modelos de aislamiento

Debe decidir el nivel de aislamiento 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:

  • Clave de partición por inquilino, que a menudo se usa para soluciones totalmente multiinquilino, como las que se usan en software como servicio de negocio a consumidor (SaaS B2C).
  • Cuenta de base de datos por inquilino, que es a menudo. Se utiliza en SaaS de negocio a negocio (B2B).

Para seleccionar 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 puede no ser una prioridad para algunos modelos B2C en los que las empresas venden directamente a un cliente individual mediante el producto o el servicio. Sin embargo, los modelos B2B pueden priorizar el aislamiento de seguridad y rendimiento sólidos y pueden 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 va a crear una solución SaaS B2B que vende a clientes empresariales, así como proporcionar una evaluación gratuita para nuevos clientes 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, al tiempo que comparte una cuenta de base de datos y usa claves de partición para aislar a los clientes de prueba.

Clave de partición por inquilino

Al aislar nuestros inquilinos por clave de partición, el rendimiento se compartirá entre inquilinos y los agrupará en el mismo contenedor.

Ventajas:

  • Rentabilidad: todos los inquilinos se colocan dentro de un contenedor, que es particionado por identificador de inquilino. Dado que solo hay un recurso facturable en el que las RU/s se aprovisionan y comparten entre varios inquilinos, este enfoque suele ser más rentable y fácil de administrar que tener cuentas independientes por inquilino.
  • Administración simplificada: menos cuentas de Azure Cosmos DB para administrar.

Contrapartidas:

  • Contención de recursos: el uso compartido del rendimiento (RU/s) entre los inquilinos del mismo contenedor puede provocar contención durante el uso máximo, lo que da lugar a un problema de vecino ruidoso que puede provocar desafíos de rendimiento si los inquilinos tienen cargas de trabajo elevadas o superpuestas. Este modelo de aislamiento es adecuado para las cargas de trabajo que necesitan RU/s garantizadas en un solo inquilino y pueden compartir.
  • Aislamiento limitado: este enfoque proporciona aislamiento lógico, no aislamiento físico. Puede que no cumpla los estrictos requisitos de aislamiento, tanto desde el punto de vista del rendimiento como de la seguridad.
  • Menor flexibilidad: la personalización de características de nivel de cuenta, como la replicación geográfica, la restauración a un momento dado (PITR) y las claves administradas por el cliente (CMK) por inquilino no están disponibles si se aísla por clave de partición (o por base de datos o contenedor).

Características de Azure Cosmos DB relevantes:

  • Controle su rendimiento: Explore 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.

  • Claves de partición jerárquica: 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 (siempre que tenga una alta cardinalidad de inquilinos), 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.

    Supongamos que tiene una carga de trabajo que aísla los inquilinos por clave de partición. Uno de los inquilinos, Contoso, es mucho más grande y consume más escritura que los demás, y su tamaño sigue creciendo. 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 combinación de TenantID y UserID producirá particiones lógicas que superen el límite de 20 GB, puede particionar más abajo a otro nivel como SessionID. Las consultas que especifican TenantID o TenantID y UserID se enrutan de forma eficaz solo al subconjunto de particiones físicas que contienen los datos relevantes, lo que evita una consulta de distribución ramificada completa. Si el contenedor tenía 1.000 particiones físicas, pero un valor específico TenantId solo estaba en 5 particiones físicas, la consulta se enrutaría al número menor de particiones físicas relevantes.

    Si el primer nivel no tiene una cardinalidad suficientemente alta y alcanza el límite de partición lógica 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.

Cuenta de base de datos por inquilino

Al aislar nuestros inquilinos por cuenta de base de datos, cada inquilino tendrá 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 con RU/s aprovisionadas por inquilino único.
  • SLA personalizados: debido a que cada inquilino tiene su propia cuenta, puede proporcionar recursos personalizados específicos, SLA orientados al cliente y garantías, ya que la cuenta de base de datos de cada inquilino se puede optimizar de forma independiente para el rendimiento.
  • Seguridad mejorada: el aislamiento de datos físicos garantiza una seguridad sólida, ya que los clientes pueden habilitar claves administradas por el 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 (PITR) y las claves administradas por el cliente (CMK) según sea necesario.

Contrapartidas:

  • Administración mejorada: este enfoque aporta una mayor complejidad porque administra varias cuentas de Azure Cosmos DB.
  • Mayores costes: más cuentas significan el rendimiento de aprovisionamiento (RU/s) en cada recurso (bases de datos o contenedores) dentro de la cuenta, para cada inquilino. Cada vez que un recurso aprovisiona RU/s, los costes de Azure Cosmos DB aumentan.
  • Limitaciones de consulta: dado que todos los inquilinos están dentro de cuentas diferentes, se necesitan varias llamadas dentro de la lógica de la aplicación a cada inquilino al consultar varios inquilinos.

Características de Azure Cosmos DB relevantes:

  • Características de seguridad: este modelo proporciona un mayor aislamiento de seguridad de acceso a 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.
  • 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 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.

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 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

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.

De forma similar al modelo 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.

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, como un GUID de cardinalidad alta, para permitir una escala casi sin enlazar. O bien, puede especificar una clave de partición jerárquica que incluya una propiedad que se usa con frecuencia en las consultas. Este enfoque le ayuda a evitar consultas entre particiones. Mediante el uso de claves de partición jerárquica, puede 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 ramificada costosas.

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.

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 unidades de solicitud al inquilino. En el caso de los inquilinos con requisitos menos estrictos, se recomienda aislar los inquilinos por clave de partición, lo que permite compartir unidades de solicitud entre los inquilinos y le ayuda a optimizar un bajo coste 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. 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:

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

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: