Compartir a través de

Enfoques arquitectónicos para la mensajería en soluciones multiinquilino

Las aplicaciones distribuidas que incluyen varios servicios internos y externos requieren mensajería asincrónica y comunicación controlada por eventos. Al diseñar la solución multiinquilino, debe decidir cómo compartir o particionar mensajes que pertenecen a diferentes inquilinos.

Puede compartir un sistema de mensajería o un servicio de streaming de eventos en todos los inquilinos para reducir la complejidad de la administración y el costo operativo. Como alternativa, puede usar un sistema de mensajería dedicado para cada inquilino para obtener un mejor aislamiento de datos, reducir el riesgo de pérdida de datos, eliminar el problema de vecino ruidoso y cobrar los costos de Azure a los inquilinos con mayor facilidad.

Este artículo ayuda a los arquitectos de soluciones a decidir cómo usar la infraestructura de mensajería o eventos en una solución multiinquilino.

Mensajes, puntos de datos y eventos discretos

Debe comprender la diferencia entre los servicios que entregan un evento y los sistemas que envían un mensaje. Un evento es una notificación ligera de un cambio de estado o condición. Normalmente, un evento describe algo que ya ha ocurrido. Un mensaje contiene datos sin procesar que un servicio genera para consumirse o almacenarse en otro lugar. Los mensajes son instrucciones o solicitudes implícitas.

En la tabla siguiente se describen los tipos de mensajería clave y las soluciones multiinquilino de ejemplo que pueden usar ese tipo de entidad.

Tipo de entidad Contenido Examples
Eventos discretos Información sobre acciones específicas que lleva a cabo la aplicación de publicación
  • Una plataforma para compartir música realiza un seguimiento de la música que escucha un usuario de un arrendatario específico.

  • Una aplicación de software como servicio (SaaS) de fabricación envía información en tiempo real a los clientes y a terceros externos sobre el mantenimiento de equipos, el estado del sistema y las actualizaciones de contratos.
Eventos de serie Puntos de datos informativos en un flujo continuo
  • Un sistema de control de edificio multiinquilino recibe eventos de telemetría, como lecturas de temperatura o humedad, de sensores que pertenecen a varios clientes.

  • Un script del lado cliente en una página web recopila acciones de usuario y las envía a una solución de análisis de clics.
Mensajes Información que un servicio receptor necesita para ejecutar pasos en un flujo de trabajo o una cadena de procesamiento
  • Una aplicación financiera de negocio a negocio (B2B) recibe un mensaje para empezar a procesar los registros bancarios de un inquilino.

  • Un cliente de un servicio de correo electrónico de negocio a consumidor (B2C) inicia una solicitud de cumplimiento de registros de datos que se debe procesar gradualmente durante varios días.

Para más información, consulte Elección del servicio de mensajería de Azure adecuado para los datos.

Azure proporciona varios servicios de mensajería que pueden admitir sus requisitos de mensajería. Estos servicios incluyen Azure Event Hubs, Azure Event Grid y Azure Service Bus. Para más información, consulte Elección entre los servicios de mensajería de Azure.

También puede implementar y administrar su propio servicio de mensajería en máquinas virtuales (VM), contenedores o en servicios como Azure Kubernetes Service (AKS). Este enfoque requiere implementar, administrar y mantener la infraestructura de mensajería.

Consideraciones clave y requisitos

El modelo de implementación y arrendamiento que elija para la solución afecta a la seguridad, el rendimiento, el aislamiento de datos, la administración y la capacidad de cobrar los costos de recursos entre los inquilinos. Al realizar este análisis, considere también el modelo que seleccione para la infraestructura de mensajería y eventos. En las secciones siguientes se describen las decisiones clave que debe tomar al planear un sistema de mensajería en la solución multiinquilino.

Escala

Al planear la infraestructura de mensajería o eventos, tenga en cuenta el número de inquilinos, la complejidad de los flujos de mensajes y las secuencias de eventos, el volumen de mensajes, el perfil de tráfico esperado y el nivel de aislamiento.

