Enfoques de arquitectura para el proceso en soluciones multiinquilino

La mayoría de las soluciones basadas en la nube se componen de recursos de proceso. Estos recursos pueden incluir niveles web y de aplicación, procesadores por lotes, trabajos programados o recursos especializados, como GPU y proceso de alto rendimiento. Las soluciones multiinquilino suelen beneficiarse de los recursos de proceso compartidos porque una mayor densidad de inquilinos para cada infraestructura reduce los costos operativos y simplifica la administración. Debe tener en cuenta los requisitos de aislamiento y las implicaciones de la infraestructura compartida.

En este artículo se ofrece orientación en torno a las consideraciones y requisitos cruciales que los arquitectos de soluciones deben tener en cuenta al planear un nivel de procesamiento multitenant. Esta guía incluye patrones comunes para aplicar el multialojamiento a los servicios de computación y antipatrones a evitar.

Consideraciones clave y requisitos

Tanto la multitenencia como el modelo de aislamiento que elijas afectan al escalado, el rendimiento, la gestión del estado y la seguridad de tus recursos de cómputo. En las siguientes secciones se revisan las decisiones clave que debe tomar al planificar una solución informática multitenante.

Escala

Los sistemas deben funcionar adecuadamente a medida que cambian la demanda. A medida que aumente el número de inquilinos y el tráfico, es posible que tenga que escalar los recursos para que coincidan con la creciente demanda y mantener un rendimiento aceptable. De forma similar, cuando el número de usuarios activos o la cantidad de tráfico disminuye, debería reducir automáticamente la capacidad de proceso para reducir los costos. Sin embargo, debe minimizar cualquier interrupción para los usuarios al ajustar la capacidad.

Si implementa recursos dedicados para cada inquilino, tiene la flexibilidad de escalar los recursos de cada inquilino de forma independiente. En una solución en la que los recursos de computación se comparten entre varios usuarios, el escalado de esos recursos permite que todos los usuarios se beneficien de la mayor capacidad. Sin embargo, todos los inquilinos se ven afectados cuando la escala es insuficiente para manejar su carga total. Para obtener más información, consulte Antipatrón vecino ruidoso.

Al crear soluciones en la nube, puede elegir si se va a escalar horizontal o verticalmente. En una solución multiinquilino que tiene un número creciente de inquilinos, el escalado horizontalmente suele proporcionar mayor flexibilidad y un límite máximo de escala general más alto.

Los problemas de rendimiento a menudo permanecen sin detectar hasta que una aplicación está bajo carga. Puede usar un servicio totalmente administrado, como Azure Load Testing, para obtener información sobre cómo funciona la aplicación bajo estrés.

Desencadenadores de escalado

Independientemente del enfoque que utilice para escalar, normalmente es necesario planificar los desencadenantes que provocan que sus componentes se escalen. Cuando tenga componentes compartidos, considere los patrones de carga de trabajo de cada inquilino para asegurarse de que la capacidad aprovisionada cumple la demanda total necesaria. Este enfoque ayuda a evitar la contención de recursos y reduce la probabilidad de que los inquilinos experimenten el problema de vecino ruidoso. También puede planear la capacidad de escalado en función del número de inquilinos. Por ejemplo, si mide los recursos que usa para atender a 100 inquilinos, a medida que incorpora más inquilinos, puede planear escalar para que sus recursos se dupliquen por cada 100 inquilinos adicionales.

Estado

Los recursos de proceso pueden ser sin estado o pueden ser con estado. Los componentes sin estado no mantienen ningún dato entre solicitudes. Desde el punto de vista de la escalabilidad, los componentes sin estado suelen ser fáciles de escalar horizontalmente, ya que se pueden añadir rápidamente nuevos trabajadores, instancias o nodos. Los componentes sin estado también pueden empezar a procesar solicitudes de forma inmediata. Si la arquitectura admite la reutilización de instancias, también puede reasignar instancias de un inquilino a otro.

Los recursos con estado se pueden subdividir aún más en función del tipo de estado que mantienen. El estado persistente es los datos que deben almacenarse de forma permanente. En las soluciones en la nube, evite almacenar un estado persistente en el nivel de proceso. En su lugar, use servicios de almacenamiento como bases de datos o cuentas de almacenamiento. El estado transitorio es datos almacenados temporalmente. Incluye cachés en memoria de solo lectura y almacenamiento de archivos temporales en discos locales.

