3.14 マルチテナンシーとSaaSアーキテクチャ

概要と動機

マルチテナンシーとは、ソフトウェアの一つのインスタンスを動かして、多くの別々の顧客に同時に仕える実践で、各顧客のデータと設定を論理的に分けながら、同じコードと、しばしば同じインフラを共有します。各顧客がテナントです。この一つの考え方が、ソフトウェア・アズ・ア・サービス(SaaS)、つまりインストールするコピーではなく、動いているアプリケーションへのアクセスを売るモデルの、経済的なエンジンです。千のテナントが同じデプロイを共有するとき、パッチを一度当て、一つのシステムをスケールし、次の顧客の限界コストはゼロに近づきます。だからこそ、よく作られたマルチテナントの製品は、二人のスタートアップと十万席の企業に同じコードベースから仕えられ、選んだテナンシーのモデルが、利益率、セキュリティの姿勢、運用の負荷を何年も形づくるのです。

大きなチームにとって、賭け金はコストより深く及びます。マルチテナンシーは、アーキテクチャの中心に厳しい要件を置きます。テナントAは、どんなバグ、競合、誤設定のもとでも、テナントBのデータを決して見てはならない。一つのテナント間の漏洩が会社を終わらせえます。同時に、共有の要点全体は効率なので、あらゆる設計上の決定は、強い隔離(より安全でより高価)と密な共有(より安くよりリスクが高い)の間の範囲にあります。これを正しくすることが、優雅にスケールする製品と、インフラで破産するか見出しになる製品との違いです。本章は、クラウドアーキテクチャ(3.11章)の上に築かれ、データアーキテクチャ(3.4章)とクラウドのセキュリティ(4.3章)に大きく依拠し、スケーラビリティとレジリエンス(3.5章)とコストの帰属(9.4章)につながります。

企業と政府はハードルをさらに上げます。企業の買い手は、契約上のデータ保証を交渉し、自分の階層に専用の隔離を求め、ダウンタイムなしに環境間を移行してくれることを期待します。政府は、データ所在地の法律、分類に駆動される分離、そして各機関が独自の監査境界を持つ独自のテナントであるというしばしばの要件を加えます。ここでのテナンシーの決定は実装の詳細ではありません。データを託してくれたすべての顧客へのコミットメントです。

主要原則

隔離はスイッチではなく範囲である。 サイロ、プール、ブリッジのモデルは、効率と分離を取引します。一度にすべてではなく、階層ごと、リソースごとに選びます。
テナントの文脈は神聖である。 すべてのリクエスト、クエリ、ログ行、バックグラウンドのジョブはテナント識別子を運ばなければならず、すべてのデータアクセスはそれでスコープされなければなりません。
テナント間の漏洩が、最も重要な失敗である。 一つの欠けたフィルターが別のテナントのデータを露出できないよう設計します。一つのWHERE句ではなく、多層防御で。
うるさい隣人は、アーキテクチャの問題である。 クォータと公平性がなければ、一つの重いテナントが全員を劣化させます。起こる前に計画します。
テナントごとの設定はスケールし、テナントごとのコードはスケールしない。 フォークではなく、データとフラグで製品を曲げます。
テナントのライフサイクルは製品の機能である。 オンボーディング、プロビジョニング、オフボーディング、データのエクスポートは、第一級で、自動化され、監査可能でなければなりません。
帰属できないものは管理できない。 オブザーバビリティとコストをテナントで切り分けなければ、信頼性と利益率の両方で盲目的に飛ぶことになります。

推奨事項

隔離対効率の範囲に沿って、階層ごとにテナンシーのモデルを選ぶ

三つのモデルが範囲を固定します。サイロ(専用)モデルでは、各テナントが独自の隔離されたスタックを得ます。別のコンピュート、別のデータベース、ときに別のアカウントやネットワーク。隔離は最強で、バグの影響範囲は一つのテナントですが、顧客ごとのアイドル容量を払い、多くのコピーを運用します。プール(共有)モデルでは、すべてのテナントが同じコンピュートとデータベースを共有し、ロジックとテナント識別子だけで分けられます。効率は最高で、テナントの限界コストはゼロに近いですが、隔離は完全にコードの正しさに依存します。ブリッジ(ハイブリッド)モデルは両者を混ぜます。共有のコンピュートとテナントごとのデータベース、あるいは小さなテナントには共有のプール、大きなまたは規制されたテナントには専用のサイロ。

