Approches architecturales pour les solutions multilocataires basées sur IoT Hub

Les solutions IoT Hub multilocataires sont disponibles dans de nombreuses versions et tailles différentes. Vous pouvez avoir de nombreuses exigences et contraintes, allant de la propriété de l’infrastructure à l’isolation des données client, à la conformité. Il peut être difficile de définir un modèle qui répond à toutes ces contraintes de conception, et cela nécessite souvent de prendre en compte plusieurs dimensions. Cet article décrit plusieurs approches couramment utilisées pour résoudre les considérations multilocataires pour les solutions IoT Hub.

Principaux éléments et exigences à prendre en compte

Ces considérations et exigences sont présentées dans l’ordre dans lequel elles sont généralement prioritaires pour concevoir une solution.

Gouvernance et conformité

Les considérations relatives à la gouvernance et à la conformité peuvent nécessiter l’utilisation d’un modèle particulier ou d’un ensemble de ressources IoT. Tous les services IoT n’ont pas les mêmes certifications ou fonctionnalités. Si vous avez besoin de respecter des normes de conformité spécifiques, vous devrez peut-être sélectionner des services spécifiques. Pour plus d’informations, consultez approches architecturales pour la gouvernance et la conformité dans les solutions multilocataires.

La gouvernance dans IoT peut également prendre d’autres formes, telles que la propriété et la gestion des appareils. Le client est-il propriétaire de l’appareil ou est-ce le fournisseur de solutions ? Qui est-il responsable de la gestion de ces appareils ? Ces considérations et implications sont propres à chaque fournisseur de solutions et peuvent aboutir à différents choix dans la technologie, le modèle de déploiement et le modèle d’architecture multi-location que vous utilisez.

Mise à l’échelle

Il est important de planifier la mise à l’échelle de votre solution. La mise à l’échelle est souvent considérée sur ces trois dimensions :

• Quantité d’appareils : tous les services de gestion des appareils Azure, Azure IoT Central, service Azure IoT Hub Device Provisioning (DPS) et Azure IoT Hub, ont des limitations sur le nombre d’appareils pris en charge dans une instance unique.

  Conseil

  Reportez-vous à la documentation sur les déploiements à grande échellesi vous envisagez de déployer un très grand nombre d’appareils.

• Débit de l’appareil : les différents appareils, même dans la même solution, peuvent avoir des exigences différentes en termes de débit. Dans ce contexte, le débit fait référence au nombre de messages sur une période de temps et à la taille des messages. Par exemple, dans un :

  • Solution de construction intelligente, les thermostats signalent généralement des données à une fréquence inférieure à celle des ascenseurs.
  • Dans une solution de véhicule connecté, les messages de données d’enregistrement de caméra de véhicule sont généralement plus volumineux que les messages de télémétrie de navigation.

  Si vos messages sont limités par rapport à la fréquence, envisagez d’effectuer un scale-out vers d’autres instances d’un service. Si vos messages sont limités par rapport à la taille, envisagez d’effectuer un scale-up vers des instances plus volumineuses d’un service.

• Locataires : la mise à l’échelle d’un seul locataire peut être petite, mais lorsqu’elle est multipliée par le nombre de locataires, elle peut rapidement croître.

Performances et fiabilité

Isolation des locataires

Les solutions entièrement partagées peuvent avoir des voisins bruyants. Dans les cas d’IoT Hub et d’IoT Central, les voisins bruyants peuvent entraîner des codes de réponse HTTP 429 (« Trop de requêtes ») qui sont des défaillances difficiles qui peuvent entraîner un effet en cascade. Pour plus d’informations, consultez Quotas et limites.

Dans les solutions entièrement multilocataires, ces effets peuvent s’exécuter en cascade. Lorsque les clients partagent des applications IoT Hub ou IoT Central, tous les clients sur l’infrastructure partagée reçoivent des erreurs. Étant donné que IoT Hub et IoT Central sont généralement les points d’entrée pour les données dans le Cloud, d’autres systèmes en aval qui dépendent de ces données sont susceptibles d’échouer également. Souvent, la raison la plus courante de ces erreurs est lorsqu’une limite de quota de messages est dépassée. Dans ce cas, le correctif le plus rapide et le plus simple pour les solutions IoT Hub consiste à mettre à niveau le SKU IoT Hub, à augmenter le nombre d’unités IoT Hub, ou les deux. Pour les solutions IoT Central, la solution est automatiquement mise à l’échelle en fonction des besoins, jusqu’au nombre indiqué de messages pris en charge.

