Compartir a través de

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

  • Artículo

La mensajería asincrónica y la comunicación controlada por eventos son recursos críticos al crear una aplicación distribuida que se compone de varios servicios internos y externos. Al diseñar una solución multiinquilino, es fundamental realizar un análisis preliminar para definir cómo compartir o particionar los mensajes que pertenecen a distintos inquilinos.

Compartir el mismo sistema de mensajería o servicio de streaming de eventos puede reducir significativamente el costo operativo y la complejidad de la administración. Sin embargo, el uso de un sistema de mensajería dedicado para cada inquilino ofrece un mejor aislamiento de datos, reduce el riesgo de pérdida de datos, elimina el problema del vecino ruidoso y permite cargar fácilmente los costes de Azure a los inquilinos.

En este artículo, puede encontrar una distinción entre mensajes y eventos, y encontrará las directrices que pueden seguir los arquitectos de soluciones al decidir qué enfoque usar para una infraestructura de mensajería o eventos en una solución multiinquilino.

Mensajes, puntos de datos y eventos discretos

Todos los sistemas de mensajería tienen funcionalidades, protocolos de transporte y escenarios de uso similares. Por ejemplo, la mayoría de los sistemas de mensajería modernos admiten comunicaciones asincrónicas que usan colas volátiles o persistentes, los protocolos de transporte AMQP y HTTPS, entrega al menos una vez, etc. Sin embargo, al mirar más de cerca el tipo de información publicada y cómo consumen y procesan los datos las aplicaciones cliente, podemos distinguir entre diferentes tipos de mensajes y eventos. Hay una distinción esencial entre los servicios que entregan un evento y los sistemas que envían un mensaje. Para obtener más información, consulte los siguientes recursos:

Eventos

Un evento es una notificación ligera de una condición o un cambio de estado. Los eventos pueden ser unidades discretas o parte de una serie. Los eventos son mensajes que no suelen transmitir la intención de un publicador que no sea la de informar. Un evento captura un hecho y lo comunica a otros servicios o componentes. Un consumidor del evento puede procesar el evento a su elección y no cumple ninguna expectativa específica que el publicador pueda tener. Podemos clasificar los eventos en dos categorías principales:

  • Los eventos discretos tienen información sobre acciones específicas que ha llevado a cabo la aplicación de publicación. Cuando se usa la comunicación asincrónica controlada por eventos, una aplicación publica un evento de notificación cuando sucede algo dentro de su dominio. Una o varias aplicaciones de consumo deben ser conscientes de este cambio de estado, por ejemplo, un cambio de precio en una aplicación de catálogo de productos. Los consumidores se suscriben a los eventos para recibirlos de forma asincrónica. Cuando se produce un evento determinado, las aplicaciones que lo consumen pueden actualizar sus entidades de dominio, lo que puede hacer que se publiquen más eventos de integración.
  • Los eventos de series llevan puntos de datos informativos, como las lecturas de temperatura de los dispositivos para su análisis o las acciones del usuario en una solución de análisis de clics, como elementos de un flujo continuo y en curso. Un flujo de eventos está relacionado con un contexto específico, como la temperatura o la humedad notificadas por un dispositivo de campo. Todos los eventos relacionados con el mismo contexto tienen un orden temporal estricto que importa al procesar estos eventos con un motor de procesamiento de flujos de eventos. El análisis de los flujos de eventos que transportan puntos de datos requiere acumular estos eventos en un búfer que abarque un período de tiempo deseado. O bien, puede estar en un número seleccionado de elementos y, a continuación, procesar estos eventos mediante una solución casi en tiempo real o un algoritmo entrenado por una máquina. El análisis de una serie de eventos puede producir señales, como el promedio de un valor medido en un período de tiempo que cruza un umbral. A continuación, se pueden generar esas señales como eventos discretos y sobre los que se puede actuar.

Los eventos discretos notifican cambios de estado y se puede actuar sobre ellos. La carga del evento tiene información sobre lo que ha ocurrido, pero, en general, no tiene los datos completos que desencadenaron el evento. Por ejemplo, un evento notifica a los consumidores que una aplicación de informes ha creado un nuevo archivo en una cuenta de almacenamiento. La carga del evento puede tener información general sobre el archivo, pero no tiene el propio archivo. Los eventos discretos funcionan muy bien con soluciones sin servidor que necesitan escalarse.

