Enfoques arquitectónicos para el almacenamiento y los datos en soluciones de multiinquilino

A menudo, los datos se consideran la parte más valiosa de una solución porque representa la información empresarial valiosa de sus clientes y sus clientes. Es importante administrar cuidadosamente los datos. Al planear el almacenamiento o los componentes de datos para un sistema multiinquilino, debe decidir un enfoque para compartir o aislar los datos de los inquilinos.

En este artículo se proporcionan instrucciones sobre las consideraciones clave y los requisitos para los arquitectos de soluciones cuando deciden un enfoque para almacenar datos en un sistema multiinquilino. En este artículo también se describen algunos patrones comunes para aplicar multiinquilino a servicios de almacenamiento y datos y algunos antipatrones para evitar. También proporciona instrucciones dirigidas para algunos escenarios específicos.

Consideraciones clave y requisitos

Es importante tener en cuenta los enfoques que se usan para el almacenamiento y los servicios de datos desde varias perspectivas, incluidos los pilares de Azure Well-Architected Framework.

Escala

Al trabajar con servicios que almacenan los datos, debe tener en cuenta el número de inquilinos que tiene y el volumen de datos que almacena. Si tiene pocos inquilinos, como cinco o menos, y almacena pequeñas cantidades de datos para cada inquilino, es probable que no necesite planear un enfoque de almacenamiento de datos altamente escalable o crear un enfoque totalmente automatizado para administrar los recursos de datos.

Pero, a medida que crece, se beneficia cada vez más de tener una estrategia clara para escalar los datos y los recursos de almacenamiento y automatizar su administración. Cuando tenga 50 inquilinos o más, o si planea alcanzar ese nivel de escala, es especialmente importante diseñar el enfoque de datos y almacenamiento con escala como consideración clave.

Tenga en cuenta la medida en que planea escalar, y planee claramente el enfoque arquitectónico del almacenamiento de datos para satisfacer ese nivel de escala.

Predictibilidad del rendimiento

Los servicios de almacenamiento y datos multiinquilino son susceptibles al problema de vecino ruidoso. Es importante tener en cuenta si es posible que sus inquilinos afecten al rendimiento de los demás. Por ejemplo, considere si los inquilinos tienen picos superpuestos en sus patrones de uso a lo largo del tiempo. Considere también si todos los clientes usan la solución al mismo tiempo cada día y si las solicitudes se distribuyen uniformemente. Estos factores afectan al nivel de aislamiento que necesita diseñar, la cantidad de recursos que necesita aprovisionar y el grado en que los inquilinos pueden compartir recursos.

Es importante tener en cuenta las cuotas de recursos y solicitudes de Azure como parte de esta decisión. Por ejemplo, supongamos que implementa una sola cuenta de almacenamiento para contener todos los datos de los inquilinos. Si supera un número específico de operaciones de almacenamiento por segundo, Azure Storage rechaza las solicitudes de la aplicación, lo que afecta a todos los inquilinos. Este comportamiento se denomina limitación. Es importante supervisar las solicitudes limitadas.

Aislamiento de datos

Al diseñar una solución que contenga servicios de datos multiinquilino, hay diferentes opciones y niveles de aislamiento de datos que tienen sus propias ventajas y desventajas. Tenga en cuenta los ejemplos siguientes:

• Al usar Azure Cosmos DB, puede implementar contenedores independientes para cada inquilino y puede compartir bases de datos y cuentas entre varios inquilinos. Como alternativa, puede considerar la posibilidad de implementar bases de datos diferentes o incluso cuentas para cada inquilino, en función del nivel de aislamiento que necesite.

• Al usar Storage para datos de blobs, puede implementar contenedores de blobs independientes para cada inquilino o puede implementar cuentas de almacenamiento independientes.

• Al usar Azure SQL, puede usar tablas independientes en bases de datos compartidas o puede implementar bases de datos o servidores independientes para cada inquilino.

• En todos los servicios de Azure, puede considerar la posibilidad de implementar recursos dentro de una sola suscripción de Azure compartida, o bien puede usar varias suscripciones de Azure o incluso una suscripción para cada inquilino.

