メニュー
SaaSpresto株式会社はLogicMonitorの国内販売代理店です

SaaS開発において必須となるマルチテナント(マルチテナンシー)の有効性と注意点

サブスクリプションモデルが一般化する中で、SaaS型でサービスを提供するビジネスも増えつつあります。SaaS型のシステムを開発する際に必須ともいえるのが、マルチテナントモデルへの理解です。マルチテナントにはどのようなメリットがあり、またどのような点に注意しなければならないのでしょうか。この記事では、テナントという概念に加え、マルチテナントの有効性と注意事項について解説します。

目次

マルチテナントとは

以下ではまず、テナントという概念を紹介しつつ、マルチテナントの概要について解説します。

テナントという概念

SaaSにおいては、その性質上、数多くの企業や消費者に共通的にサービスを提供し、またそのデータを預かります。サービスの規模が拡大すれば、数千社や数百万ユーザーといった規模でサービスを運営することも珍しくありません。

多数のユーザーのリクエスト処理やデータ管理を実施するためには、「テナント」を意識した設計が重要です。ここでいうテナントとは、SaaSなどのサービスを利⽤するユーザーの契約単位を指します。テナントの単位は提供するサービスの内容や顧客の利用方法などにより、会社や部署、顧客ひとりひとりとさまざまなパターンが考えられます。

マルチテナントの概要とユースケース

サービスにおいて多数のテナントを抱えている状況においては、テナントごとに個別のインフラ環境を用意することには限界があります。そこで、複数のテナントを同一のインフラ環境に同居させることで、コスト効率性やスケーラビリティの確保を目指します。このような設計方法を、マルチテナントといいます。

同様のサービス内容を多数の顧客に提供するSaaSビジネスは、マルチテナントが有効である典型的なユースケースといえます。SaaS開発において、アジリティの向上やコスト最適化を実現するためには、マルチテナントの理解と活用は必須となります。

シングルテナントとの比較

テナントごとに個別にインフラ環境を用意するケースを、マルチテナントと対比させてシングルテナントといいます。

従来、システムの多くはシングルテナントにて構築・運用されてきました。シングルテナントはマルチテナントと比較すると情報漏洩リスクが低い点やコンピューティングリソースを占有できる点などにメリットがありますが、コスト面やビジネスとしてのスケーラビリティの低さがデメリットとなります。

マルチテナントとシングルテナントはどちらかが優位というものではありません。サービスの特性や求められるセキュリティレベル、取り扱う業務の重要性など様々な観点を考慮して、マルチテナントか、シングルテナントか、もしくはハイブリット型という選択肢も含めて検討しなければなりません。

なぜマルチテナントが有効なのか

「SaaS開発においてマルチテナントの理解は必須」とご紹介しましたが、なぜマルチテナントは有効なアーキテクチャなのでしょうか。以下では、マルチテナントの有効性について詳細に紹介していきます。

コスト効率性

まずは、コスト効率性の観点です。複数のテナントを同一のインフラ環境に同居させることで、インフラストラクチャリソースを共有することができます。これにより、インフラコストを削減可能です。

一般的に、テナントによってサービスの利用方法やデータ利用量などは様々です。シングルテナントでは、各テナントに対してある程度のバッファを持たせた設計が必要ですが、マルチテナントでは全テナントでバッファを共有することができます。これにより、バッファを最低限とし、また無駄な待機リソースを減らすこともできます。

スケーラビリティと俊敏性

多数の顧客に利用してもらうことでビジネスを拡大するSaaSビジネスにおいては、スケーラビリティが重要です。

マルチテナントを採用することでテナントごとの個別管理を減らすことができます。テナントごとに個別にインフラ環境を構築したり、データベーススキーマを変更したりすると、それらのメンテナンスだけでかなりのエンジニアリソースが割かれてしまいます。限りある人的リソースの中でビジネスをスケールさせていくためには、個別管理を減らし共通的な環境を提供するべきです。

また、マルチテナントを採用しつつ初期セットアップ作業を共通化することで、テナントごとのアプリケーションやインフラ環境のセットアップを効率化、もしくは自動化できます。これにより、俊敏性を確保しやすくなります。

ユーザー側の視点でも、すぐにサービスを利用開始できることにはメリットがあります。SaaSは一般的に「リテンションモデル」というビジネスモデルに分類されますが、リテンションモデルにおいては「早期にその価値を届けること」が重要視されます。サービスを利用しようと思ったユーザーが、すぐにその価値を理解できことが重要となります。

メンテナンス性

マルチテナントにおいては、メンテナンス性の面でもメリットがあります。共通のソースコードで多数の顧客にサービスを提供するため、プログラムの修正やリリースなどの作業を迅速に行うことができます。

多数の顧客を抱えることになるSaaS等のビジネスにおいては、できる限りシステムを共通化することが望ましいといえます。個別の顧客ごとに機能やインフラストラクチャのカスタマイズをすることは、個別のアップデート対応が発生するなど保守コスト増加の原因となります。

メンテナンスコストを抑えることは、ビジネスの成功という観点でも重要ですし、限られた人的リソースで運用を行うためにも重要です。

テナント分離の実現方法

ひとつのインフラ上に様々な顧客が存在するマルチテナントにおいては、当然ながら各テナントの情報漏洩や処理の混在などのリスクがあります。このリスクを避けるために、テナント間の分離は必須です。以下では、具体的にどのようにテナントを分離するのか紹介します。

主なテナント分離パターン

各テナントの独立性を確保するために、幾つかの分離パターンが知られています。具体的には以下のとおりです。

プールモデル

複数のテナントを共通のインフラで扱う方法であり、マルチテナントを実現するための一般的な方法です。インフラコストやスケーラビリティに優れますが、テナント境界を厳格に設定しないと、セキュリティ上のリスクが発生します。

