This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the architectural approaches for IoT in multitenant solutions.
IoT services like storage services are hetereogenous in their functionality. IoT systems vary in flavor and size. Not all IoT systems have the same certifications or capabilities. Multitenant solutions introduce sharing which brings a higher density of tenants to infrastructure and reduce the operational cost and management. Unlike compute or storage, isolation model can be as granular as the devices. Services that depend on the number of devices supported in a single instance include Azure IoT central, Azure IoT Hub Device Provisioning Service (DPS) and Azure IoT Hub. Different devices even in the same solution might have different throughput requirements. Throughput refers to the total bytes transferred in unit time and can be affected by both the number of messages as well as the size of messages.
When these IoT resources are shared, isolation model, impact to scaling performance, state management and security of the IoT resources become complex. These key decisions for planning a multitenant IoT solution are discussed below.
Scaling resources helps meet the changing demand from the growing number of tenants and the increase in the amount of traffic. We might need to increase the capacity of the resources to maintain an acceptable performance rate. For example, if a single IoT topic/queue is provisioned for all the tenants and the traffic exceeds the specific number of IoT operations per second, the Azure IoT will reject the application’s requests and all the tenants will be impacted. Scaling depends on Number of producers and consumers, Payload size, Partition count, Egress request rate and Usage of IoT Hubs Capture, Schema Registry, and other advanced features. When additional IoT is provisioned or rate limit is adjusted, the multitenant solution can perform retries to overcome the transient failures from requests. When the number of active users reduces or there is a decrease in the traffic, the IoT resources could be released to reduce costs. When the resources are dedicated to a tenant, they can be independently scaled to meet the tenants’ demands. This is the simplest solution, but it requires a minimum number of resources per tenant. A shared scaling of resources in the platform implies all the tenants will be affected. They will also suffer when the scale is insufficient to handle their overall load. If a single tenant uses a disproportionate amount of the resources available in the system, it leads to a well-known problem called the noisy neighbor antipattern. When the resource usage increases above the total capacity from the peak load of the tenants involved, failures occur which are not specific to a tenant and impact the performance of those tenants. The total capacity can also be exceeded when the individual usages are small, but the number of tenants increase dramatically. Performance problems often remain undetected until an application is under load. A load testing preview can help analyze the behavior of the application under stress. Scaling horizontally or vertically helps correct the correlated application behavior.
Data isolation depends on the scope of isolation. When the storage for IoT is SQL Server, then the IoT solution can make use of IoT Hub. If the storage is Azure Data Explorer, the IoT solution can benefit from IoT Central. Finally, IoT resources can be provisioned within a single subscription or separated into one per tenant.
Varying levels and scope of sharing of IoT resources demands simplicity from the architecture of the multitenant application to store and access data with little expertise. A particular concern for multitenant solution is the level of customization to be supported.
Patterns such as the use of the deployment stamp pattern, the IoT resource consolidation pattern and the dedicated IoT resources per tenant pattern help to optimize the operational cost and management with little or no impact to the usages.
Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN
No comments:
Post a Comment