Vous pouvez isoler et distribuer les locataires dans les plans de contrôle, de gestion et de communication IoT à l’aide des stratégies d’allocation personnaliséesdu DPS. En outre, lorsque vous suivez les instructions pour les solutions IoT à grande échelle , vous pouvez gérer d'autres répartitions d'allocation au niveau de l'équilibreur de charge DPS.

Stockage, requête, utilisation et rétention des données

Les solutions IoT ont tendance à être gourmandes en données, à la fois lors de la diffusion en continu et au repos. Pour plus d’informations sur la gestion des données dans des solutions multilocataires, consultez Approches architecturales en matière de stockage et de données dans les solutions multilocataires.

Sécurité

Les solutions IoT ont souvent des considérations de sécurité sur plusieurs couches, en particulier dans les solutions déployées dans une architecture de référence d’entreprise Purdue modifiée dans le cloud ou les solutions Industry 4.0. L’approche de conception que vous sélectionnez affecte les couches réseau et les limites qui existent ; après avoir sélectionné la conception physique, vous pouvez sélectionner l’implémentation de sécurité. Vous pouvez utiliser les outils suivants dans n’importe quelle approche :

• Microsoft Defender pour IoT, une solution de supervision IoT complète que vous devriez envisager et qui offre une licence EIoT par appareil et des licences de site OT pour chaque appareil et/ou site du client. En fonction de l’approche sélectionnée plus loin dans cet article, le scénario de licence utilisateur nommé Microsoft 365 peut ne pas être possible. Dans ce cas, les options de licence par appareil et par site sont envisageables. Elles sont indépendantes des licences de locataire Microsoft 365.

• Pare-feu Azure ou un dispositif de pare-feu non-Microsoft, que vous devriez envisager d'utiliser pour isoler les couches réseau et surveiller le trafic réseau. Le choix exact de l’approche détermine où les charges de travail ont une isolation réseau par rapport à un réseau partagé, comme indiqué plus loin dans cet article.

• Azure IoT Edge.

La plupart de ces points relatifs à la sécurité s'appliquent à une solution multilocataire de la même manière qu'à une solution à locataire unique, les variations étant liées à l'approche choisie. L'identité de l'utilisateur et de l'application constitue l'un des éléments qui sera probablement très différent dans une solution IoT globale. Les approches architecturales concernant l'identité dans les solutions multilocataire abordent cet aspect d'une solution multilocataire globale.

Approches à envisager

Les considérations et les choix pour les composants principaux, tels que la gestion, l’ingestion, le traitement, le stockage et la sécurité, sont les mêmes pour les solutions IoT uniques et mutualisées. La principale différence réside dans la façon dont vous organisez et utilisez les composants pour prendre en charge l’architecture multi-location. Par exemple, points de décision courants pour :

• Le stockage peut choisir d’utiliser SQL Server ou Azure Data Explorer.
• Le niveau d’ingestion et de gestion consiste à choisir entre IoT Hub et IoT Central.

La plupart des solutions IoT s’intègrent dans un modèle d’architecture racine, qui est une combinaison de la cible de déploiement, du modèle de location et du modèle de déploiement. Les principales exigences et considérations décrites précédemment déterminent ces facteurs.

L’un des plus grands points de décision à prendre, dans l’espace IoT, est de choisir entre une application-plateforme en tant que service (aPaaS) et une approche de plateforme en tant que service (PaaS). Pour plus d’informations, consultez comparaison des approches de solution IoT (PaaS et aPaaS).

Ce choix est le dilemme courant « faire ou acheter » auquel de nombreuses organisations sont confrontées dans de nombreux projets. Il est important d’évaluer les avantages et les inconvénients de ces deux options.

Concepts et considérations pour les solutions aPaaS

Une solution aPaaS classique utilisant Azure IoT Central, comme cœur de la solution, peut utiliser les services Azure PaaS et aPaaS suivants :

• Azure Event Hubs en tant que moteur de flux de données et de messagerie de messagerie d’entreprise multiplateforme.
• Azure Logic Apps comme offre de plateforme en tant que service, ou iPaaS, d’intégration.
• Azure Data Explorer est une plateforme d’analytique de données.
• Power BI en tant que plateforme de visualisation et de création de rapports.

Dans le schéma précédent, les locataires partagent un environnement IoT Central, Azure Data Explorer, Power BI et Azure Logic Apps.

Cette approche est généralement la méthode la plus rapide pour commercialiser une solution. Il s’agit d’un service à grande échelle qui prend en charge la multilocation à l’aide d'organisations.

