web-dev-qa-db-ja.com

マスターアカウントを使用したマルチテナントのセットアップ

マルチテナントシステムとなるSaaS）を作成したいと思います。開発はLaravelで行われるため、それほど重要ではありません。マスター管理者アカウントをどのように処理するかを知りたいです。 （私にとって）テナントの数、サブスクリプションとそのタイプ、権限などを監視できましたか？

現在、新しいテナントごとに独自のサブドメインを取得する設定があります（したがって、テナントt1はt1.example.comになります）。

ルートとシステムの整合性で気になるのは、テーブル/モデルUsersがあり、単一のユーザーが単一のテナントに属することができるのに対し、テナントには多くのユーザーがいることです。この設定では、管理者アカウントをテナントに属さないのは少し不自然に感じます。これにより、今後さらに問題が発生する可能性があると考えています。

ダミーのテナントがいることも頭に浮かびましたが、これが正しい道かどうかはわかりません。

また、テナント以外の特定のものを担当する分割システムを考えていたので、一方ではテナントとシステムごとのアクションを観察でき、もう一方のシステムはテナント指向であり、すべてが必要なDB関係。この設定では、1つがテナントに依存しないように、2つの別々のUserモデルが必要になると思います。しかし、これは多くの重複のように感じます。

あなたの経験は何ですか？

phpdatabaselaravelmultitenancy
1
Norgul

私が知りたいのは、テナントの数、サブスクリプションとそのタイプ、アクセス許可などを監視できるマスター管理者アカウント（私にとって）をどのように処理するかです。

別のドメインadmin.example.comを持つことができます。テナントに許可されない予約済みサブドメインのリストもあります。

ルートとシステムの整合性で気になるのは、単一のユーザーが単一のテナントに属することができるテーブル/モデルのユーザーがいるのに対し、テナントには多くのユーザーがいることです。この設定では、管理者アカウントをテナントに属さないのは少し不自然に感じます。これにより、今後さらに問題が発生する可能性があると考えています。

管理者ログインはユーザーとは別のものになります。別のテーブルに「admin_users」と言います。 Usersテーブルの複合主キーを設計する必要があります。 （id、tenant_id）が主キーになる場合。 adminユーザーがテナントWebサイト（t1.example.com）にログインするには、admin_usersからUsersテーブルにすべてのレコードをそれぞれのtenant_idで挿入します。

table: admin_users // This would work mainly for admin.example.com
id, name
121, Admin 
123, Norgul

table: users // This would work for tenant's users as well as you as an admin can "login as tenant" into tenant system for debugging or setup.
id, tenant_id, admin_user_id
1, 1,  121 // admin user
2, 1, 123 // admin user
3, 1, NULL // tenant's user

table:sub_domains
id, sub_domain, tenant_id
1, t1, 1

このようにして、admin_usersとテナントユーザーが完全に分離されます。ある時点で、tenant_idの下に他のユーザーを作成する権限を持つ1つのテナントの管理者ユーザーを作成する必要があります。

ルート

ルートはすべてのサブドメインで同じですが、tenant_idに応じて、そのテナントのデータをロードします。作成するテナント固有のテーブルが何であれ、複合主キーとして（id、tenant_id）が必要になります。

URLに基​​づいて、sub_domainsテーブルからtenant_idを検出します。

スケーラブル

将来、トラフィックとトランザクションが増加した場合、特定のテナントのデータを別のデータベースサーバーに簡単に移動できます。 sub_domainsテーブルで、テナントとデータベースのマッピングを行います。

テナント以外の特定のもの

タイプテーブル、国テーブル、tenant_statusなど、クライアント固有ではないテーブルがいくつかあります。このようなテーブルにtenant_idフィールドを追加することはありません。このようなテーブルをマスターテーブルと呼びます。

PermissionsURLが次のようになっているとします：t1.example.com/manage_users/add_user。ここで、manage_userはモジュールで、add_userはアクションです。現在のユーザーと現在のモジュールのアクセス許可テーブルをチェックするアクセス許可ミドルウェアまたはアクセス許可レイヤーのみを使用できます。許可されている場合は、ページを表示します。そうでない場合は、エラーメッセージを表示します。

経験

この種のマルチテナンシーアーキテクチャは最も成功しています。私は同様のアーキテクチャを使用しており、以前にも使用していました。まず、単一のデータベースと2つのスキーマ（管理者、テナント）から始めました。次に、テナントを別のデータベースに移動しました。テナントが増えるにつれ、より多くのテナントデータベースを作成しました。参照： https://docs.Microsoft.com/en-us/Azure/sql-database/saas-tenancy-app-design-patterns

1
Shaunak Sontakke