Enfoques arquitectónicos para soluciones multiinquilino basadas en IoT Hub

Las soluciones basadas en IoT Hub multiinquilino vienen en muchos tipos y tamaños diferentes. Es posible que tenga muchos requisitos y restricciones, que van desde la propiedad de la infraestructura, el aislamiento de los datos del cliente y hasta el cumplimiento. Puede ser complicado definir un patrón que cumpla todas estas restricciones de diseño y, a menudo, es necesario tener en cuenta varias dimensiones. En este artículo se describen varios enfoques que se usan habitualmente para resolver consideraciones multiinquilino para soluciones basadas en IoT Hub. En este documento se incluyen ejemplos de arquitecturas multitenant que utilizan componentes comunes, según la arquitectura de referencia de IoT de .

Consideraciones clave y requisitos

Estas consideraciones y requisitos se presentan en el orden en que normalmente se les da prioridad para el diseño de una solución.

Gobernanza y cumplimiento

Las consideraciones de gobernanza y cumplimiento pueden requerir que use un patrón o conjunto de recursos de IoT determinados. No todos los servicios de IoT tienen las mismas certificaciones o funcionalidades. Si necesita cumplir estándares de cumplimiento específicos, es posible que tenga que seleccionar servicios específicos. Para obtener más información, consulte Enfoques arquitectónicos para la gobernanza y el cumplimiento en soluciones multiinquilino.

La gobernanza en IoT también puede adoptar otras formas, como la propiedad y la administración de dispositivos. ¿Es el cliente el propietario del dispositivo o lo es el proveedor de soluciones? ¿Quién posee la administración de esos dispositivos? Estas observaciones e implicaciones son únicas para cada proveedor de soluciones y pueden dar lugar a distintas opciones en la tecnología, el patrón de implementación y el patrón multiinquilino que use.

Escala

Es importante planear la escala de la solución. A menudo, la escala se tiene en cuenta en estas tres dimensiones:

• Cantidad de dispositivos: todos los servicios de administración de dispositivos de Azure (Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) y Azure IoT Hub) tienen limitaciones en el número de dispositivos admitidos en una sola instancia.

  Sugerencia

  Consulte la documentación a gran escala si planea implementar un gran número de dispositivos.

• Rendimiento del dispositivo: los distintos dispositivos, incluso en la misma solución, pueden tener requisitos de rendimiento diferentes. "Rendimiento" en este contexto hace referencia tanto al número de mensajes durante un período de tiempo como al tamaño de los mensajes. Por ejemplo, en un:

  • Solución de edificio inteligente, termostatos normalmente notifican datos con una frecuencia menor que los ascensores.
  • En una solución de vehículo conectado, los mensajes de datos de grabación de cámara de vehículo suelen ser mayores que los mensajes de telemetría de navegación.

  Si sus mensajes son estrangulados con respecto a la frecuencia, considere escalar a más instancias de un servicio. Si los mensajes están limitados con respecto al tamaño, considere la posibilidad de escalar verticalmente a instancias más grandes de un servicio.

• Inquilinos: la escala de un solo inquilino puede ser pequeña, pero cuando se multiplica por el número de inquilinos, puede crecer rápidamente.

Rendimiento y confiabilidad

Aislamiento de inquilinos

Las soluciones totalmente compartidas pueden tener vecinos ruidosos. En los casos de IoT Hub e IoT Central, los vecinos ruidosos pueden dar lugar a códigos de respuesta HTTP 429 ("Demasiadas solicitudes"), que son errores difíciles que pueden provocar un efecto en cascada. Para obtener más información, consulte Cuotas y límites.

En soluciones que son totalmente multiinquilino, estos efectos pueden darse en cascada. Cuando los clientes comparten aplicaciones de IoT Hub o IoT Central, todos los clientes de la infraestructura compartida reciben errores. Dado que IoT Hub e IoT Central normalmente son los puntos de entrada de los datos a la nube, es probable que también se puedan producir errores en otros sistemas de bajada que dependen de estos datos. A menudo, el motivo más común de estos errores es cuando se supera un límite de cuota de mensajes. En esta situación, la solución más rápida y sencilla para las soluciones de IoT Hub es actualizar la SKU de IoT Hub, aumentar el número de unidades de IoT Hub o realizar ambas opciones. En el caso de las soluciones de IoT Central, la solución se escala automáticamente según sea necesario, hasta el número documentado de mensajes admitidos.

