次の方法で共有

テナント統合とデータ アクセスのアーキテクチャに関するアプローチ

  • [アーティクル]

一般的には、システムは組織の境界を越えて統合します。 マルチテナント ソリューションを構築するときに、テナントのシステムとデータを送受信する要件がある場合があります。 この記事では、マルチテナント ソリューションの統合を設計および開発するための主な考慮事項とアプローチについて説明します。

注意

複数の統合ポイントを指定する場合は、それぞれを個別に検討することをお勧めします。 多くの場合、異なる統合ポイントごとに異なる要件があり、さまざまな方法で同じシステムを接続している場合でも、その設計は異なります。

主な考慮事項と要件

データ フローの方向

データが流れる方向を理解することが重要です。 データ フローの方向は、ID の管理方法やソリューションのネットワーク トポロジなど、アーキテクチャのいくつかの側面に影響します。 一般的には、次の 2 つのデータ フローがあります。

  • エクスポート。データがマルチテナント システムから個々のテナントのシステムに流れることを意味します。
  • インポート。データがテナントのシステムからマルチテナント システムに流れることを意味します。

また、ネットワーク データ フローの方向を考慮することも重要です。これは、必ずしも論理的なデータ フローの方向に対応しません。 たとえば、テナントのシステムからデータをインポートできるように、テナントへの送信接続を開始する場合もあります。

フルまたはユーザー委任アクセス

多くのシステムでは、特定のデータへのアクセスは特定のユーザーに制限されています。 あるユーザーがアクセスできるデータは、別のユーザーがアクセスできるデータと同じではない場合があります。 完全なデータ セットを使用するか、またはインポートまたはエクスポートするデータ セットが特定ユーザーのアクセス許可の有無に基づいているかを考慮することが重要です。

たとえば、お客様が所有するデータ ストア上でレポートとビジネス インテリジェンスを提供するマルチテナント サービスである Microsoft Power BI の場合を考えます。 Power BI を構成するときは、データベース、API、その他のデータ ストアからデータをプルするように "データ ソース" を構成します。 データ ストアは、次の 2 つの異なる方法で構成できます。

  • 基になるデータ ストアからすべてのデータをインポートします。 このアプローチでは、データ ストア全体にアクセスできる ID の資格情報を Power BI に提供する必要があります。 その後、Power BI 管理者は、Power BI へのインポート後に、インポートしたデータに対してアクセス許可を個別に構成できます。 Power BI によってアクセス許可が適用されます。
  • ユーザーのアクセス許可に基づいて、基になるデータ ストアからデータのサブセットをインポートします。 ユーザーは、データ ソースを作成するときに、資格情報および関連付けられたアクセス許可を使用します。 Power BI によってインポートされるデータの正確なサブセットは、データ ソースを作成したユーザーのアクセス レベルによって異なります。

どちらの方法にも有効なユース ケースがあるため、テナントの要件を明確に理解することが重要です。

データ・セット全体を使用する場合、ソース・システムは宛先システムを実質的に "信頼できるサブシステム" として扱います。 この種の統合では、ユーザー ID ではなく "ワークロード ID" の使用を検討する必要もあります。 ワークロード ID は、1 人のユーザーに対応しないシステム ID です。 ワークロード ID には、ソース システム内のデータに対する高レベルのアクセス許可が付与されます。

または、ユーザー スコープのデータを操作する場合は、"委任" などのアプローチを使用して、データ セットからデータの正しいサブセットにアクセスすることが必要な場合があります。 これにより、宛先システムは、実質的に特定のユーザーと同じアクセス許可を取得します。 ユーザー委任の詳細については、以下の「委任されたユーザー アクセス」アプローチを参照してください。 委任を使用する場合は、ユーザーがプロビジョニング解除されたり、アクセス許可が変更されたりするシナリオを処理する方法を検討します。

リアルタイムまたはバッチ

リアルタイム データを使用するか、データをバッチで送信するかを検討します。