No hay ninguna solución única que funcione para cada escenario. La opción que elija depende de varios factores y de los requisitos de los inquilinos. Por ejemplo, si diseña una solución de negocio a consumidor (B2C), puede ser razonable tener un único almacén de datos para todos los datos. Sin embargo, si los inquilinos necesitan cumplir estándares normativos o de cumplimiento específicos, es posible que tenga que aplicar un mayor nivel de aislamiento.

Del mismo modo, es posible que tenga requisitos comerciales para aislar físicamente los datos de los clientes, o puede que tenga que aplicar el aislamiento para evitar el problema de vecino ruidoso. Si se aplica alguna de las condiciones siguientes, es posible que tenga que aislar inquilinos de otros usuarios o agruparlos con inquilinos que tengan directivas similares:

• Los inquilinos deben usar sus propias claves de cifrado.
• Los inquilinos tienen directivas individuales de copia de seguridad y restauración
• Los inquilinos deben tener sus datos almacenados en diferentes ubicaciones geográficas

Complejidad de la implementación

Es importante tener en cuenta la complejidad de la implementación. Es recomendable mantener la arquitectura lo más sencilla posible, a la vez que cumple los requisitos. Evite confirmar una arquitectura que pueda ser cada vez más compleja a medida que escale o una arquitectura que no tenga los recursos o conocimientos necesarios para desarrollar y mantener.

Del mismo modo, si la solución no necesita escalar a un gran número de inquilinos o si no le preocupa el rendimiento o el aislamiento de datos, es mejor mantener la solución simple y evitar agregar complejidad innecesaria.

Una inquietud particular relacionada con las soluciones de datos de varios inquilinos es el nivel de personalización que se admite. Por ejemplo, puede permitir que un inquilino amplíe el modelo de datos o aplique reglas de datos personalizadas. Asegúrese de diseñar para este requisito por adelantado. Evite la bifurcación o proporcione una infraestructura personalizada para inquilinos individuales. Una infraestructura personalizada le impide la capacidad de escalar, probar la solución e implementar actualizaciones. En su lugar, considere la posibilidad de usar marcas de características y otras formas de configuración de inquilinos.

Complejidad de la administración y las operaciones

Tenga en cuenta cómo planea operar la solución y cómo afecta el enfoque multiinquilino a sus operaciones y procesos.

• Administración: Considere las operaciones de administración, como las actividades de mantenimiento normales. Si usa varios servidores, almacenes de archivos o bases de datos, planee cómo iniciar y supervisar las operaciones de mantenimiento de los recursos de cada inquilino.

• Supervisión y medición: Si supervisa o mide los inquilinos, tenga en cuenta cómo notifica las métricas de la solución y si puede vincular fácilmente las métricas al inquilino que desencadenó la solicitud.

• Informes: Considere si necesita informar sobre los datos agregados de entre varios inquilinos aislados. A medida que la solución se escala, resulta complicado ejecutar consultas en cada base de datos individualmente y agregar los resultados. Un enfoque diferente es hacer que las aplicaciones de cada inquilino publiquen datos en un almacenamiento de datos centralizado.

• Actualizaciones de esquema: Si usa una base de datos que aplica un esquema, planee cómo implementar actualizaciones de esquema en todo el patrimonio. Tenga en cuenta de qué manera la aplicación sabe qué versión de esquema usar para las consultas a las base de datos de un inquilino específico.

• Requisitos: Tenga en cuenta los requisitos de alta disponibilidad de los inquilinos, como los contratos de nivel de servicio (SLA) de tiempo de actividad y los requisitos de recuperación ante desastres, como los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO). Si los inquilinos tienen expectativas diferentes, compruebe que puede cumplir los requisitos de cada inquilino.

• Migración: Considere si desea permitir que los inquilinos se muevan a otro tipo de servicio, una implementación diferente u otra región. Si tiene previsto ofrecer esta funcionalidad, cree procesos y herramientas para asegurarse de que es un proceso repetible y seguro.

Costos

Por lo general, cuanto mayor sea la densidad de los inquilinos en la infraestructura de implementación, menor será el costo de aprovisionar esa infraestructura. Sin embargo, la infraestructura compartida aumenta la probabilidad de problemas como el problema de vecino ruidoso, por lo que considere cuidadosamente las ventajas.

Enfoques y patrones que se deben tener en cuenta

