マルチテナント SaaS データベース テナント パターンMulti-tenant SaaS database tenancy patterns

この記事では、マルチ テナント SaaS アプリケーションに使用できるさまざまなテナント モデルについて説明します。This article describes the various tenancy models available for a multi-tenant SaaS application.

マルチテナント SaaS アプリケーションを設計するときは、アプリケーションのニーズに最適なテナント モデルを慎重に選択する必要があります。When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your application. テナント モデルでは、各テナントのデータをストレージにマップする方法を決定します。A tenancy model determines how each tenant’s data is mapped to storage. 選択したテナント モデルは、アプリケーションの設計と管理に影響します。Your choice of tenancy model impacts application design and management. 後で別のモデルに切り替えると、高コストになる場合があります。Switching to a different model later is sometimes costly.

A.A. SaaS の概念と用語SaaS concepts and terminology

サービスとしてのソフトウェア (SaaS) モデルでは、ソフトウェア会社は "ライセンス" を販売しません。In the Software as a Service (SaaS) model, your company does not sell licenses to your software. 代わりに、各顧客は会社にレンタル料金を支払って、会社の "テナント" になります。Instead, each customer makes rent payments to your company, making each customer a tenant of your company.

レンタル料金の支払いと引き換えに、各テナントは、SaaS アプリケーションのコンポーネントにアクセスし、データを SaaS システムに保存できるようになります。In return for paying rent, each tenant receives access to your SaaS application components, and has its data stored in the SaaS system.

"テナント モデル" という用語は、テナントが保存するデータの編成方法を指します。The term tenancy model refers to how tenants' stored data is organized:

  • シングル テナント:  各データベースには、1 つのテナントからのデータだけが格納されます。Single-tenancy:  Each database stores data from only one tenant.
  • マルチテナント:  各データベースには、複数の異なるテナントからのデータが (データのプライバシーを保護するメカニズムを使って) 格納されます。Multi-tenancy:  Each database stores data from multiple separate tenants (with mechanisms to protect data privacy).
  • ハイブリッド テナント モデルも利用できます。Hybrid tenancy models are also available.

B.B. 適切なテナント モデルを選択する方法How to choose the appropriate tenancy model

一般に、テナント モデルがアプリケーションの機能に影響を及ぼすことはありませんが、ソリューション全体の他の側面に影響を与えることがあります。In general, the tenancy model does not impact the function of an application, but it likely impacts other aspects of the overall solution. 次の条件は、各モデルの評価に使用されています。The following criteria are used to assess each of the models:

  • 拡張性:Scalability:

    • テナントの数Number of tenants.
    • テナントごとのストレージStorage per-tenant.
    • 集計でのストレージStorage in aggregate.
    • ワークロードWorkload.
  • テナントの分離:  データの分離とパフォーマンス (1 つのテナントのワークロードが他のテナントに影響を及ぼすかどうか)Tenant isolation:  Data isolation and performance (whether one tenant’s workload impacts others).

  • テナントあたりのコスト:  データベースのコストPer-tenant cost:  Database costs.

  • 開発の複雑さ:Development complexity:

    • スキーマへの変更Changes to schema.
    • クエリへの変更 (パターン別に必要)Changes to queries (required by the pattern).
  • 運用の複雑さ:Operational complexity:

    • パフォーマンスの監視と管理Monitoring and managing performance.
    • スキーマ管理Schema management.
    • テナントの復元Restoring a tenant.
    • ディザスター リカバリーDisaster recovery.
  • カスタマイズ性:  テナント固有またはテナント クラス固有どちらかの、サポートされるスキーマ カスタマイズの容易性Customizability:  Ease of supporting schema customizations that are either tenant-specific or tenant class-specific.

テナントの説明ではデータ レイヤーに着目していますが、The tenancy discussion is focused on the data layer. アプリケーション レイヤーについて少し検討してみましょう。But consider for a moment the application layer. アプリケーション レイヤーは、モノリシック エンティティとして扱われます。The application layer is treated as a monolithic entity. アプリケーションを多数の小規模コンポーネントに分割した場合、選択したいテナント モデルが変わる可能性もあります。If you divide the application into many small components, your choice of tenancy model might change. テナントと使用するストレージ テクノロジ/プラットフォームの両方に関して、一部のコンポーネントを他のコンポーネントとは別に扱うこともできます。You could treat some components differently than others regarding both tenancy and the storage technology or platform used.