製品全体で一つのモデルを選んではいけません。正しい答えは通常、価格の階層に対応するブリッジです。小さなテナントの長い尾を、その経済性が成り立つ効率的な共有プールに置きます。隔離と契約上の保証にお金を払う企業顧客のために、専用またはシングルテナントのデプロイを、プレミアムの階層として提供します。「どのテナントが何を共有するか」は、セキュリティ、営業、財務のチームがすべて依存する主張なので、そのマッピングをアーキテクチャ決定記録(3.11章)として書き留めます。

データを意図して分割し、テナントのスコープを忘れられないものにする

データこそマルチテナンシーが生き死にする場所なので、分割の選択を、中核のデータアーキテクチャの決定(3.4章)として扱います。三つの戦略がテナンシーのモデルに対応します。テナントごとの別のデータベースは、最強の隔離、容易なテナントごとのバックアップと復元、単純なデータのエクスポートを、運用すべき多くのデータベースと展開すべきスキーマ移行というコストで与えます。共有データベース内のテナントごとの別のスキーマは中間の道です。一つのサーバー、論理的な分離、それでも移行すべき多くのオブジェクト。テナントの列でキー付けされた共有テーブルは、すべての行がtenant_idを運び、最も密で最も安く、最も危険です。一つのクエリがテナントのフィルターを欠くと、顧客間でデータが漏れるからです。

テーブルを共有するなら、開発者がフィルターを覚えていることに頼ってはいけません。バイパスできない層でテナントのスコープを徹底します。セッションのテナントに基づいてすべてのクエリに必須の述語を付けるデータベースの行レベルセキュリティ、テナントの句を自動的に注入するORMやデータアクセス層、あるいはその両方。ここでは二重の備えが正しいのです。テナントが育つにつれて、テナントによるシャーディングが自然になります。テナントのグループを異なるデータベースのシャードに置き、単一のインスタンスが全員を保持しないようにします。それは一つのシャードの障害の影響範囲にも上限を課し、モデルを変えずに、大きなテナントを独自のシャードに移せるようにします。

テナントの文脈をあらゆる所に伝播させ、テナント間の漏洩に多層で防御する

テナント識別子は、すべての仕事の単位に付いて回らなければなりません。縁で確立し、通常は認証されたセッションやサブドメインから、検証し、リクエストの文脈、すべての下流のサービス呼び出し、すべてのデータベースセッション、すべてのキューに入れられたジョブ、すべてのログ行とメトリクスを通じて通します。危険なギャップは非同期のものです。テナントの文脈を再確立せずにジョブを処理するバックグラウンドワーカー、テナントなしでキー付けされたキャッシュ、呼び出し元からのテナント識別子を信頼するウェブフックのハンドラ。どれも、あるテナントのデータを別のテナントに提供する経路です。

テナント間の隔離を、多層防御を伴うセキュリティの性質として扱い、詳細は4.3章に任せます。最小権限の原則を適用し、侵害されたコンポーネントでさえ、自分が代わりに動いているテナントにしか届かないようにします。認可の決定のために、クライアントが制御する入力からテナント識別子を受け入れてはいけません。認証されたアイデンティティから導出します。キャッシュ、オブジェクトストレージのプレフィックス、検索インデックスをテナントで名前空間化し、キーの衝突が境界をまたげないようにします。それから境界を意図してテストします。テナントAの認証情報がテナントBのレコードを読めないことをアサートする自動テストと、テナントから抜け出そうとする定期的なレッドチームの演習。テストスイートが見つけた漏洩はバグで、顧客が見つけた漏洩は危機です。

クォータ、レート制限、公平性でうるさい隣人を封じ込める

テナントがリソースを共有するとき、一つのテナントのスパイクは全員の障害になります。このうるさい隣人の問題はエッジケースではなく、負荷のもとの共有プールの既定の振る舞いです。最初からそれに対して設計します。重要なリソース(毎秒のリクエスト、同時のジョブ、ストレージ、クエリのコスト)にテナントごとのクォータを設定し、縁と高価な内部の境界でレート制限で徹底します。一つのテナントが残りを飢えさせる先着順のキューより、各テナントに取り分を与える公平なスケジューリングを好みます。