Los eventos de serie notifican una condición y son analizables. Los eventos discretos están ordenados en el tiempo e interrelacionados. En algunos contextos, el consumidor debe recibir la secuencia completa de eventos para analizar lo que ha ocurrido y tomar la acción necesaria.

Mensajes

Los mensajes contienen datos sin procesar producidos por un servicio que se consumen o almacenan en otro lugar. Los mensajes suelen llevar la información necesaria para que un servicio receptor ejecute los pasos de un flujo de trabajo o una cadena de procesamiento. Un ejemplo de este tipo de comunicación es el patrón de comando. El publicador también puede esperar que los receptores de un mensaje ejecuten una serie de acciones e informen del resultado de su procesamiento con un mensaje asincrónico. Existe un contrato entre el publicador de los mensajes y los receptores de los mensajes. Por ejemplo, el publicador envía un mensaje con algunos datos sin procesar y espera que el consumidor cree un archivo a partir de esos datos y envíe una respuesta cuando finalice el trabajo. En otras situaciones, un proceso remitente podría enviar un mensaje asincrónico unidireccional para pedir a otro servicio que realice una operación determinada, pero sin expectativas de recibir un mensaje de confirmación o respuesta de él.

Este tipo de control de mensajes contractuales es bastante diferente al de un publicador que publica eventos discretos para una audiencia de agentes de consumidor, sin ninguna expectativa específica de cómo controlarán estas notificaciones.

Escenarios de ejemplo

Esta es una lista de algunos escenarios multiinquilino de ejemplo para mensajes, puntos de datos y eventos discretos:

  • Eventos discretos:
    • Una plataforma de uso compartido de música realiza un seguimiento del hecho de que un usuario específico de un inquilino específico haya escuchado una pista de música determinada.
    • En una aplicación web de tienda en línea, la aplicación de catálogo envía un evento mediante el patrón de publicador y suscriptor a otras aplicaciones para notificarles que ha cambiado el precio de un artículo.
    • Una empresa de fabricación inserta información en tiempo real para clientes y terceros sobre el mantenimiento de los equipos, el estado de los sistemas y las actualizaciones de los contratos.
  • Puntos de datos:
    • Un sistema de control de un edificio recibe eventos de telemetría, como las lecturas de temperatura o humedad de sensores que pertenecen a varios clientes.
    • Un sistema de supervisión controlado por eventos recibe y procesa registros de diagnóstico casi en tiempo real de varios servicios, como servidores web.
    • Un script del lado cliente en una página web recopila las acciones del usuario y las envía a una solución de análisis de clics.
  • Mensajes:
    • Una aplicación financiera B2B recibe un mensaje para empezar a procesar los registros bancarios de un inquilino.
    • Un flujo de trabajo de larga duración recibe un mensaje que desencadena la ejecución del paso siguiente.
    • La aplicación de cesta de la compra de una aplicación de tienda en línea envía un comando para crear un pedido, mediante un mensaje asincrónico y persistente, a la aplicación de pedidos.

Consideraciones clave y requisitos

El modelo de implementación e inquilinato que elija para la solución tiene un impacto profundo en la seguridad, el rendimiento, el aislamiento de datos, la administración y la capacidad de cargar los costos de los recursos a los inquilinos. Este análisis incluye el modelo que seleccione para la infraestructura de mensajería y eventos. En esta sección, se revisan algunas de las decisiones clave que debe tomar al planear un sistema de mensajería en la solución multiinquilino.

Escala

El número de inquilinos, la complejidad de los flujos de mensajes y los flujos de eventos, el volumen de mensajes, el perfil de tráfico esperado y el nivel de aislamiento deben impulsar las decisiones al planear una infraestructura de mensajería o eventos.

El primer paso consiste en llevar a cabo un planeamiento exhaustivo de la capacidad y establecer la capacidad máxima necesaria para un sistema de mensajería en términos de rendimiento para controlar correctamente el volumen esperado de mensajes bajo tráfico normal o máximo.