C.C. シングルテナント データベースを利用したスタンドアロンのシングルテナント アプリStandalone single-tenant app with single-tenant database

アプリケーション レベルの分離Application level isolation

このモデルでは、アプリケーション全体がテナントごとに 1 回ずつ、繰り返しインストールされます。In this model, the whole application is installed repeatedly, once for each tenant. アプリの各インスタンスはスタンドアロン インスタンスなので、他のスタンドアロン インスタンスとやり取りすることはありません。Each instance of the app is a standalone instance, so it never interacts with any other standalone instance. アプリの各インスタンスにはテナントが 1 つしかないため、データベースも 1 つしか必要ありません。Each instance of the app has only one tenant, and therefore needs only one database. テナントのデータベースは、そのテナント専用です。The tenant has the database all to itself.

単独のシングルテナント データベースを利用したスタンドアロン アプリの設計Design of standalone app with exactly one single-tenant database.

各アプリ インスタンスは、別個の Azure リソース グループにインストールされます。Each app instance is installed in a separate Azure resource group. リソース グループは、ソフトウェア ベンダーまたはテナントのいずれかが所有するサブスクリプションに属することができます。The resource group can belong to a subscription that is owned by either the software vendor or the tenant. どちらの場合も、ベンダーはテナントに対してソフトウェアを管理できます。In either case, the vendor can manage the software for the tenant. 各アプリケーション インスタンスは、そのインスタンスに対応するデータベースに接続するように構成されます。Each application instance is configured to connect to its corresponding database.

各テナント データベースは単一データベースとしてデプロイされます。Each tenant database is deployed as a single database. このモデルでは、最大限のデータベースの分離を提供しています。This model provides the greatest database isolation. しかし、ピーク時の負荷を処理できる十分なリソースが各データベースに割り当てられていることが、分離の要件になります。But the isolation requires that sufficient resources be allocated to each database to handle its peak loads. そこで、異なるリソース グループまたは異なるサブスクリプションにデプロイされているデータベースに対して、エラスティック プールは使用できないことが問題になります。Here it matters that elastic pools cannot be used for databases deployed in different resource groups or to different subscriptions. この制約によって、このようなスタンドアロン シングルテナント アプリのモデルは、データベース全体のコストの観点では、最も高コストなソリューションになります。This limitation makes this standalone single-tenant app model the most expensive solution from an overall database cost perspective.

ベンダーの管理Vendor management

アプリ インスタンスが別のテナント サブスクリプションにインストールされていても、ベンダーはすべてのスタンドアロン アプリ インスタンスの全データベースにアクセスできます。The vendor can access all the databases in all the standalone app instances, even if the app instances are installed in different tenant subscriptions. アクセスは、SQL 接続経由で行われます。The access is achieved via SQL connections. このクロス インスタンス アクセスによって、ベンダーはスキーマ管理やレポートまたは分析を目的としたデータベース間のクエリを一元化できます。This cross-instance access can enable the vendor to centralize schema management and cross-database query for reporting or analytics purposes. このような一元管理が求められている場合、データベース URI にテナント識別子をマップするカタログがデプロイされている必要があります。If this kind of centralized management is desired, a catalog must be deployed that maps tenant identifiers to database URIs. Azure SQL Database には、カタログを提供するために、SQL データベースと共に使用されるシャーディング ライブラリが用意されています。Azure SQL Database provides a sharding library that is used together with a SQL database to provide a catalog. シャーディング ライブラリは、正式には "Elastic Database クライアント ライブラリ" といいます。The sharding library is formally named the Elastic Database Client Library.

D.D. テナント単位データベースを利用したマルチテナント アプリMulti-tenant app with database-per-tenant

このパターンでは、多数のデータベースを備えたマルチテナント アプリケーションを使用します。各データベースはすべて、シングルテナント データベースです。This next pattern uses a multi-tenant application with many databases, all being single-tenant databases. 新しいデータベースは、新しいテナントごとにプロビジョニングされます。A new database is provisioned for each new tenant. アプリケーション層は、ノードごとにリソースを追加すると、垂直方向に拡大します。The application tier is scaled up vertically by adding more resources per node. また、ノードを追加すると、アプリは水平方向に縮小します。Or the app is scaled out horizontally by adding more nodes. 拡大/縮小はワークロードに基づいており、個々のデータベースの数や大きさには依存しません。The scaling is based on workload, and is independent of the number or scale of the individual databases.

