IoT Hub ベースのマルチテナント ソリューションのアーキテクチャ アプローチ
マルチテナント IoT Hub ベースのソリューションには、さまざまな種類とサイズがあります。 ユーザーには、インフラストラクチャの所有権から顧客データの分離やコンプライアンスに至るまで、さまざまな要件と制約がある場合があります。 これらの設計上の制約すべてを満たすパターンを定義することは困難な場合があり、多くの場合、そのために複数のディメンションを考慮することが必要になります。 この記事では、IoT Hub ベースのソリューションのマルチテナントに関する考慮事項を解決するために一般的に使用されるいくつかの方法について説明します。
主な考慮事項と要件
次の考慮事項と要件は、ソリューション設計のための一般的な優先度付けの順序に従って示されています。
ガバナンスとコンプライアンス
ガバナンスとコンプライアンスに関する考慮事項では、特定のパターンまたは一連の IoT リソースを使用することが必要になる場合があります。 すべての IoT サービスが同じ認定や機能を有しているわけではありません。 特定のコンプライアンス基準を満たす必要がある場合は、特定のサービスを選択する必要があります。 詳細については、マルチテナント ソリューションのガバナンスとコンプライアンスに関するアーキテクチャ アプローチ
IoT のガバナンスは、デバイスの所有権や管理など、他の形式を取ることもできます。 デバイスを所有するのは顧客か、それともソリューション プロバイダーか。 これらのデバイスの管理は誰が行うか。 これらの考慮事項と影響はソリューション プロバイダーごとに固有であり、使用するテクノロジ、展開パターン、マルチテナント パターンの選択が異なる場合があります。
スケール
ソリューションのスケールを計画するのは重要なことです。 多くの場合、スケールは次の 3 つのディメンションで考慮されます。
デバイスの数: すべての Azure デバイス管理サービス (Azure IoT Central、Azure IoT Hub Device Provisioning Service (DPS)、および Azure IoT Hub) には、1 つのインスタンスでサポートされるデバイス数に制限があります。
ヒント
デプロイする予定のデバイス数が非常に多い場合は、高スケールに関するドキュメントを参照してください。
デバイスのスループット: 同じソリューション内であっても、デバイスが異なるとスループット要件も異なる場合があります。 このコンテキストの "スループット" は、一定期間内のメッセージ数とそれらのメッセージのサイズの両方を意味しています。 たとえば、次のようになります。
- スマートビルディングソリューション、サーモスタットは、通常、エレベーターよりも低い周波数でデータを報告します。
- コネクテッド車両ソリューションでは、車両カメラの記録データ メッセージは、通常、ナビゲーション テレメトリ メッセージよりも大きくなります。
メッセージの頻度が制限される場合は、サービスのインスタンスを増やして規模を拡大することを検討してください。 サイズ制限によりメッセージが制限される場合は、サービスのより大きなインスタンスへの拡張を検討してください。
テナント: 1 つのテナントのスケールは小さくできますが、テナントの数を乗算すると、すぐに拡張できます。
パフォーマンスと信頼性
テナントの分離
完全に共有されたソリューションには、うるさい隣人が存在する場合があります。 IoT Hub と IoT Central の場合、ノイズの多い近隣ノードによって HTTP 429 ("要求が多すぎます") 応答コードが生成される可能性があります。これは、連鎖的な影響を引き起こす可能性のあるハード エラーです。 詳細については、クォータとスロットリングに関する記事を参照してください。
完全なマルチテナント ソリューションでは、これらの影響がカスケードする場合があります。 お客様が IoT Hub または IoT Central アプリケーションを共有すると、共有インフラストラクチャ上のすべての顧客にエラーが発生します。 IoT Hub と IoT Central は通常、クラウドへのデータのエントリ ポイントであるため、このデータに依存する他のダウンストリーム システムでもエラーが発生する可能性があります。 多くの場合、これらのエラーの最も一般的な理由は、メッセージ クォータの制限を超えた場合です。 このような場合、IoT Hub ソリューションを最速かつ最も簡単に修正する方法は、IoT Hub SKU をアップグレードするか、IoT Hub ユニット数を増やすか、その両方を行うことです。 IoT Central ソリューションでは、記載されているサポートされるメッセージ数の上限まで、ソリューションは必要に応じて自動的にスケーリングされます。
DPS カスタム割り当てポリシーを使用することで、IoTのコントロール、管理、および通信プレーンそれぞれにわたりテナントを分離し、分配することができます。 さらに、
データ ストレージ、クエリ、使用、および保持
IoT ソリューションは、ストリーミング時と保存時の両方でデータを大量に消費する傾向があります。 マルチテナント ソリューションでのデータ管理の詳細については、「マルチテナント ソリューションでのストレージとデータのアーキテクチャ アプローチ」を参照してください。
セキュリティ
IoT ソリューションには多くの場合、複数のレイヤーでセキュリティに関する考慮事項があります。特に、クラウドで変更された Purdue Enterprise Reference Architecture または Industry 4.0 ソリューションにデプロイされるソリューションでは、注意が必要です。 選択した設計アプローチは、存在するネットワーク レイヤーと境界に影響します。物理設計を選択したら、セキュリティ実装を選択できます。 任意の方法で次のツールを使用できます。
Microsoft Defender for IoT は、顧客のデバイスやサイトごとに、デバイスごとの EIoT ライセンスと OT サイト ライセンスを提供する包括的な IoT 監視ソリューションであるため、使用を検討してください。 この記事の後半で選択した方法によっては、Microsoft 365 の名前付きユーザー ライセンス シナリオが不可能な場合があります。 その場合、Microsoft 365 テナント ライセンスに依存しないライセンス オプションとして、デバイスごとのライセンス オプションとサイト ライセンス オプションを使用できます。
ネットワーク レイヤーの分離とネットワーク トラフィックの監視を行うために、Azure Firewall または Microsoft 以外のファイアウォール アプライアンスの使用を検討してください。 この記事で後述するように、方法の正確な選択によって、ワークロードのネットワーク分離と共有ネットワークの比較が決まります。
これらのセキュリティ トピックのほとんどは、シングル テナント ソリューションの場合と同様に、マルチテナント ソリューションにも適用され、バリエーションは選択したアプローチに関連付けられています。 IoT ソリューション全体で大きく異なる可能性が高いコンポーネントの 1 つは、ユーザー ID とアプリケーション ID です。 マルチテナント ソリューションでの ID のアーキテクチャに関するアプローチでは、一般的なマルチテナント ソリューションのこの側面について説明します。
考慮すべきアプローチ
管理、インジェスト、処理、ストレージ、セキュリティなどの主要コンポーネントの考慮事項と選択肢は、単一およびマルチテナント IoT ソリューションでも同じです。 主な違いは、マルチテナントをサポートするためにコンポーネントをどのように配置し、活用するかです。 たとえば、次の一般的な決定ポイントがあります。
- ストレージは、SQL Server または Azure Data Explorer の使用を選択する場合があります。
- インジェストと管理のレベルは、IoT Hub と IoT Central のどちらかを選択することです。
ほとんどの IoT ソリューションは、デプロイ ターゲット、テナント モデル、デプロイ パターンを組み合わせたルート アーキテクチャ パターンに適合しています。 前述の主な要件と考慮事項によって、これらの要因が決まります。
IoT 空間内での決定を要する最大の判断ポイントの 1 つは、サービスとしてのアプリケーション プラットフォーム (aPaaS) アプローチとサービスとしてのプラットフォーム (PaaS) アプローチのどちらかを選択することです。 詳細については、「モノのインターネット (IoT) ソリューションアプローチの比較 (PaaS と aPaaS) の比較」を参照してください。
この選択は、多くの組織が多くのプロジェクトで直面する一般的な "ビルドと購入" のジレンマです。 両方の選択肢の長所と短所を評価することが重要です。
aPaaS ソリューションの概念と考慮事項
Azure IoT Central をソリューションの中核として使用する一般的な aPaaS ソリューションでは、次の Azure PaaS サービスおよび aPaaS サービスを使用できます。
- Azure Event Hubs。クロスプラットフォームのエンタープライズ グレード メッセージングおよびデータフロー エンジンとして使用されます。
- Azure Logic Apps。サービスとしての統合プラットフォーム (iPaaS) オファリングとして使用されます。
- Azure Data Explorer。Data Analytics プラットフォームとして使用されます。
- Power BI。視覚化とレポートのプラットフォームとして使用されます。
上の図では、テナントは IoT Central 環境、Azure Data Explorer、Power BI、および Azure Logic Apps を共有しています。
このアプローチは、通常、市場にソリューションを最も迅速に投入できる方法です。 これは、組織を使用することによってマルチテナント機能をサポートする高スケールのサービスです。
IoT Central は aPaaS オファリングであるため、実装者の制御外にある特定の決定があることを理解しておくことが重要です。 そのような決定事項には次のものが含まれます。
- IoT Central では、ID プロバイダーとして Microsoft Entra ID が使用されます。
- IoT Central のデプロイは、宣言型ドキュメントと命令型コードが組み合わされた、コントロール プレーンとデータ プレーンの両方の操作を使用して実現される。
- IoT Central ベースのマルチテナント パターンでのノードの最大制限 とツリーの深さの最大値は、サービス プロバイダーに複数の IoT Central インスタンスを強制的に割り当てさせる可能性があります。 この場合、デプロイ スタンプ パターンに従うことを検討する必要があります。
- IoT Central では、API 呼び出しの制限が適用され、大規模な実装に影響する可能性があります。
PaaS ソリューションの概念と考慮事項
PaaS ベースのアプローチでは、次の Azure サービスを使用できます。
- Azure IoT Hub。コア デバイス構成および通信プラットフォームとして使用されます。
- Azure IoT Device Provisioning Service。デバイスのデプロイと初期構成のプラットフォームとして使用されます。
- Azure Data Explorer。IoT デバイスからのウォーム パスとコールド パスの時系列データを格納および分析する目的で使用されます。
- Azure Stream Analytics。IoT デバイスからのホット パス データを分析する目的で使用されます。
- 、IoT Edge デバイスで人工知能 (AI)、Microsoft 以外のサービス、または独自のビジネス ロジックを実行するための Azure IoT Edge です。
上の図では、各テナントは共有された Web アプリに接続し、そのアプリが IoT Hub と関数アプリからのデータを受信しています。 デバイスは、Device Provisioning Service と IoT Hub に接続します。
このアプローチでは、aPaaS アプローチと比べて、ソリューションの作成、デプロイ、保守のために開発者により多くの作業が求められます。 実装者の便宜を図って事前に構築されている機能は少なくなります。 そのため、基になるプラットフォームに埋め込まれる前提条件が少なくなるため、この方法では制御が増えます。
ルート アーキテクチャ パターン
次の表に、マルチテナント IoT ソリューションの一般的なパターンを示します。 各パターンには、次の情報が含まれます。
- パターンの名前。これは、ターゲット、モデル、および展開の種類の組み合わせに基づいています。
- 配置ターゲット。これは、リソースの展開先となる Azure サブスクリプションを表します。
- テナント モデル。これは、マルチテナント モデルに関する記事で説明されているパターンによって参照されます。
- デプロイ パターン。これは、展開に関する考慮事項が最小限のシンプルな展開、Geode パターン、またはデプロイ スタンプ パターンを指します。
| Pattern | 配置ターゲット | テナント モデル | デプロイ パターン |
|---|---|---|---|
| 単純な SaaS | サービス プロバイダーのサブスクリプション | 完全マルチテナント | シンプル |
| 水平 SaaS | サービス プロバイダーのサブスクリプション | 水平方向にパーティション分割 | デプロイ スタンプ |
| シングル テナント自動 | サービス プロバイダーか顧客のサブスクリプション | 顧客ごとに 1 テナント | シンプル |
単純な SaaS
| 配置ターゲット | テナント モデル | デプロイ パターン |
|---|---|---|
| サービス プロバイダーのサブスクリプション | 完全マルチテナント | シンプル |
単純な SaaS アプローチは、SaaS IoT ソリューションの最も単純な実装方法です。 上の図に示されているように、このインフラストラクチャはすべて共有され、地理的スタンプやスケールのスタンプはインフラストラクチャに適用されません。 多くの場合、このインフラストラクチャは 1 つの Azure サブスクリプション内に存在します。
Azure IoT Central では、組織の概念がサポートされています。 組織を使用すると、ソリューション プロバイダーは、すべてのテナント間で基本的なアプリケーション設計を共有しながら、安全かつ階層的な方法でテナントを簡単に分離できます。
長期的なデータ分析などの IoT Central 以外のシステムとの通信は、コールド パスまたは事業運営との接続性に従って、他の Microsoft PaaS および aPaaS オファリングを通じて行われます。 これらの他の提案には、次のサービスが含まれる場合があります。
- Azure Event Hubs。クロスプラットフォームのエンタープライズ グレード メッセージングおよびデータフロー エンジンとして使用されます。
- Azure Logic Apps。サービスとしての統合プラットフォーム (iPaaS) として使用されます。
- Azure Data Explorer。Data Analytics プラットフォームとして使用されます。
- Power BI。視覚化とレポートのプラットフォームとして使用されます。
単純な SaaS アプローチをシングル テナント自動 aPaaS モデルと比較すると、多くの特性が似ています。 2 つのモデルの主な違いは、次の点です。
- シングル テナント自動化 モデルでは、テナントごとに個別の IoT Central インスタンスをデプロイします。
- Simple SaaS with aPaaS モデルでは、複数の顧客の共有インスタンスをデプロイし、テナントごとに IoT Central 組織を作成します。
このモデルではマルチテナント データ層を共有するため、顧客データを分離するために行レベルのセキュリティを実装する必要があります。 詳細については、「マルチテナント ソリューションのストレージとデータのアーキテクチャアプローチを参照してください。
利点:
- ここで説明する他のアプローチと比べて、管理と操作が容易である。
リスク:
このアプローチでは、多くのデバイス、メッセージ、テナントにスケーリングするのが困難な場合がある。
サービスとコンポーネントは共有されるため、すべてのコンポーネントで障害が発生すると、すべてのテナントに影響する可能性があります。 このリスクは、ソリューションの信頼性と高可用性に対するリスクです。
デバイスのサブフリートのコンプライアンス、運用、テナントのライフサイクル、セキュリティを管理する方法を検討することが重要です。 これらの考慮事項は、制御、管理、通信の各プレーンでこのソリューションの種類に共通する性質のために重要になります。
水平 SaaS
| 配置ターゲット | テナント モデル | デプロイ パターン |
|---|---|---|
| サービス プロバイダーのサブスクリプション | 水平方向にパーティション分割 | デプロイ スタンプ |
一般的なスケーラビリティ アプローチは、ソリューションを水平方向にパーティション分割することです。 これは、共有コンポーネントと顧客ごとのコンポーネントがそれぞれいくつか存在することを意味しています。
IoT ソリューション内には、水平方向にパーティション分割できる多くのコンポーネントが存在します。 水平方向にパーティション分割されたサブシステムは、通常、より大きなソリューションと統合するデプロイ スタンプ パターンを使用して配置されます。
水平 SaaS の例
次のアーキテクチャの例では、エンド カスタマーごとに IoT Central をパーティション分割します。これは、デバイス管理、デバイス通信、管理ポータルとして機能します。 多くの場合、このパーティション分割は、ソリューションを使用するエンド カスタマーが、ソフトウェア ベンダーの介入なしに、デバイスの追加、削除、更新を完全に制御できるように行われます。 ソリューションの残りの部分は、ホット パス分析、ビジネス統合、SaaS 管理、およびデバイス分析のニーズを解決する標準的な共有インフラストラクチャ パターンに従っています。
各テナントには独自の IoT Central 組織があります。これにより、テレメトリが共有関数アプリに送信され、Web アプリを介してテナントのビジネス ユーザーが利用できるようになります。
利点:
- 管理と運用は簡単ですが、シングルテナント コンポーネントには追加の管理が必要になる場合があります。
- 柔軟なスケーリング オプション。レイヤーは必要に応じてスケーリングされます。
- コンポーネントの障害の影響が軽減されます。 共有コンポーネントの障害はすべての顧客に影響しますが、水平方向にスケーリングされたコンポーネントは、特定のスケール インスタンスに関連付けられているお客様にのみ影響します。
- パーティション分割されたコンポーネントに対する、テナントごとの消費分析情報が向上する。
- パーティション分割されたコンポーネントにより、テナントごとのカスタマイズが簡単になる。
リスク:
- ソリューションのスケール (特に共有コンポーネントの場合)。
- 信頼性と高可用性が影響を受ける可能性があります。 共有コンポーネントで 1 つの障害が発生すると、一度にすべてのテナントに影響する可能性がある。
- テナントごとのパーティション分割されたコンポーネントのカスタマイズに、長期的な DevOps および管理に関する考慮事項を検討する必要がある。
水平パーティション分割に適した最も一般的なコンポーネントを次に示します。
データベース
データベースをパーティション分割できます。 多くの場合、このデータベースは、パーティション分割されているテレメトリとデバイスのデータ ストアです。 たいてい、ウォーム ストレージとアーカイブ ストレージなどの異なる特定の目的や、テナント サブスクリプションの状態情報のために複数のデータ ストアが使用されます。
テナントごとにデータベースを分離することで、次の利点が得られます。
- コンプライアンス標準をサポートする。 各テナントのデータは、データ ストアのインスタンス間で分離されます。
- うるさい隣人の問題を軽減する。
デバイスの管理、通信、管理
Azure IoT Hub Device Provisioning Service、IoT Hub、IoT Central アプリケーションは、多くの場合、水平方向にパーティション分割されたコンポーネントとしてデプロイできます。 この方法では、その特定のテナントの管理、制御、テレメトリ プレーンの適切な DPS インスタンスにデバイスをリダイレクトするための別のサービスが必要です。 詳細については、Azure IoT ソリューションをスケールアウトして、ホワイトペーパー 数百万台のデバイスをサポートする方法に関するページを参照してください。
多くの場合、このアプローチは、より直接的かつ完全に分離されたデバイスの独自のフリートをエンド カスタマーが管理および制御できるようにするために行われます。
デバイス通信プレーンが水平方向にパーティション分割されている場合は、ソース テナントを識別するデータでテレメトリ データをエンリッチする必要があります。 このエンリッチメントにより、ストリーム プロセッサは、データ ストリームに適用するテナント ルールを認識できます。 たとえば、テレメトリ メッセージがストリーム プロセッサで通知を生成する場合、ストリーム プロセッサは、関連付けられているテナントの適切な通知パスを決定する必要があります。
ストリーム処理
ストリーム処理をパーティション分割することにより、ストリーム プロセッサ内の分析をテナントごとにカスタマイズできるようになります。
シングル テナント自動
シングル テナントの自動アプローチは、エンタープライズ ソリューションと同様の意思決定プロセスと設計に基づいています。
各テナントには、同一の分離された環境がそれぞれ独自に設けられ、専用の IoT Central 組織と他のコンポーネントがそれらに割り当てられます。
| 配置ターゲット | テナント モデル | デプロイ パターン |
|---|---|---|
| サービス プロバイダーか顧客のサブスクリプション | 顧客ごとに 1 テナント | シンプル |
このアプローチの重要な判断ポイントは、コンポーネントのデプロイ先となる Azure サブスクリプションの選択です。 開発者がコンポーネントを自分のサブスクリプションにデプロイする場合、ソリューションのコストの制御や可視性は向上しますが、そのソリューションのセキュリティとガバナンスに関して、開発者が対処する必要のある懸念事項も多くなります。 逆に、ソリューションが顧客のサブスクリプションにデプロイされる場合、そのデプロイのセキュリティとガバナンスについて、顧客が最終的な責任を負うことになります。
テナントとサブスクリプションの要件は通常、ほとんどのソリューションの制限要因であるため、このパターンは高度なスケーラビリティをサポートします。 そのため、各テナントを分離すると、ソリューション開発者側では多くの労力を割かなくても、各テナントのワークロードをさまざまな規模でスケーリングすることが可能になります。
また、顧客の地域に基づいてソリューション コンポーネントをデプロイできるため、一般に、このパターンは他のパターンと比較して待機時間が短くなります。 地理的アフィニティにより、IoT デバイスと Azure デプロイの間のネットワーク パスを短くすることができます。
必要に応じて、既存または新しい地域でソリューションの追加インスタンスを迅速にデプロイできるようにすることで、自動化されたデプロイを拡張して待機時間やスケールの向上をサポートできます。
シングル テナント自動アプローチは、単純な SaaS aPaaS モデルと似ています。 2 つのモデルの主な違いは、シングル テナント自動アプローチでは、テナントごとに個別の IoT Central インスタンスをデプロイするのに対し、aPaaS を使用する単純な SaaS モデルでは、複数の IoT Central 組織が設定された IoT Central の共有インスタンスをデプロイする点です。
利点:
- 管理と操作が簡単です。
- テナントの分離が保証されます。
リスク:
- 新しい開発スタッフにとって、最初の自動化が複雑になる場合がある。
- より高いレベルでデプロイを管理するため、顧客間資格情報のセキュリティを適用する必要がある。そうしないと、侵害が顧客全体に及ぶ恐れがあります。
- 顧客間の共有インフラストラクチャのスケールメリットを利用できないため、コストが高くなると予想されます。
- 各インスタンスのメンテナンスをソリューションプロバイダーが所有している場合、多くのインスタンスを維持する必要があります。
SaaS のスケールを増やす
ソリューションの規模を大規模なデプロイに拡張する場合、サービスの制限、地理的な懸念、その他の要因に基づいて発生する特定の課題があります。 大規模な IoT デプロイ アーキテクチャの詳細については、「Azure IoT ソリューションをスケールアウトして、数百万台のデバイスをサポートする」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Michael C. Bazarewsky | FastTrack for Azure のシニア カスタマー エンジニア
- David Crook | FastTrack for Azure のプリンシパル カスタマー エンジニア
その他の共同作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
次の手順
- 「マルチテナント機能と Azure Cosmos DB」のガイダンスを確認する。
- 「Azure 上で IoT を使用したホット、ウォーム、コールド データ パス」について学習する。