Il est important de comprendre que, étant donné qu’IoT Central est une offre aPaaS, certaines décisions sont en dehors du contrôle de l’implémenteur. Ces décisions sont les suivantes :

• IoT Central utilise Microsoft Entra ID comme fournisseur d’identité.
• Les déploiements IoT Central sont réalisés à l’aide des opérations de plan de contrôle et de données, qui combinent des documents déclaratifs avec du code impératif.
• La limite maximale de nœuds et la profondeur maximale de l'arborescence dans un modèle multitenant basé sur IoT Central peuvent obliger un fournisseur de services à avoir plusieurs instances d'IoT Central. Dans ce cas, vous devez envisager de suivre le modèle d’empreinte de déploiement.
• IoT Central impose des limites d'appels à l'API, ce qui peut affecter les grandes implémentations.

Concepts et considérations pour les solutions aPaaS

Une approche PaaS peut utiliser les services Azure suivants :

• Azure IoT Hub en tant que plateforme de communication et de configuration de l’appareil principal.
• Service de provisionnement des appareils Azure IoT en tant que plateforme de déploiement de l’appareil et de configuration initiale.
• Azure Data Explorer pour le stockage et l’analyse à chaud et à froid des données de série chronologique d’appareils IoT.
• Azure Stream Analytics pour l’analyse de données de chemin chaud d’appareils IoT.
• Azure IoT Edge pour exécuter l’intelligence artificielle (IA), les services non-Microsoft ou votre propre logique métier sur les appareils IoT Edge.

Dans le schéma précédent, chaque locataire se connecte à une application Web partagée, qui reçoit des données de services IoT Hub et d’une application de fonction. Les appareils se connectent au service de provisionnement des appareils et à IoT Hub.

Cette approche nécessite un travail supplémentaire de développement pour créer, déployer et gérer la solution (par opposition à une approche aPaaS). Moins de fonctionnalités sont prédéfinies aux fins de commodité pour le responsable de l’implémentation. Par conséquent, cette approche offre également davantage de contrôle, car moins d’hypothèses sont incorporées dans la plateforme sous-jacente.

Modèles d’architecture racine

Le tableau suivant répertorie les modèles courants pour les solutions IoT multilocataires. Chaque modèle comporte les informations suivantes :

• Nom du modèle, qui est basé sur la combinaison de la cible, du modèle et du type de déploiement.
• La cible de déploiement, représentant l’abonnement Azure sur lequel déployer des ressources.
• Le modèle de location référencé par le modèle, comme décrit dans Modèles de multilocation
• Le modèle de déploiement, qui fait référence à un déploiement simple avec des considérations de déploiement minimales, un modèle Geode ou un modèle d’empreinte de déploiement.

Modèle	Cible de déploiement	Modèle de location	Modèle de déploiement
SaaS simple	Abonnement du fournisseur de services	Entièrement multilocataire	Simple
SaaS horizontal	Abonnement du fournisseur de services	Données partitionnées	Empreinte de déploiement
Automatisé à un seul locataire	L’abonnement du fournisseur de services ou du client	Un seul locataire par client	Simple

SaaS simple

Cible de déploiement	Modèle de location	Modèle de déploiement
Abonnement du fournisseur de services	Entièrement multilocataire	Simple

L’approche Saas simple est l’implémentation la plus simple pour une solution IOT SaaS. Comme le montre le schéma précédent, toute l’infrastructure est partagée et l’infrastructure n’a pas d’empreinte géographique ou de mise à l’échelle appliquée. Souvent, l’infrastructure réside dans un seul abonnement Azure.

Azure IoT Central prend en charge le concept d'organisation. Les organisations permettent à un fournisseur de solutions de séparer facilement les locataires de façon sécurisée et hiérarchique, tout en partageant la conception d’applications de base sur tous les locataires.

Les communications vers des systèmes en dehors d’IoT Central, telles que l’analyse de données à plus long terme, sur un chemin froid ou la connectivité avec les opérations métier, s’effectuent par le biais d’autres offres Microsoft PaaS et aPaaS. Ces autres offres peuvent inclure les services suivants :

• Azure Event Hubs en tant que moteur de flux de données et de messagerie d’entreprise multiplateforme.
• Azure Logic Apps comme offre de plateforme en tant que service, ou iPaaS, d’intégration.
• Azure Data Explorer est une plateforme d’analytique de données.
• Power BI en tant que plateforme de visualisation et de création de rapports.

Si vous comparez l’approche Saas simple au modèle aPaaS automatisé à locataire unique, de nombreuses caractéristiques sont similaires. La principale différence entre les deux modèles est que :