Algunas ofertas de servicio, como el nivel Premium de Azure Service Bus, proporcionan aislamiento de recursos en el nivel de CPU y de memoria para que cada carga de trabajo de cliente se ejecute de forma aislada. Este contenedor de recursos se llama unidad de mensajería. A cada espacio de nombres premium se le asigna al menos una unidad de mensajería. Puede comprar 1, 2, 4, 8 o 16 unidades de mensajería para cada espacio de nombres Premium de Service Bus. Una sola carga de trabajo o entidad puede abarcar varias unidades de mensajería y puede cambiar el número de unidades de mensajería según sea necesario. El resultado es un rendimiento predecible y repetible para su solución basada en Service Bus. Para más información, consulte Niveles de mensajería Premium y Estándar de Service Bus. Del mismo modo, los planes de tarifa de Azure Event Hubs permiten determinar el tamaño del espacio de nombres, en función del volumen esperado de eventos entrantes y salientes. Por ejemplo, la oferta Premium se factura por unidades de procesamiento (PU), que corresponden a un recurso compartido de recursos aislados (CPU, memoria y almacenamiento) de la infraestructura subyacente. La ingesta efectiva y el rendimiento del flujo por PU dependerán de los siguientes factores:

  • Número de productores y consumidores
  • Tamaño de carga
  • Recuento de particiones
  • Velocidad de solicitudes de salida
  • Uso de Event Hubs Capture, registro de esquema y otras características avanzadas

Para más información, consulte Introducción a Event Hubs Premium.

Cuando la solución controla un número considerable de inquilinos y decide adoptar un sistema de mensajería independiente para cada inquilino, debe tener una estrategia coherente para automatizar la implementación, la supervisión, las alertas y el escalado de cada infraestructura, por separado entre sí.

Por ejemplo, un sistema de mensajería para un inquilino determinado se podría implementar durante el proceso de aprovisionamiento mediante una herramienta de infraestructura como código (IaC), como las plantillas JSON de Terraform, Bicep o Azure Resource Manager (ARM) y un sistema 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.

El sistema de mensajería se podría dimensionar con un rendimiento máximo en mensajes por unidad de tiempo. Si el sistema admite el escalado automático dinámico, su capacidad se podría aumentar o reducir automáticamente, en función de las condiciones del tráfico y las métricas para cumplir el contrato de nivel de servicio esperado.

Predictibilidad y confiabilidad del rendimiento

Al diseñar y crear un sistema de mensajería para un número limitado de inquilinos, el uso de un único sistema de mensajería podría ser una solución excelente para cumplir los requisitos funcionales en términos de rendimiento y podría reducir el costo total de propiedad. Una aplicación multiinquilino podría compartir las mismas entidades de mensajería, como las colas y los temas, entre varios clientes. O bien, pueden usar un conjunto dedicado de componentes para cada uno, con el fin de aumentar el aislamiento de los inquilinos. Por otro lado, compartir la misma infraestructura de mensajería entre varios inquilinos podría exponer toda la solución al problema del vecino ruidoso. La actividad de un inquilino podría dañar a otros inquilinos, en términos de rendimiento y operabilidad.

En este caso, el sistema de mensajería debe tener el tamaño adecuado para mantener la carga de tráfico esperada en las horas punta. Lo ideal es que admita el escalado automático. El sistema de mensajería se debe escalar horizontalmente de forma dinámica cuando el tráfico aumente y reducir horizontalmente cuando el tráfico disminuya. Un sistema de mensajería dedicado para cada inquilino también podría mitigar el riesgo de vecino ruidoso, pero administrar un gran número de sistemas de mensajería podría aumentar la complejidad de la solución.

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