徹底をテナンシーのモデルに合わせます。共有プールでは、クォータと公平性が主な防御なので、それらに投資します。公平な共有が吸収できる以上の負荷を持つテナントには、答えはしばしば、プールからブリッジやサイロのデプロイに昇格させることで、それは失敗ではなく、売れる機能です。これをスケーラビリティとレジリエンスの仕事(3.5章)に結びつけます。負荷の切り捨て、サーキットブレーカー、バックプレッシャーは、すべてテナントを意識したものでなければならず、一つのテナントの過剰な負荷を切り捨てることが、システム全体を劣化させるのではなく、他を守るようにします。

フォークではなく、データでテナントを設定する

すべての顧客は、少し違うものを望みます。ロゴ、ワークフローのルール、統合、あなたが持っていないフィールド。はいと言うスケーラブルな方法は、テナントごとの設定です。フィーチャーフラグ、設定、権利、拡張点が、データで、実行時に評価され、一つのコードベースで共有される。SaaSの事業を破壊する道は、テナントごとのカスタムコードです。大きな顧客のためのブランチやフォークやコードパスの特殊ケース。それが十個あれば、もう製品ではなく、トレンチコートを着た十個の製品を持ち、すべての変更を十回テストしなければなりません。

はっきりと線を引いてください。サポートする意思のある変動の軸を第一級の設定としてモデル化し、それらの軸の外の要求を、製品ロードマップか、きっぱりしたノーとして扱います。顧客が本当にカスタマイズを必要とするとき、あなたのものを分岐させずに彼らのロジックを走らせる拡張点(ウェブフック、API、プラグイン、カスタムフィールド)を与えます。本当に特注のデプロイは、隔離こそが要点で、より高い価格が運用コストを賄う、シングルテナントのプレミアムの階層のために取っておきます。

テナントのライフサイクルを自動化し、観察可能にし、コストを帰属する

テナントのオンボーディングは、セルフサービスで自動化されたフローであるべきです。テナントのデータ分割をプロビジョニングし、既定を投入し、権利を設定し、運用チームへのチケットではなく数秒で準備ができる。オフボーディングも同じくらい重要で、無視しやすいものです。テナントが去るとき、使える形式でデータをエクスポートでき、それから証明可能に削除できなければなりません。契約とプライバシー法が両方を求めるからです。データのエクスポートと削除を初日に設計してください。共有テーブルのスキーマに後付けするのは苦痛です。

すべてをテナントごとに計装します。ログ、トレース、メトリクスにテナント識別子を付け、「この障害は全テナントか一つか」と「どのテナントがこのコストを駆動しているか」に数秒で答えられるようにします。インフラのコストをテナントに帰属させ、顧客ごとの本当の利益率を知り、現在の価格では使用量のために採算が合わないテナントを見つけられるようにします(9.4章)。テナントを意識したオブザーバビリティとコストの帰属は、マルチテナンシーを、ブラックボックスから、実際に運用し値付けできるシステムに変えます。

トレードオフ: 長所と短所

テナンシーのモデル	長所	短所
サイロ(テナントごとに専用スタック)	最強の隔離、最小の影響範囲、テナントごとのコンプライアンスとエクスポートが容易、うるさい隣人の話が単純	最高のコスト、テナントごとのアイドル容量、運用しパッチを当てる多くのコピー
プール(完全に共有)	最低の限界コスト、最も密な詰め込み、スケールとアップグレードするシステムが一つ	隔離が完全にコードの正しさに依存、最悪のうるさい隣人のリスク、テナントごとのエクスポートと削除が最も難しい
ブリッジ(ハイブリッド、階層)	小さなテナントに効率的、大きなものに専用の隔離、価格に対応	築いて運用するモデルが増える、階層間の昇格の経路を保守する
共有DB、共有スキーマ(テナントの列)	最も安いストレージ、移行が一つ、最も単純な運用	一つの欠けたフィルターがデータを漏らす。バックストップとして行レベルセキュリティが必要
共有DB、テナントごとのスキーマ	論理的な隔離、サーバーが一つ、まずまずのエクスポート	多くのスキーマオブジェクト、移行が展開される、サーバーごとのスケール限界
テナントごとのデータベース	強いデータの隔離、テナントごとのバックアップとエクスポート	多くのデータベース、移行の展開、より高いコスト