En primer lugar, planee la capacidad y establezca la capacidad de rendimiento máxima para el sistema de mensajería. Este planeamiento le ayuda a controlar correctamente el volumen esperado de mensajes durante el tráfico normal y máximo.

Cuando la solución controla muchos inquilinos y tiene un sistema de mensajería independiente para cada inquilino, aplique una estrategia de automatización coherente. Esta estrategia debe automatizar la implementación, la supervisión, las alertas y el escalado de cada infraestructura.

Por ejemplo, puede implementar un sistema de mensajería para un inquilino durante el proceso de aprovisionamiento mediante una herramienta de infraestructura como código (IaC), como Terraform, Bicep o plantillas de Azure Resource Manager (plantillas de ARM) y un sistema de DevOps como Azure DevOps o Acciones de GitHub. Para más información, consulte Enfoques basados en la arquitectura para implementar y configurar soluciones multiinquilino.

Puede ajustar el tamaño del sistema de mensajería con un rendimiento máximo en los mensajes por unidad de tiempo. Si el sistema admite el escalado automático dinámico, puede aumentar o disminuir automáticamente su capacidad en función de las condiciones de tráfico y las métricas para cumplir el acuerdo de nivel de servicio (SLA) esperado.

Predictibilidad y confiabilidad del rendimiento

Para solo unos pocos inquilinos, un único sistema de mensajería puede cumplir los requisitos de rendimiento funcionales y reducir el costo total de propiedad (TCO). Una aplicación multiusuario podría compartir las mismas entidades de mensajería, como colas y tópicos, entre varios clientes. Como alternativa, puede usar un conjunto dedicado de componentes para cada inquilino para aumentar el aislamiento de inquilinos. Pero una infraestructura de mensajería compartida entre varios arrendatarios puede exponer toda la solución al problema del vecino ruidoso. La actividad de un inquilino puede interrumpir el rendimiento y la operabilidad de otros inquilinos.

En este caso, debe ajustar correctamente el tamaño del sistema de mensajería para mantener la carga de tráfico esperada en el momento máximo. Lo ideal es que el sistema admita el escalado automático, que se ajuste dinámicamente cuando el tráfico aumenta y reduzca el escalado cuando el tráfico disminuye. Un sistema de mensajería dedicado para cada inquilino también puede mitigar el riesgo de vecino ruidoso, pero administrar muchos sistemas de mensajería aumenta la complejidad de la solución.

Una aplicación multiinquilino puede usar un enfoque híbrido. En este enfoque, los servicios principales usan el mismo conjunto de colas y temas en un único sistema de mensajería compartido para implementar comunicaciones internas y asincrónicas. En cambio, otros servicios pueden adoptar un grupo dedicado de entidades de mensajería o incluso un sistema de mensajería dedicado para cada inquilino para mitigar el problema de vecino ruidoso y garantizar el aislamiento de datos.

Administración y complejidad operativa

Desde el principio, planee cómo piensa operar, supervisar y mantener la infraestructura de mensajería y eventos y cómo afecta el enfoque multiinquilino a sus operaciones y procesos. Por ejemplo, tenga en cuenta los siguientes factores:

  • Al compartir un sistema de mensajería en varios inquilinos, defina cómo recopila la solución e informa de las métricas de uso de cada inquilino o cómo limita el número de mensajes que cada inquilino puede enviar o recibir.

  • Cuando los inquilinos necesitan moverse a otro tipo de servicio de mensajería, una implementación diferente u otra región, determine cómo migrarlos.

  • Cuando el sistema de mensajería usa una oferta de plataforma como servicio (PaaS), tenga en cuenta las consideraciones siguientes:

  • Si decide hospedar el sistema de mensajería que usa la aplicación en un conjunto dedicado de máquinas virtuales o contenedores (uno para cada inquilino), defina cómo implementar, actualizar, supervisar y escalar horizontalmente estos sistemas.

