Multiinquilinato y Azure Cosmos DB

  • Artículo
  • 9 minutos para leer

En esta página se describen algunas de las características de Azure Cosmos DB que son útiles al trabajar con sistemas multiinquilino y se ofrecen 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 Cosmos DB, puede crear contenedores que se comparten 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, Cosmos DB distribuye los inquilinos entre varios nodos físicos para lograr un alto grado de escala.

Más información:

Administración de unidades de solicitud

El modelo de precios de 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. 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 Cosmos DB.

Un modelo de inquilino para Cosmos DB implica la implementación de contenedores independientes para cada inquilino dentro de una base de datos compartida. 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 inquilino no se superponen, esto puede proporcionar un enfoque útil para reducir los costos operativos. Pero tenga en cuenta que 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 esto después de identificar a los inquilinos ruidosos, puede establecer 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.

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. En una solución multiinquilino, puede combinar todos estos enfoques para admitir diferentes tipos de inquilino.

Nota

Al planear la configuración de 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 Cosmos DB API 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. Cosmos DB proporciona una característica de clave administrada por el cliente. Esta característica se aplica en el nivel de una cuenta de Cosmos DB, por lo que los inquilinos que necesiten sus propias claves de cifrado tendrán que implementarse mediante cuentas de 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. Azure Cosmos DB admite varios modelos de aislamiento:

Contenedores compartidos con claves de partición por inquilino Contenedor con rendimiento compartido por inquilino Contenedor con rendimiento dedicado por inquilino Cuenta de base de datos por inquilino
Opciones de aislamiento
  • El rendimiento se comparte entre inquilinos agrupados por contenedor (excelente para reducir el costo en inquilinos "con picos").
  • Permite consultas sencillas entre inquilinos (los contenedores actúan como límite para las consultas). Se mitiga un radio de ráfaga de vecino ruidoso (los inquilinos se agrupan por contenedor).
  • El rendimiento se comparte entre inquilinos agrupados por base de datos (lo que es excelente para reducir los costos en inquilinos "con picos").
  • Administración sencilla de inquilinos (cuando el inquilino se va, se quita el contenedor).
  • Se mitiga el radio de ráfaga de vecino ruidoso (los inquilinos se agrupan por base de datos).
  • Opciones de rendimiento independientes (el rendimiento dedicado elimina los vecinos ruidosos).
  • Los inquilinos se agrupan dentro de las cuentas de base de datos, en función de las necesidades regionales.
  • Mecanismos de replicación geográfica independientes.
  • Varias opciones de rendimiento (el rendimiento dedicado elimina los vecinos ruidosos).
Requisitos de rendimiento >0 RU por inquilino >100 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

Contenedor compartido con claves de partición por inquilino

Cuando se usa un único contenedor para varios inquilinos, puede utilizar la compatibilidad de Cosmos DB con la creación de particiones. 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 multiinquilino y de un solo inquilino, donde los inquilinos más pequeños se agrupen en contenedores con particiones compartidas y los clientes grandes tengan contenedores dedicados.

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. También se pueden usar claves de partición jerárquicas para admitir inquilinos grandes.

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. Esto puede funcionar bien cuando los datos que almacena para el inquilino se pueden combinar en un único contenedor.

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. Si es necesario, planee agrupar los inquilinos en bases de datos diferentes basadas en patrones de carga de trabajo.

Como alternativa, puede aprovisionar un rendimiento dedicado para cada contenedor. Esto 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 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.

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.

Cuenta de base de datos por inquilino

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. 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. También puede configurar la ubicación de la cuenta de base de datos según los requisitos del inquilino y puede ajustar la configuración de las características de 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 Cosmos DB dedicada por inquilino, tenga en cuenta el número máximo de cuentas de Cosmos DB por suscripción de Azure.

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

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.

Pasos siguientes

Revise Recursos para arquitectos y desarrolladores de soluciones multiinquilino.