[Architect]ABP(現代ASP.NETテンプレート開発フレームワーク)(6)マルチテナント

このセクションのディレクトリ

マルチテナントとは

マルチデプロイメント-マルチデータベース

シングル・デプロイメント-マルチ・データベース

シングル・デプロイメント-シングル・データベース

ABPのマルチテナント

マルチテナント使用可能

Host vs Tenant

Session

Data Filters

IMustHaveTenant

IMayHaveTenant

エンティティ

を保存

 

マルチテナントとは

Wikipedia:ソフトウェアマルチテナントは1つのソフトウェアアーキテクチャであり、ソフトウェアの1つのインスタンスがサーバ上に走り、複数のテナントにサービスしている.
1人のテナントとは、ソフトウェアにおける共通の1つの特定の権限を持つユーザのグループである.
マルチテナントのアーキテクチャの下で、ソフトウェアは各テナントに独立したデータ、構成、ユーザー管理を提供することができる.
マルチインスタンスアーキテクチャと比較する、ソフトウェアインスタンスを分離することによって異なるテナントに提供される動作である.
マルチテナントはSaaS(Software as-a Service)アプリケーション(クラウドコンピューティング)を作成するために使用される.
 
以下の複数のテナントがあります.

マルチデプロイメント-マルチデータベース

実際、これはマルチテナントではありません.単一のサーバ上でマルチテナントサービスを提供する場合、データベースを分離することによって、テナントごとに1つのソフトウェアインスタンスを提供する.複数のソフトウェアインスタンスが同じサーバで競合しないことを確認するだけです.
既存のアプリケーションはほとんど実現できる.このようなアプリケーションは容易に作成することができ、アプリケーションはマルチテナントに関心を持つ必要はない.
しかし、彼らの配置、使用、メンテナンスは問題です.

 

シングルデプロイメント-マルチデータベース
この場合、サーバ上で1つのソフトウェアのインスタンスを実行することができる.各ユーザがログインするとき、masterデータベースからユーザのテナントをチェックし、対応するテナントが存在するデータベース情報(接続文字列)を取得する.
次に、sessionに接続文字列を格納し、データベース操作を実行する際にこの特定の接続文字列を使用する.
この場合、ソフトウェアはマルチテナントに設計する必要がある.マルチテナントにとって、ソフトウェアの大部分は独立している.
同様に、このようなソフトウェアもインストール、使用、導入の問題がある.テナントごとにデータベースを作成および配置する必要があります.

 

単一配置-単一データベース

これは最も真実なマルチテナントアーキテクチャです.ソフトウェアの単一のインスタンスを配置し、単一のデータベースを1台のサーバに配置します.
マルチテナントが必要なテーブルにTenantIdフィールドを設計します.
 
これは導入とメンテナンスが容易です.しかし、このようなソフトウェアを作成するのは難しい.
なぜなら、1人のテナントが他のテナントのデータを読み書きすることを阻止する必要があるからです.データを読むたびにTenantId filterを1つ追加する必要があるかもしれません.
同様に、このエンティティが現在のテナントに関連付けられている場合.私たちは書くたびにチェックする必要があります.これは非常に面白くないし、間違いやすい.
しかしABPは自動データフィルタリングを用いてこれらを処理する.
 
もし私たちが多くのテナントの大量のデータを持っているならば、この方法は性能の問題があるかもしれません.テーブルを分割したり、1組のテナントに異なるサーバを提供したりすることができます.

ABPでのマルチテナント

ABPは1つの作成単配置、単データベース、多テナントのアーキテクチャフレームワークのサポートを提供した.
 

マルチテナントの有効化

マルチテナントのデフォルトは無効です.PreInitializeで有効にできます.次のようになります.

Configuration.MultiTenancy.IsEnabled = true; 

　　

Host vs Tenant

まず、マルチテナントの2つの項目について説明します.

テナント:1人のお客様は自分のユーザー、役割、権限、設定...完全に独立した他のテナントがこのソフトウェアを使用する.1つのCRMソフトウェアであれば、異なるテナントは自分の口座、連絡先、製品、注文を持っています.だから、私たちが「マルチテナントユーザー」と言うと、私たちは1人のテナントに属するユーザーを指します.

借主:借主は唯一です.テナントはテナントを作成および管理することができる.したがって、「テナント・ユーザー」は、すべてのテナントを独立させ、管理するより高いレベルです.

 

Session

ABPは現在のユーザとテナントを取得する1つのインタフェースIAbpSessionを定義する.このインタフェースはマルチテナントの下で現在のテナントidを取得することができます.彼はidを通じてデータを取得します.

UserId and TenantIdがnullの場合、現在のユーザーはログインしていません.したがって、現在のユーザーロールはわかりません.この場合、操作は許可する.

UserId is not null and TenantId is nullの場合、現在のユーザーはhost userであると考えられます.

UserId is not null and also TenantId is not nullの場合、現在のユーザーtenant user.

(See session documentation for more information on the session.)

 

Data Filters

データからエンティティを検索する場合は、TenantIdを追加して現在のtenantのデータを取得する必要があります.エンティティが2つのインタフェースのうちの1つを実装すると、ABPは自動的に実装されます.(IMustHaveTenant and IMayHaveTenant)
 
IMustHaveTenant
このインタフェースはTenantId属性によって異なるテナントを定義する.

public class Product : Entity, IMustHaveTenant
{
    public int TenantId { get; set; }
        
    public string Name { get; set; }
    
    //...other properties
}

このようにABPはこれが1つのテナントエンティティであることを知っていて、自動的にtenantをフィルタします.
IMayHaveTenant 
ホストとtenantsでエンティティを共有する必要がある場合.すなわち、このエンティティはtenantまたはhostに属する可能性がある.IMayHaveTenantインタフェースは1つの空のTenantIdを定義することができる.

public class Role : Entity, IMayHaveTenant
{
    public int? TenantId { get; set; }
        
    public string RoleName { get; set; }
    
    //...other properties
}

　　
上記の例では、同じロールクラスでHost roles and Tenant rolesを格納する.TenantId属性がnullの場合、host entity、nullではなく、このエンティティが指定tenantに属することを示す.
IMayHaveTenantはIMustHaveTenantのようによく使われていない.例えば、ProductクラスはIMayHaveTenantインタフェースを実現することができず、Productクラスと実際のソフトウェアが関連する必要がある場合、tenantsとは関連しない.
IMayHaveTenantインタフェースを使用してhostとtenantで共有すると、コードのメンテナンスがさらに難しくなります.

エンティティの保存

1人のテナントユーザーは、他のテナントエンティティを作成および変更できません.
Data filtersがオンである限り、ABPはデータを保存する前に確認する.(See data filters document for more information on data filters.)