リアルタイム統合の場合、次の方法が一般的です。

  • 要求と応答では、クライアントがサーバーへの要求を開始し、応答を受信します。 通常、要求と応答の統合は API または Webhook を使用して実装されます。 要求は "同期的" であり、受信確認と応答を待機します。 または、非同期の要求-応答パターンなどを使用して応答を待機して、要求を"非同期" にすることもできます。
  • 疎結合通信は、多くの場合、システムを疎結合するように設計されたメッセージング コンポーネントを介して有効化されます。 たとえば、Azure Service Bus はメッセージ キュー機能を提供し、Azure Event Grid と Event Hubs はイベント機能を提供します。 これらのコンポーネントは、多くの場合、統合アーキテクチャの一部として使用されます。

一方、バッチ統合は、多くの場合、バックグラウンド ジョブを通じて管理されます。これは、1 日の特定の時間にトリガーされる場合があります。 一般的に、バッチ統合は、交換されるデータ セットが大きい可能性があるため、BLOB ストレージ コンテナーなどの "ステージングの場所" を介して行われます。

データ ボリューム

統合を通じて交換するデータの量を理解することが重要です。この情報は、全体的なシステムの容量を計画するのに役立つからです。 システムの容量を計画するときは、テナントが異なると交換するデータの量も異なる場合があることに注意してください。

リアルタイム統合の場合は、指定した期間におけるトランザクション数として量を測定できます。 バッチ統合の場合は、交換されたレコードの数またはバイト単位のデータ量として量を測定できます。

データ形式

データが 2 つの当事者間でやり取りされる場合は、両者ともデータの書式設定と構造化方法を明確に理解することが重要です。 データ形式の次の部分について考えてみます。

  • ファイル形式 (JSON、Parquet、CSV、XML など)。
  • スキーマ (含まれるフィールドの一覧、日付形式、フィールドの NULL 値の許容など)。

マルチテナント システムを使用する場合は、可能であれば、すべてのテナントで同じデータ形式を標準化して使用することをお勧めします。 そうすることで、各テナントの要件に合わせて統合コンポーネントをカスタマイズして再テストする必要がなくなります。 ただし、状況によっては、異なるテナントとの通信に異なるデータ形式を使用する必要があるため、複数の統合を実装することが必要になる場合があります。 このような状況を簡素化するために役立つアプローチについては、「コンポーザブルな統合コンポーネント」セクションを参照してください。

テナントのシステムへのアクセス

一部の統合では、テナントのシステムまたはデータ ストアに接続する必要があります。 テナントのシステムに接続するときは、接続のネットワークと ID の両方のコンポーネントを慎重に検討する必要があります。

ネットワーク アクセス

テナントのシステムにアクセスするためのネットワーク トポロジを検討します。これには、次のオプションが含まれる場合があります。

  • インターネット経由で接続します。 インターネット経由で接続する場合、接続の保護方法とデータの暗号化方法はどうなるでしょうか。 テナントで IP アドレスに基づいて制限することを計画している場合は、ソリューションで使用される Azure サービスが送信接続の静的 IP アドレスをサポートできることを確認します。 たとえば、NAT Gateway を使用して、必要に応じて静的 IP アドレスを指定することを検討します。 VPN が必要な場合は、テナントと安全にキーを交換する方法を検討してください。
  • テナントの環境にデプロイされるエージェントは、柔軟なアプローチを提供でき、テナントが受信接続を許可する必要性を回避するのに役立ちます。
  • リレー (Azure Relay など) も受信接続を回避するためのアプローチを提供します。

詳細については、マルチテナントのネットワーク アプローチに関するガイダンスを参照してください。

認証

接続を開始するときに、各テナントで認証する方法を検討します。 次のアプローチを検討します。

  • API キーや証明書などのシークレット。 テナントの資格情報を安全に管理する方法を計画することが重要です。 テナントのシークレットが漏えいすると、重大なセキュリティ インシデントが発生し、多くのテナントに影響する恐れがあります。
  • Microsoft Entra トークンでは、テナント独自の Microsoft Entra ディレクトリによって発行されたトークンを使用します。 トークンは、マルチテナント Microsoft Entra アプリケーションの登録または特定のサービス プリンシパルを使用して、ワークロードに直接発行される場合があります。 または、ワークロードでは、テナントのディレクトリ内の特定のユーザーに代わってリソースにアクセスするための委任されたアクセス許可を要求することもできます。

