「テナント」は、ソフトウェアアーキテクチャについての議論で頻出する用語です。クラウドベースのアプリケーションの購入を検討している場合でも、社内ソフトウェアプラットフォームを構築する場合でも、マルチテナントかシングルテナントかを選択しなければなりません。しかし、これらの言葉の本来の意味はどのようなものでしょうか。もう一方と比べてどのようなメリットがあるのでしょうか。どちらの方が実装が困難なのでしょうか。これらについて見ていきましょう。
ソフトウェアアプリケーションがサービスを提供する対象となる顧客やユーザグループは、多岐にわたる傾向があります。このとき、各顧客/ユーザグループをテナントと考えることができます。マルチテナントは、1つのソフトウェアの導入で複数のテナントにサービスを提供できるアーキテクチャです。基礎となるリソースはすべてのテナントで共有されますが、各テナントにはプライバシーと特定の設定のカスタマイズが保証されます。
一方、シングルテナントアーキテクチャでは、インスタンスごとに1つのテナントだけがサポートされます。各テナントは個別の専用のリソースセットを受け取ります。また、シングルテナントでは、ソフトウェアベンダーは、顧客の個別のニーズに合わせて構築された製品を提供することができます。
例えば、マルチテナントのWebアプリケーションでは、同じWebサーバがすべての顧客の要求を処理します。同じデータベースを使用して、すべての顧客のデータを保存します。ただし、顧客は、アプリケーションの外観やモードなど、設定可能な部分をカスタマイズすることができます。ソースコードのカスタマイズを要求することはできません。
マルチテナントの導入をアパートの建物のように考えることができます。この同じ建物が、それぞれ独立したアパートの部屋を通じて住まい、セキュリティ、ユーティリティを異なるテナントに提供します。同様に、1つのソフトウェアアプリケーションのインスタンスが、どの顧客のプライバシーやサービス提供も侵害することなく、さまざまな顧客のニーズに対応します。
アパートの建物が個別の住居(アパートの一室)を各テナントに割り当てるように、マルチテナントアプリケーションでは、各顧客用に個別のリソースを確保することができます。例えば、アプリケーションは、異なる顧客の要求を処理するためにさまざまなプロセスを生成できます。また、異なる顧客のために、同じデータベース内に個別のテーブルを作成することもできます。
マルチテナントアプリケーションは導入が容易です。ソフトウェアアプリケーションの1つのインスタンスを設定するだけで、すべての顧客にサービスを提供できます。
マルチテナントアーキテクチャでは、計算およびハードウェアのリソースを効率的に使用できます。
所有およびメンテナンスコストが複数の顧客で共有されるため、総合的なコストが削減されます。
通常、新たな顧客を追加するには設定を変更するだけで、新たなリソースをプロビジョニングする必要はありません。
ソフトウェアインスタンスが1つの方が、メンテナンス、保護、最適化がはるかに簡単です。
効率的で将来性のあるマルチテナントアーキテクチャの設計と開発は困難な場合があります。
セキュリティの侵害が発生した場合、すべての顧客のデータがリスクに曝される可能性があります。
リソースが完全に分離されているため、最も適切な性能とスループットが実現されます。
顧客データを切り離すことで、複数の顧客に影響を与えるサイバー攻撃のリスクが低減されます。
すべての顧客が製品を最大限カスタマイズすることができます。
ひとつの顧客のデータだけが関連しているため、シングルテナントアプリケーションの方が移行が簡単です。
顧客と同じ数のソフトウェアインスタンスがあるため、リソースが十分に活用されないことが頻繁にあります。
シングルテナントアプリケーションでは各顧客が個別のインスタンスを受け取るため、導入に多くの時間がかかります。
所有およびメンテナンスコストも大幅に大きくなります。
新規顧客を追加するには新しいインスタンスを追加する必要があります。つまり、リソースとコストが増えることになります。
複数のソフトウェアインスタンスのメンテナンス、保護、最適化は難しく、非常に大きいチームが必要になります。
ソフトウェアアプリケーションの構築にあたっては、以下のような場合にマルチテナントを使用します。
コスト効率の高いクラウドサービス環境で複数の顧客をサポートしたい場合
大規模なインフラストラクチャを希望しない場合
導入、メンテナンス、サポートのための大規模なチームがない場合
円滑な拡張性を望む場合
経験豊富な開発者とアーキテクトのチームがある場合
ソフトウェアアプリケーションの購入にあたっては、以下のような場合にマルチテナントを選択します。
所属組織がリソースやデータの共有を禁止していない場合
製品の設定のカスタマイズとその既存の機能セットで対応できる場合
性能とコストの最適なバランスを見つけたい場合
ソフトウェアアプリケーションの構築にあたっては、以下のような場合にシングルテナントを使用します。
導入、メンテナンス、サポートのための大規模なチームがある場合
顧客の数が多くない場合
大規模なインフラストラクチャを使用できる場合
予算に関する制約がない場合
比類のない性能とスループットを提供したい場合
経験豊富な開発者とアーキテクトのチームがない場合
ソフトウェアアプリケーションの購入にあたっては、以下のような場合にシングルテナントを選択します。
企業ポリシーでリソースとデータの共有が許可されていない場合
個別のニーズに応じて製品を完全に変換したい場合
わずかな性能向上に対して大きなコストが発生してもかまわない場合
いずれのアーキテクチャパラダイムにもメリットとデメリットがありますが、ほとんどの場合はマルチテナントの方が選択肢として優れています。適切に実施すれば、リソースの利用を最適化でき、メンテナンスがはるかに容易な、将来性のあるプラットフォームを構築することができます。
マルチテナントはクラウドファーストのアプローチでもあります。ほとんどのクラウドプラットフォームは、それ自体がマルチテナントアーキテクチャ上に構築されています。同じ基本ハードウェアリソースを使用して非常に多くの顧客をサポートしています。
ただし、お客様の業界や組織に厳格なセキュリティガイドラインがある場合(医療機関、金融など)、シングルテナントアーキテクチャでお客様のニーズをより適切に満たすことができます。