Varios patrones de diseño del Centro de arquitectura de Azure son relevantes para los servicios de datos y almacenamiento multiinquilino. Puede optar por seguir un patrón de manera coherente. O bien, puede considerar la posibilidad de combinar y buscar coincidencias de patrones. Por ejemplo, puede usar una base de datos multiinquilino para la mayoría de los inquilinos, pero implementar stamps de inquilino único para los inquilinos que pagan más o que tienen requisitos inusuales.

Patrón de stamps de implementación

Para obtener más información sobre cómo usar el patrón de stamps de implementación para admitir una solución multiinquilino, vea Información general.

Bases de datos y almacenes de archivos multiinquilino compartidos

Puede considerar la posibilidad de implementar una base de datos multiinquilino compartida, una cuenta de almacenamiento o un recurso compartido de archivos y compartirlo en todos los inquilinos.

Este enfoque proporciona la mayor densidad de inquilinos a la infraestructura, por lo que tiende a llegar al menor costo financiero de cualquier enfoque. También suele reducir la sobrecarga de administración porque hay una sola base de datos o recurso para administrar, realizar copias de seguridad y proteger.

Sin embargo, al trabajar con la infraestructura compartida, tenga en cuenta los siguientes inconvenientes:

• Límites de escala: Cuando se basa en un único recurso, tenga en cuenta la escala y los límites admitidos de ese recurso. Por ejemplo, si la arquitectura se basa en una base de datos compartida única, el tamaño máximo de una base de datos o un almacén de archivos, o los límites de rendimiento máximos, finalmente se convierten en un bloqueador duro. Tenga en cuenta cuidadosamente la escala máxima que necesita para lograr y compararla con los límites actuales y futuros antes de seleccionar este patrón.

• Vecinos ruidosos: El problema de vecino ruidoso puede convertirse en un factor, especialmente si tiene inquilinos ocupados o generan cargas de trabajo más altas que otras. Considere la posibilidad de aplicar el patrón throttling o el patrón de limitación de velocidad para mitigar estos efectos.

• Medir el consumo de los inquilinos: Tenga en cuenta si necesita medir el consumo de cada inquilino. Algunos servicios de datos, como Azure Cosmos DB, proporcionan informes sobre el uso de recursos para cada transacción. Puede realizar un seguimiento de esta información y agregarla para medir el consumo de cada inquilino. Otros servicios no proporcionan el mismo nivel de detalle. Por ejemplo, al usar Azure Files con recursos compartidos de archivos Premium, puede acceder a las métricas de capacidad de archivo para cada dimensión de recurso compartido de archivos. El nivel estándar proporciona las métricas solo en el nivel de cuenta de almacenamiento.

• Requisitos de inquilino: Los inquilinos pueden tener requisitos diferentes para la seguridad, copia de seguridad, disponibilidad o ubicación de almacenamiento. Si estos requisitos no coinciden con la configuración del recurso único, es posible que no pueda acomodarlos.

• Personalización del esquema: Cuando se trabaja con una base de datos relacional u otro escenario en el que el esquema de los datos es importante, la personalización del esquema de nivel de inquilino es difícil.

Patrón de particionamiento

El patrón de particionamiento implica implementar varias bases de datos independientes, denominadas particiones, que cada una contiene uno o varios datos de inquilinos. A diferencia de los stamps de implementación, las particiones no implican que toda la infraestructura esté duplicada. Puede particionar bases de datos sin duplicar ni particionar otras infraestructuras de la solución.

El particionamiento está estrechamente relacionado con la creación de particiones y los términos a menudo se usan indistintamente. Analice la guía para la creación de particiones de datos horizontales, verticales y funcionales.

El patrón de particionamiento puede escalar a un gran número de inquilinos. En función de la carga de trabajo, también puede lograr una alta densidad de inquilinos en particiones, lo que puede reducir los costos. Puede usar el patrón de particionamiento para abordar las cuotas, límites y restricciones de suscripción y servicio de Azure.

Algunos almacenes de datos, como Azure Cosmos DB, ofrecen compatibilidad nativa para particionamiento o creación de particiones. Al trabajar con otras soluciones, como Azure SQL, puede ser más complejo crear una infraestructura de particionamiento y enrutar las solicitudes a la partición correcta para un inquilino determinado.