Puede aislar y distribuir inquilinos en los planos de comunicaciones, administración y control de IoT mediante las directivas de asignación personalizadas de DPS. Además, cuando sigue las instrucciones de las soluciones de IoT de gran escala, puede administrar la distribución de asignación adicional en el nivel de equilibrador de carga de DPS.

Almacenamiento, consulta, uso y retención de datos

Las soluciones de IoT tienden a consumir muchos datos, tanto cuando se transmiten como en reposo. Para obtener más información sobre la administración de datos en soluciones multiinquilino, consulte Enfoques de arquitectura para el almacenamiento y los datos en soluciones multiinquilino.

Seguridad

Las soluciones de IoT suelen tener consideraciones de seguridad en varias capas, especialmente en las soluciones que se implementan en una arquitectura de referencia empresarial de Purdue modificada en la nube o soluciones de la Industria 4.0. El enfoque de diseño que seleccione afecta a qué capas de red y límites existen; después de seleccionar el diseño físico, puede seleccionar la implementación de seguridad. Puede usar las siguientes herramientas en cualquier enfoque:

• Microsoft Defender para IoT, una solución completa de supervisión de IoT que debe tener en cuenta que ofrece una licencia de EIoT por dispositivo y licencias de sitio de OT para cada dispositivo de cliente o sitio. Según el enfoque seleccionado más adelante en este artículo, es posible que el escenario de licencias de usuario con nombre de Microsoft 365 no sea posible. En ese caso, las opciones de licencia por dispositivo y sitio están disponibles, que son opciones de licencia independientes de las licencias de inquilino de Microsoft 365.

• Azure Firewall o un dispositivo de firewall que no sea de Microsoft, que se debe considerar para aislar las capas de red y supervisar el tráfico de red. La elección exacta del enfoque determina dónde las cargas de trabajo tienen aislamiento de red frente a una red compartida, como se aborda más adelante en este artículo.

• Azure IoT Edge.

La mayoría de estos temas de seguridad se aplican en una solución multiinquilino de forma similar a como lo harían en una solución de inquilino único, con las variaciones ligadas al enfoque seleccionado. Un componente que probablemente sea sustancialmente diferente en una solución de IoT general es la identidad de usuario y aplicación. Los enfoques arquitectónicos para la identidad en soluciones multiinquilino describen este aspecto de una solución multiinquilino general.

Enfoques a tener en cuenta

Las consideraciones y opciones para los componentes principales, como la administración, la ingesta, el procesamiento, el almacenamiento y la seguridad, son las mismas para las soluciones de IoT únicas y multiinquilino. La principal diferencia es cómo organizar y usar los componentes para admitir el multiinquilino. Por ejemplo, puntos de decisión comunes para:

• Es posible que storage elija usar SQL Server o Azure Data Explorer.
• El nivel de ingesta y administración consiste en elegir entre IoT Hub e IoT Central.

La mayoría de las soluciones de IoT se ajustan a un patrón de arquitectura raíz, que es una combinación del destino de implementación, el modelo de inquilino y el patrón de implementación. Los requisitos y consideraciones clave descritos anteriormente determinan estos factores.

Uno de los puntos más importantes a tener en cuenta al tomar una decisión en el espacio de IoT, es seleccionar entre una Aplicación de plataforma como servicio (aPaaS) y Plataforma como servicio (PaaS). Para obtener más información, consulte Comparación de enfoques de soluciones de Internet de las cosas (IoT) (PaaS frente a aPaaS).

Este es el dilema común de "compilación frente a compra" al que se enfrentan muchas organizaciones en muchos proyectos. Es importante evaluar las ventajas y desventajas de ambas opciones.

Conceptos y consideraciones para soluciones de aPaaS

Una solución aPaaS típica que usa Azure IoT Central como núcleo de la solución, podría usar los siguientes servicios PaaS y aPaaS de Azure:

• Azure Event Hubs como un motor de flujo de datos y mensajería multiplataforma de nivel empresarial.
• Azure Logic Apps como una oferta de plataforma como servicio de integración o iPaaS.
• Azure Data Explorer como una plataforma de análisis de datos.
• Power BI como plataforma de visualización e informes.

En el diagrama anterior, los inquilinos comparten un entorno de IoT Central, Azure Data Explorer, Power BI y Azure Logic Apps.

