multi-tenantアーキテクチャ：スケーラブルなSaaSの土台

SaaSを構築しているなら、「multi-tenant」という言葉はすぐに出てきます。そしてこれは些細な専門用語ではありません。あなたのプロダクトがどうスケールするか、運用にいくらかかるか、顧客のデータがどれだけ安全かを左右する判断です。明快に説明しましょう。

multi-tenantとは

multi-tenant（マルチテナント）とは、アプリケーションの単一インスタンスが同時に多くの顧客（テナント）に提供しつつ、各顧客のデータを分離してプライベートに保つことを意味します。集合住宅のようなものです。建物は1つですが、各入居者は閉じた自分の空間を持ちます。代替手段であるsingle-tenantは、顧客ごとにアプリ全体のコピーを用意することになります。最初はシンプルですが、規模が大きくなると高くつき手に負えなくなります。

なぜそれほど重要なのか

multi-tenantこそが、SaaSモデルを収益性のあるものにします。単一のシステムを保守し、改善を全員に一度にリリースし、インフラを効率的に活用できます。優れたmulti-tenantアーキテクチャなら、プロダクトを書き直すことなく10人から10,000人の顧客へ移行できます。劣ったものは、成長し始めたまさにそのときに、つらい書き直しを強います。

モデル：データをどう分離するか

各顧客のデータを分離するには主に3つのアプローチがあり、コスト、分離度、複雑さのバランスがそれぞれ異なります。

• 共有データベース：すべての顧客が同じテーブルにあり、識別子で分けられる。最も安く効率的だが、データを混同しないよう細心の注意が必要。
• 顧客ごとのスキーマ：同じデータベースに、顧客ごとに分かれたスキーマ。分離とコストのバランス。
• 顧客ごとのデータベース：各顧客が自分のデータベースを持つ。最大の分離（非常に機密性の高いデータに理想的）だが、運用コストは高い。

データ分離とセキュリティ

multi-tenant SaaSの最大のリスクは、ある顧客が別の顧客のデータを見てしまうことです。だからこそ分離は任意ではありません。データ層で設計し、各リクエストでアクセス制御により補強します。優れたmulti-tenant設計は、あるテナントが別のテナントの情報にアクセスすることを技術的に不可能にし、そのために特別にテストされます。

スケーラビリティとコスト

選んだモデルが、何年にもわたるインフラ費用を決めます。共有データベースは顧客あたりのコストが最も低く、だからこそ大量の顧客を抱えるSaaSで最も一般的です。より分離されたモデルは顧客あたりのコストが高くなりますが、厳格な分離を求める規制業界（医療、金融）に販売する場合には正しい選択肢です。

それぞれのモデルを選ぶべきとき

万能の勝者はいません。多くの顧客を抱えるB2Cや中小企業向けのSaaSには、共有データベースが最適なことが多いです。少数の大口顧客と機密データを抱えるエンタープライズSaaSには、スキーマごとまたはデータベースごとの分離が見合います。重要なのは最初に決めることです。本番環境に顧客がいる状態でモデルを移行するのは高くつくからです。

multi-tenant設計でよくあるミス

最も高くつく失敗はたいてい2つです。「念のため」最も分離されたモデルを選び、必要もないのにインフラ費用を跳ね上げること。あるいはその逆で、堅固な分離なしに共有データベースでデータを混在させ、顧客間の漏洩のリスクを冒すこと。もう一つの典型的なミスは、判断を「後回し」にすることです。本番環境に顧客がいる状態でモデルを変更するのは、存在する中で最も高くつき危険な作業の一つです。あなたの顧客タイプとセキュリティ要件を踏まえて早期に決め、分離を付け足しではなく要件として設計しましょう。

AxiomTechでは、あなたの顧客タイプとセキュリティ要件に応じてSaaSのmulti-tenantアーキテクチャを設計し、効率的にスケールし、各顧客のデータが常に分離されているようにします。