Al implementar un sistema de mensajería en máquinas virtuales, debe colocar estas máquinas virtuales con los recursos de proceso para reducir la latencia de red. Estas máquinas virtuales no se deben compartir con otros servicios o aplicaciones para evitar que la infraestructura de mensajería compita por los recursos del sistema, como la CPU, la memoria y el ancho de banda de red, con otros sistemas. Las máquinas virtuales también se pueden distribuir entre las zonas de disponibilidad para aumentar la resistencia dentro de la región y la confiabilidad de las cargas de trabajo críticas para la empresa, incluidos los sistemas de mensajería. Supongamos que decide hospedar un sistema de mensajería, como RabbitMQ o Apache ActiveMQ, en máquinas virtuales. En ese caso, se recomienda implementarlo en un conjunto de escalado de máquinas virtuales y configurarlo para el escalado automático, en función de métricas como la CPU o la memoria. De este modo, el número de nodos de agente que hospedan el sistema de mensajería se escalará horizontalmente y se reducirá horizontalmente de forma correcta en función de las condiciones de tráfico. Para más información, consulte Introducción a la escalabilidad automática con conjuntos de escalado de máquinas virtuales de Azure.

Del mismo modo, al hospedar el sistema de mensajería en un clúster de Kubernetes, considere la posibilidad de usar selectores de nodo e intolerancias para programar la ejecución de sus pods en un grupo de nodos dedicado, no compartido con otras cargas de trabajo, con el fin de evitar el problema del vecino ruidoso. Al implementar un sistema de mensajería en un clúster de AKS con redundancia de zona, use restricciones de distribución de topología de pods para controlar cómo se distribuyen los pods del clúster de AKS entre dominios de error, como regiones, zonas de disponibilidad y nodos. Al hospedar un sistema de mensajería de terceros en AKS, use el escalado automático de Kubernetes para escalar horizontalmente de forma dinámica el número de nodos de trabajo cuando aumente el tráfico. Con el escalador horizontal automático de pods y el escalador automático del clúster de AKS, los volúmenes de nodos y pods se ajustan dinámicamente en tiempo real para que coincidan con la condición del tráfico y para evitar tiempos de inactividad causados por problemas de capacidad. Para más información, consulte Escalar automáticamente un clúster para satisfacer las necesidades de la aplicación en Azure Kubernetes Service (AKS). Considere la posibilidad de usar el escalado automático controlado por eventos de Kubernetes (KEDA) si desea escalar horizontalmente el número de pods de un sistema de mensajería hospedado en Kubernetes, como RabbitMQ o Apache ActiveMQ, en función de la longitud de una cola determinada. Con KEDA, puede controlar el escalado de cualquier contenedor de Kubernetes en función del número de eventos que se deben procesar. Por ejemplo, puede usar KEDA para escalar aplicaciones en función de la longitud de una cola de Azure Service Bus, una cola de RabbitMQ o una cola de ActiveMQ. Para más información sobre KEDA, consulte Escalado automático controlado por eventos de Kubernetes.

Aislamiento