中心的な緊張は隔離と効率で、すべての行に走っています。より密な共有は、同じ動きで利益率とリスクを掛け合わせ、より強い隔離は、本物のテナントごとのコストで、安全と単純さを買います。解決は一方の極を選ぶことではなく、通常は階層ごとに、各テナントを範囲に沿って意図して置くことです。経済性が要求しリスクが限られる所では小さなテナントを密に詰め、大きく規制されたテナントは、彼らが払い、影響範囲が小さくなければならない所で隔離します。それから、密な端を徹底されたテナントのスコープで安全にし、隔離された端を自動化で安くして、素朴な版ほど、どちらの極も痛まないようにします。

チームで議論すべき問い

テナントのスコープのフィルターが明日一つ欠けたら、顧客は別の顧客のデータを見ますか。 これは、擁護できるマルチテナントの製品と、起こりかけている事故を分ける問いです。誠実なテストは、本物の読み取りの経路をたどり、何がテナントの境界を徹底しているかを問うことです。開発者が書いた一つのWHERE句か、データベースの行レベルセキュリティや、何があってもスコープを注入するデータアクセス層のようなバックストップか。実際のクエリの経路、バックグラウンドのジョブ、キャッシュを持ち込んでください。漏洩はほぼ常に、誰もスコープしなかった非同期の隅に隠れているからです。テナントAのセッションでテナントBのレコードを意図して要求し、拒否をアサートするテストの結果も持ち込んでください。境界が人間の警戒だけに拠るなら、潜在的な侵害を抱えており、修正(多層防御)はバックログの最上位に跳ね上がるべきです。
各顧客の階層は実際にどのテナンシーとデータ分割のモデルを使っていて、売ったものと合っていますか。 多くのチームは既定で単一のモデルにずれ込み、それから価格とアーキテクチャが食い違っていることを発見します。企業の顧客には共有プールが提供しない隔離が約束されていたり、小さな顧客が利益率を台無しにする高価な専用スタックに置かれていたり。各階層を実際のモデル(サイロ、プール、ブリッジ。テナントごとのデータベース、スキーマ、共有テーブル)に対応づけ、営業チームが行う契約上のデータ保証と並べてください。食い違う所には、コンプライアンスのリスクかコストの問題があり、顧客や監査人が見つける前に表面化する価値があります。持ち込む証拠は、階層とモデルのマッピング、テナントごとのコスト、企業との契約の実際の文言です。
大きなテナントの負荷が急増したとき、他の誰がそれを感じ、計画は何ですか。 共有プールでは答えはしばしば「全員」で、チームはインシデントがそれを明白にするまで、これを知らないことがよくあります。最大のテナントが一括インポートを実行したり、トラフィックの急増に見舞われたりしたら何が起こるかをたどってください。テナントごとのクォータと公平なスケジューリングがそれを封じ込めますか、負荷の切り捨てが隣人を守りますか、それともシステム全体が一緒に劣化しますか。負荷のデータと、直近のうるさい隣人のインシデントの話を持ち込んでください。あなたを傷つけるテナントは、たいてい名前を挙げられる相手だからです。答えは、レート制限への投資とティアリングの戦略の両方を形づくるはずです。公平な共有を超えて育ったテナントへの最もきれいな修正は、課金できるブリッジや専用のデプロイに昇格させることだからです。
テナントが明日オフボードされたら、きれいなエクスポートを渡し、すべての痕跡を削除したことを証明できますか。それとも慌てますか。 オフボーディングは、契約の終了条項やプライバシー法の要求がそれを強いるまでチームが無視する、テナントのライフサイクルの部分で、その頃には共有のスキーマが、抽出と削除を苦痛にしています。大きなチームにとって、リスクは増幅します。テナントのデータは、主要なデータベース、キャッシュ、オブジェクトストレージ、検索インデックス、バックアップ、分析のパイプラインに散らばっており、それぞれを使える形式でエクスポートし、それから証明可能に消去しなければならないからです。相反する考慮は本物です。安いストレージを与える密な共有テーブルは、まさにテナントごとの抽出と削除を最も難しくするものなので、ストレージ層で買った効率を、出口で払い戻すかもしれません。本物のテナントでのオフボーディングの実際のウォークスルー、テナントのデータを保持するすべてのストアのリスト、削除が実際に行われたことを示す証拠を持ち込んでください。企業と政府のテナントでは、エクスポートは認証され、削除は公文書とプライバシーの法令を満たすよう証明可能でなければならないので、欠けた削除の経路を、顧客が去るときに加える機能ではなく、今塞ぐコンプライアンスの欠陥として扱ってください。
個々の顧客のための一回限りの特殊ケースが、すでに何個コードの経路に住んでいて、越えない線はどこですか。 テナントごとのコードのフォークは、SaaSの事業が一つの製品であることをやめ、一つの名前を使う多くの製品になる静かな方法で、あらゆる変更がすべての特殊ケースに対してテストされなければならず、顧客を加えるたびに速度が衰えます。緊張は、本物のニーズを持つ大きな顧客は断りにくく、コードの経路のブランチは設定の面を築くより速く感じられるので、特殊ケースが妥当な例外一つずつで積み上がることです。誠実な一覧を持ち込んでください。コードベースで顧客名と階層固有のブランチをgrepし、数え、それぞれが無関係な変更に課す追加のテストとレビューのコストを見積もります。議論は、第一級の設定(フラグ、権利、拡張点)としてモデル化する変動と、より高い価格が運用コストを賄うシングルテナントのプレミアム階層のために取っておく本物の特注の仕事の間に、はっきりした線を引くべきです。深いカスタマイズを求める企業の買い手には、持続的な答えは、あなたのものを分岐させずに彼らのロジックを走らせる拡張点で、艦隊全体でガバナンスと監査が扱いやすいままになります。
テナントごとに、インシデントが誰にいくらコストをかけているか、そしてどの顧客が現在の価格では採算が合わないかを言えますか。 ログ、トレース、メトリクス、インフラのコストがテナントの次元を持たない瞬間、マルチテナンシーはブラックボックスになります。障害が一つのテナントか艦隊全体かに答えられず、契約価格では損失になる使い方をするテナントを名指しできないからです。大きなチームにとって、この帰属こそが、プラットフォームを運用することと、それを推測することを分けるもので、信頼性への対応と価格の両方を直接形づくります。考慮は、計装のコストとカーディナリティに引き合います。すべてをテナントでタグ付けすることは無料ではなく、高カーディナリティのメトリクスはオブザーバビリティの予算を圧迫するので、何をテナントごとに切り分け、何をサンプリングするかを意図して選びます。現在のテナントのタグ付けのカバレッジ、クラウドの支出を単一のテナントに帰属させる本物のクエリ、最も採算の悪い顧客を名指しできる利益率の表を持ち込んでください。企業と政府の設定では、テナントごとのコストと監査にスコープされたオブザーバビリティは、チャージバック、キャパシティ計画、各機関や事業単位が権利を持つ監査の境界にも反映されるので、テナントの次元は、運用上と同じくらいガバナンスの要件です。

