マルチテナントアプリを構築するのは難しく、多くの側面を考慮する必要があります。この記事では、マルチテナントと組織の実践を理解するための過去のブログ投稿をすべてまとめています。すぐにスタートし、時間を節約したい場合は、この記事をチェックしてください。必要な情報がすべて含まれています！一般的なガイドラインは、以下のステップで説明されています： 1. マルチテナントアーキテクチャを理解する 2. マルチテナントアプリのユースケースをマッピングする 3. テナントの分離を達成する 4. 身元の管理方法を定義する 5. 適切な認可モデルを選択する ## マルチテナントアーキテクチャを理解するソフトウェアマルチテナンシーは、単一の[ソフトウェア](https://en.wikipedia.org/wiki/Computer_software)がサーバー上で実行され、複数のテナントにサービスを提供する[ソフトウェアアーキテクチャ](https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3)です。このように設計されたシステムは「共有」され（「専用」や「分離」と対照的）、テナントはソフトウェアインスタンスへの特定の権限を共有するユーザーグループです。 multi-tenant

マルチテナンシーの重要な考え方の一つは「共有」です。マルチテナンシーの広い定義では、マルチテナントアプリケーションであることは**すべての**コンポーネントが共有されることを意味しません。むしろ、少なくとも**いくつかの**コンポーネントが複数のテナント間で再利用されていることを意味します。この用語を広く理解することで、クライアントのニーズやその背景に共感することができます。マルチテナントアーキテクチャを理解したら、次のステップは実際のシナリオにアプリを適用し、特定の製品およびビジネスニーズに焦点を当てることです。 ## マルチテナントアプリのユースケースをマッピングする ### SaaS マルチテナントアプリは、生産性ツール、コラボレーションソフトウェア、およびその他のソフトウェアアズアサービス（SaaS）製品のようなビジネス・ツー・ビジネス（B2B）ソリューションに場所を見つけることがよくあります。このコンテキストでは、各「テナント」は通常、ビジネス顧客を表し、そのビジネスには複数のユーザー（従業員）がいる可能性があります。さらに、ビジネス顧客は、個別の組織またはビジネス部門を表す複数のテナントを持つかもしれません。 ![SaaS](https://uploads.strapi.logto.io/1/saas_product_d63c736650.webp) ### 一般的な B2B ユースケース B2B アプリケーションは、SaaS 製品を超えており、しばしばマルチテナントアプリを使用します。B2B コンテキストでは、これらのアプリはさまざまなチーム、ビジネスクライアント、およびパートナー企業がアプリケーションにアクセスするための共通プラットフォームとして機能します。たとえば、B2C および B2B アプリを提供するライドシェア企業を考えてみてください。B2B アプリは複数のクライアントをサポートし、マルチテナントアーキテクチャを採用することで、従業員やリソースの管理を助けます。例えば、会社が統一されたユーザーのアイデンティティシステムを維持したい場合、次の例のようなアーキテクチャを設計できます。サラは、個人とビジネスの両方のアイデンティティを持っています。彼女は乗客としてライドシェアサービスを利用し、またアルバイトでドライバーとしても働いています。プロフェッショナルな役割では、ビジネスを管理し、ビジネス 1 のパートナーとしてビジネスアイデンティティを使用しています。