Al diseñar el sistema de mensajería para una solución multiinquilino, debe tener en cuenta que los distintos tipos de aplicaciones requieren un tipo diferente de aislamiento, que se basa en los requisitos de rendimiento, privacidad y auditoría de los inquilinos.

  • Varios inquilinos pueden compartir las mismas entidades de mensajería, como colas, temas y suscripciones, en el mismo sistema de mensajería. Por ejemplo, una aplicación multiinquilino podría recibir mensajes que transportan datos para varios inquilinos desde una única cola de Azure Service Bus. Esta solución puede dar lugar a problemas de rendimiento y escalabilidad. Si algunos de los inquilinos generan un volumen mayor de pedidos que otros, esto podría provocar un trabajo pendiente de mensajes. Este problema, también conocido como problema del vecino ruidoso, puede degradar el contrato de nivel de servicio en términos de latencia para algunos inquilinos. El problema es más evidente si la aplicación de consumidor lee y procesa mensajes de la cola, de uno en uno, en un orden cronológico estricto, y si el tiempo necesario para procesar un mensaje depende del número de elementos de la carga. Al compartir uno o varios recursos de cola entre varios inquilinos, la infraestructura de mensajería y los sistemas de procesamiento deben ser capaces de dar cabida al tráfico esperado en función de los requisitos de escalado y rendimiento. Este enfoque arquitectónico es adecuado en aquellos escenarios en los que una solución multiinquilino adopta un único grupo de procesos de trabajo con el fin de recibir, procesar y enviar mensajes para todos los inquilinos.
  • Varios inquilinos comparten el mismo sistema de mensajería, pero usan diferentes recursos de tema o cola. Este enfoque proporciona un mejor aislamiento y protección de datos a un costo mayor, una mayor complejidad operativa y una menor agilidad, ya que los administradores del sistema tienen que aprovisionar, supervisar y mantener un mayor número de recursos de cola. Esta solución garantiza una experiencia coherente y predecible para todos los inquilinos, en términos de rendimiento y contratos de nivel de servicio, ya que impide que cualquier inquilino cree un cuello de botella que pueda afectar a los demás inquilinos.
  • Se usa un sistema de mensajería independiente y dedicado para cada inquilino. Por ejemplo, una solución multiinquilino puede usar un espacio de nombres de Azure Service Bus distinto para cada inquilino. Esta solución proporciona el grado máximo de aislamiento, con una mayor complejidad y costo operativo. Este enfoque garantiza un rendimiento coherente y permite ajustar el sistema de mensajería en función de las necesidades específicas del inquilino. Cuando se incorpora un nuevo inquilino, además de un sistema de mensajería totalmente dedicado, es posible que la aplicación de aprovisionamiento también tenga que crear una identidad administrada independiente o una entidad de servicio con los permisos de RBAC adecuados para acceder al espacio de nombres recién creado. Por ejemplo, cuando se comparte un clúster de Kubernetes entre varias instancias de la misma aplicación SaaS, una para cada inquilino y cada una de ellas se ejecuta en un espacio de nombres independiente, cada instancia de aplicación puede usar una entidad de servicio o una identidad administrada diferentes para acceder a un sistema de mensajería dedicado. En este contexto, el sistema de mensajería podría ser un servicio PaaS totalmente administrado, como un espacio de nombres de Azure Service Bus o un sistema de mensajería hospedado en Kubernetes, como RabbitMQ. Al eliminar un inquilino del sistema, la aplicación debe quitar el sistema de mensajería y cualquier recurso dedicado que se haya creado previamente para el inquilino. La principal desventaja de este enfoque es que aumenta la complejidad operativa y reduce la agilidad, especialmente cuando el número de inquilinos crece con el tiempo.

Revise las siguientes consideraciones y observaciones adicionales:

  • Si los inquilinos tienen que usar su propia clave para cifrar y descifrar los mensajes, una solución multiinquilino debe proporcionar la opción de adoptar un espacio de nombres Premium independiente de Azure Service Bus para cada inquilino. Para más información, consulte Configuración de las claves administradas por el cliente para el cifrado de datos en reposo de Azure Service Bus.
  • Si los inquilinos necesitan un alto nivel de resistencia y continuidad empresarial, una solución multiinquilino debe proporcionar la capacidad de aprovisionar un espacio de nombres Premium de Service Bus con la recuperación ante desastres geográfica y las zonas de disponibilidad habilitadas. Para obtener más información, consulte Recuperación ante desastres con localización geográfica de Azure Service Bus.
  • Cuando se usan recursos de cola independientes o un sistema de mensajería dedicado para cada inquilino, es razonable adoptar un grupo independiente de procesos de trabajo para cada uno de ellos para aumentar el nivel de aislamiento de los datos y reducir la complejidad de tratar con varias entidades de mensajería. Cada instancia del sistema de procesamiento podría adoptar credenciales diferentes, como una cadena de conexión, una entidad de servicio o una identidad administrada, con el fin de acceder al sistema de mensajería dedicado. Este enfoque proporciona un mejor nivel de seguridad y aislamiento entre inquilinos, pero requiere una mayor complejidad en la administración de identidades.