セクター別の視点

スタートアップ。 初日から単一の共有プールを出荷し、後付けできない唯一のことに乏しいエンジニアリングの注意を使ってください。徹底されたテナントのスコープ。行レベルセキュリティを備えたマネージドPostgres、すべてのテーブルのtenant_id、縁で解決されるテナントの文脈が、運用チームなしに、安全な密度を買います。投機的にサイロの階層やテナントごとのインフラを築いてはいけません。支払う企業の見込み客が隔離をそのコストに見合うものにしたときにだけ、ブリッジの階層を加えます。

小規模事業者。 プラットフォームの専門家はおらず予算も厳しいので、隔離の仕組みを自前で築くのではなく、クラウドとフレームワークがすでに与えるものに頼ってください。行レベルセキュリティを備えたマネージドデータベース、テナントを代わりにスコープするPaaS、テナントのアイデンティティを運ぶ認証プロバイダーは、通常、手作りの同等物より安く安全です。マルチテナンシーを、あらゆる層での作るか買うかの決定として扱い、あなたにしか書けないテナントの境界のテストのために、特注の仕事を取っておきます。

大企業。 問題は、多くのチームにわたるポートフォリオのガバナンスです。階層化されたブリッジのアーキテクチャ、各階層をそのテナンシーとデータ分割のモデルに対応づけるアーキテクチャ決定記録、そして財務がすべての口座の本当の利益率を知るためのテナントごとのコストの帰属。テナントの文脈の伝播とスコープのバックストップを標準化して、どのチームも再発明しないようにし、隔離とライフサイクルの自動化を明示的に予算化し、テナントが育ったりコンプライアンスのニーズが変わったりしたとき、ダウンタイムなしに階層間を移行する、サポートされ値付けされた道を保ちます。