El particionamiento también dificulta la compatibilidad con las diferencias de configuración de nivel de inquilino y permite a los clientes proporcionar sus propias claves de cifrado.

Aplicación multiinquilino con bases de datos dedicadas para cada inquilino

Otro enfoque común es implementar una sola aplicación multiinquilino que tenga bases de datos dedicadas para cada inquilino.

En este modelo, los datos de cada inquilino están aislados de los datos de los demás y es posible que pueda admitir algún grado de personalización para cada inquilino.

El costo de este enfoque puede ser mayor que los modelos de hospedaje compartidos porque se aprovisionan recursos de datos dedicados para cada inquilino. Sin embargo, Azure proporciona varias opciones que puede considerar para compartir el costo de hospedar recursos de datos individuales en varios inquilinos. Por ejemplo, al trabajar con Azure SQL Database, puede considerar los grupos elásticos. Para Azure Cosmos DB, puede aprovisionar el rendimiento de una base de datos y el rendimiento se comparte entre los contenedores de esa base de datos. Sin embargo, este enfoque no es adecuado cuando se necesita un rendimiento garantizado para cada contenedor.

En este enfoque, como solo los componentes de datos se implementan individualmente para cada inquilino, es probable que pueda lograr una alta densidad para los demás componentes de la solución y reducir su costo.

Patrón de nodo geográfico

El patrón Geode está diseñado específicamente para soluciones distribuidas geográficamente, incluidas las soluciones multiinquilino. Admite una alta carga y altos niveles de resistencia. Si implementa el patrón Geode, el nivel de datos debe poder replicar los datos entre regiones geográficas y debe admitir escrituras de varias zonas geográficas.

Azure Cosmos DB proporciona escrituras en varias regiones para admitir este patrón y Azure Managed Instance para Apache Cassandra admite clústeres de varias regiones. Normalmente, otros servicios de datos no pueden admitir este patrón sin una personalización significativa.

Antipatrones que se deben evitar

Al crear servicios de datos multiinquilino, es importante evitar situaciones que impidan su capacidad de escalado.

En el caso de las bases de datos relacionales, estos antipatrones incluyen:

• Aislamiento basado en tablas. Al trabajar en una base de datos única, evite crear tablas individuales para cada inquilino. Una base de datos única no puede admitir un gran número de inquilinos cuando se usa este enfoque y resulta cada vez más difícil consultar, administrar y actualizar datos. En su lugar, considere la posibilidad de usar un único conjunto de tablas multiinquilino con una columna de identificador de inquilino. Como alternativa, puede usar un patrón recomendado para implementar bases de datos independientes para cada inquilino.

• Personalización del inquilino a nivel de columna. Evite hacer actualizaciones de esquema que solo se apliquen a un único inquilino. Por ejemplo, supongamos que tiene una base de datos multiinquilino única. evite agregar una nueva columna para satisfacer los requisitos de un inquilino específico. Puede ser aceptable para algunas personalizaciones, pero este método se vuelve rápidamente inadministrable cuando tiene muchas personalizaciones que se deben tener en cuenta. En su lugar, considere la posibilidad de revisar el modelo de datos para realizar un seguimiento de los datos personalizados de cada inquilino en una tabla dedicada.

• Cambios manuales en el esquema. Evite actualizar el esquema de la base de datos manualmente, incluso si solo tiene una única base de datos compartida. Es fácil perder el seguimiento de las actualizaciones que aplique y, si necesita escalar horizontalmente a más bases de datos, es difícil identificar el esquema correcto que se va a aplicar. En su lugar, cree herramientas o una canalización automatizada para implementar los cambios de esquema y úsela de forma coherente. Realice un seguimiento de la versión de esquema que use para cada inquilino de una base de datos dedicada o tabla de búsqueda.

• Dependencias de versión. Evite que la aplicación tome una dependencia en una sola versión del esquema de la base de datos. A medida que escale, es posible que tenga que aplicar actualizaciones de esquema en momentos diferentes para distintos inquilinos. En su lugar, asegúrese de que la versión de la aplicación sea compatible con al menos una versión de esquema anterior y que los cambios de esquema destructivos de secuencia en varias versiones admitan reversiones.

Bases de datos