Del mismo modo, una aplicación controlada por eventos puede proporcionar diferentes niveles de aislamiento:

  • Una aplicación controlada por eventos recibe eventos de varios inquilinos mediante una única instancia compartida de Azure Event Hubs. Esta solución proporciona un alto nivel de agilidad, ya que la incorporación de un nuevo inquilino no requiere la creación de un recurso de ingesta de eventos dedicado, pero proporciona un nivel de protección de datos bajo, ya que intercala mensajes de varios inquilinos en la misma estructura de datos.
  • Los inquilinos pueden optar por un centro de eventos o un tema de Kafka dedicado para evitar el problema del vecino ruidoso y cumplir sus requisitos de aislamiento de datos cuando los eventos no se deben intercalar con los de otros inquilinos para la seguridad y la protección de los datos.
  • Si los inquilinos necesitan un alto nivel de resistencia y continuidad empresarial, una solución multiinquilino debe proporcionar la capacidad de aprovisionar un espacio de nombres Premium de Event Hubs con la recuperación ante desastres geográfica y las zonas de disponibilidad habilitadas. Para más información, consulte Azure Event Hubs: recuperación ante desastres geográfica.
  • Se deben crear centros de eventos dedicados, con la captura de Event Hubs habilitada, para aquellos clientes que necesiten archivar eventos en una cuenta de Azure Storage por motivos y obligaciones de cumplimiento normativo. Para más información, consulte Captura de eventos a través de Azure Event Hubs en Azure Blob Storage o Azure Data Lake Storage.
  • Una sola aplicación multiinquilino puede enviar notificaciones a varios sistemas internos y externos mediante Azure Event Grid. En este caso, se debe crear una suscripción de Event Grid independiente para cada aplicación de consumidor. Si la aplicación usa varias instancias de Event Grid para enviar notificaciones a un gran número de organizaciones externas, considere la posibilidad de usar dominios de eventos, que permiten a una aplicación publicar eventos en miles de temas, por ejemplo, uno para cada inquilino. Para más información, consulte Dominios de eventos para administrar temas de Event Grid.

Complejidad de la implementación

Al diseñar una solución multiinquilino, es esencial tener en cuenta cómo evolucionará el sistema a medio y largo plazo, con el fin de evitar que su complejidad crezca con el tiempo hasta que sea necesario rediseñar toda la solución o parte de ella. Este rediseño le ayudará a hacer frente a un número creciente de inquilinos. Al diseñar un sistema de mensajería, debe tener en cuenta el crecimiento esperado en los volúmenes de mensajes e inquilinos en los próximos años y, a continuación, crear un sistema que se pueda escalar horizontalmente para mantenerse al día con el tráfico previsto y reducir la complejidad de las operaciones, como el aprovisionamiento, la supervisión y el mantenimiento.

La solución debe crear o eliminar automáticamente las entidades de mensajería necesarias cada vez que se aprovisione o desaprovisione una aplicación de inquilino, sin necesidad de operaciones manuales.

Una inquietud particular relacionada con las soluciones de datos de varios inquilinos es el nivel de personalización que se admite. El sistema de aprovisionamiento de aplicaciones (por ejemplo, un sistema DevOps) debe configurar y aplicar automáticamente cualquier personalización, en función de un conjunto de parámetros iniciales, siempre que se implemente una aplicación multiinquilino o de un solo inquilino.

Complejidad de la administración y las operaciones

Planee desde el principio 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 las siguientes posibilidades:

  • Es posible que planee hospedar el sistema de mensajería que usa la aplicación en un conjunto dedicado de máquinas virtuales, uno para cada inquilino. Si es así, ¿cómo planea implementar, actualizar, supervisar y escalar horizontalmente estos sistemas?
  • Del mismo modo, si incluye en contenedores y hospeda el sistema de mensajería en un clúster compartido de Kubernetes, ¿cómo planea implementar, actualizar, supervisar y escalar horizontalmente los sistemas de mensajería individuales?
  • Supongamos que comparte un sistema de mensajería entre varios inquilinos. ¿Cómo puede la solución recopilar e informar de las métricas de uso por inquilino o limitar el número de mensajes que cada inquilino puede enviar o recibir?
  • Cuando el sistema de mensajería utiliza un servicio PaaS, como Azure Service Bus, debe formular las siguientes preguntas:
    • ¿Cómo puede personalizar el plan de tarifa para cada inquilino en función de las características y el nivel de aislamiento (compartido o dedicado) solicitados por el inquilino?
    • ¿Cómo puede crear una identidad administrada y una asignación de roles de Azure por cada inquilino para asignar los permisos adecuados solo a las entidades de mensajería, por ejemplo, colas, temas y suscripciones, a las que el inquilino puede acceder? Para más información, consulte Autenticación de una identidad administrada con Microsoft Entra ID para acceder a recursos de Azure Service Bus.
  • ¿Cómo va a migrar los inquilinos si tienen que moverse a un tipo de servicio de mensajería diferente, a una implementación diferente o a otra región?

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. Sin embargo, la infraestructura compartida aumenta la probabilidad de errores, como el problema del vecino ruidoso, así que analice atentamente las ventajas y desventajas.