### SaaS 製品でマルチテナンシーを採用すべき理由 #### マルチテナンシーでのスケールエンタープライズビジネスにとって、マルチテナンシーは、可用性、リソース管理、コスト管理、およびデータセキュリティの要件を効果的に満たすための鍵です。技術的なレベルでは、マルチテナントアプローチを採用することで、開発プロセスを合理化し、技術的な課題を最小限に抑え、スムーズな拡張を促進します。 #### 統一された体験の作成 SaaS 製品のルーツを調べると、それはさまざまなアパートを備えたビルに似ています。すべてのテナントは水、電気、ガスなどの共通のユーティリティを共有していますが、自分の空間やリソースの管理については独立したコントロールを保ちます。このアプローチはプロパティ管理を簡素化します。 #### テナントの分離によるセキュリティの確保マルチテナンシーアーキテクチャでは、異なるテナントのリソースとデータを共有されたインスタンス内で分離し保護する「テナント」という用語が導入されます。これにより、テナント間のデータと操作が区別され、安全を確保でき、同じ基盤リソースを使用していてもセキュリティが保たれます。 ## テナントの分離を達成するマルチテナントアプリケーションを語る際には、常に**テナントの分離**を達成する必要があります。これには、異なるテナントのデータとリソースを共有システム（たとえばクラウドインフラやマルチテナントアプリケーション）内で分離して保護することを意味します。他のテナントのリソースに対する許可されていないアクセス試行を防ぐことができます。説明は抽象的に感じられるかもしれませんが、テナントの分離の考え方とベストプラクティスをより具体的な例で説明します。 ### テナントの分離はマルチテナンシーの「共有」の考え方に反しないテナントの分離は必ずしもインフラストラクチャのリソースレベルの構築ではありません。マルチテナンシーと分離の領域では、一部の人々は分離をインフラストラクチャの実際のリソース間の厳格な分割と捉えています。これは通常、各テナントが別々のデータベース、コンピューティングインスタンス、アカウント、またはプライベートクラウドを持つモデルを導きます。共有リソースのシナリオ、たとえばマルチテナントアプリにおいては、分離を達成する方法は論理的な構築です。テナントの分離は、アクセスを制限するために“テナント”コンテキストを使用することに専念しています。これは、現在のテナントのコンテキストを評価し、そのテナントがどのリソースにアクセスできるかを決定するためにそのコンテキストを使用します。 ### 認証と承認は「分離」とは同じではない SaaS 環境へのアクセスを制御するために認証と承認を使用することは重要ですが、完全な分離には十分ではありません。これらのメカニズムはセキュリティパズルの一部に過ぎません。一般的な質問は、一般的な承認ソリューションとロールベースのアクセス制御を使用してテナント分離を達成できるかということです。問題は、マルチテナントアプリを構築できても、それをすることが分離戦略を実装するベストプラクティスを達成したと言えないことです。一般にお勧めしません。テナントの分離は認証と承認とは別物です。例を挙げると、SaaS システムの認証と承認を設定した状況を考えてみてください。ユーザーがログインすると、アプリケーションでの動作を指示する役割情報を含むトークンを受け取ります。このアプローチはセキュリティを高めますが、分離を保証するものではありません。 ### SaaS 製品のテナントを表すための「組織」を利用してテナントの分離を実現する認証と承認のみに依存しても、適切な役割を持つユーザーが他のテナントのリソースにアクセスするのを防ぐことはできません。したがって、「テナント」コンテキスト、テナント ID などを組み込んでリソースへのアクセスを制限する必要があります。ここにテナント分離が登場します。これは、壁、ドア、ロックのように明確な境界を設定するために、テナント固有の識別子を使用します。これにより、テナント間の区別と分離が保証されます。 ## マルチテナントアプリにおけるアイデンティティテナントの分離について話しましたが、アイデンティティはどうでしょうか？アイデンティティが「分離」されるべきかどうかはどう決定されるのでしょうか？「アイデンティティの分離」という概念には混乱があります。それは、大抵の場合、一般的理解では、1 つのリアルワールドユーザーが 2 つのアイデンティティを持つ状況を指すことがあります。 1. 両方のアイデンティティが単一のアイデンティティシステム内に存在する可能性があります。たとえば、サラが、シングルサインオン（SSO）で接続された個人用メールと企業用メールを登録しているかもしれません。 2. ユーザーが別々のアイデンティティシステム内で 2 つの別個のアイデンティティを維持している場合、その製品は完全に無関係です。これらのシナリオは、「アイデンティティが分離されている」と呼ばれることがあります。しかし、このラベルは意思決定に役立たない可能性があります。「アイデンティティの分離」が必要かどうかを決定するのではなく、以下を考慮してくださいビジネスまたは製品の一部が別々のアイデンティティシステムを維持する必要があるかどうかこの回答がシステム設計を指導することができます。マルチテナントアプリに関して短い回答は、ほとんどの場合、マルチテナントアプリでは、アイデンティティは共有されている一方で、各テナントのリソースは分離されています。マルチテナントアプリケーションにおいて、アイデンティティはテナント固有のリソースやデータとは異なり、複数のテナント間で共有されています。建物の管理者として考えてみてください。テナントのアイデンティティを管理するために 2 つの別々のリストを維持したくはないでしょう。テナントの分離を目指す際、「組織」という用語が繰り返し強調され、マルチテナントアプリケーションを構築するためのベストプラクティスと見なされることが多いです。「組織」の概念を使用することで、統一されたアイデンティティシステムを維持しながら、マルチテナントアプリケーションでテナントの分離を達成することができます。 ## より良いアクセス制御のための認可モデルを選択する ### 適切な認可モデルの選択と設計適切な認可モデルを選択する際には、次の質問を考慮してください： 1. B2C、B2B、または両方の種類の製品を開発していますか？ 2. アプリにマルチテナントアーキテクチャがありますか？ 3. ビジネスユニットによって決定される特定の分離レベルがアプリで必要ですか？ 4. 組織のコンテキストで定義される必要がある権限と役割は何ですか、そうでないものはどれですか？ ### Logto での異なる認可モデルを理解する #### ロールベースのアクセス制御 RBAC（ロールベースアクセス制御）は、ユーザーの役割に基づいて権限を付与し、リソースアクセスを効果的に管理する方法です。この一般的な手法は、アクセス制御の根幹をなし、Logto の認可機能の重要な要素です。総合的なアイデンティティ管理プラットフォームとして、Logto は、多様な製品アーキテクチャをサポートするために、開発者や企業向けに適合したソリューションを提供します。 #### API ロールベースのアクセス制御特定の組織に関連せず、コンテキスト制限が必要ない一般的な API リソースを保護するには、**_API RBAC_** 機能が理想的です。 API を登録して、各リソースに権限を割り当てます。その後、役割とユーザーの関係を通じてアクセスを制御します。 API リソース、役割、および権限は、統一されたアイデンティティシステムの下で「民主化」されています。これは階層が少なく、非常に深い分離レベルを必要としない B2C 製品で一般的です。 #### 組織ロールベースのアクセス制御 B2B およびマルチテナント環境では、テナント分離が必要です。これを実現するために、組織が分離のコンテキストとして使用されます。つまり、RBAC はユーザーが特定の組織に属する場合にのみ有効です。組織 RBAC は、API レベルではなく、組織レベルでのアクセス制御に焦点を当てています。これにより、長期的には、統一されたアイデンティティシステム内でありながら、組織レベルの自己管理に大きな柔軟性を提供します。組織 RBAC の重要な特徴は、他の組織に渡って役割と権限が通常同じであることであり、これが Logto の「組織テンプレート」を非常に意味のあるものにし、開発効率を向上させます。これは、SaaS 製品で一般的な実践である、アクセス制御ポリシーとアイデンティティがすべてのテナント（アプリテナント）間で一般的なインフラストラクチャコンポーネントであるというマルチテナントアプリの共有の考え方と一致しています。 ## 終わりにこの記事は、マルチテナントアプリの準備と設定を始めるために必要なすべてを提供します。今日、Logto を試して、組織を使用したマルチテナントアプリ開発のベストプラクティスを始めてみましょう。無料で Logto Cloud を試す