テナント単位データベースを利用したマルチテナント アプリの設計Design of multi-tenant app with database-per-tenant.

テナントのカスタマイズCustomize for a tenant

スタンドアロン アプリ パターンと同様に、シングルテナント データベースを使用すると、テナントが強固に分離されます。Like the standalone app pattern, the use of single-tenant databases gives strong tenant isolation. モデルにシングルテナント データベースのみを定義しているアプリでは、指定された任意の 1 つのデータベースに対応するスキーマを、そのテナント用にカスタマイズおよび最適化できます。In any app whose model specifies only single-tenant databases, the schema for any one given database can be customized and optimized for its tenant. このカスタマイズは、アプリの他のテナントには影響しません。This customization does not affect other tenants in the app. おそらく、該当のテナントは、すべてのテナントで必要とされる基本的なデータ フィールド以外のデータを必要としています。Perhaps a tenant might need data beyond the basic data fields that all tenants need. さらに、追加のデータ フィールドにはインデックスが必要です。Further, the extra data field might need an index.

テナント単位データベースでは、1 つまたは複数の個別テナントに対するスキーマをカスタマイズすることが、目的達成への近道です。With database-per-tenant, customizing the schema for one or more individual tenants is straightforward to achieve. アプリケーション ベンダーは、スキーマのカスタマイズを一括で慎重に管理するための手順を作成する必要があります。The application vendor must design procedures to carefully manage schema customizations at scale.

エラスティック プールElastic pools

同じリソース グループにデータベースをデプロイする場合、それらのデータベースをエラスティック プール内にまとめることができます。When databases are deployed in the same resource group, they can be grouped into elastic pools. プールは、多数のデータベース間のリソースの共有をコスト効率よく行う方法を提供しています。The pools provide a cost-effective way of sharing resources across many databases. このプールのオプションは、発生するピーク時の使用率に対応する十分な規模を各データベースが備えるよりも、低コストです。This pool option is cheaper than requiring each database to be large enough to accommodate the usage peaks that it experiences. プールされたデータベース共有からリソースにアクセスしても、高レベルでのパフォーマンスの分離を達成できます。Even though pooled databases share access to resources they can still achieve a high degree of performance isolation.

エラスティック プールを使用する、テナント単位データベースを利用したマルチテナント アプリの設計Design of multi-tenant app with database-per-tenant, using elastic pool.

Azure SQL Database では、共有を構成、監視、および管理するために必要なツールを提供しています。Azure SQL Database provides the tools necessary to configure, monitor, and manage the sharing. プールレベルとデータベースレベルの両方のパフォーマンス メトリックを、Azure portal で、または Azure Monitor ログ経由で使用できます。Both pool-level and database-level performance metrics are available in the Azure portal, and through Azure Monitor logs. メトリックは、集計とテナント固有両方のパフォーマンスに対して、優れた洞察を与えることができます。The metrics can give great insights into both aggregate and tenant-specific performance. 個々のデータベースは、特定のテナントに対して予約済みのリソースを提供するために、プール間で移動できます。Individual databases can be moved between pools to provide reserved resources to a specific tenant. これらのツールを活用すると、コスト効率の高い方法で優れたパフォーマンスを確保できます。These tools enable you to ensure good performance in a cost effective manner.

テナント単位データベースに対する操作のスケールOperations scale for database-per-tenant

Azure SQL Database プラットフォームには、100,000 台を大きく超えるような多数のデータベースを一括で管理するために設計された、多数の管理機能が用意されています。The Azure SQL Database platform has many management features designed to manage large numbers of databases at scale, such as well over 100,000 databases. これらの機能により、テナント単位データベース パターンの有用性が確保されます。These features make the database-per-tenant pattern plausible.