Enfoques y patrones que se deben tener en cuenta

Se pueden aplicar varios patrones de diseño en la nube del Centro de arquitectura de Azure a un sistema de mensajería multiinquilino. Puede optar por seguir uno o varios patrones de forma coherente, o bien puede considerar la posibilidad de combinar patrones en función de sus necesidades. Por ejemplo, podría usar un espacio de nombres multiinquilino de Service Bus para la mayoría de los inquilinos, pero después podría implementar un espacio de nombres de Service Bus dedicado de un solo inquilino para aquellos inquilinos que paguen más o que tengan requisitos más altos en términos de aislamiento y rendimiento. De manera similar, suele ser un procedimiento recomendado escalar mediante stamps de implementación, incluso cuando se usa un espacio de nombres multiinquilino de Service Bus o espacios de nombres dedicados dentro de un stamp.

Patrón de stamps de implementación

Para más información sobre el patrón de stamps de implementación y el multiinquilinato, consulte la sección Patrón de stamps de implementación del artículo Enfoques arquitectónicos para la arquitectura multiinquilino. Para más información sobre los modelos de inquilinato, consulte Modelos de inquilinato que se deben tener en cuenta para una solución multiinquilino.

Sistema de mensajería compartido

Es posible que considere la posibilidad de implementar un sistema de mensajería compartido, como Azure Service Bus, y compartirlo entre todos los inquilinos.

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

Este enfoque proporciona la mayor densidad de inquilinos a la infraestructura, por lo que reduce el costo total de propiedad general. También suele reducir la sobrecarga de administración, ya que hay un único sistema o recurso de mensajería que administrar y proteger.

Sin embargo, cuando comparta un recurso o una infraestructura completa entre varios inquilinos, tenga en cuenta las advertencias siguientes:

  • Tenga siempre en cuenta las restricciones, las funcionalidades de escalado, las cuotas y los límites del recurso en cuestión. Por ejemplo, el número máximo de espacios de nombres de Service Bus en una suscripción de Azure, el número máximo de centros de eventos en un único espacio de nombres o los límites de rendimiento máximo, podrían convertirse finalmente en un bloqueador si la arquitectura crece para admitir más inquilinos. Tenga en cuenta detenidamente la escala máxima que debe lograr en cuanto al número de espacios de nombres por una única suscripción de Azure o las colas por cada único espacio de nombres. A continuación, compare las estimaciones actuales y futuras con las cuotas y límites existentes del sistema de mensajería de su elección antes de seleccionar este patrón.
  • Como se ha mencionado en las secciones anteriores, el problema del vecino ruidoso puede convertirse en un factor al compartir un recurso entre varios inquilinos, especialmente si algunos están especialmente ocupados o si generan un tráfico mayor que otros. En este caso, considere la posibilidad de aplicar el patrón de limitación o el patrón de limitación de velocidad para mitigar estos efectos. Por ejemplo, podría limitar el número máximo de mensajes que un solo inquilino puede enviar o recibir en una unidad de tiempo.
  • Es posible que tenga dificultades para supervisar la actividad y medir el consumo de recursos de un solo inquilino. Algunos servicios, como Azure Service Bus, cobran por las operaciones de mensajería. Por lo tanto, al compartir un espacio de nombres entre varios inquilinos, la aplicación debe poder realizar un seguimiento del número de operaciones de mensajería realizadas en nombre de cada inquilino y los costos de contracargo para ellos. Otros servicios no proporcionan el mismo nivel de detalle.

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

Patrón de particionamiento

El patrón de particionamiento implica la implementación de varios sistemas de mensajería, llamados particiones, que contienen una o varias entidades de mensajería de los inquilinos, como colas y temas. A diferencia de los stamps de implementación, las particiones no implican que toda la infraestructura esté duplicada. 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 compartido. Un sistema de mensajería contiene las colas de los inquilinos A y B, y la otra contiene las colas del inquilino C.

