マルチテナント ソリューションの IoT のアーキテクチャに関するアプローチ

マルチテナント IoT ソリューションには、さまざまな種類とサイズがあります。 ユーザーには、インフラストラクチャの所有権から顧客データの分離やコンプライアンスに至るまで、さまざまな要件と制約がある場合があります。 これらの設計上の制約すべてを満たすパターンを定義することは困難な場合があり、多くの場合、そのために複数のディメンションを考慮することが必要になります。 この記事では、IoT ベース ソリューションのマルチテナント機能に関する考慮事項を解決するためによく使用されるいくつかのアプローチについて説明します。 このドキュメントには、IoT 参照アーキテクチャに従って共通コンポーネントを利用するマルチテナント アーキテクチャの例が含まれています。

主な考慮事項と要件

次の考慮事項と要件は、ソリューション設計のための一般的な優先度付けの順序に従って示されています。

ガバナンスとコンプライアンス

ガバナンスとコンプライアンスに関する考慮事項では、特定のパターンまたは一連の 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 ソリューションのガイダンスに従うと、DPS ロード バランサー レベルで追加の割り当て配布を管理できます。

データ ストレージ、クエリ、使用、および保持

IoT ソリューションは、ストリーミング時も保存時も大量のデータを集中的に使用する傾向があります。 マルチテナント ソリューションでのデータ管理の詳細については、「マルチテナント ソリューションでのストレージとデータのアーキテクチャ アプローチ」を参照してください。

セキュリティ

IoT ソリューションには多くの場合、複数のレイヤーでセキュリティに関する考慮事項があります。特に、クラウドで変更された Purdue Enterprise Reference Architecture または Industry 4.0 ソリューションにデプロイされるソリューションでは、注意が必要です。 以下から選択した設計アプローチは、存在するネットワーク レイヤーと境界に影響します。物理設計を選択すると、セキュリティの実装を選択できます。 どのアプローチでも使用できるツールは次のとおりです。

• Microsoft Defender for IoT は、顧客のデバイスやサイトごとに、デバイスごとの EIoT ライセンスと OT サイト ライセンスを提供する包括的な IoT 監視ソリューションであるため、使用を検討してください。 この記事の後半で選択したアプローチによっては、Microsoft 365 の名前付きユーザー ライセンスのシナリオが該当しない場合があります。 その場合、Microsoft 365 テナント ライセンスに依存しないライセンス オプションとして、デバイスごとのライセンス オプションとサイト ライセンス オプションを使用できます。

• ネットワーク レイヤーの分離とネットワーク トラフィックの監視を行うために、Azure Firewall またはサードパーティ製のファイアウォール アプライアンスの使用を検討してください。 次に示すように、どのアプローチを選択するかによって、ワークロードがネットワークから分離されるか、ネットワークと共有されるかに影響します。

• デバイスを直接インターネット アクセスに公開することなく、Azure でホストされるサービスへのデバイス接続の一部とするには、Azure IoT Edge または Azure IoT Operations の使用を検討してください。 現時点で Azure IoT Operations はプレビュー段階であるため、このドキュメントには、当該サービスの一般的な使用方法について記載しません。 今後のドキュメントの改訂で、この件に対処する予定です。

これらのセキュリティ トピックのほとんどは、シングル テナント ソリューションの場合と同様に、マルチテナント ソリューションにも適用され、バリエーションは選択したアプローチに関連付けられています。 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 デバイスからのホット パス データを分析する目的で使用されます。
• Azure IoT Edge。人工知能 (AI)、サード パーティーのサービス、または独自のビジネス ロジックを 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 インスタンスをデプロイするのに対し、aPaaS を使用する単純な SaaS モデルでは、代わりに複数の顧客のために共有インスタンスをデプロイし、テナントごとに IoT Central 組織を作成する点です。

このモデルではマルチテナント化されたデータ層を共有するので、顧客データを分離するために、「マルチテナント ソリューションでのストレージとデータのアーキテクチャ アプローチ」の説明に従って行レベルのセキュリティを実装する必要があります。

利点:

• ここで説明する他のアプローチと比べて、管理と操作が容易である。

リスク:

• このアプローチでは、非常に多くのデバイス、メッセージ、テナントにスケーリングするのが困難な場合がある。

• すべてのサービスとコンポーネントが共有されているため、いずれかのコンポーネントの障害がすべてのテナントに影響を与える可能性がある。 これは、ソリューションの信頼性と高可用性へのリスクとなります。

