マルチテナントアプリのためのテナントモデル

私たちは頻繁に、特にサービスとしてのソフトウェア（SaaS）アプリケーションを開発する際に、マルチテナントアプリケーションの作成の重要性について耳にします。

「マルチテナントアプリ」の概念や、それを開発するために使用されるさまざまなモデルについては、いくらかの混乱があります。この記事では、それらの用語をより実践的な方法で詳しく見ていきました。

技術的観点からさまざまなテナントモデルを理解する#

シングルテナントアーキテクチャ#

シングルテナントアーキテクチャは、各顧客やテナントがアプリケーションまたはサービスの専用インスタンスを持つソフトウェアまたはクラウドコンピューティングモデルです。B2Bビジネスモデルの起源を見てみると、ソフトウェアの各インスタンスが1つの顧客または組織にのみサービスを提供するところから始まっています。

特徴#

• 分離: 各顧客またはテナントは、専用のリソース、データベース、構成で隔離された環境で操作します。
• カスタマイズ: シングルテナントアーキテクチャは、特定の顧客ニーズに応じたより大きなカスタマイズと柔軟性をしばしば可能にします。
• セキュリティ: 他のテナントのデータと混在しないため、データプライバシーとセキュリティが強化されています。
• スケーラビリティ: 各テナントのインスタンスを個別に調整することで、リソースと容量の拡張がより簡単になることがあります。
• メンテナンス: 各テナントの環境に対する変更が他のテナントに影響を与えないため、独立したメンテナンスと更新が可能です。
• コスト: 各テナントのために別々のインスタンスを維持する必要があるため、通常はインフラと運用費用が高くなります。

例#

• 専用ホスティング: 従来のWebホスティングプロバイダーは、各クライアントが独自のリソース、データベース、または設定を持つシングルテナントアーキテクチャを提供します。
• オンプレミスソフトウェア: カスタマーリレーションシップマネジメント（CRM）または人事管理システム（HRMS）などのエンタープライズレベルのソフトウェアアプリケーションは、データセキュリティとカスタマイズの要件が厳しい組織向けにシングルテナント展開オプションを提供します。
• プレミアムティア付きのSaaS: 一部のサービスとしてのソフトウェア（SaaS）オファリングでは、強化されたセキュリティ、コンプライアンス、またはカスタマイズを必要とする顧客向けにプレミアムまたはエンタープライズティアでシングルテナントオプションを提供します。

シングルテナントアーキテクチャは、コンプライアンスが最も重要な場合や、特定のセキュリティ要件を満たす必要があるシナリオで一般的に使用されます。たとえば、金融、医療、政府のように厳格な規制要件を持つ業界では、コンプライアンスを確保するためにシングルテナントソリューションを好むことがあります。

ただし、シングルテナントアーキテクチャは、各顧客のインスタンスが独自のインフラとメンテナンスを必要とするため、マルチテナントアーキテクチャと比較して、よりリソース集約型で管理が複雑になる可能性があることに注意してください。その結果、カスタマイズと隔離が非常に重要な、数が少ないが大きな顧客を持つアプリケーションに適しているかもしれません。

マルチテナントアーキテクチャ#

ソフトウェアマルチテナンシーは、単一のインスタンスのソフトウェアがサーバー上で動作し、複数のテナントにサービスを提供するソフトウェアアーキテクチャです。このように設計されたシステムは「専用」または「隔離」されているのではなく、「共有」されています。テナントとは、ソフトウェアのインスタンスへの特定の特権を持つ共通のアクセスを共有するユーザーのグループです。マルチテナントアーキテクチャでは、ソフトウェアアプリケーションは、テナントごとにインスタンスの専用の共有、データ、設定、ユーザー管理、テナントの個別の機能、および非機能的プロパティを提供するように設計されています。 -- Wikipedia

特徴#

• 共有リソース: 複数のテナントが同じインフラ、サーバー、データベース、ネットワークリソースを共有してリソース利用を最適化します。
• 分離: テナントのデータと設定は論理的に分離されており、データプライバシーとセキュリティを確保します。
• 規模の経済: マルチテナンシーは、オーバーヘッドが複数のユーザーに分散され、運用およびインフラコストが削減されるため、費用対効果があります。
• スケーラビリティ: アーキテクチャは、大規模なテナントとユーザーに対応するために水平または垂直にスケールできます。
• メンテナンス: 更新とメンテナンスは簡素化され、変更がすべてのテナントに一律に適用され、管理が簡素化されます。
• カスタマイズ: シングルテナントアーキテクチャと比較して、システム全体の一貫性を維持するためカスタマイズは通常より制限されていますが、一部のカスタマイズは可能です。

例#

• クラウドベースのSaaS: Google WorkspaceやSalesforceなど、ほとんどのサービスとしてのソフトウェア（SaaS）アプリケーションは、共有プラットフォーム上で複数の組織またはユーザーにサービスを提供するためマルチテナンシーを採用しています。
• 共有ホスティング: Webホスティングでは、共有ホスティングサービスが異なる顧客または組織に属する複数のWebサイトを同じサーバーでホストします。
• パブリッククラウドサービス: AWSやAzureなどのパブリッククラウドプロバイダーは、共有データセンター内で仮想化されたリソースを他のユーザーと分離し、多様なクライアントに提供します。
• 組織全体で共有されるインフラソリューション: たとえば、組織内の複数のビジネスユニットで使用される共有Kubernetesクラスターなど。

現実世界におけるマルチテナントアプリの再定義#

アーキテクチャの観点から定義を提供し、マルチテナントデザインとシングルテナントデザインを区別することが簡単になりました。しかし、これはより技術的な定義に傾いています。これらの定義を現実の開発環境で使用してテナントモデルを設計するとき、この思考方法は、マルチテナントアプリが純粋に共有されたマルチテナントインフラを持たなければならないと仮定しています。

しかし、ビジネスと製品は多様でさまざまなケースバイケースの要件を持っているため、すべてのケースに対応できる万能の解決策はありません。

テナントが共有インフラからリソースを使用しているが、特定のビジネスニーズのためにシステムの一部を専用に割り当てる必要があるというシナリオを想像してみてください。この専用部分はデータベース、インスタンス、または他のコンポーネントの組み合わせかもしれませんが、全体的なインフラは共有されています。これが混在テナントアーキテクチャの登場を意味します。

実際のSaaS製品開発では、製品が主に一般的なマルチテナンシーモデルで設計されている状況に会うことがよくあります。しかし、アーキテクチャやリソースの特定の面では「シングルテナンシー」アプローチに向かうことがあります。

AWSはこのコンセプトを伝えるために次のケースを使用しました：マルチテナンシーは広い概念であり、共有リソースとデータ隔離を達成するための正しい戦略を組み合わせて選択するためにケースバイケースであること。