たとえば、1000 個のテナントを持つデータベースが、唯一のデータベースとしてシステムに搭載されているとします。For example, suppose a system has a 1000-tenant database as its only one database. データベースが保持するインデックスの数を 20 とします。The database might have 20 indexes. 1000 個のシングルテナント データベースを保持するようにシステムが変換されると、インデックスの数は 20,000 に増加します。If the system converts to having 1000 single-tenant databases, the quantity of indexes rises to 20,000. SQL Database では、自動チューニングの一環として、インデックスの自動作成機能が既定で有効になっています。In SQL Database as part of Automatic tuning, the automatic indexing features are enabled by default. インデックスの自動作成では、20,000 個すべてのインデックスと進行中の create および drop の最適化を、ユーザーに代わって管理します。Automatic indexing manages for you all 20,000 indexes and their ongoing create and drop optimizations. 自動化されたこれらのアクションは個々のデータベース内で実行され、他のデータベースでの類似のアクションによる調整や制限は受けません。These automated actions occur within an individual database, and they are not coordinated or restricted by similar actions in other databases. インデックスの自動作成では、ビジー状態のデータベースのインデックスをそれ以外のデータベースとは異なる方法で処理します。Automatic indexing treats indexes differently in a busy database than in a less busy database. 仮にこの大がかりな管理タスクを手動で実行しなければならないとしたら、テナント単位データベースのスケールで、このようにインデックス管理をカスタマイズすることは難しいでしょう。This type of index management customization would be impractical at the database-per-tenant scale if this huge management task had to be done manually.

効果的なスケーリングを行う他の管理機能を次に示します。Other management features that scale well include the following:

  • 組み込みのバックアップBuilt-in backups.
  • 高可用性:High availability.
  • ディスク上での暗号化On-disk encryption.
  • パフォーマンス テレメトリPerformance telemetry.

AutomationAutomation

管理操作は、DevOps モデルを使って、スクリプト化して提供できます。The management operations can be scripted and offered through a devops model. 操作を自動化して、アプリケーションに公開することもできます。The operations can even be automated and exposed in the application.

たとえば、単一のテナントを以前のポイント イン タイムまで自動的に復旧できます。For example, you could automate the recovery of a single tenant to an earlier point in time. 復旧するには、テナントを格納する 1 つの単一テナント データベースを復元するだけでかまいません。The recovery only needs to restore the one single-tenant database that stores the tenant. この復元が他のテナントに影響を及ぼすことはなく、必ず個々のテナントごとに極めて詳細なレベルで管理操作が行われます。This restore has no impact on other tenants, which confirms that management operations are at the finely granular level of each individual tenant.

E.E. マルチテナント データベースを利用したマルチテナント アプリMulti-tenant app with multi-tenant databases

利用可能な別のパターンとして、マルチテナント データベースに多数のテナントを格納する方法があります。Another available pattern is to store many tenants in a multi-tenant database. アプリケーション インスタンスは、任意の数のマルチテナント データベースを保持できます。The application instance can have any number of multi-tenant databases. マルチテナント データベースのスキーマは、特定のテナントのデータを選択的に取得できるように、1 つまたは複数のテナント識別子列を必ず保持します。The schema of a multi-tenant database must have one or more tenant identifier columns so that the data from any given tenant can be selectively retrieved. さらに、スキーマでは、テナントのサブセットからのみ使用されるいくつかのテーブルまたは列が必要になることがあります。Further, the schema might require a few tables or columns that are used by only a subset of tenants. ただし、静的コードと参照データは 1 回しか格納されず、すべてのテナントで共有されます。However, static code and reference data is stored only once and is shared by all tenants.

テナントの分離が犠牲になるTenant isolation is sacrificed

データ:  マルチ テナント データベースでは必然的に、テナントの分離が犠牲になります。Data:  A multi-tenant database necessarily sacrifices tenant isolation. 複数のテナントのデータが、1 つのデータベースに一緒に格納されます。The data of multiple tenants is stored together in one database. 開発時には、クエリによって複数のテナントのデータを公開しないようにしてください。During development, ensure that queries never expose data from more than one tenant. SQL Database では、行レベルのセキュリティをサポートしています。これにより、1 つのクエリから返されるデータのスコープを強制的に単一のテナントにすることが可能です。SQL Database supports row-level security, which can enforce that data returned from a query be scoped to a single tenant.

