Azure Data Explorer でのマルチテナントの概念は、異なるテナントにサービスを提供し、そのデータを 1 つのクラスターに格納することを指します。
テナントは、顧客、ユーザーのグループ、またはテナントの境界に沿ってデータを分離する必要があるユーザーの分類を表すことができます。 複数のテナントを持つ複数のアプリケーションなど、マルチレベルのマルチテナント シナリオを作成することもできます。 このシナリオはこの記事では取り上げませんが、同様の原則が適用されます。
重要な要素は、エンド ユーザーがテナント データにアクセスする方法です。 エンド ユーザーが Azure Data Explorer に直接アクセスする場合は、ユーザーのビューを自分のデータに分離するために、Azure Data Explorer でアクセス制御を構成する必要があります。 プロキシ アプリケーションが Azure Data Explorer でデータにアクセスすると、アプリケーションは分離を実行できます。
この記事では、いくつかのデプロイ アーキテクチャについて説明し、それぞれに特性を提供します。 この特性を使用すると、ソリューションに最適なアーキテクチャを決定するのに役立ちます。
ノイズの多い隣人
一般に、使用されているアーキテクチャに関係なく、多くのテナント間でクラスターを共有するということは、異なるテナントがクラスターのリソースを共有することを意味します。 これにより、 noisy ネイバー アンチパターンが発生する可能性があります。
たとえば、テナントが多くのコンピューティング集中型クエリまたはインジェストを実行する場合、他のテナントはリソース不足の影響を受ける可能性があります。 これは、 workload グループを使用して軽減できます。 ポリシーを使用して、キャッシュとストレージ全体を制御することもできます。
アーキテクチャの概要
次のセクションでは、デプロイ アーキテクチャについて詳しく説明します。 このセクションでは、意思決定を容易にするアーキテクチャを比較します。
| Architecture | Strenghts |
|---|---|
| データベースごとに 1 つのテナント | - テナントの分離: プロキシは必要ありません - テナントごとに異なるポリシー (アイテム保持ポリシーなど) を持つことができます - テナントごとのスキーマの進化の柔軟性 - テナント データの簡単かつ迅速な削除 |
| 多くのテナントに対して 1 つのテーブル | - 効率的なデータ統合とエクステント管理 - 簡略化されたスキーマの進化 - 具体化されたビューに最適 - パーティション分割に最適 |
| 1 つのデータベース内のテーブルごとに 1 つのテナント | 非推奨 |
アーキテクチャ: データベースごとに 1 つのテナント
これは一般的で簡単なアーキテクチャです。 各テナントは、独自のデータベースを取得します。 各データベースには同じスキーマがあります。
このアーキテクチャの特性は次のとおりです。
新しいテナントのプロビジョニング: 新しいデータベースを作成し スキーマ エンティティをデプロイする必要があります 。
テナントの削除: データベースを削除する必要があります。 データベースの削除は数秒で実行できます。 テナントのデータ ボリュームに線形ではない、ほとんど一定のリソースを消費します。
データベース スキーマの更新: 各テナントは、異なる時間に個別に更新できます。 データベースにアクセスするアプリケーションは、操作する各データベースのバージョンを認識する必要があります。
保持ポリシーとキャッシュ ポリシー: 各テナントには独自のポリシーを設定できます。このポリシーを使用すると、カスタムの保持ポリシーとキャッシュ ポリシーを顧客に提供できます。
テナントごとのセキュリティ境界:
- マルチテナント アプリケーション (プロキシ) の場合: 関連するデータベースをターゲットにするようにアプリケーションを構成します。 クエリ アクセス制限 を使用して、 クロス データベース クエリを禁止します。
- 直接アクセス権を持つユーザーの場合: ユーザーには、 データベース レベルでアクセス権を付与できます。 ユーザーにデータベースへの直接アクセスを許可すると、実装の詳細に対する依存関係が作成され、実装の変更が困難になります。 そのため、データベースへのアクセスにはプロキシ アプローチを使用することを強くお勧めします。
大規模な複数のテナントからのデータの集計: union 演算子 を使用してデータベース間のデータを集計します。 ただし、テナントの数が増えると、この方法が煩雑になる可能性があります。 複数のテナントからデータを集計することは、テナントの観点から見た設計上の目標である可能性がありますが、ソリューション所有者がすべてのテナントのデータを集計して統計を収集することが重要な場合があります。
エクステントの断片化: 各テナントがデータベース テーブルごとにいくつかのレコードを取り込むと、後でマージする必要がある小さな 拡張 が作成されます。 これにより、エクステント管理のコストが高くなります。 そのため、Event Hubs や Event Grid のインジェストなどストリーミング インジェストを使用することを強くお勧めします。 ストリーミング インジェストを使用するには、クラスターとテーブルで有効になっていることを確認する必要があります。
具体化されたビューとパーティション分割ポリシー。 テナントの数が増えるにつれて、クラスターを効率的に実行できるパーティション ポリシーとパーティション ポリシーの数に制限があることに注意することが重要です。
Event Grid と Event Hubs のデータ接続: これらのデータ接続はデータベースごとに作成されます。 そのため、このアーキテクチャでは、テナントごとにデータ接続と Event Grid または Event Hubs インスタンスが必要であり、管理が複雑になります。 Event Hubs および Event Grid にイベント ルーティングを使用することを検討してください。
アーキテクチャ: 多くのテナントに対して 1 つのテーブル
このアーキテクチャは、すべてのテナントに 1 つのデータベースを使用して、統合をより積極的に行います。 データベース内の各テーブルには、 テナント ID 列、または同等の列があり、1 つのテナントのデータをフィルター処理できます。 ほとんどのクエリはテナントによってフィルター処理される可能性が高いため、テナントごとにパーティションテーブルをしてクエリのパフォーマンスを向上させることができます。 可能であれば、 compound パーティション キーを使用して、別の列とのパーティションを検討する必要があります。 たとえば、テナント ID と別の列の値を連結するcompoundパーティション キーを作成できます。
このアーキテクチャの特性は次のとおりです。
新しいテナントのプロビジョニング: 新しいテナントをプロビジョニングする場合、データベースの作成やスキーマの調整は必要ありません。 新しい テナント ID は、新しいレコードで使用されます。
テナントの削除: テナントのデータの soft delete または purge が必要です。 前者の方が効率的ですが、後者は GDPR の義務をサポートしています。 たとえば、週の終わりに複数の消去をバッチ処理して、リソースの消費への影響を制限できます。
Note
この記事は、デバイスまたはサービスから個人データを削除する手順について説明しており、GDPR の下で義務を果たすために使用できます。 GDPR に関する一般情報については、Microsoft Trust Center の GDPR に関するセクションおよび Service Trust Portal の GDPR に関するセクションをご覧ください。
データベース スキーマの更新: すべてのテナントのスキーマが同時にアップグレードされます。 すべてのテナントがテーブルを共有するため、テーブル スキーマを変更すると、すべてのテナントが一度に変更されます。
保持ポリシーとキャッシュ ポリシー: ポリシーはすべて同じテーブルを共有するため、すべてのテナントで同じです。
テナントごとのセキュリティ境界:
- マルチテナント アプリケーション (プロキシ) の場合: Restrict ステートメントを使用します
- 直接アクセス権を持つユーザーの場合: Row レベルのセキュリティ ポリシーを使用しについて理解します。 ユーザーにデータベースへの直接アクセスを許可すると、実装の詳細に対する依存関係が作成され、実装の変更が困難になります。 そのため、データベースへのアクセスにはプロキシ アプローチを使用することを強くお勧めします。
大規模な複数のテナントからのデータの集計: 十分なアクセス許可を持つユーザーは、複数のテナントのデータに対して標準の集計クエリを実行できます。
エクステントの断片化: すべてのテナントが同じテーブルにデータを取り込むため、通常、データを 1 つまたは少数のエクステントに統合して効率的に取り込むことができます。
具体化されたビューとパーティション分割ポリシー: マルチテナント テーブルで使用できます。 テナント ID、または同等の列でパーティション分割することで、パフォーマンスを向上させることができます。 詳細については、「パーティション ポリシーの Scenariosを参照してください。
Event Grid と Event Hubs のデータ接続: すべてのテナントのデータが 1 つのテーブルに終わるため、データ接続を統合しました。
アーキテクチャ: 1 つのデータベース内のテーブルごとに 1 つのテナント
このアーキテクチャは、すべてのテナントのデータが 1 つのデータベースに終わり、個別のテーブルに終わる、以前のアーキテクチャの組み合わせです。 このアーキテクチャでは、他のアーキテクチャのすべての利点をキャプチャできません。
各テナントのデータは分離されますが、それらはすべて同じデータベースの同じセキュリティ コンテキストに存在します。 マルチデータベース アーキテクチャと同様に、このアーキテクチャはエクステントの断片化につながる可能性があります。 テーブル名はテナントごとに異なるため、クエリはテナントごとにカスタマイズする必要があります。