マルチテナントとは、単一のソフトウェアアプリケーションインスタンスが複数の顧客（テナント）にサービスを提供するアーキテクチャスタイルです。これは、複数のユーザーや組織がデータを分離した状態で同じアプリケーションを利用するSaaS（Software as a Service）アプリケーションの台頭とともに普及しました。マルチテナントが登場する以前、SaaSアプリケーションの主流はシングルテナントアーキテクチャであり、各顧客がアプリケーションの専用インスタンスを保有していました。これらの概念を詳しく見ていきましょう。

目次

• テナントとは？
• シングルテナントとマルチテナント
• マルチテナントの深掘り
• マルチテナントにおけるスケーラビリティ
• Next.js におけるマルチテナント

テナントとは？

テナントとは、単に（ワークスペース内の）ユーザー、ユーザーグループ、または組織全体であり、共有アプリケーションやシステムを利用する存在です。 これらのテナントは、データの分離と安全性を確保するために効果的に管理される必要があります。これらすべては、テナント管理におけるシングルテナント方式とマルチテナント方式に分類されます。

これらの概念についてさらに掘り下げてみましょう。

シングルテナント vs マルチテナント ⚒️ ️

• シングルテナントとは、各テナントがアプリケーション、リソース、ストレージ、データベースの独自のインスタンスを保有することを意味します。各テナントは他のテナントの存在を完全に認識せず、完全に隔離されています。
• 各テナントが専用のリソースを保有するため、セキュリティとカスタマイズ性のレベルは高くなります。
• このアーキテクチャの欠点は、サービスプロバイダーがテナント固有のリソースに対応する必要があるため、維持コストが高額になることです。
• 一方、マルチテナントとは、データの論理的な分離に基づき、複数のテナントがアプリケーション、リソース、ストレージ、データベースの同一インスタンスを共有することを意味します。
• これによりサービスプロバイダーはリソースを最適化し、テナントに費用対効果の高いソリューションを提供できます（いわばウィンウィンの関係です）。
• マルチテナントには、データ分離、セキュリティ上の懸念、カスタマイズの制限といった固有の課題が存在します。

マルチテナントの深層を探る 🌊

ビルとアパートの比喩 🏢

マルチテナントを議論する際によく用いられる比喩が、アパートの建物と個々の住戸です。

• アパートビルは、複数のユーザー（テナント）が利用する共有アプリケーションまたはシステムを表します。
• ビル内の各アパート/ユニットは、1人のテナントを表します。
• ビルには電気、水道、セキュリティなどの共有インフラがあり、すべてのテナントが利用します。これはマルチテナントアーキテクチャにおけるストレージ、コンピューティング、データベースの共有リソースに類似しています。
• 各アパートには、そのテナント専用の独立した居住空間、キッチン、バスルームなどがあります。これは、マルチテナントアーキテクチャにおいて各テナントが共有アプリケーション内で独自のデータとリソースを保有する仕組みに類似しています。
• この比喩は、マルチテナントの主な利点であるコスト効率性、効果的なリソース利用、保守性の容易さを浮き彫りにします。

なぜマルチテナントなのか？ ❓

マルチテナントとは、テナントがデータを共有するのではなく、データを論理的に分離したまま同じアプリケーションインスタンスを共有することを意味します。 以下のような場合に適しています：

1. コストを抑えることが優先される場合
2. インフラの保守・管理に費やす時間を削減したい場合

マルチテナントアプリケーションをシングルテナントアプリケーションのように動作させる（専用リソースを提供することで）ことは、その逆よりもはるかに容易です。

騒がしい隣人問題 🏘️

• マルチテナントの課題の一つは「騒がしい隣人」問題であり、あるテナントの過剰なリソース使用が他のテナントのパフォーマンスに影響を与える可能性があります。
• マンションで一世帯が大音量のパーティーを開き、他の世帯の迷惑になる状況を想像してみてください。同様に、マルチテナントアーキテクチャでは、一テナントが過剰なリソースを消費すると、他のテナントのパフォーマンス低下を招く可能性があります。
• これは、あるテナントがCPU、メモリ、ネットワーク帯域幅、ストレージを過剰に使用し、同じリソースを共有する他のテナントに悪影響を与える場合に発生します。
• これを軽減するには、騒がしい隣人を隔離し、専用のリソースを提供することで個別に処理できます。これにより、他のテナントのパフォーマンスは影響を受けません。
• 騒がしい隣人を効果的に特定・管理するには、定期的な監視とアラートメカニズムが有効です。

マルチテナント環境におけるカスタマイズの取り扱い ⚙️

• カスタマイズは、すべてのテナントが同一のアプリケーションインスタンスを共有するマルチテナント環境では課題となり得ます。
• 各テナントが独自のインスタンスを持つシングルテナント環境のように単純ではありません。マルチテナントでは、他のテナントに影響を与えないよう、カスタマイズを慎重に扱う必要があります。
• これを実現する方法の一つが機能フラグの使用です。
• 機能フラグを使用すると、他のテナントに影響を与えることなく、個々のテナント向けに特定の機能を有効化または無効化できます。
• その他のアプローチとしては、設定ファイルやデータベース設定を使用してテナント固有のカスタマイズを管理する方法があります。
• マルチテナント環境では、カスタマイズ性と保守性のバランスを取ることが重要です。これにより、アプリケーションのスケーラビリティと扱いやすさを維持できます。