処理:  マルチテナント データベースでは、全テナントでコンピューティング リソースおよびストレージ リソースが共有されます。Processing:  A multi-tenant database shares compute and storage resources across all its tenants. データベースが許容できる状態で実行されるように、データベース全体を監視できます。The database as a whole can be monitored to ensure it is performing acceptably. ただし、Azure システムは、これらのリソースの使用を個々のテナントごとに監視または管理するための組み込みの方法を備えていません。However, the Azure system has no built-in way to monitor or manage the use of these resources by an individual tenant. そのため、過稼働状態の 1 つのテナントのワークロードが、同じデータベース内の他のテナントのパフォーマンス エクスペリエンスに影響を及ぼすことで、マルチテナント データベースが "迷惑な隣人" に遭遇するリスクは高まります。Therefore, the multi-tenant database carries an increased risk of encountering noisy neighbors, where the workload of one overactive tenant impacts the performance experience of other tenants in the same database. 追加のアプリケーション レベルの監視を使用すると、テナントレベルのパフォーマンスを監視できます。Additional application-level monitoring could monitor tenant-level performance.

低コストLower cost

一般に、マルチテナント データベースは、テナント単位でのコストが最も低くなります。In general, multi-tenant databases have the lowest per-tenant cost. 単一データベースのリソース コストは、同じサイズのエラスティック プールより低くなります。Resource costs for a single database are lower than for an equivalently sized elastic pool. さらに、テナントが限られた 1 つのストレージしか必要としないシナリオでは、潜在的には何百万ものテナントが単一のデータベース内に格納される可能性があります。In addition, for scenarios where tenants need only limited storage, potentially millions of tenants could be stored in a single database. エラスティック プールに何百万ものデータベースを保持することはできません。No elastic pool can contain millions of databases. しかし、1000 個のプールを保持して、1 つのプールあたり 1000 個のデータベースを含むソリューションでは、何百万単位の規模に達して管理が困難になる恐れがあります。However, a solution containing 1000 databases per pool, with 1000 pools, could reach the scale of millions at the risk of becoming unwieldy to manage.

最も柔軟かつスケーラブルなシャード マルチテナント モデルを含め、マルチテナント データベース モデルによる 2 つの方法について、以下に説明します。Two variations of a multi-tenant database model are discussed in what follows, with the sharded multi-tenant model being the most flexible and scalable.

F.F. 単一のマルチテナント データベースを利用したマルチテナント アプリMulti-tenant app with a single multi-tenant database

最も単純なマルチテナント データベース パターンでは、すべてのテナントのデータをホストする単一データベースを使用します。The simplest multi-tenant database pattern uses a single database to host data for all tenants. 追加されるテナントが増えると、ストレージおよびコンピューティング リソースが増大し、データベースは拡大されます。As more tenants are added, the database is scaled up with more storage and compute resources. 拡大/縮小には限界がありますが、この拡大に対応できれば十分かもしれません。This scale up might be all that is needed, although there is always an ultimate scale limit. しかし、その限界に達するずっと前に、データベースの管理が困難になります。However, long before that limit is reached the database becomes unwieldy to manage.

個々のテナントに重点を置いた管理操作は、マルチテナント データベースでの実装がより複雑になります。Management operations that are focused on individual tenants are more complex to implement in a multi-tenant database. そして、一括して行う場合は、許容できないほどにこれらの操作が遅くなる恐れがあります。And at scale these operations might become unacceptably slow. 例として、1 つのテナントだけに対するデータのポイント イン タイム リストアがあります。One example is a point-in-time restore of the data for just one tenant.

G.G. シャード マルチテナント データベースを利用したマルチテナント アプリMulti-tenant app with sharded multi-tenant databases

ほとんどの SaaS アプリケーションでは、一度に 1 つのテナントのデータにしかアクセスしません。Most SaaS applications access the data of only one tenant at a time. 任意の 1 つのテナントに対するすべてのデータが 1 つのシャードに格納されている場合、このアクセス パターンによって、複数のデータベースまたはシャード間にテナント データを分散させることができます。This access pattern allows tenant data to be distributed across multiple databases or shards, where all the data for any one tenant is contained in one shard. マルチテナント データベース パターンと組み合わせると、シャード モデルによってほぼ無限の拡大/縮小が可能になります。Combined with a multi-tenant database pattern, a sharded model allows almost limitless scale.

シャード マルチテナント データベースを利用したマルチテナント アプリの設計Design of multi-tenant app with sharded multi-tenant databases.

シャードの管理Manage shards

