マルチテナントDBアーキテクチャ

マルチテナントSaaS特有の分離レベル問題

シャーディング方式は「1つのデータ集合をどう水平分割するか」という一般論でしたが、マルチテナントSaaSではもう1段階手前に固有の意思決定があります。**「テナント（契約企業・ユーザー組織）同士のデータとリソースを、どこまで物理的に分離するか」**という選択です。これは単なるスケール手法ではなく、セキュリティ境界・運用コスト・機能提供速度を同時に左右する設計判断です。

分離レベルは大きく3パターンに整理できます。

• DB単位分離（silo）: テナントごとに独立したデータベース（インスタンスまたはクラスタ）を持つ。
• スキーマ単位分離（bridge）: 1つのDBサーバー内で、テナントごとに別スキーマ（名前空間）を持つ。
• 行単位共有（pool）: 1つのテーブル群をテナントIDカラムで水平共有し、全テナントが同じ行集合を使う。

三者は隔離の強さと運用効率がちょうど反比例する関係にあり、どれか1つが常に正解ということはありません。

パターン1: DB単位分離（silo）

テナントAとテナントBが物理的に別のデータベース（別クラスタ、少なくとも別スキーマ以上の隔離）を持ちます。接続文字列やルーティング層でテナントIDからDB実体を引き当てるのは、ディレクトリ分割方式の考え方そのものです。

• 隔離性は最強。あるテナントの暴走クエリやロック競合が他テナントの性能に及ぶ経路が物理的に存在しない。
• テナントごとにバックアップ、リストア、コンプライアンス対応（データ所在地の指定など）を個別に完結できる。
• 一方でDB接続やメモリ、バックグラウンドプロセスなど固定オーバーヘッドをテナント数だけ乗算するため、テナント数が数千を超えるとハードウェア効率が著しく悪化する。小規模テナントが大量にいるSaaSでは非現実的になりやすい。

パターン2: スキーマ単位分離（bridge）

1つのDBサーバー（1インスタンス）の中に、テナントごとの**スキーマ（名前空間）**を作り、同名のテーブル群を複製します。接続後に search_path やスキーマ修飾でテナントを切り替えます。

• DB単位分離よりハードウェア効率が良い（接続プールやバッファプールをテナント間で共有できる）一方、隔離性は下がる。同一インスタンス上のリソース（CPU、ディスクIO、バッファキャッシュ）は全テナントで奪い合いになる。
• テナント数が数百〜数千のオーダーで現実的な妥協点になりやすい。
• 欠点はカタログの肥大化です。テーブル数×テナント数ぶんのメタデータをDBが保持するため、システムカタログの検索やプランキャッシュの管理コストが増え、数千テナントを超えると起動やDDL自体が重くなる。

パターン3: 行単位共有（pool）

全テナントが同一のテーブルを使い、各行に tenant_id カラムを持たせて論理的に区別します。アプリ層またはDBのRLS（行レベルセキュリティ）で、クエリに必ず tenant_id 条件を強制します。

• ハードウェア効率は最大。テーブル・インデックス・バッファキャッシュ・接続プールをすべて共有するため、小規模テナントを大量に収容するコストが最も低い。
• 隔離性は最弱。分離はアプリまたはDBのポリシー層に委ねられ、tenant_id の条件漏れ（バグ）がテナント間データ漏洩に直結する。
• スキーマ変更は全テナントに即座に反映されるが、それは裏を返せば1テナントだけの個別対応ができないということでもある。

ノイジーネイバー問題とリソース分離

ノイジーネイバー問題とは、あるテナントの過大な負荷（大量書き込み、非効率なクエリ、突発的なバッチ処理）が、同居する他テナントの性能を巻き添えにする現象です。共有度が上がるほど経路が増えます。

• silo: 物理的に別インスタンスなので、他テナントへの波及経路が存在しない。最も安全だが、暇なテナントの空きリソースを忙しいテナントへ融通することもできない。
• bridge: CPU・ディスクIO・バッファプールは同一インスタンス内で共有される。1テナントのフルスキャンがバッファキャッシュを丸ごと入れ替えてしまい、他テナントの体感速度を落とすことがある。
• pool: テーブルやインデックス自体を共有するため、ロック競合や特定インデックスのホットページ争いも加わる。

行単位共有でノイジーネイバーを抑える実務的な対策は次のとおりです。

• リソースガバナでテナントごとにCPU時間・同時接続数・実行時間の上限を強制し、1テナントが持てる分を頭打ちにする。
• クエリタイムアウトの強制と、重いバッチ処理を専用のリードレプリカへ逃がす分離。
• 突出して大きい・重いテナントだけをsiloへ個別に退避する。3パターンは排他ではなく、大口だけ抜き出すハイブリッド運用がよく行われる。

テナントごとのスキーマ移行の複雑さ

分離レベルはスキーマ変更（マイグレーション）の運用難度にも直結します。

• silo: テナントごとに独立したマイグレーション実行が可能。障害があっても影響は1テナントに閉じる。反面、数百〜数千テナント分のマイグレーション完了状態を個別に追跡・管理するコストが発生し、「テナントAはv12、テナントBはまだv10」というバージョンのばらつきが常態化しやすい。
• bridge: スキーマの数だけDDLを繰り返す必要があり、途中失敗時に「どのテナントまで適用済みか」を厳密に管理しないと不整合が生じる。オンラインスキーマ変更の手法をテナント数ぶん反復適用するイメージに近い。
• pool: DDLは1回で全テナントに反映されるため管理は単純に見えるが、テーブルが巨大なぶんオンラインスキーマ変更のコスト（新旧スキーマの二重書き込み、ロック取得の待ち行列）を全テナント分のトラフィックが同時に受ける。ロールバックも全テナントに波及するため、失敗時の影響範囲が最大になる。

行単位共有でのテナントIDインデックス設計

pool方式を選ぶなら、tenant_id のインデックス設計が性能を決定づけます。

原則は複合インデックスの先頭列に tenant_id を置くことです。複合インデックスの列順の一般論のとおり、B+Treeは複合キーを辞書式順序で保持するため、先頭に tenant_id を置くと同一テナントの行が物理的に隣接し、テナント単位のクエリが狭い範囲へ絞り込まれます。

-- 良い例: tenant_id を先頭に置き、以後のクエリ条件を続ける
CREATE INDEX idx_orders_tenant_created
  ON orders (tenant_id, created_at DESC);

-- クエリはこの並びをそのまま使える
SELECT * FROM orders
WHERE tenant_id = 'acme' AND created_at > now() - interval '7 days'
ORDER BY created_at DESC;

tenant_id を先頭に置かず created_at だけで並べると、インデックスは全テナントの行を時系列に混在させて保持するため、特定テナントの絞り込みには不要な行を大量に読み飛ばす必要が生じます。

もう1つの実務的な論点はカーディナリティの偏りです。巨大テナントと零細テナントが同じテーブルに混在すると、tenant_id のヒストグラムが極端に歪みます。オプティマイザのカーディナリティ推定が不正確になりやすく、巨大テナントに対しては想定外のプラン（インデックスを使わないシーケンシャルスキャンなど）を選ぶことがあるため、大口テナントは統計情報の更新頻度を上げる、またはsiloへ退避するといった対応が必要になります。

分離レベルの選び方

分離レベルの選択は一度決めたら終わりではなく、テナント構成の変化（大口契約の獲得、零細テナントの急増）に応じて見直す対象です。行単位共有を土台にしつつ、突出したテナントだけを個別分離するハイブリッド構成が、多くのSaaSにとって現実的な着地点になります。