政府。 調達、データ所在地、公的な説明責任がモデルを駆動します。各機関のデータを、ポリシー・アズ・コードで国内のリージョンに固定し、機密性の高い、あるいは高い分類のワークロードを、独自の監査境界を持つ別のアカウントにサイロ化し、各機関に独自のアイデンティティ統合、保持のルール、監査証跡を与えて、ある機関の監査人が別の機関の活動を決して見ないようにします。オフボーディングは、公文書とプライバシーの法令を満たすために、認証されたエクスポートと証明可能な削除を生まなければならず、署名するテナンシーの保証は、アーキテクチャが実際に守れるものでなければなりません。

事例

スタートアップ。 15人のスタートアップは、初日から製品を単一の共有プールとして築き、それは正しいことです。すべてのテナントが、すべてのテーブルにtenant_idを持つ一つのマネージドPostgresデータベースを共有し、行レベルセキュリティがデータベースでテナントの述語を徹底するので、忘れられたフィルターは漏洩できず、アプリケーションは縁でサブドメインからテナントを解決して、あらゆるリクエストとバックグラウンドのジョブを通して通します。オンボーディングはセルフサービスです。新しいサインアップがテナントの行をプロビジョニングし、既定を投入し、数秒で稼働します。運用するシステムが一つなので、二人のエンジニアがプラットフォーム全体を運用しています。最初の本物の企業の見込み客が、専用のデータベースと契約上の隔離の保証を求めたとき、彼らはブリッジの階層を加えます。同じコードベースですが、このテナントは独自のシャードに独自のデータベースを得て、コストを賄う価格で売られます。

大企業。 大きな金融機関に仕えるSaaSのベンダーが、階層化されたブリッジのアーキテクチャを運用しています。何千もの小中規模の顧客が、テナントでシャードされた地域の共有プールに住み、クォータと公平なスケジューリングがうるさい隣人を抑えています。最上位の銀行の顧客は、隔離されたクラウドのアカウントでシングルテナントのデプロイを得て、専用のデータベース、テナントごとの暗号鍵、基本契約に書かれた契約上のデータ所在地と隔離の保証があります。プラットフォームの能力が、テナントが育ったりコンプライアンスのニーズが変わったりしたとき、ダウンタイムなしに階層間を移行します。すべてのテナントのコストはタグ付けを通じて帰属され、財務はすべての口座の本当の利益率を知り、テナントでタグ付けされたオブザーバビリティにより、オンコールのエンジニアは、アラートが一つのテナントか艦隊全体かを数秒で言えます。

政府。 多くの政府機関を別々のテナントとしてホストする国のプラットフォームのプロバイダーは、隔離を好みではなく法的な要件として扱います。データ所在地の法律が各機関のデータを国内のリージョンに固定し、許可されないリージョンのリソースをブロックするポリシー・アズ・コード(3.11章)で徹底されます。分類がモデルを駆動します。機微な資料を扱う機関は、独自の監査境界を持つ別のアカウントで完全にサイロ化されたデプロイを得て、低い分類のワークロードは統治された共有のプールを共有します。各機関は、独自のアイデンティティ統合、独自の保持とエクスポートのルール、境界にスコープされた監査証跡を持つ独自のテナントなので、ある機関の監査人が別の機関の活動を見ることは決してありません。オフボーディングは、記録が公文書とプライバシーの法令の対象なので、認証されたデータのエクスポートと証明可能な削除を生みます。

ビジネスケース: 動機、ROI、TCO