El estado transitorio suele ser útil para mejorar el rendimiento del nivel de aplicación al reducir el número de solicitudes a los servicios de almacenamiento back-end. Por ejemplo, cuando se usa una caché en memoria, es posible que pueda atender solicitudes de lectura sin conectarse a una base de datos y sin realizar una consulta intensiva que ha realizado recientemente al atender otra solicitud.

En las aplicaciones sensibles a la latencia, el costo de la hidratación de la caché puede ser significativo. Una solución multiinquilino puede empeorar este problema si cada inquilino requiere que se almacenen en caché datos diferentes. Para mitigar este problema, algunas soluciones aplican afinidad de sesión. Este enfoque garantiza que el mismo nodo de cálculo procese todas las solicitudes de un usuario o inquilino específico. La afinidad de sesión puede mejorar la capacidad del nivel de aplicación para usar su caché de forma eficaz. Sin embargo, la afinidad de sesión también complica el escalado y el equilibrio de carga del tráfico entre los trabajadores. Considere cuidadosamente esta compensación. Para muchas aplicaciones, no se requiere afinidad de sesión.

También es posible almacenar datos en cachés externas, como Azure Managed Redis. Las memorias caché externas están optimizadas para la recuperación de datos de baja latencia, a la vez que se aísla el estado de los recursos de proceso para que se puedan escalar y administrar por separado. En muchas soluciones, las cachés externas le permiten mejorar el rendimiento de la aplicación, mientras mantiene el nivel de proceso sin estado.

Aislamiento

Cuando diseña un nivel de computación multicliente, tiene varias opciones para el aislamiento de clientes. Puede implementar recursos de proceso compartidos para todos los inquilinos, recursos de proceso dedicados para inquilinos individuales o un enfoque semi aislado que se encuentra entre estos extremos. Cada opción tiene desventajas. Para ayudarle a decidir qué opción se adapta mejor a su solución, tenga en cuenta sus requisitos para el aislamiento.

Es posible que le interese el aislamiento lógico de los inquilinos y cómo separar las responsabilidades o directivas de administración que se aplican a cada inquilino. Como alternativa, es posible que tenga que implementar configuraciones de recursos distintas para inquilinos específicos, como implementar una SKU de máquina virtual específica para adaptarse a la carga de trabajo de un inquilino.

En función del modelo de aislamiento que elija, asegúrese de que los datos del inquilino permanecen aislados correctamente, incluso si se producen errores o interrupciones de componentes. Considere la posibilidad de usar Azure Chaos Studio en el proceso de prueba automatizado normal para introducir errores que simulan interrupciones del mundo real. Esta prueba ayuda a comprobar que la solución mantiene el aislamiento de inquilino adecuado y sigue funcionando bajo presión.

Procedimientos y patrones que se deben tener en cuenta

Escalado automático

Los servicios de proceso de Azure proporcionan varias funcionalidades que escalan las cargas de trabajo. Muchos servicios de proceso admiten el escalado automático, lo que requiere determinar cuándo escalar y establecer los niveles de escala mínimo y máximo. Las opciones de escalado específicas dependen de los servicios de proceso que use. Consulte los siguientes servicios o componentes de ejemplo:

• Azure App Service:especifique reglas de escalado automático que escalen la infraestructura en función de sus requisitos.

• Azure Functions: Elija entre varias opciones de escala, incluido un modelo de escalado controlado por eventos que se escale automáticamente en función del trabajo que realizan las funciones.

• Azure Container Apps: Use el escalado automático controlado por eventos para escalar la aplicación en función del trabajo que realiza y en su carga actual.

• Azure Kubernetes Service (AKS): Para mantenerse al día con las demandas de la aplicación, es posible que tenga que ajustar el número de nodos que ejecutan las cargas de trabajo. Para escalar rápidamente las cargas de trabajo de aplicaciones en un clúster de AKS, puede usar nodos virtuales.

• Vms: Un conjunto de escalado de máquinas virtuales puede aumentar o disminuir automáticamente el número de instancias de máquina virtual que ejecutan la aplicación.

Patrón de stamps de implementación

Para obtener más información sobre cómo puede utilizar el patrón de sellos de implementación para respaldar una solución multicliente, consulte Enfoques arquitectónicos para una solución multicliente.

Patrón de Consolidación de Recursos Informáticos