テナントのルーティング方法 🚏

マルチテナントアプリケーションにおけるテナントのルーティングは、アプリケーションの要件やアーキテクチャに応じて様々な方法で実現できます。

一般的な方法には以下のようなものがあります：

• サブドメインルーティング：このアプローチでは、各テナントに固有のサブドメインが割り当てられます。例：org1.foo.com、org2.foo.com など。アプリケーションはサブドメインでテナントを識別し、それに応じてリクエストをルーティングします。この手法は多くのSaaSアプリケーションで採用されています。Sentryはユーザー/組織向けにサブドメインルーティングを使用しています。
• パスベースルーティング: このアプローチでは、各テナントはURL内の特定のパスによって識別されます。例えば、foo.com/org1、foo.com/org2などです。アプリケーションはパスを使用してテナントを識別し、それに応じてリクエストをルーティングします。Dub、Linearはパスベースルーティングアプローチを採用しています。

サブドメインとパスベースルーティングのSEOへの影響 📈

サブドメインは、ウェブサイトの順位や総合的なSEOパフォーマンスへの影響に関して懸念されることがよくあります。 検索エンジンはサブドメインをメインドメインとは別個のエンティティとして扱います。つまり、各サブドメインにはバックリンク、コンテンツ最適化、権威性構築など、独自のSEO対策が必要です。 一方、パスベースルーティングでは、すべてのコンテンツがメインドメイン下に配置されるため、メインドメインのSEO上の利点を継承できます。

テナントが明確なアイデンティティやブランディングを必要とする場合（例：異なる製品やサービス）、サブドメインがより適切な選択肢となります。一方、SEOが主要な関心事となるアプリケーション（例：コンテンツプラットフォーム、ブログなど）には、パスベースルーティングがより適しています。

マルチテナントにおけるスケーラビリティ 📐

マルチテナントを扱う際に留意すべき核心的な要素は、データ分離とリソース管理の2点です。

1. データ分離:

これは単純に、私（テナントとして）が他のテナントのデータにアクセスできず、逆もまた然りであることを意味します。これはテナントのセキュリティとプライバシーにとって重要です。データ分離を実現する主な手法は以下の通りです：

1. サイロモデル／データベースレベル分離：各テナントが独自のデータベースインスタンスを保有。最高レベルのデータ分離を実現するが、維持コストが高くなる。
2. 分離スキーマモデル／スキーマレベル分離：共有データベース内に各テナント専用のスキーマを配置。データ分離とリソース利用効率のバランスに優れる。
3. プールモデル / 行レベル分離: 全テナントが同一データベースとスキーマを共有するが、テナント識別子を用いてデータを論理的に分離する。中小規模のマルチテナントアプリケーション構築において、最も費用対効果が高く一般的な手法である。

データ分離手法の選択は、セキュリティ要件、カスタマイズニーズ、スケーラビリティ目標、予算などの要因によって決まります。

2. リソース管理:

これは、マルチテナントアーキテクチャにおいて、共有リソース（コンピューティング、ストレージ、ネットワークなど）がテナント間でどのように割り当てられ管理されるかを指します。

先述した「ノイジーネイバー問題」は、マルチテナントにおけるリソース管理の課題の一つであり、あるテナントの過剰な使用が他のテナントのパフォーマンスに影響を与える可能性があります。

この問題に対処するには、リソースを効果的に管理し、テナントの要件と使用パターンに基づいて割り当てる必要があります。 これを実現することで、アプリケーションのパフォーマンス、コスト効率、運用効率、スケーラビリティが向上します。

実世界の事例 🌐

マルチテナントは、プロジェクト管理、CRM、コンテンツ管理、LMSなど様々な分野で広く利用されています。 以下のような多くの人気SaaSアプリケーションで採用されています：

• Slack: 複数の組織が同じSlackアプリケーションを利用しながら、データを分離して保持します。
• Shopify: 複数の販売者が同じShopifyプラットフォームでオンラインストアを管理します。
• HubSpot: 複数の企業が同じHubSpot CRMプラットフォームで顧客関係を管理します。

Next.js におけるマルチテナント 🚀

Next.js は、マルチテナントアプリケーションの構築に使用できる人気の React フレームワークです。

カスタムサブドメインルーティングと、テナント固有のロジックを処理するミドルウェアの使用によってこれを実現します。

Lee Robinson による Next.js でのマルチテナント実装の動画をご覧ください: Next.jsでのマルチテナントSaaS

マルチテナントデモ: https://vercel.com/templates/next.js/platforms-starter-kit

Github: https://github.com/vercel/platforms

まとめ

• マルチテナントとは、複数のテナント／ユーザー／組織が同一の基盤アプリケーションインスタンスを共有しつつ、データを論理的に分離するアーキテクチャである。
• コスト効率、効果的なリソース活用、保守性の向上を実現します。
• 課題としては、データ分離、セキュリティ上の懸念、カスタマイズの制限、リソース管理などが挙げられます。
• テナントのルーティング手法にはサブドメインルーティングとパスベースルーティングなどがあり、それぞれ長所と短所があります。
• Next.jsではカスタムサブドメインルーティングとミドルウェアを用いてマルチテナントアプリケーションを構築できます。