シャーディングは、設計および運用管理の両方をより複雑にします。Sharding adds complexity both to the design and operational management. テナントとデータベース間のマッピングを維持するために、カタログが必要になります。A catalog is required in which to maintain the mapping between tenants and databases. さらに、シャードとテナントの入力を管理するための管理手順が必要になります。In addition, management procedures are required to manage the shards and the tenant population. たとえば、シャードの追加と削除、およびシャード間でのテナント データの移動の手順が作成される必要があります。For example, procedures must be designed to add and remove shards, and to move tenant data between shards. 拡大/縮小するための 1 つの方法は、新しいシャードを追加して、新しいテネントを入力することです。One way to scale is to by adding a new shard and populating it with new tenants. また、別の方法として、入力密度の高いシャードをより入力密度の低い 2 つのシャードに分割することもできます。At other times you might split a densely populated shard into two less-densely populated shards. 複数のテナントが移動または停止された後は、入力が少ないシャードを統合することもできます。After several tenants have been moved or discontinued, you might merge sparsely populated shards together. 統合によって、リソース活用のコスト効率が高まります。The merge would result in more cost-efficient resource utilization. また、ワークロードを分散させるために、シャード間でテナントが移動される場合もあります。Tenants might also be moved between shards to balance workloads.

SQL Database は、シャーディング ライブラリとカタログ データベースの併用で動作する分割/マージ ツールを提供しています。SQL Database provides a split/merge tool that works in conjunction with the sharding library and the catalog database. 提供されているアプリを使って、シャードを分割およびマージでき、シャード間でテナント データを移動できます。The provided app can split and merge shards, and it can move tenant data between shards. また、アプリでは、影響を受けたテナントを移動する前にオフラインとしてマークすることで、これらの操作時にカタログを維持することもできます。The app also maintains the catalog during these operations, marking affected tenants as offline prior to moving them. 移動後、アプリはもう一度、新しいマッピングでカタログを更新し、テナントのマーキングをオンラインに戻します。After the move, the app updates the catalog again with the new mapping, and marking the tenant as back online.

より管理しやすい小規模なデータベースSmaller databases more easily managed

シャード マルチテナント ソリューションでは、複数のデータベースにテナントを分散させることで、より管理しやすい小規模なデータベースになります。By distributing tenants across multiple databases, the sharded multi-tenant solution results in smaller databases that are more easily managed. たとえば、特定のテナントのポイント イン タイム リストアでは、すべてのテナントを含む大規模なデータベースではなく、より小規模な単一のデータベースをバックアップから復元します。For example, restoring a specific tenant to a prior point in time now involves restoring a single smaller database from a backup, rather than a larger database that contains all tenants. ワークロードと管理の手間のバランスを取るために、データベース サイズと、データベースごとのテナント数を選ぶことができます。The database size, and number of tenants per database, can be chosen to balance the workload and the management efforts.

スキーマ内のテナント識別子Tenant identifier in the schema

使用されるシャーディングの手法に応じて、データベース スキーマに追加の制約が適用される場合があります。Depending on the sharding approach used, additional constraints may be imposed on the database schema. SQL Database の分割/マージ アプリケーションでは、スキーマにシャーディング キーが含まれている必要があります。このキーは通常、テナント識別子です。The SQL Database split/merge application requires that the schema includes the sharding key, which typically is the tenant identifier. テナント識別子は、シャード化されたすべてのテーブルの主キー内にある最初の要素です。The tenant identifier is the leading element in the primary key of all sharded tables. テナント識別子によって、分割/マージ アプリケーションは、特定のテナントに関連付けられたデータを迅速に検索して移動できます。The tenant identifier enables the split/merge application to quickly locate and move data associated with a specific tenant.

シャードのエラスティック プールElastic pool for shards

シャード マルチテナント データベースは、エラステック プール内に配置できます。Sharded multi-tenant databases can be placed in elastic pools. 一般に、プール内に多数のシングルテナント データベースを保持すると、少数のマルチテナント データベース内に多数のテナントを保持する場合と同じくらい、コスト効率が高まります。In general, having many single-tenant databases in a pool is as cost efficient as having many tenants in a few multi-tenant databases. 比較的非アクティブなテナントの数が多い場合、マルチテナント データベースが便利です。Multi-tenant databases are advantageous when there are a large number of relatively inactive tenants.

H.H. ハイブリッドのシャード マルチテナント データベース モデルHybrid sharded multi-tenant database model

