SaaS開発の落とし穴 ~マルチテナント編~

はじめに：マルチテナントアーキテクチャとは

Software as a Service (SaaS) では、複数の顧客 (テナント) に対して単一のアプリケーションを提供することが一般的に行われますが、この状態をマルチテナントと呼んでいます。

本記事を通して、マルチテナントアーキテクチャ特有の「落とし穴」について入門していきましょう。

① データ分離

マルチテナントのアーキテクチャは複数ありますが、デプロイモデルの観点では

プール型 : 複数のテナントが同じコンピュート/ストレージを共有する
サイロ型 : テナントごとにコンピュート/ストレージを用意する
ブリッジ型 / ハイブリッド型: 共有するリソースと共有しないリソースが混在する

のように分けられ、それぞれにメリット・デメリットがあります。

プール型のようにデータストレージを複数テナントで共有する場合、アプリケーションの実装不備によって、テナント間でデータが意図せず混在したり、他のテナントのデータへ不正アクセスできてしまったりする可能性があります。

他のアーキテクチャでも同様です。例えばテナントごとにデータストレージを分けるサイロ型は、プール型に比べて安全だと思ってしまいそうですが、ストレージの公開範囲やテナントごとのアクセス権限を誤るといったリスクは常に存在します。

対策

マルチテナントSaaSにおけるユーザーの認証・認可では、個人単位の識別や権限だけでは足りません。該当ユーザーがどのテナントに所属し、そのテナントにおいてどのような権限が割り当てられているのかを判断する情報 (テナントコンテキスト) が必要になります。

テナント間のデータ混在や不正アクセスを防ぐには、このテナントコンテキストに基づく厳格なデータ分離を設計段階から考慮する必要があります。

これにはデータベース固有のセキュリティ機能やID管理サービス（IDaaS）の活用も有効です。

例えば、代表的なRDBMSの一つであるPostgreSQLには、Row Level Security (RLS) という機能があります。RLSをテナントIDに対して有効化することで、データベース側でのテナント分離が可能になります。

② パフォーマンス

プール型のアーキテクチャなどにおいて、複数のテナントが計算資源 (CPUやメモリ)、データベース接続、ネットワーク帯域などのリソースを共有することを考えます。このとき、あるテナントの利用量が急増すると、他のテナントのパフォーマンスが低下するリスクがあります。

このように、あるテナントが他のテナントのパフォーマンスに影響を与えてしまう問題を、「ノイジーネイバー問題」といいます。

対策

このようなパフォーマンスの問題への対策としては、まずは負荷に応じて柔軟にスケールできるアーキテクチャ設計が基本となります。必要に応じてテナントごとのリソース制限 (スロットリング) の導入も検討します。

また、運用においては、テナントごとのリソース使用状況を継続的に監視し、異常を早期に検知することが重要です。

また、非常に利用量の大きいテナントのみ別リソースに切り出し、サイロとする方法も考えられます。この場合、後述のテナントオンボーディングなどにおいて複雑性が増すというトレードオフに注意する必要があります。

③ カスタマイズ

マルチテナントSaaSは、単一のアプリケーションを複数の顧客が使うことでスケールするビジネスモデルです。

しかしながら、SaaSを利用するテナントは、それぞれ独自の業務要件やブランディングに合わせて、UI、機能、ワークフロー、データ項目などのカスタマイズを要求することがあります。

これらのカスタマイズ要求に対してすべて答えようとすると、迅速な開発を阻害し、SaaSがスケールしづらくなる恐れがあります。特に、テナントごとにソースコードが別になるような設計をしてしまうと、SaaSのスケールメリットが大きく損なわれてしまいます。

対策

カスタマイズ要求に対応しつつ効率的な管理を維持するためには、テナントごとのソースコード分岐を伴わない手法が強く推奨されます。

例えば、フィーチャーフラグ (機能フラグ) を用いることで、テナントごとの機能の分岐が可能になります。

また、料金プランによって使える機能が異なるような設計も考えられます。

その他に、APIを提供することで、顧客が自らSaaSの機能を柔軟に組み合わせて利用することができるようになります。より発展的には、SaaSがModel Context Protocol (MCP) に対応することで、SaaS本体のUIにとらわれず、ユーザーごとにカスタマイズされたAIエージェントがSaaSの機能を扱える、といった新しい潮流もあります。