• Dans le modèle automatisé de locataire unique , vous déployez une instance IoT Central distincte pour chaque locataire.
• Dans le modèle SaaS simple avec aPaaS modèle, vous déployez une instance partagée pour plusieurs clients et créez une organisation IoT Central pour chaque locataire.

Étant donné que vous partagez un niveau de données mutualisé dans ce modèle, vous devez implémenter la sécurité au niveau des lignes pour isoler les données client. Pour plus d’informations, consultez approches architecturales pour le stockage et les données dans des solutions multilocataires.

Avantages :

• Plus facile à gérer et à utiliser par rapport aux autres approches présentées ici.

Risques :

• Cette approche pourrait ne pas s'adapter facilement à un grand nombre d'appareils, de messages ou de locataires.

• Les services et les composants sont partagés, par conséquent, une défaillance dans n’importe quel composant peut affecter tous vos locataires. Ce risque est un risque pour la fiabilité et la haute disponibilité de votre solution.

• Il est important de prendre en compte la façon dont vous gérez la conformité, les opérations, le cycle de vie du locataire et la sécurité des sous-ensembles d’appareils. Ces considérations deviennent importantes en raison de la nature partagée de ce type de solution au niveau des plans de contrôle, de gestion et de communication.

SaaS horizontal

Cible de déploiement	Modèle de location	Modèle de déploiement
Abonnement du fournisseur de services	Données partitionnées	Empreinte de déploiement

Une approche courante de scalabilité consiste à partitionner horizontalement la solution. Cela signifie que vous avez des composants partagés et des composants par client.

Dans une solution IoT, il existe de nombreux composants qui peuvent être partitionnés horizontalement. Les sous-systèmes partitionnés horizontalement sont généralement organisés à l’aide d’un modèle d’empreinte de déploiement qui s’intègre à la meilleure solution.

Exemple de SaaS horizontal

L’exemple architectural suivant partitionne IoT Central par client final, qui sert de portail de gestion des appareils, de communications d’appareils et d’administration. Ce partitionnement est souvent effectué de telle sorte que le client final qui consomme la solution a un contrôle total sur l’ajout, la suppression et la mise à jour de leurs appareils, sans intervention du fournisseur de logiciels. Le reste de la solution suit un modèle standard d’infrastructure partagée, qui résout les besoins en matière d’analyse de chemin chaud, d’intégration métier, de gestion SaaS et d’analyse des appareils.

Chaque locataire a sa propre organisation IoT Central, qui envoie la télémétrie à une application de fonction partagée et la met à la disposition des utilisateurs professionnels des locataires via une application Web.

Avantages :

• Facile à gérer et à utiliser, bien que la gestion supplémentaire puisse être nécessaire pour les composants monolocataires.
• Options de mise à l’échelle flexibles, car les couches sont mises à l’échelle en fonction des besoins.
• L’effet des défaillances des composants est réduit. Si une défaillance d’un composant partagé affecte tous les clients, les composants mis à l’échelle horizontalement affectent uniquement les clients associés à des instances de mise à l’échelle spécifiques.
• Amélioration des insights sur la consommation par locataire pour les composants partitionnés.
• Les composants partitionnés fournissent des personnalisations par locataire plus faciles.

Risques :

• L'échelle de la solution, en particulier pour les composants partagés.
• La fiabilité et la haute disponibilité sont potentiellement affectées. Une seule défaillance dans les composants partagés peut affecter tous les locataires à la fois.
• La personnalisation des composants partitionnés par locataire nécessite des considérations de gestion et DevOps à long terme.

Voici les composants les plus courants qui conviennent généralement au partitionnement horizontal.

Bases de données

Vous pouvez choisir de partitionner les bases de données. Souvent, ce sont les magasins de données de télémétrie et d’appareil qui sont partitionnés. Plusieurs magasins de données sont fréquemment utilisés à des fins spécifiques, telles que le stockage d’archives par rapport au stockage à chaud, ou pour les informations sur l’état des abonnements de location.

Séparez les bases de données pour chaque locataire pour bénéficier des avantages suivants :

• Prendre en charge les normes de conformité. Les données de chaque locataire sont isolées sur l’ensemble des instances du magasin de données.
• Résoudre les problèmes de voisins bruyants.

Gestion des appareils, communications et administration

Service Azure IoT Hub Device Provisioning, IoT Hub et les applications IoT Central peuvent souvent être déployés sous forme de composants partitionnés horizontalement. Dans cette approche, vous avez besoin d’un autre service pour rediriger les appareils vers l’instance DPS appropriée pour le plan de gestion, de contrôle et de télémétrie de ce locataire particulier. Pour en savoir plus, consultez le livre blanc Mise à l'échelle d'une solution Azure IoT pour prendre en charge des millions d'appareils.