El patrón de consolidación de recursos de computación le ayuda a lograr una mayor densidad de inquilinos en la infraestructura de computación mediante el uso compartido de los recursos de computación subyacentes. Al compartir recursos de computación, puede reducir el costo directo de esos recursos. Además, los costos de administración suelen ser menores porque hay menos componentes que administrar.

Sin embargo, la consolidación de recursos de cómputo aumenta la probabilidad del problema de vecino ruidoso. La carga de trabajo de cualquier inquilino puede consumir una cantidad desproporcionada de la capacidad de proceso que está disponible. A menudo, puede mitigar este riesgo asegurándose de escalar la solución de forma adecuada y aplicando controles como cuotas y límites de API para evitar inquilinos que consumen más que su cuota justa de la capacidad.

Este patrón se logra de diferentes maneras, en función del servicio de proceso que use. Consulte los siguientes servicios o componentes de ejemplo:

• App Service y Azure Functions: Implemente planes compartidos de App Service, que representan la infraestructura del servidor de hospedaje.

• Aplicaciones de contenedor: Implementar entornos compartidos.

• AKS: Implemente pods compartidos con una aplicación compatible con la multiinquilino.

• Vms: Implemente un único conjunto de máquinas virtuales para que todos los inquilinos los usen.

Recursos de cómputo dedicados para cada cliente

También puede implementar recursos de cómputo dedicados para cada cliente. Los recursos dedicados mitigan el riesgo del problema de vecino ruidoso al asegurarse de que los recursos de proceso de cada inquilino están aislados de los demás. También permite implementar una configuración distinta para los recursos de cada inquilino en función de sus requisitos. Sin embargo, los recursos dedicados suelen incurrir en un costo mayor porque tienen una menor densidad de inquilinos por recurso.

En función de los servicios de proceso de Azure que use, es posible que tenga que implementar diferentes recursos dedicados:

• App Service y Azure Functions: Implemente planes de App Service independientes para cada inquilino.

• Aplicaciones de contenedor: Implemente entornos independientes para cada inquilino.

• AKS: Implemente clústeres dedicados para cada inquilino.

• Vms: Implemente máquinas virtuales dedicadas para cada inquilino.

El aislamiento de nivel de host físico también se puede proporcionar mediante la ejecución de máquinas virtuales de inquilino en hosts dedicados de Azure, que reservan un servidor físico completo para un solo cliente. Sin embargo, este enfoque suele ser más caro que usar hosts compartidos.

Recursos de cómputo semi-aislados

Los enfoques semi aislados requieren que implemente aspectos de la solución en una configuración aislada mientras comparte los demás componentes.

Al usar App Service y Azure Functions, puede implementar aplicaciones distintas para cada inquilino y hospedar las aplicaciones en planes compartidos de App Service. Este enfoque reduce el costo del nivel de proceso, ya que los planes de App Service representan la unidad de facturación. También permite aplicar directivas y configuración distintas a cada aplicación. Sin embargo, este enfoque introduce el riesgo del problema de vecino ruidoso.

Puede usar Container Apps para implementar varias aplicaciones en un entorno compartido y, a continuación, usar Dapr y otras herramientas para configurar cada aplicación por separado.

AKS y Kubernetes, de manera más amplia, proporcionan varias opciones para la multitenencia.

• Espacios de nombres específicos del inquilino que pueden proporcionar aislamiento lógico de recursos específicos del inquilino, que se implementan en clústeres compartidos y grupos de nodos.

• Nodos o grupos de nodos específicos del inquilino en un clúster compartido

• Pods específicos del cliente que podrían usar el mismo conjunto de nodos

También puede utilizar AKS para aplicar la gobernanza a nivel de pod para mitigar el problema del vecino ruidoso. Para obtener más información, consulte Procedimientos recomendados para que los desarrolladores de aplicaciones administren recursos en AKS.

También es importante tener en cuenta los componentes compartidos en un clúster de Kubernetes y cómo la multitenencia podría afectar a estos componentes. Por ejemplo, el servidor de API de Kubernetes es un servicio compartido que se usa en todo el clúster. Incluso si proporciona grupos de nodos específicos del inquilino para aislar las cargas de trabajo de aplicación de los inquilinos, el servidor de API podría experimentar contención debido a un gran número de solicitudes entre todos los inquilinos.

Antipatrones que se deben evitar