サイロモデル

テナントごとに個別のリソースを準備する方法であり、上述したシングルテナントを実現する方法です。たとえば、通常はプールモデルを採用しつつ、特定の上位プランを契約する顧客にたいしてはコンピューティングリソースを占有できるように、サイロモデルを採用することも考えられます。

ブリッジモデル

サーバーは共有化しつつ、データベースは個別に構築するなど、サイロモデルとプールモデルの中間となるパターンです。セキュリティ面で重要なデータ部分の機密性を高めつつ、コンピューティングリソースについては効率化を図ることができます。

これらの分離パターンを参考にしつつ、提供するサービスや掛けられるコストなどの観点で最適なアーキテクチャを選択します。

主なデータ分離パターン

同様に、データの分離についてもいくつかのパターンが知られています。

データベース分離

個々のテナントごとにデータベースを構築します。最も分離レベルが高い選択肢です。

テーブル分離

テナントごとにテーブルを作成して分離します。

行分離

共通のテーブル中に、テナントIDなどを設定することで分離します。分離レベルは低いものの、効率性が高い選択肢です。

データベース分離・テーブル分離・行分離の順に、徐々にデータの機密性は下がっていくものの、リソース効率は良くなります。マルチテナントにおいては、セキュリティなどを意識しつつどのようなデータ分離を行うか検討する必要があります。

マルチテナントにおける注意事項

リソース効率やコスト効率などにメリットがあるマルチテナントですが、注意事項も存在します。マルチテナントシステムの開発においては、具体的に以下の点について考慮が必要です。

セキュリティ対策

マルチテナントにおいてインフラを共有する際に、適切に分離を行わなければ情報漏洩などの問題が発生します。十分にセキュリティが考慮されたコードとなっていなかったり、開発者や運用者がミスをしたりというケースもあれば、漏洩したトークンからデータにアクセスする悪質な攻撃まで、あらゆる可能性が想定されます。

特にマルチテナント構成においては、サービス開発の初期段階からテナント間のデータ漏洩防止を明確に設計しておく必要があります。テナントの境界を意識しなければ、重大なインシデントを引き起こすことになるリスクとなります。

ノイジーネイバー対策

マルチテナントにおいてはインフラを共有するため、特定のテナントがインフラリソースを大量に消費した場合に他のテナントのサービス利用に影響を及ぼすことになります。これは、ノイジーネイバーの問題と呼ばれており、マルチテナントシステムにおいては対処が必要な課題となります。

マルチテナントにおいては、ノイジーネイバー対策もセットで行う必要があります。たとえば、問題となっているテナントを個別のインフラへ移動させることが一つの解決策となります。もしくは、暫定的な対応としてコンピューティングリソースを一時的に増加させることも検討できるでしょう。

その他、利用可能なコンピューティングリソース量に応じた複数の料金プランを用意することで、テナントのリソース使用量を調整することも有効です。

モニタリングの重要性

どのようなシステムにも言えますが、マルチテナントにおいてもモニタリングは重要です。アプリケーションレベルでの可視性を向上させつつ、ログやメトリクス、トレースなどの情報を収集し、運用監視ツールなどを活用して可視化していく取り組みが必要です。

加えて、クラウド環境を利用している場合には、コストの可視化も大切です。SaaSをビジネスとして成り立たせるためには、正確なコスト測定と必要に応じた改善が必要でしょう。

SaaSのモニタリングを実現するLogicMonitorとは

利用者数が多く、また利用するインフラの規模も大きくなるSaaSの運用管理においては、適切なモニタリングが重要となります。そこで検討したいのが、充実した機能を持った運用監視ツールの採用です。

LogicMonitorは、インフラからアプリまで一元的な監視を実現するクラウド型IT統合運用監視サービスです。システムの稼働状況の可視化はもちろんのこと、自動化やITリソースの将来予測など高度な機能も備えます。

LogicMonitorはエージェントレスで利用でき、またAWSやAzureなどSaaSの運用基盤としてよく利用されるサービスに対応したテンプレートも用意されています。ビジネス環境やユーザーニーズの変化に追従していくために、SaaS開発には迅速さが求められますが、このようにLogicMonitorは導入や設定も容易に行うことができるため、俊敏性を維持したサービスの運用を実現することができます。

あわせて読みたい
IT統合監視サービス「LogicMonitor」サービス概要資料 日本を含む2,000社以上での導入実績がある、IT統合監視サービス「LogicMonitor」のサービス概要資料です。 以下のような課題をもつ企業におすすめです。 現状、監視ツー...

まとめ

この記事では、SaaS開発において必須となるマルチテナントについて解説を行いました。簡単に利用を開始できるSaaSは、裏を返せば簡単に他のサービスへ移行されてしまうことを意味します。変化が激しい時代において、ユーザーのニーズに対して迅速な対応を行っていき、SaaSをビジネスとして成功させるためにも、マルチテナントのアーキテクチャを採用することは、SaaS開発において第一の選択肢となるでしょう。

一方で、マルチテナントにおいてはモニタリングも重要となります。モニタリングに関する可視化やアラーティングなどにおいては、できるだけ高機能なツールを選択するべきでしょう。

日本を含む2,000社以上での導入実績がある、
IT統合監視サービス「LogicMonitor」
のサービス概要資料はこちらから

以下のような課題をもつ企業におすすめです。

  • 現状、監視ツールの複数導入でコスト・運用面で負荷が大きく、1つのツールで統合監視したい
  • AIOpsやオブザーバビリティの考え方を取り入れた最先端のSaaSツールで、運用のDXを推進したい
  • マルチテナント機能やシンプルな価格体系で、MSP事業者としてスムーズにサービスを提供したい
目次