マルチテナントSaaSの設計戦略：分離モデル・セキュリティ・スケールの最適解

3つの分離モデル：どれを選ぶかが運命を分ける

モデル	説明	メリット	注意点
Row-level	同一DB・同一スキーマでtenant_id列を持つ	運用が最小・コスト効率高い	誤実装リスク。RLSの強制が必須
Schema-per-tenant	同一DB内にテナントごとのスキーマ	論理分離が強く、拡張性と中庸の運用負荷	マイグレーションのオーケストレーションが必要
DB-per-tenant	テナントごとに独立DB	最強の分離・SLA差別化容易	コスト・運用・接続数のスケールに注意

推奨：PostgreSQL × RLS（Row Level Security）

Row-level採用時は、必ずRLSを“デフォルトON”で強制し、アプリケーション層からもテナントIDを強制注入します。

-- PostgreSQL RLS example
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY by_tenant ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::text);

-- アプリ側は接続直後に必ずテナントIDをセット
SET app.tenant_id = 't-123';

接続プール（PgBouncer等）利用時はセッション変数の伝播戦略を事前に確認しましょう。

アイソレーションの二重化：アプリとデータの両面で

• アプリ層：認可ミドルウェア（OPA/ladon）でtenant_idをポリシー化
• データ層：RLS＋ビューのみにアクセスを限定
• ストレージ：S3はバケットorプレフィックスで名前空間分離、SSE-KMS

スケールとSRE：Kubernetes＋IaCで“均質な運用”へ

マルチテナントでは差分運用を排除するのが肝要です。 Helm/ArgoCDで宣言的デプロイ、TerraformでDB/ネットワークをコード化。監視はSLI/SLOをテナント別に観測し、アラートを“顧客影響”基準へ。

最小コストで始めるならRow-level＋RLS、規模と要件でSchema/DB分離へ段階的に移行。移行可能性を前提に設計するのが勝ち筋です。