ハイブリッド モデルでは、すべてのデータベースがスキーマ内にテナント識別子を保持します。In the hybrid model, all databases have the tenant identifier in their schema. データベースはすべて、複数のテナントを格納できると共に、データベースのシャード化が可能です。The databases are all capable of storing more than one tenant, and the databases can be sharded. そのため、スキーマ検出では、すべてマルチテナント データベースになります。So in the schema sense, they are all multi-tenant databases. 実際には、これらのデータベースの中にはテナントを 1 つしか含んでいないものもありますが、Yet in practice some of these databases contain only one tenant. 関係ありません。特定のデータベースに格納されているテナント数が、データベース スキーマに影響を与えることはありません。Regardless, the quantity of tenants stored in a given database has no effect on the database schema.

テナントの移動Move tenants around

特定のテナントを独自のマルチテナント データベースにいつでも移動できます。At any time, you can move a particular tenant to its own multi-tenant database. また、考えが変われば、複数のテナントを含む 1 つのデータベースにそのテナントをいつでも戻すことができます。And at any time, you can change your mind and move the tenant back to a database that contains multiple tenants. 新しいデータベースをプロビジョニングするときに、新しいシングルテナント データベースにテナントを割り当てることも可能です。You can also assign a tenant to new single-tenant database when you provision the new database.

識別可能なテナント グループでリソースの必要性に大きな差異がある場合は、ハイブリッド モデルが最適です。The hybrid model shines when there are large differences between the resource needs of identifiable groups of tenants. たとえば、無料試用版に参加しているテナントでは、サブスクライブしているテナントと同等の高いパフォーマンス レベルが保証されないと考えられます。For example, suppose that tenants participating in a free trial are not guaranteed the same high level of performance that subscribing tenants are. 無料試用版のフェーズにあるテナントは、すべての無料試用版のテナント間でシャード化された 1 つのマルチテナント データベースに格納されるよう、ポリシーで規定されている場合もあります。The policy might be for tenants in the free trial phase to be stored in a multi-tenant database that is shared among all the free trial tenants. 無料試用版のテナントが基本サービス層にサブスクライブされると、そのテナントは、テナント数がより少ない別のマルチテナント データベースに移動できます。When a free trial tenant subscribes to the basic service tier, the tenant can be moved to another multi-tenant database that might have fewer tenants. Premium サービス層の契約を結んでいるサブスクライバーであれば、独自のシングルテナント データベースに移動できます。A subscriber that pays for the premium service tier could be moved to its own new single-tenant database.

プールPools

このハイブリッド モデルでは、テナントごとのデータベース コストを削減するために、サブスクライバーのテナント用の単一テナント データベースをリソース プールに配置できます。In this hybrid model, the single-tenant databases for subscriber tenants can be placed in resource pools to reduce database costs per tenant. これは、テナント単位データベース モデルでも実行できます。This is also done in the database-per-tenant model.

I.I. テナント モデルの比較Tenancy models compared

以下の表に、主なテナント モデル間の違いをまとめています。The following table summarizes the differences between the main tenancy models.

MeasurementMeasurement スタンドアロン アプリStandalone app テナント単位データベースDatabase-per-tenant シャード マルチテナントSharded multi-tenant
スケールScale MediumMedium
1 ~1001-100s
非常に高Very high
1 ~ 100,0001-100,000s
無制限Unlimited
1 ~1,000,0001-1,000,000s
テナントの分離Tenant isolation 非常に高Very high High 低。シングル テナント (MT DB 内で単独) を除く。Low; except for any single tenant (that is alone in an MT db).
テナントごとのデータベース コストDatabase cost per tenant 高。ピーク時のサイズHigh; is sized for peaks. 低。プールが使用されるLow; pools used. 最低。MT DB にある小規模テナントの場合Lowest, for small tenants in MT DBs.
パフォーマンスの監視と管理Performance monitoring and management テナント単位のみPer-tenant only 集計およびテナント単位Aggregate + per-tenant 集計。ただし、シングルの場合のみテナント単位。Aggregate; although is per-tenant only for singles.
開発の複雑さDevelopment complexity Low Low 中。シャーディングに起因Medium; due to sharding.
操作の複雑さOperational complexity 低 ~ 高。Low-High. 個別の場合は単純、一括の場合は複雑Individually simple, complex at scale. 低 ~ 中。Low-Medium. 一括の場合はパターンで複雑さに対応Patterns address complexity at scale. 低 ~ 高。Low-High. 個々のテナント管理が複雑Individual tenant management is complex.
 

次の手順Next steps