Este enfoque suele ser la manera más rápida de obtener una solución para el mercado. Se trata de un servicio a gran escala que admite multiinquilinos mediante organizaciones.

Es importante comprender que, dado que IoT Central es una oferta de aPaaS, hay ciertas decisiones que están fuera del control del implementador. Estas decisiones incluyen:

• IoT Central usa Microsoft Entra ID como proveedor de identidades.
• Las implementaciones de IoT Central se logran mediante operaciones de plano de datos y de control, que combinan documentos declarativos con código imperativo.
• El límite máximo de nodos y la profundidad máxima del árbol en un patrón multitenant basado en IoT Central, podría obligar a un proveedor de servicios a tener múltiples instancias de IoT Central. En ese caso, debe considerar la posibilidad de seguir el patrón de implementación de Stamp.
• IoT Central impone límites de llamadas API, lo que podría afectar a implementaciones de gran tamaño.

Conceptos y consideraciones para soluciones de aPaaS

Un enfoque basado en PaaS podría usar los siguientes servicios de Azure:

• Azure IoT Hub como plataforma principal de comunicaciones y configuración de dispositivos.
• Azure IoT Device Provisioning Service como la plataforma de implementación y configuración inicial del dispositivo.
• Azure Data Explorer para almacenar y analizar datos de series temporales de ruta de acceso activa e inactiva desde dispositivos IoT.
• Azure Stream Analytics para analizar los datos de ruta de acceso frecuente de los dispositivos IoT.
• Azure IoT Edge para ejecutar inteligencia artificial (IA), servicios que no son de Microsoft, o su propia lógica empresarial en dispositivos IoT Edge.

En el diagrama anterior, cada inquilino se conecta a una aplicación web compartida, que recibe datos de instancias de IoT Hub y de una aplicación de funciones. Los dispositivos se conectan al servicio de aprovisionamiento de dispositivos y a IoT Hub.

Este enfoque requiere que el desarrollador dedique un esfuerzo extra para crear, implementar y mantener la solución (frente a un enfoque de aPaaS). Hay menos funcionalidades creadas previamente para mayor comodidad del implementador. Por lo tanto, este enfoque también ofrece más control, ya que se insertan menos suposiciones en la plataforma subyacente.

Patrones de arquitectura raíz

En la tabla siguiente se enumeran los patrones comunes para las soluciones de IoT multiinquilino. Cada patrón incluye la siguiente información:

• Nombre del patrón, que se basa en la combinación del destino, el modelo y el tipo de implementación.
• El destino de implementación, que representa la suscripción de Azure en la que se implementarán los recursos.
• El modelo de inquilino al que hace referencia el patrón, como se describe en Modelos multiinquilino.
• El patrón de implementación, que hace referencia a una implementación simple con consideraciones de implementación mínimas, un patrón de nodo geográfico o un patrón de marca de implementación.

SaaS simple

El enfoque de SaaS simple es la implementación más sencilla para una solución de IoT de SaaS. Tal como se muestra en el diagrama anterior, se comparte toda la infraestructura y no se aplica ninguna marca geográfica o de escala. A menudo, la infraestructura reside en una sola suscripción de Azure.

Azure IoT Central admite el concepto de organizaciones. Las organizaciones permiten a un proveedor de soluciones separar fácilmente los inquilinos de una manera segura y jerárquica, al tiempo que comparten el diseño básico de la aplicación entre todos los inquilinos.

Las comunicaciones a sistemas fuera de IoT Central, por ejemplo, para realizar el análisis de datos a largo plazo, a lo largo de una ruta de acceso esporádico o de conectividad con operaciones empresariales, se realizan a través de otras ofertas de PaaS y aPaaS de Microsoft. Estas otras ofertas pueden incluir los siguientes servicios:

• Azure Event Hubs como un motor de flujo de datos y mensajería multiplataforma de nivel empresarial.
• Azure Logic Apps como una oferta de plataforma como servicio de integración o iPaaS.
• Azure Data Explorer como una plataforma de análisis de datos.
• Power BI como plataforma de visualización e informes.

Si compara el enfoque de SaaS simple con el modelo aPaaS automatizado de inquilino único, muchas características son similares. La principal diferencia entre los dos modelos es que:

• En el Modelo automatizado de inquilino único, se implementa una instancia de IoT Central distinta para cada inquilino,
• En el modelo SaaS simple con aPaaS, se implementa una instancia compartida para varios clientes y se crea una organización de IoT Central para cada tenant.

Dado que en este modelo se comparte un nivel de datos multiarrendatario, es necesario implementar la seguridad a nivel de fila para aislar los datos de los clientes. Para obtener más información, consulte Enfoques arquitectónicos para el almacenamiento y los datos en soluciones multiinquilino.

Ventajas

• Es más fácil de administrar y operar con respecto a los otros enfoques presentados aquí.

Riesgos:

• Es posible que este enfoque no se escale fácilmente a un número elevado de dispositivos, mensajes o inquilinos.

• Los servicios y componentes se comparten, por lo tanto, un error en cualquier componente podría afectar a todos los inquilinos. Este riesgo es un riesgo para la confiabilidad y alta disponibilidad de la solución.

• Es importante tener en cuenta cómo administrar el cumplimiento, las operaciones, el ciclo de vida del inquilino y la seguridad de los subfletos de dispositivos. Estas consideraciones son importantes debido a la naturaleza compartida de este tipo de solución en los planos de control, administración y comunicaciones.

SaaS horizontal

Un enfoque de escalabilidad común es particionar horizontalmente la solución. Esto significa que tiene algunos componentes compartidos y algunos componentes por cliente.

En una solución de IoT, hay muchos componentes que se pueden particionar horizontalmente. Los subsistemas con particiones horizontales se organizan normalmente mediante un patrón de marca de implementación que se integra con la solución mayor.

SaaS horizontal de ejemplo

En el ejemplo de arquitectura siguiente se crean particiones de IoT Central por cliente final, que actúa como el portal de administración de dispositivos, comunicaciones de dispositivos y administración. Esta creación de particiones se suele realizar de forma que el cliente final que consume la solución tenga control total sobre la adición, eliminación y actualización de sus dispositivos, sin intervención del proveedor de software. El resto de la solución sigue un patrón de infraestructura compartida estándar, que resuelve las necesidades de análisis de rutas de acceso activas, de integraciones empresariales, de administración de SaaS y de análisis de dispositivos.

Cada inquilino tiene su propia organización IoT Central, que envía telemetría a una aplicación de función compartida y la pone a disposición de los usuarios empresariales de los inquilinos a través de una aplicación web.

Ventajas

• Fácil de administrar y operar, aunque puede ser necesaria una administración adicional para los componentes de un solo inquilino.
• Opciones de escalado flexibles, ya que las capas se escalan según sea necesario.
• Se reduce el efecto de los fallos de los componentes. Aunque un error de un componente compartido afecta a todos los clientes, los componentes escalados horizontalmente solo afectan a los clientes asociados a instancias de escalado específicas.
• Se ha mejorado la información de consumo por inquilino para componentes con particiones.
• Los componentes con particiones proporcionan personalizaciones por inquilino más sencillas.

Riesgos:

• Escala de la solución, especialmente para cualquier componente compartido.
• La confiabilidad y la alta disponibilidad pueden verse afectadas. Un único error en los componentes compartidos podría afectar a todos los inquilinos a la vez.
• La personalización de componentes con particiones por inquilino requiere consideraciones de administración y DevOps a largo plazo.

A continuación se muestran los componentes más comunes que suelen ser adecuados para la creación de particiones horizontales.

Bases de datos

Puede optar por crear particiones de las bases de datos. A menudo son los almacenes de datos de telemetría y de dispositivo los que tienen particiones. Con frecuencia, se usan varios almacenes de datos para distintos propósitos específicos, como el almacenamiento flexible frente al almacenamiento de archivado, o para la información de estado de la suscripción de inquilino.

Separe las bases de datos de cada inquilino para obtener las siguientes ventajas:

• Compatibilidad con estándares de cumplimiento. Los datos de cada inquilino están aislados en las instancias del almacén de datos.
• Evitar los problemas de tipo "vecino ruidoso".

Administración, comunicaciones y gestión de dispositivos

Las aplicaciones de Azure IoT Hub Device Provisioning Service, IoT Hub e IoT Central se pueden implementar a menudo como componentes con particiones horizontales. En este enfoque, necesita otro servicio para redirigir los dispositivos a la instancia de DPS adecuada para el plano de administración, control y telemetría de ese inquilino concreto. Para obtener más información, consulte el artículo técnico Ampliación de una solución Azure IoT para admitir millones de dispositivos.