マルチテナンシーの中核のビジネスケースは利益率です。顧客ごとに新しいコピーをデプロイするシングルテナントのモデルは、インフラと運用のコストが顧客数におおよそ線形に増え、エンジニアは多くのコピーにパッチを当てて日々を過ごすことを意味します。共有のマルチテナントのモデルはその結びつきを断ちます。パッチを一度当て、一つのシステムをスケールし、次のテナントの限界コストがゼロに近づくほど密に顧客を詰め込みます。それが、SaaSの事業が収益をコストよりはるかに速く増やせる理由であり、投資家や取締役会がきれいなマルチテナントのアーキテクチャを、スケーラブルな会社の代理指標として扱う理由です。

見返りは三つの場所に現れます。運用上のてこ(一つのチームが艦隊全体を運用する)、より速いデリバリー(修正はすべてのテナントに一度に出荷されるので、顧客を加えても速度が衰えない)、価格の選択肢の価値(長い尾のための共有のプランと企業のためのプレミアムの隔離されたプラン、どちらも一つのコードベースから)。それらを、誠実に資金を出さなければならないコストと量ってください。徹底されたテナントの隔離、クォータ、ライフサイクルの自動化、テナントごとのオブザーバビリティを築くエンジニアリングと、境界を無傷に保つ規律。間違えたコストは非対称で深刻です。一つのテナント間のデータ侵害が、共有して節約したインフラをはるかに上回る、規制上の罰則、大量の解約、評判の傷を引き起こしうるからです。リーダーシップには、上振れとして利益率とスケーラビリティ、下振れとして存亡のリスクで論拠を示してください。サービスレベル合意と契約上のデータ保証を、実際に提供できるテナンシーのモデルに固定してください。アーキテクチャが守れない約束は、販売ではなく負債だからです。

アンチパターンと落とし穴

慣習によるテナントのスコープ。 データベースやデータアクセス層のバックストップなしに、すべてのクエリでテナントのフィルターを開発者が覚えていることに頼ること。一つの見落としが侵害です。
クライアントが提供するテナント識別子を信頼する。 認証されたアイデンティティから導出する代わりに、認可のためにリクエストの入力からテナントを受け入れ、呼び出し元が他人のデータを求められるようにすること。
スコープされないバックグラウンドの仕事。 誰かが同期的なリクエストの経路だけをスコープしたために、テナントの文脈を失うジョブ、キャッシュ、ウェブフック、エクスポート。
テナントごとのコードのフォーク。 大きな顧客をコードの経路で特殊ケースにし、一つの名前の下で多くの分岐した製品を保守し、あらゆる変更が十倍のコストになるまで。
うるさい隣人への防御がない。 テナントごとのクォータも公平性もない共有プールを動かし、最初に急増したテナントが全員を落とすこと。
後付けとしてのオフボーディング。 データのエクスポートと証明可能な削除なしに築き、共有のスキーマが抽出を苦痛にするために、顧客の退出条項やプライバシー法の要求に失敗すること。
テナントごとに盲目的に飛ぶ。 ログ、メトリクス、コストにテナントの次元がなく、誰のインシデントか、どのテナントが採算が合わないかを言えないこと。

成熟度モデル

レベル1、開始: マルチテナンシーは即興で反応的です。テナントの分離は、バックストップのない手書きのフィルターに拠り、モデルは画一的で、クォータはなく、オンボーディングは手作業で、ログとコストにテナントの次元がありません。チームは、うるさい隣人とあやうく漏洩しかけた出来事を、インシデントから知ります。
レベル2、発展: 基本的な実践が現れますが、チーム間で一貫しません。テナンシーのモデルが選ばれ、テナントの文脈は主要なリクエストの経路を通じて伝播し、データベースやデータアクセスのバックストップが中核のテーブルでスコープを徹底し、基本的なテナントごとのクォータがあります。オンボーディングは部分的に自動化され、ログはテナント識別子を運びますが、バックグラウンドの経路、エクスポート、コストの帰属はサービスごとに異なり、どこにも書き留められていません。
レベル3、標準化: テナンシーのアプローチが文書化され、組織全体で徹底されています。階層化されたテナンシーが価格に対応し、小さなテナントには共有のプール、企業と規制されたものには隔離されたデプロイがあり、テナントのスコープは多層で徹底され意図してテストされ、クォータと公平なスケジューリングがうるさい隣人を封じ込め、エクスポートと証明可能な削除を含むテナントのライフサイクルは自動化され、オブザーバビリティとコストはテナントごとに切り分けられます。すべてのチームが、独自のものではなく、同じテナンシーの標準に従います。
レベル4、管理: テナンシーの資産が、ベースラインに対して測定され、制御されています。テナントごとの隔離、公平性、レイテンシ、コストが、合意された目標を伴う指標として追跡されます。テナント間のテストのカバレッジ、クォータ違反とうるさい隣人のインシデント率、オンボーディングとオフボーディングの時間、テナントごとの利益率がベースラインに対して報告され、テナントを階層間で昇格させたり、採算の悪いものを値付けし直したりする決定は、逸話ではなくその証拠で行われます。所在地と分類への適合は継続的に監視され、標準からのずれは文書化された対応を引き起こします。
レベル5、オーケストレーション: テナンシーは継続的に改善され、組織全体に統合されています。テナント間の境界は日常的なレッドチームの演習で試され、テナントは育ったりコンプライアンスのニーズが変わったりしたとき、ダウンタイムなしに階層間を移り、テナントごとの利益率が価格とキャパシティ計画に反映され、所在地と分類のルールはレビューではなくポリシーで徹底されます。モデルは顧客構成と規制の状況の変化に応じて適応し、そこからの教訓は、製品、セキュリティ、財務に、一つのループとして流れます。