Coste

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. Pero la infraestructura compartida aumenta la probabilidad de problemas como el problema de vecino ruidoso. Tenga en cuenta cuidadosamente las ventajas.

Enfoques y patrones que se deben tener en cuenta

Cuando planee una solución multiinquilino que implique mensajería, tenga en cuenta el nivel de aislamiento entre inquilinos. Revise las siguientes consideraciones y observaciones:

  • Claves de cifrado: Si los inquilinos necesitan su propia clave para cifrar y descifrar mensajes, confirme cómo admite el servicio de mensajería el aislamiento de claves. Por ejemplo, si usa Service Bus, es posible que tenga que crear un espacio de nombres de Service Bus Premium independiente para cada inquilino que necesite sus propias claves. Esta separación le permite usar claves administradas por el cliente (CMK).

  • Continuidad empresarial: Identifique los inquilinos que necesitan un alto nivel de capacidad de recuperación y continuidad empresarial. Tenga en cuenta la redundancia de zona, la redundancia geográfica y las funcionalidades de recuperación ante desastres geográfica para estos inquilinos cuando estén disponibles.

  • Procesamiento de trabajo: Al usar recursos de cola independientes o un sistema de mensajería dedicado para cada inquilino, puede adoptar un grupo independiente de procesos de trabajo para cada inquilino. Este enfoque aumenta el nivel de aislamiento de datos y reduce la complejidad de administrar varias entidades de mensajería.

    Cada instancia del sistema de procesamiento puede adoptar credenciales diferentes, como una cadena de conexión, una entidad de servicio o una identidad administrada, para acceder al sistema de mensajería dedicado. Este enfoque mejora la seguridad y el aislamiento entre los inquilinos, pero aumenta la complejidad de la administración de identidades.

Sistema de mensajería compartido

Puede implementar un sistema de mensajería compartido, como un único espacio de nombres de Service Bus, y compartirlo con todos sus clientes.

Diagrama que muestra un único sistema de mensajería multiinquilino compartido para todos los inquilinos.

Este enfoque proporciona la mayor densidad de inquilinos a la infraestructura y reduce el TCO general. A menudo reduce la sobrecarga de administración porque solo necesita administrar y proteger un único sistema de mensajería o recurso.

Pero al compartir un recurso o una infraestructura completa en varios inquilinos, tenga en cuenta las siguientes limitaciones:

  • Tenga en cuenta las restricciones, las funcionalidades de escalado, las cuotas y los límites del recurso. Por ejemplo, el número máximo de Event Hubs en un solo espacio de nombres o los límites máximos de rendimiento podría convertirse en un obstáculo cuando la arquitectura crece para admitir más clientes.

  • El problema de vecino ruidoso podría convertirse en un factor al compartir un recurso entre varios inquilinos, especialmente si tiene inquilinos ocupados o inquilinos que generan mayor tráfico que otros. Para mitigar estos efectos, considere el patrón de interrupción o el patrón de limitación de tasa. Por ejemplo, puede limitar el número máximo de mensajes que un solo inquilino puede enviar o recibir en un período de tiempo.

  • Es posible que tenga dificultades para supervisar la actividad y medir el consumo de recursos para un inquilino individual. Algunos servicios, como niveles específicos de Service Bus, cobran por las operaciones de mensajería. Al compartir un namespace entre varios clientes, la aplicación debe realizar un seguimiento del número de operaciones de mensajería que genera cada cliente y sus costos de refacturación asociados. Otros servicios no proporcionan el mismo nivel de detalle.

Los inquilinos pueden tener requisitos diferentes para la seguridad, la resistencia dentro de la región, la recuperación ante desastres o la ubicación. Si estos requisitos no coinciden con la configuración del sistema de mensajería, es posible que no se adapten a ellos solo con un único recurso.

Uso del patrón Sharding

