Approches architecturales pour l’IoT dans une solution multilocataire

Les solutions IoT multilocataire sont disponibles dans de nombreux types et tailles différents. 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 relatives à l’architecture multilocation pour les solutions IoT. Ce document comprend des exemples d’architectures multilocataire qui tirent parti des composants communs, en fonction de l'architecture de référence IoT.

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. Les informations sur la gouvernance et la conformité sont traitées dans un article dédié sur ce sujet.

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 une solution de bâtiment intelligent, les thermostats signaleront probablement des données à une fréquence inférieure à celle des ascenseurs, tandis que dans une solution de véhicule connecté, les messages de données des enregistrements de la caméra du véhicule seront probablement plus volumineux que les messages de télémétrie de navigation. Si vos messages sont limités en termes de fréquence, vous devrez peut-être effectuer un scale-out d’instances pour un service particulier, mais s’ils sont limités en termes de taille, vous devrez peut-être effectuer un scale-up d’instances plus volumineuses d’un service particulier.

• 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 de IoT Hub et IoT Central, cela peut entraîner des codes de réponse HTTP 429 (« Trop de demandes »), qui sont des défaillances matérielles pouvant provoquer 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 de l’infrastructure partagée commencent à recevoir 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, l’occurrence la plus courante de cette situation se produit lorsqu’une limite de quota de messages a été 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 une distribution d’allocation supplémentaire au niveau de l’équilibreur de charge DPS.

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

Les solutions IoT ont tendance à être très consommatrices de données, à la fois lors de la diffusion 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 retenue parmi les approches ci-dessous aura une incidence sur les couches et les limites du réseau ; une fois la conception physique choisie, on peut sélectionner l’implémentation de la sécurité. Les outils suivants peuvent être utilisés quelle que soit l'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. Selon 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 une appliance de pare-feu tierce, que vous devrez envisager pour isoler les couches réseau et superviser le trafic réseau. Le choix exact de l’approche aura une incidence sur le point où les charges de travail auront une isolation réseau par rapport à un réseau partagé, comme indiqué ci-dessous.

• Azure IoT Edge ou Azure IoT Operations, que vous devriez envisager dans le cadre de la connectivité des appareils aux services hébergés par Azure sans exposer directement les appareils à un accès direct à Internet. Azure IoT Operations étant actuellement en version préliminaire, ce document ne décrit pas l'utilisation de cette offre en général. Une prochaine révision de ce document abordera ce point.

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

Toutes les considérations que vous feriez normalement dans une architecture IoT, pour tous les composants principaux (tels que la gestion, l’ingestion, le traitement, le stockage, la sécurité, etc.), sont tous les choix que vous devez toujours effectuer quand vous envisagez une solution multi-locataire. 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, les points de décision courants pour le stockage peuvent décider s’il faut utiliser SQL Server ou Azure Data Explorer, ou peut-être au niveau de l’ingestion et de la gestion, 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. Ces facteurs sont déterminés par les exigences clé et les considérations décrites ci-dessus.

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 Comparer des solutions IoT (Internet des objets) PaaS et aPaaS.

Il s’agit du dilemme classique « créer ou acheter » que de nombreuses organisations rencontrent 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 qu’étant donné que IoT Central est une offre aPaaS, certaines décisions ne reviennent pas à un responsable de l’implémentation. 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.
• Dans un modèle multilocataire, la limite maximale de nœuds IoT Central (qui s’applique à la fois aux parents et aux feuilles) et à la profondeur d’arborescence maximale, peuvent forcer 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’appel d’API, ce qui peut avoir un impact sur les implémentations volumineuses.

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 l’exécution de services d’intelligence artificielle (IA) tiers ou votre propre logique métier sur des 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. Cela signifie que 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 offres supplémentaires 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é à 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 pour plusieurs clients et vous créez une organisation IoT Central pour chaque locataire.

Lorsque vous partagez une couche Données à multilocataire dans ce modèle, vous devez implémenter la sécurité au niveau des lignes, comme décrit dans Approches architecturales en matière de stockage et de données dans les solutions multilocataires, afin d’isoler les données client.

Avantages :

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

Risques :

• Cette approche peut ne pas être facilement mise à l’échelle avec un grand nombre d’appareils, de messages ou de locataires.

• Étant donné que tous les services et composants sont partagés, l’échec d’un composant peut affecter tous vos locataires. Il s’agit d’un risque relatif à la fiabilité et à la haute disponibilité de votre solution.

• Il est important de réfléchir à la façon dont vous gérez la conformité, les opérations, le cycle de vie des locataires et la sécurité des sous-flottes 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 d’architecture ci-dessous partitionne IoT Central par client final, qui sert de portail de gestion des appareils, de communication des appareils et d’administration. Cela s’effectue souvent de manière à ce que le client final qui consomme la solution ait un contrôle total sur l’ajout, la suppression et la mise à jour des appareils eux-mêmes, sans l’intervention de l’éditeur du logiciel. 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 :

• Généralement facile à gérer et à utiliser, bien qu’une gestion supplémentaire soit nécessaire pour les composants à locataire unique.
• Options de mise à l’échelle flexibles, car les couches sont mises à l’échelle en fonction des besoins.
• L’impact des défaillances des composants est réduit. Bien qu’une défaillance d’un composant partagé ait un impact sur 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 :

• Tenez compte de lamise à l’échelle de la solution, en particulier pour tous 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 sont généralement adaptés 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. Si vous suivez cette approche, vous devez disposer d’un service supplémentaire pour rediriger les appareils vers le service d’approvisionnement des appareils approprié pour le plan de gestion, de contrôle et de télémétrie du locataire en particulier. Oour plus d’informations, reportez-vous au livre blanc sur la mise à l’échelle d’une solution Azure IoT pour prendre en charge des millions d’appareils.

Cela est souvent fait pour permettre aux clients finaux de gérer et de contrôler leurs propres flottes d’appareils qui sont 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 données pour le locataire source, de sorte que le processeur de flux sache quelles règles de locataire s’appliquent 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, ce dernier 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é de scalabilité. Cela est dû au fait que les conditions requises du client et de l’abonnement sont généralement les facteurs limitatifs 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 a généralement une faible latence, par rapport à d’autres modèles, car vous êtes en mesure de déployer les composants de la solution en fonction de la géographie 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 accrue, en autorisant le déploiement rapide d’instances supplémentaires de la solution, pour un client dans les 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 :

• Relativement facile à gérer et à utiliser.
• L’isolation des locataires est quasiment 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 mise à l’échelle d’une infrastructure partagée entre les clients ne sont pas disponibles.
• Si le fournisseur de solutions est responsable de la maintenance de chaque instance, vous pouvez avoir plusieurs instances à gérer.

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

Lorsque vous développez la mise à l’échelle d’une solution à de très grands déploiements, des problèmes spécifiques se posent 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.
• Reportez-vous à Architectures de référence Azure IoT.