• コンプライアンス、運用、テナントのライフサイクル、デバイスのサブフリートのセキュリティを管理する方法を検討することが重要です。 これらの考慮事項は、制御、管理、通信の各プレーンでこのソリューションの種類に共通する性質のために重要になります。

水平 SaaS

配置ターゲット	テナント モデル	デプロイ パターン
サービス プロバイダーのサブスクリプション	水平方向にパーティション分割	デプロイ スタンプ

一般的なスケーラビリティ アプローチは、ソリューションを水平方向にパーティション分割することです。 これは、共有コンポーネントと顧客ごとのコンポーネントがそれぞれいくつか存在することを意味しています。

IoT ソリューション内には、水平方向にパーティション分割できる多くのコンポーネントが存在します。 水平方向にパーティション分割されたサブシステムは、通常、より大きなソリューションと統合するデプロイ スタンプ パターンを使用して配置されます。

水平 SaaS の例

次のアーキテクチャ例では、デバイス管理、デバイス通信、および管理ポータルに使用する IoT Central を、エンド カスタマーごとにパーティション分割します。 多くの場合、これは、ソリューションを使用するエンド カスタマーが、ソフトウェア ベンダーの介入なしに、デバイス自体の追加、削除、更新を完全に制御できる方法で行われます。 ソリューションの残りの部分は、ホット パス分析、ビジネス統合、SaaS 管理、およびデバイス分析のニーズを解決する標準的な共有インフラストラクチャ パターンに従っています。

各テナントには独自の IoT Central 組織があります。これにより、テレメトリが共有関数アプリに送信され、Web アプリを介してテナントのビジネス ユーザーが利用できるようになります。

利点:

• 一般に、管理や操作が簡単である。ただし、シングルテナント コンポーネントのための追加の管理が必要になる場合があります。
• 柔軟なスケーリング オプション。レイヤーは必要に応じてスケーリングされます。
• コンポーネントの障害の影響を軽減できる。 共有コンポーネントの障害がすべての顧客に影響するのに対して、水平方向にスケーリングされたコンポーネントは、特定のスケール インスタンスに関連付けられている顧客にのみ影響します。
• パーティション分割されたコンポーネントに対する、テナントごとの消費分析情報が向上する。
• パーティション分割されたコンポーネントにより、テナントごとのカスタマイズが簡単になる。

リスク:

• 特に共有コンポーネントについて、ソリューションのスケールを考慮する必要がある。
• 信頼性と高可用性に影響が及ぶ可能性がある。 共有コンポーネントで 1 つの障害が発生すると、一度にすべてのテナントに影響する可能性がある。
• テナントごとのパーティション分割されたコンポーネントのカスタマイズに、長期的な DevOps および管理に関する考慮事項を検討する必要がある。

水平パーティション分割に特に適した最も一般的なコンポーネントを次に示します。

データベース

データベースをパーティション分割できます。 多くの場合、このデータベースは、パーティション分割されているテレメトリとデバイスのデータ ストアです。 たいてい、ウォーム ストレージとアーカイブ ストレージなどの異なる特定の目的や、テナント サブスクリプションの状態情報のために複数のデータ ストアが使用されます。

テナントごとにデータベースを分離することで、次の利点が得られます。

• コンプライアンス標準をサポートする。 各テナントのデータは、データ ストアのインスタンス間で分離されます。
• うるさい隣人の問題を軽減する。

デバイスの管理、通信、管理

Azure IoT Hub Device Provisioning Service、IoT Hub、IoT Central アプリケーションは、多くの場合、水平方向にパーティション分割されたコンポーネントとしてデプロイできます。 このアプローチに従う場合は、その特定のテナントの管理、制御、テレメトリ プレーンのために、デバイスを適切な Device Provisioning Service にリダイレクトする追加のサービスが必要です。 詳細については、「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 | FastTrack for Azure のプリンシパル カスタマー エンジニア
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

次の手順

• 「マルチテナント機能と Azure Cosmos DB」のガイダンスを確認する。
• 「Azure 上で IoT を使用したホット、ウォーム、コールド データ パス」について学習する。
• 「Azure IoT 参照アーキテクチャ」を参照する。
• デプロイ スタンプを使用した IoT ソリューションのスケーリング方法に関するドキュメントを確認する。