Cada sistema de mensajería o partición puede tener características diferentes en términos de confiabilidad, SKU y ubicación. Por ejemplo, podría particionar los inquilinos en varios sistemas de mensajería con características diferentes, en función de su ubicación o necesidades en términos 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 individualizar el sistema de mensajería de destino en función del nombre o identificador del inquilino. Varios inquilinos pueden compartir la misma partición, pero las entidades de mensajería utilizadas por un único inquilino no se distribuirán entre varias particiones. El mapa se puede implementar con un único diccionario que asigne el nombre del inquilino al nombre o la referencia del sistema de mensajería de destino. El mapa se puede almacenar en una caché distribuida accesible por todas las instancias de una aplicación multiinquilino o en un almacén persistente, como una tabla de una base de datos relacional o una tabla de una cuenta de almacenamiento.

El patrón de particionamiento se puede escalar a un gran número de inquilinos. Además, según la carga de trabajo, es posible que pueda lograr una alta densidad de inquilinos por particiones, por lo que el costo puede ser atractivo. El patrón de particionamiento también se puede usar para abordar las cuotas de servicio, los límites y las restricciones de la suscripción de Azure.

Aplicación multiinquilino con sistema de mensajería dedicado para cada inquilino

Otro enfoque común es implementar una única aplicación multiinquilino con sistemas de mensajería dedicados para cada inquilino. En este modelo de inquilinato, tiene algunos componentes compartidos, como los recursos de proceso, mientras que otros servicios se aprovisionan y administran mediante un enfoque de implementación dedicado de un solo inquilino. Por ejemplo, podría crear una única capa de aplicación y, a continuación, implementar sistemas de mensajería individuales para cada inquilino, como se muestra en la siguiente ilustración.

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

Las implementaciones con particiones horizontales pueden ayudarle a mitigar los problemas del vecino ruidoso, si ha identificado que la mayor parte de la carga del sistema se debe a componentes específicos que puede implementar por separado para cada inquilino. Por ejemplo, puede que tenga que usar un sistema de streaming de eventos o de mensajería independiente para cada inquilino porque una sola instancia no es suficiente para tratar el tráfico generado por varios inquilinos. Cuando se usa un sistema de mensajería dedicado para cada inquilino, si un solo inquilino provoca un gran volumen de mensajes o eventos, esto puede afectar a los componentes compartidos, pero no a los sistemas de mensajería de otros inquilinos.

Dado que los recursos dedicados se aprovisionan para cada inquilino, el costo de este enfoque puede ser mayor que el de un modelo de hospedaje compartido. Por otro lado, al adoptar este modelo de inquilinato, es más fácil cobrar los costos de los recursos de un sistema dedicado al único inquilino que hace uso de ellos. Este enfoque permite lograr una alta densidad para otros servicios, como los recursos de proceso, y reduce los costos de estos componentes.

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

Patrón de nodo geográfico

El patrón de nodo geográfico implica la implementación de una colección de servicios de back-end en un conjunto de nodos geográficos. Cada uno puede atender cualquier solicitud de cualquier cliente de cualquier región. Este patrón permite atender las solicitudes con un estilo activo-activo, lo que mejora la latencia y aumenta la disponibilidad al distribuir el procesamiento de las solicitudes en todo el mundo.

Diagrama que muestra el patrón de nodo geográfico, con sistemas de mensajería implementados en varias regiones que se sincronizan juntas.

Azure Service Bus y Azure Event Hubs admiten la recuperación ante desastres de los metadatos, en espacios de nombres de recuperación ante desastres principales y secundarios, y en regiones y zonas de disponibilidad independientes, con el fin de proporcionar la mejor resistencia dentro de la región. Además, Azure Service Bus y Azure Event Hubs implementan un conjunto de patrones de federación que replican activamente el mismo tema, cola o centro de eventos lógicos para que estén disponibles en varios espacios de nombres, ubicados finalmente en regiones diferentes. Para obtener más información, consulte los siguientes recursos:

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Pasos siguientes

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