どちらのアプローチを選択する場合でも、テナントが最小特権の原則に従っていることを確認し、システムに不要なアクセス許可を付与しないようにします。 たとえば、システムでテナントのデータ ストアからデータを読み取ることだけが必要な場合、システムが使用する ID に書き込みアクセス許可は不要です。

テナントからシステムへのアクセス

テナントからシステムに接続する必要がある場合は、専用の API またはその他の統合ポイントを提供することを検討します。これにより、ソリューションへの外部からのアクセスの一部としてモデル化できます。

状況によっては、Azure リソースへの直接アクセスをテナントに提供する場合があります。 その影響を慎重に検討し、より安全な方法でテナントにアクセス権を付与する方法を把握するようにします。 たとえば、次のようなアプローチがあります。

  • バレー キー パターンを使用します。Shared Access Signature などのセキュリティ対策を使用して、特定の Azure リソースへの制限付きアクセスを許可する必要があります。
  • 専用ストレージ アカウントなど、統合ポイントに専用リソースを使用します。 統合リソースをコア システム リソースから分離しておくことをお勧めします。 このアプローチは、セキュリティ インシデントの "影響範囲" を最小限に抑えるのに役立ちます。 これにより、テナントでリソースへの多数の接続が誤って開始され、その容量が使い果たされた場合でも、システムの残りの部分は引き続き実行されます。

コンプライアンス

テナントのデータを直接やり取りしたり、そのデータを送信したりするときは、テナントのガバナンスとコンプライアンスの要件を明確に理解することが重要です。

考慮すべきアプローチとパターン

API を公開する

通常、リアルタイム統合には、使用するテナントや他のパーティに API を公開する必要があります。 特に外部パーティが使用する場合は、API で特別な考慮が必要です。 次の質問について考えてみましょう。

  • API へのアクセス権が付与されているのは誰か。
  • API のユーザーをどのように認証するか。
  • API ユーザーが一定期間に行うことができる要求数に制限はあるか。
  • 各 API に関する情報とドキュメントをどのように提供するか。 たとえば、開発者ポータルを実装する必要があるか。

Azure API Management などの API ゲートウェイを使用して、これらの懸念事項やその他の多くの事項を処理することをお勧めします。 API ゲートウェイを使用すると、API が従うポリシーを実装する単一の場所が提供され、バックエンド API システムの実装が簡略化されます。 API Management がどのようにマルチテナント アーキテクチャをサポートするかについて詳しくは、「マルチテナント ソリューションで Azure API Management を使用する」を参照してください。

バレット キー パターン

Azure Storage などのデータ ソースにテナントが直接アクセスすることが必要な場合があります。 バレー キー パターンに従って、データを安全に共有し、データ ストアへのアクセスを制限することを検討してください。

たとえば、大きなデータ ファイルをバッチ エクスポートする場合に、このアプローチを使用できます。 エクスポート ファイルを生成したら、Azure Storage の BLOB コンテナーに保存し、読み取り専用の期限付き Shared Access Signature を生成できます。 この署名を BLOB URL と共にテナントに提供できます。 テナントでは、署名の有効期限が切れるまで Azure Storage からファイルをダウンロードできます。

同様に、特定の BLOB に書き込むアクセス許可を持つ Shared Access Signature を生成できます。 Shared Access Signature を提供すると、テナントではデータを BLOB に書き込むことができます。 Azure Storage の Event Grid 統合を使用すると、アプリケーションで通知を受け取り、データ ファイルを処理してインポートできます。

Webhooks