議論のためのアイデア

各顧客の階層は、隔離対効率の範囲の今日どこにあり、約束した保証や必要な利益率に対して、間違ったモデルにある階層はありますか。
テナントAがテナントBのデータにアクセスできないことを監査人に証明するとしたら、今すぐどんな証拠を出せ、そのどれだけが主張ではなく自動化されていますか。
非同期の経路(ジョブ、キャッシュ、ウェブフック、エクスポート、検索インデックス)のうち、どれがテナントの文脈を再確立し、どれが単に継承したり呼び出し元を信頼したりしていますか。
テナントが公平な共有を超えて育ったとき、ブリッジや専用のデプロイへの、サポートされ値付けされた昇格の道がありますか。それとも、答えは既定でインシデントですか。
インフラのコストを個々のテナントに、最も採算の悪い顧客を名指しできるほどうまく帰属させられ、それは価格の付け方を変えますか。
政府や規制されたテナントのために、ポリシーでデータ所在地と分類に駆動される隔離を徹底し、認証されたエクスポートと証明可能な削除でオフボードできますか。

要点

マルチテナンシー、つまり一つのインスタンスが多くのテナントに仕えることは、SaaSの経済的なエンジンです。それが利益率を駆動し、テナント間の隔離をアーキテクチャの中心に置きます。
隔離対効率を範囲として扱い、階層化します。小さなテナントは効率的な共有プールに詰め、大きく規制されたテナントは、彼らが払うブリッジやサイロのデプロイで隔離します。
テナントのスコープを手書きのフィルターに拠らせてはいけません。行レベルセキュリティやデータアクセス層で多層に徹底し、境界を意図してテストします。
テナントの文脈を、あらゆるリクエスト、ジョブ、キャッシュ、ログを通じて伝播させ、漏洩が隠れる非同期の経路を防御します。
テナントごとのクォータ、レート制限、公平なスケジューリングでうるさい隣人を封じ込め、プールを劣化させるのではなく、プールを超えて育ったテナントを昇格させます。
テナントごとのコードではなくテナントごとの設定で製品を曲げ、テナントのライフサイクルとテナントごとのオブザーバビリティとコストの帰属を第一級にします。

参考文献とさらなる読み物

Tom Kwok, Thao Nguyen, and Linh Lam, A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application (IEEE International Conference on Services Computing)
Frederick Chong and Gianpaolo Carraro, Architecture Strategies for Catching the Long Tail (Microsoft)
Amazon Web Services, SaaS Lens, AWS Well-Architected Framework and SaaS Tenant Isolation Strategies
Microsoft, Multitenant SaaS architecture and patterns (Azure Architecture Centre)
Google Cloud, Architecture for Multi-tenant SaaS Applications
Cor-Paul Bezemer and Andy Zaidman, Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare? (Proceedings of the Joint ERCIM Workshop on Software Evolution)
The Open Web Application Security Project, OWASP Application Security Verification Standard (access-control and multi-tenancy requirements)
Martin Kleppmann, Designing Data-Intensive Applications (partitioning, sharding, and data isolation)