El patrón de particionamiento implica implementar varios sistemas de mensajería, también denominados particiones. Cada fragmento contiene una o varias entidades de mensajería de inquilinos, como colas y tópicos. A diferencia de las marcas de implementación, los fragmentos no implican que se duplique toda la infraestructura. Puede particionar los sistemas de mensajería sin duplicar ni particionar también otras infraestructuras de la solución.

Diagrama que muestra un sistema de mensajería particionado.

Cada sistema de mensajería o partición puede tener características diferentes en términos de confiabilidad, SKU y ubicación. Por ejemplo, puede particionar los inquilinos en varios sistemas de mensajería en función de su ubicación o requisitos de rendimiento, confiabilidad, protección de datos o continuidad empresarial.

Al usar el patrón de particionamiento, debe usar una estrategia de particionamiento para asignar un inquilino determinado al sistema de mensajería que contiene sus colas. La estrategia de búsqueda usa un mapa para identificar el sistema de mensajería de destino en función del nombre de inquilino o el identificador. Varios clientes pueden compartir el mismo fragmento, pero las entidades de mensajería que usa un solo cliente permanecen dentro de un fragmento.

Puede implementar el mapa como un diccionario que vincule cada nombre de inquilino al nombre o referencia de su sistema de mensajería de destino. Puede almacenar el mapa en una caché distribuida a la que todas las instancias de una aplicación multiinquilino pueden tener acceso o almacenarla en un almacén persistente, como una tabla en una base de datos relacional o una cuenta de almacenamiento.

El patrón de particionamiento puede escalar para admitir varios inquilinos. En función de la carga de trabajo, puede lograr una alta densidad de inquilinos en particiones, lo que puede reducir el costo. También puede usar el patrón de particionamiento para abordar las cuotas, límites y restricciones de suscripción y servicio de Azure.

Uso de una aplicación multiinquilino con un sistema de mensajería dedicado para cada inquilino

También puede implementar una sola aplicación multiinquilino que use sistemas de mensajería dedicados para cada inquilino. Este modelo de arrendamiento incluye algunos componentes compartidos, como los recursos informáticos. Usted aprovisiona y administra otros servicios mediante un enfoque de implementación dedicado de un solo inquilino. Por ejemplo, puede crear un único nivel de aplicación y, a continuación, implementar sistemas de mensajería individuales para cada inquilino, como se muestra en la ilustración siguiente.

Diagrama que muestra diferentes sistemas de mensajería para cada inquilino.

Si los componentes específicos generan la mayor parte de la carga del sistema y puede implementar estos componentes por separado para cada inquilino, use una implementación con particiones horizontales para reducir problemas ruidosos vecinos. Por ejemplo, use un sistema de mensajería o eventstream independiente para cada inquilino si una sola instancia no puede mantenerse al día con el tráfico que generan varios inquilinos. Cuando se usa un sistema de mensajería dedicado para cada inquilino, un gran volumen de mensajes o eventos de un solo inquilino podría afectar a los componentes compartidos, pero no a los sistemas de mensajería de otros inquilinos.

Dado que aprovisiona recursos dedicados para cada inquilino, este enfoque suele costar más que un modelo de hospedaje compartido. Sin embargo, también proporciona una manera sencilla de cobrar a cada inquilino los recursos que usan. Este enfoque le permite lograr una alta densidad para otros servicios, como los recursos informáticos, y reduce el costo de estos componentes.

Con una implementación con particiones horizontales, necesita un proceso automatizado para implementar y administrar los servicios de una aplicación multiinquilino, especialmente los servicios que usa un solo inquilino.

Colaboradores

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

Autor principal:

Otros colaboradores:

  • Daphne Choong | Arquitecto sénior de soluciones de asociados
  • John Downs | Ingeniero principal de software, Patrones y prácticas de Azure
  • Clemens Vasters | Arquitecto principal, servicios de mensajería y estándares
  • Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Para más información sobre los patrones de diseño de mensajería, consulte los siguientes recursos:

  • Last updated on