Webhook を使用すると、それによって提供される URL でテナントにイベントを送信できます。 送信する情報がある場合は、テナントの Webhook への接続を開始し、HTTP 要求ペイロードにデータを含めます。

独自の Webhook イベント システムを構築する場合は、CloudEvents 標準に従ってテナントの統合要件を簡略化することを検討します。

または、Azure Event Grid などのサービスを使用して、Webhook の機能を提供することもできます。 Event Grid は CloudEvents とネイティブに連携し、マルチテナント ソリューションに役立つイベント ドメインをサポートします。

注意

テナントのシステムへの送信接続を行う場合は常に、外部システムに接続していることを忘れないでください。 再試行パターン、サーキット ブレーカー パターン、バルクヘッド パターンの使用など、推奨されるクラウド プラクティスに従って、テナントのシステムの問題がシステムに伝達されないようにします。

委任されたユーザー アクセス

テナントのデータ ストアからデータにアクセスする場合は、特定のユーザーの ID を使用してデータにアクセスする必要があるかどうかを検討します。 必要である場合、統合には、ユーザーが持っているのと同じアクセス許可が適用されます。 このアプローチは、委任されたアクセスとよく呼ばれます。

たとえば、マルチテナント サービスがテナントのデータに対して機械学習モデルを実行するとします。 Azure Synapse Analytics、Azure Storage、Azure Cosmos DB など、各テナントのサービス インスタンスにアクセスする必要があります。 各テナントには独自の Microsoft Entra ディレクトリがあります。 この場合、特定のユーザーがアクセス可能なデータを取得できるように、データ ストアに委任されたアクセスをソリューションに付与できます。

データ ストアで Microsoft Entra 認証がサポートされている場合は、委任されたアクセスの方が簡単です。 多くの Azure サービスでは、Microsoft Entra ID がサポートされています。

たとえば、マルチテナント Web アプリケーションとバックグラウンド プロセスで、Microsoft Entra ID のテナントのユーザー ID を使用して Azure Storage にアクセスする必要があるとします。 次の手順を実行できます。

  1. ソリューションを表すマルチテナント Microsoft Entra アプリケーション登録を作成します。
  2. サインインしているユーザーとして Azure Storage にアクセスするための委任されたアクセス許可をアプリケーションに付与します。
  3. Microsoft Entra ID を使用してユーザーを認証するようにアプリケーションを構成します。

ユーザーがサインインした後、Microsoft Entra ID によって、ユーザーの代わりに Azure Storage にアクセスするために使用できる有効期間の短いアクセス トークンがアプリケーションに発行され、有効期間の長い更新トークンも発行されます。 バックグラウンド プロセスが新しいアクセス トークンを取得し、ユーザーの代わりに引き続き Azure Storage にアクセスできるように、システムで更新トークンを安全に格納する必要があります。

メッセージング

メッセージングを使用すると、システムまたはコンポーネント間の非同期の疎結合通信が可能になります。 一般的に、メッセージングは、ソースと宛先のシステムを切り離す統合シナリオで使用されます。 メッセージングとマルチテナントの詳細については、「マルチテナント ソリューションにおけるメッセージングのアーキテクチャ アプローチ」を参照してください。

テナントのシステムとの統合の一環としてメッセージングを使用する場合は、Azure Service Bus または Azure Event Hubs に Shared Access Signature を使用する必要があるか検討します。 Shared Access Signature を使用すると、メッセージング サブシステムの残りの部分にアクセス可能にすることなく、メッセージング リソースへの制限付きアクセスをサード パーティに付与できます。

シナリオによっては、テナントごとに異なるサービス レベル アグリーメント (SLA) またはサービスの品質 (QoS) の保証を提供する場合があります。 たとえば、あるテナントのサブセットでは、データ エクスポート要求をより迅速に処理することが想定されている場合があります。 優先順位キュー パターンを使用すると、異なるワーカー インスタンスで、優先順位のレベルごとに個別のキューを作成し、それに応じて優先順位を付けることができます。

コンポーザブルな統合コンポーネント