Hay algunas características que pueden ser útiles para el multiinquilinato. Sin embargo, estas características no están disponibles en todos los servicios de base de datos. Tenga en cuenta si necesita las siguientes características al decidir el servicio que se va a usar para su escenario:

• La seguridad de nivel de fila puede proporcionar aislamiento de seguridad para los datos específicos de los inquilinos en una base de datos multiinquilino compartida. Esta característica está disponible en algunas bases de datos, como SQL Database y el servidor flexible de Azure Database for PostgreSQL.

  Al usar la seguridad de nivel de fila, debe asegurarse de que la identidad del usuario y la identidad del inquilino se propagan a través de la aplicación y en el almacén de datos con cada consulta. Este enfoque puede ser complejo diseñar, implementar, probar y mantener. Muchas soluciones multiinquilino no usan la seguridad de nivel de fila debido a esas complejidades.

• Es posible que se requiera cifrado de nivel de inquilino para admitir inquilinos que proporcionen sus propias claves de cifrado para sus datos. Esta característica está disponible en SQL Server y Azure SQL como parte de Always Encrypted. Azure Cosmos DB ofrece claves administradas por el cliente a nivel de cuenta y también admite Always Encrypted.

• La agrupación de recursos permite compartir recursos y sus costos entre varias bases de datos o contenedores. Esta característica está disponible en grupos elásticos de SQL Database, en Azure SQL Managed Instance y en el rendimiento de la base de datos de Azure Cosmos DB.

• El particionamiento y la creación de particiones tienen una compatibilidad nativa más sólida en algunos servicios que en otros. Esta característica está disponible en Azure Cosmos DB mediante su creación de particiones lógicas y físicas. Aunque SQL Database no admite de forma nativa el particionamiento, proporciona herramientas de particionamiento para admitir este tipo de arquitectura.

Además, al mantener una flota de bases de datos relacionales u otras bases de datos basadas en esquemas, tenga en cuenta dónde se debe desencadenar el proceso de actualización del esquema. En un pequeño patrimonio de bases de datos, podría considerar la posibilidad de usar una canalización de implementación para implementar los cambios de esquema. A medida que aumenta el número de bases de datos, puede ser mejor que el nivel de aplicación detecte la versión del esquema de una base de datos específica e inicie el proceso de actualización.

Almacenamiento de archivos y blobs

Tenga en cuenta el enfoque que se usa para aislar los datos dentro de una cuenta de almacenamiento. Por ejemplo, puede implementar cuentas de almacenamiento independientes para cada inquilino, o compartir cuentas de almacenamiento e implementar contenedores individuales. Como alternativa, puede crear contenedores de blobs compartidos y, luego, puede usar la ruta de acceso del blob para separar los datos de cada inquilino. Considere los límites y cuotas de la suscripción de Azure y planee cuidadosamente el crecimiento para asegurarse de que los recursos de Azure se escalan para satisfacer sus necesidades futuras.

Si usa contenedores compartidos, planee cuidadosamente la estrategia de autenticación y autorización para asegurarse de que los inquilinos no puedan acceder a los datos de los demás. Tenga en cuenta el patrón de clave de valet al proporcionar a los clientes acceso a los recursos de Storage.

Asignación de costos

Considere cómo medir el consumo y asignar costos a los inquilinos para el uso de servicios de datos compartidos. Siempre que sea posible, utilice métricas integradas en lugar de calcular las propias. Sin embargo, con una infraestructura compartida, resulta difícil dividir los datos de telemetría para inquilinos determinados y debería tener en cuenta la opción de utilizar un sistema de medición personalizado para la aplicación.

En general, los servicios nativos de nube, como Azure Cosmos DB y Azure Blob Storage, proporcionan métricas más granulares para hacer un seguimiento y modelar el uso de un inquilino específico. Por ejemplo, Azure Cosmos DB ofrece el rendimiento consumido para cada solicitud y respuesta.

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:

• Paul Burpo | Ingeniero principal de clientes, FastTrack para Azure
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

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

Recursos relacionados

Para más información sobre los servicios de Azure multiinquilino y específicos, consulte los siguientes recursos:

• Multiinquilino y almacenamiento
• Multiinquilino y SQL Database
• Multiinquilinato y Azure Cosmos DB
• Multiinquilino y Azure Database for PostgreSQL