Evite los siguientes antipatrones.

Antipatrón Vecino ruidoso

Al implementar componentes que comparten los inquilinos, el problema de vecino ruidoso es un riesgo potencial. Asegúrese de incluir la gobernanza y supervisión de recursos para mitigar el riesgo de que la actividad de otros arrendatarios afecte la carga de trabajo computacional de un cliente.

Pérdida de datos entre inquilinos

Los niveles de procesos pueden estar sujetos a fugas de datos entre inquilinos si no se administran adecuadamente. Este riesgo no suele ser algo que debe tener en cuenta al usar un servicio multiinquilino en Azure porque Microsoft proporciona protecciones en la capa de plataforma. Sin embargo, al desarrollar su propia aplicación multiinquilino, considere si algún recurso compartido, como las memorias caché de disco local, la RAM y las cachés externas, podría contener datos que otro inquilino pueda ver o modificar accidentalmente.

Antipatrón Front End ocupado

Para evitar el antipatrón de front-end ocupado, asegúrese de que su nivel de front-end no realice la mayor parte del trabajo que pueden administrar otros componentes o niveles de su arquitectura. Este antipatrón es especialmente importante cuando se crean servidores front-end compartidos para una solución multiinquilino porque un front-end ocupado degrada la experiencia de todos los inquilinos.

En su lugar, considere la posibilidad de usar el procesamiento asincrónico mediante colas u otros servicios de mensajería. Este enfoque también le permite aplicar controles de calidad de servicio (QOS) para distintos inquilinos en función de sus requisitos. Por ejemplo, todos los inquilinos pueden compartir un nivel de front-end común, pero los inquilinos que pagan por un nivel de servicio superior podrían tener un mayor conjunto de recursos dedicados para procesar el trabajo desde sus mensajes de cola.

Escalado inelástico o insuficiente

Las soluciones multiinquilino suelen estar sujetas a patrones de escalado a ráfagas. Los componentes compartidos son especialmente vulnerables a este problema porque el ámbito de ráfaga es mayor y el efecto es mayor cuando tiene más inquilinos que tienen patrones de uso distintos.

Asegúrese de aprovechar la elasticidad y la escala de la nube. Tenga en cuenta si debe usar el escalado horizontal o vertical y usar el escalado automático para controlar automáticamente los picos de carga. Pruebe la solución para comprender cómo funciona en diferentes niveles de carga. Asegúrese de incluir los volúmenes de carga que se esperan en producción y el crecimiento esperado. Puede usar un servicio totalmente administrado, como Load Testing, para obtener información sobre cómo funciona la aplicación bajo estrés.

Antipatrón No Caching

El antipatrón Sin caché se produce cuando el rendimiento de la solución se ve afectado porque la capa de aplicación solicita repetidamente o vuelve a calcular información que podría reutilizarse en las solicitudes. Si tiene datos que se pueden compartir, ya sea entre inquilinos o entre usuarios dentro de un único inquilino, es probable que valga la pena almacenarlos en caché para reducir la carga en el nivel de back-end o de base de datos.

Estado innecesario

La implicación del antipatrón Sin almacenamiento en caché es que también debe evitar almacenar estados innecesarios en su nivel de procesos. Sea explícito sobre dónde mantener el estado y por qué. Los niveles de aplicación y de front-end con estado pueden reducir la capacidad de escalado. Por lo general, los niveles de proceso con estado también requieren afinidad de sesión, lo que puede reducir la capacidad de equilibrar la carga del tráfico entre los nodos o los roles de trabajo de forma eficaz.

Considere las ventajas e inconvenientes de cada elemento de estado que mantiene en su nivel de proceso y si afecta a su capacidad para escalar o crecer a medida que cambian los patrones de carga de trabajo de sus inquilinos. También puede almacenar el estado en una caché externa, como Azure Managed Redis.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

• Dixit Arora | Ingeniero superior de clientes, FastTrack para Azure
• John Downs | Ingeniero principal de software, Patrones y prácticas de Azure

Otros colaboradores:

• Arsen Vladimirskiy | Ingeniero Principal de Clientes, FastTrack para Azure

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

Recursos relacionados

Revisa la guía específica para los servicios de computación:

• Consideraciones de App Service y Azure Functions para sistemas multiinquilino
• Consideraciones para usar Container Apps en una solución multiinquilino
• Consideraciones de AKS para la multiinquilino