それぞれ異なるデータ形式や異なる種類のネットワーク接続を使用する、多数の異なるテナントと統合することが必要な場合もあります。

統合の一般的なアプローチは、次の種類のアクションを実行する個々のステップをビルドしてテストすることです。

  • データ ストアからデータを取得します。
  • データを特定の形式またはスキーマに変換します。
  • 特定のネットワーク トランスポートを使用して、または既知の宛先の種類にデータを送信します。

通常は、Azure Functions や Azure Logic Apps などのサービスを使用して、これらの個々の要素を構築します。 次に、Logic Apps や Azure Data Factory などのツールを使用して、統合プロセス全体を定義し、定義済みの各手順を呼び出します。

複雑なマルチテナント統合シナリオに取り組む場合は、再利用可能な統合手順のライブラリを定義すると便利です。 その後、各テナントのワークフローを構築し、そのテナントの要件に基づいて、該当する部分をまとめて構成できます。 または、一部のデータ セットまたは統合コンポーネントをテナントに直接公開して、そこから独自の統合ワークフローを構築できるようにすることもできます。

同様に、異なるデータ形式や異なるトランスポートを使用するテナントから他のテナントにデータをインポートすることが必要になる場合があります。 このシナリオでは、テナント固有の "コネクタ" を構築することをお勧めします。 コネクタは、標準化された形式と場所にデータを正規化してインポートし、メインの共有インポート プロセスをトリガーするワークフローです。

テナント固有のロジックまたはコードを構築する必要がある場合は、破損対策レイヤー パターンに従うことを検討します。 このパターンは、テナント固有のコンポーネントをカプセル化するのに役立ちます。ソリューションの残りの部分では、追加された複雑さが認識されません。

階層化された価格モデルを使用すると、低い価格レベルのテナントに対して、データ形式とトランスポートのセットが制限された標準的なアプローチに従うことを要求できます。 価格レベルが高いほど、提供する統合コンポーネントのカスタマイズや柔軟性が向上する可能性があります。

回避すべきアンチパターン

  • プライマリ データ ストアをテナントに直接公開する。 テナントがプライマリ データ ストアにアクセスすると、それらのデータ ストアのセキュリティ保護が困難になり、ソリューションに影響するパフォーマンスの問題が誤って発生する可能性があります。 データ ストアの資格情報を顧客に提供することは避けてください。また、プライマリ データベースから同じデータベース システムの顧客の読み取りレプリカにデータを直接複製しないでください。 代わりに、専用の統合データ ストアを作成し、バレー キー パターンを使用してデータを公開します。
  • API ゲートウェイを使用せずに API を公開する。 API には、アクセス制御、課金、使用状況測定に関する特定の懸念事項があります。 API ポリシーを最初に使用する予定がない場合でも、API ゲートウェイを早期に含めておくことをお勧めします。 そうすることで、今後 API ポリシーをカスタマイズする必要がある場合に、サード パーティが使用する URL に重大な変更を加える必要はありません。
  • 不必要な密結合。 メッセージング アプローチの使用など、疎結合には、セキュリティ、パフォーマンスの分離、回復性に関するさまざまな利点があります。 可能であれば、サード パーティとの統合を疎結合することをお勧めします。 サード パーティと密結合する必要がある場合は、再試行パターン、サーキット ブレーカー パターン、バルクヘッド パターンなどの適切なプラクティスに従ってください。
  • 特定のテナントのカスタム統合。 テナント固有の機能やコードにより、ソリューションのテストが困難になる場合があります。 また、多くのコード パスを理解する必要があるため、今後ソリューションを変更することが困難になります。 代わりに、特定のテナントの要件を抽象化するコンポーザブル コンポーネントを構築し、同様の要件を持つ複数のテナントで再利用してみてください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • John Downs | プリンシパル ソフトウェア エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

その他の共同作成者:

  • Will Velida | カスタマー エンジニア 2、FastTrack for Azure

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

「マルチテナント ソリューションにおけるメッセージングのアーキテクチャ アプローチ」を確認します。