Cette approche est souvent prise pour permettre aux clients finaux de gérer et de contrôler leurs propres flottes d’appareils plus directement et entièrement isolés.

Si le plan de communication de l’appareil est partitionné horizontalement, les données de télémétrie doivent être enrichies avec des informations identifiant l'entité source. Cet enrichissement permet au processeur de flux de savoir quelles règles de locataire appliquer au flux de données. Par exemple, si un message de télémétrie génère une notification dans le processeur de flux, le processeur de flux doit déterminer le chemin de notification approprié pour le locataire associé.

Traitement des flux de données

En partitionnant le traitement des flux, vous activez les personnalisations par locataire de l’analyse dans les processeurs de flux.

Automatisé à un seul locataire

Une approche automatisée à un seul locataire est basée sur les mêmes processus de décision et conception qu’une solution d’entreprise.

Chaque locataire a son propre environnement isolé et identique, avec une organisation IoT Central et d’autres composants dédiés à ces derniers.

Cible de déploiement	Modèle de location	Modèle de déploiement
L’abonnement du fournisseur de services ou du client	Un seul locataire par client	Simple

Un point de décision critique de cette approche consiste à choisir l’abonnement Azure sur lequel les composants doivent être déployés. Si les composants sont déployés pour votre abonnement, vous bénéficiez d’un contrôle accru et d’une meilleure visibilité sur le coût de la solution, mais vous devez prendre en charge davantage de problèmes de sécurité et de gouvernance de la solution. À l’inverse, si la solution est déployée pour l’abonnement de votre client, le client est au final responsable de la sécurité et de la gouvernance du déploiement.

Ce modèle prend en charge un degré élevé d’extensibilité, car les exigences de locataire et d’abonnement sont généralement les facteurs de limitation dans la plupart des solutions. Par conséquent, isolez chaque locataire pour offrir une étendue importante à la mise à l’échelle de la charge de travail de chaque locataire, sans effort substantiel de votre part, en tant que développeur de solutions.

Ce modèle présente généralement une faible latence, par rapport à d’autres modèles, car vous pouvez déployer les composants de solution en fonction de la zone géographique de vos clients. L’affinité géographique permet d’avoir des chemins d’accès réseau plus courts entre un appareil IoT et votre déploiement Azure.

Si nécessaire, vous pouvez étendre le déploiement automatisé pour prendre en charge une latence ou une mise à l’échelle améliorée, en activant un déploiement rapide d’instances supplémentaires de la solution dans des zones géographiques existantes ou nouvelles.

L’approche automatisée à un seul locataire est similaire au modèle aPaaS Saas simple. La principale différence entre les deux modèles est que dans l’approche automatisée à un seul locataire, vous déployez une instance de IoT Central distincte pour chaque locataire, tandis que dans le modèle Saas simple avec aPaaS, vous déployez une instance partagée d’IoT Central avec plusieurs organisations IoT.

Avantages :

• Facile à gérer et à exploiter.
• L’isolation du locataire est garantie.

Risques :

• L’automatisation initiale peut être compliquée pour les nouveaux membres de l’équipe de développement.
• La sécurité des informations d’identification entre les clients pour une gestion du déploiement de niveau supérieur doit être appliquée, ou les compromissions peuvent affecter les autres clients.
• Les coûts sont censés être plus élevés, car les avantages de l’échelle d’une infrastructure partagée entre les clients ne sont pas disponibles.
• De nombreuses instances à gérer si le fournisseur de solutions possède la maintenance de chaque instance.

Accroître la mise à l’échelle de SaaS

Lorsque vous étendez l’échelle d’une solution à des déploiements volumineux, il existe des défis spécifiques qui surviennent en fonction des limites de service, des préoccupations géographiques et d’autres facteurs. Pour plus d’informations sur les architectures de déploiement IoT à grande échelle, consultez le livre blanc sur la mise à l'échelle d’une solution Azure IoT pour prendre en charge des millions d’appareils.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Michael C. Bazarewsky | Ingénieur client senior, FastTrack for Azure
• David Crook | Ingénieur client principal, FastTrack for Azure

Autres contributeurs :

• John Downs | Ingénieur logiciel principal
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Étapes suivantes

• Passez en revue les conseils relatifs à la multilocation et Azure Cosmos DB.
• En savoir plus sur les chemins de données de niveau d'accès chaud, chauds et froid avec IoT sur Azure.