Este enfoque se suele adoptar para permitir que los clientes finales administren y controlen sus propias flotas de dispositivos que están más directamente y totalmente aislados.

Si el plano de comunicaciones del dispositivo está particionado horizontalmente, los datos de telemetría deben enriquecerse con los datos que identifican el inquilino de origen. Este enriquecimiento permite al procesador de flujos saber qué reglas de inquilino aplicar al flujo de datos. Por ejemplo, si un mensaje de telemetría genera una notificación en el procesador de flujo, el procesador de flujo necesita determinar la ruta de notificación adecuada para el inquilino asociado.

Procesamiento de flujos

Al crear particiones del procesamiento de secuencias, se habilitan personalizaciones por inquilino del análisis en los procesadores de secuencias.

Un solo inquilino automatizado

Un enfoque automatizado de un solo inquilino se basa en un proceso de decisión y diseño similares a una solución empresarial.

Cada inquilino tiene su propio entorno aislado idéntico, con una organización de IoT Central y otros componentes dedicados a ellos.

Un punto de decisión fundamental en este enfoque es elegir en qué suscripción de Azure se deben implementar los componentes. Si los componentes se implementan en su suscripción, tendrá más control y mejor visibilidad sobre el costo de la solución, pero es necesario que tenga en cuenta los problemas de seguridad y gobernanza de la solución. Por el contrario, si la solución se implementa en la suscripción del cliente, este es responsable en última instancia de la seguridad y la gobernanza de la implementación.

Este patrón admite un alto grado de escalabilidad, ya que los requisitos de inquilino y suscripción suelen ser los factores de limitación de la mayoría de las soluciones. Por lo tanto, aísle cada inquilino para poder proporcionar un gran ámbito y así escalar la carga de trabajo de cada inquilino, sin tener que realizar un esfuerzo sustancial como desarrollador de la solución.

Este patrón también suele tener una latencia baja, en comparación con otros patrones, ya que puede implementar los componentes de la solución en función de la geografía de los clientes. La afinidad geográfica permite crear rutas de acceso de red más cortas entre un dispositivo IoT y la implementación de Azure.

Si es necesario, puede ampliar la implementación automatizada para admitir una mayor latencia o escala, habilitando la implementación rápida de instancias adicionales de la solución en zonas geográficas nuevas o existentes.

El enfoque automatizado de un solo inquilino es similar al modelo de aPaaS SaaS simple. La diferencia principal entre los dos modelos es que en el enfoque automatizado de un solo inquilino implementa una instancia de IoT Central distinta para cada inquilino, mientras que si usa el modelo SaaS simple con aPaaS, debe implementar una instancia compartida de IoT Central con varias organizaciones de IoT Central.

Ventajas

• Fácil de administrar y operar.
• Se garantiza el aislamiento de inquilinos.

Riesgos:

• La automatización inicial puede ser complicada para el nuevo personal de desarrollo.
• Debe aplicar la seguridad de las credenciales entre clientes en una administración de implementaciones de nivel superior, o los riesgos pueden extenderse entre los clientes.
• Se espera que los costos sean mayores, ya que las ventajas de escala de una infraestructura compartida entre los clientes no están disponibles.
• Serán necesarias muchas instancias para mantener si el proveedor de soluciones se encarga del mantenimiento de cada una de ellas.

Aumento de la escala de SaaS

Al expandir la escala de una solución a implementaciones de gran tamaño, existen desafíos específicos que surgen en función de los límites de servicio, los problemas geográficos y otros factores. Para obtener más información sobre las arquitecturas de implementación de IoT a gran escala, consulte Escalado horizontal de una solución de Azure IoT para admitir millones de dispositivos.

Colaboradores

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

Creadores de entidad de seguridad:

• Michael C. Bazarewsky | Ingeniero de clientes sénior, FastTrack for Azure
• David Crook | Ingeniero de clientes principal, FastTrack for Azure

Otros colaboradores:

• John Downs | Ingeniero principal de software
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Pasos siguientes

• Revise las instrucciones para multiinquilinos y Azure Cosmos DB.
• Obtenga información sobre las rutas de acceso a datos frecuentes, flexibles y pasivas con IoT en Azure.
• Consulte las arquitecturas de referencia de Azure IoT.