PostgreSQL RLSでマルチテナント分離：4階層のデータを1人で守る【第4回】
この記事で得られること マルチテナントSaaSにおけるデータ分離パターンの比較 PostgreSQL Row-Level Security（RLS）の実践的な使い方 4階層（System/Provider/Reseller/Consumer）のRLSポリシー設計 Go + pgx でRLSコンテキストを設定する方法 テストでRLS漏れを検知する手法 はじめに 第1回で紹介した通り、Saruは4階層のアカウント構造を持つマルチテナントSaaSだ。 System Admin（SMSプラットフォーム全体を管理） └── Provider（サービスを提供） ├── Reseller（サービスを販売） │ └── Consumer（購入・管理） └── Consumer（直販） この構造では、データの分離が極めて重要になる。 Provider A の顧客データを Provider B が見てはいけない Reseller A の販売実績を Reseller B が見てはいけない Consumer A のサブスクリプション情報を Consumer B が見てはいけない これをアプリケーション層で完全に防ぐのは難しい。WHERE句の書き忘れや権限チェックの漏れは、ソロ開発では特に起こりやすい。 そこで PostgreSQL Row-Level Security（RLS） を採用した。 1. マルチテナントの分離パターン比較 マルチテナントのデータ分離には主に3つのアプローチがある。 パターン比較表 パターン 分離レベル 実装コスト 運用コスト スケーラビリティ Database per Tenant 最高（物理分離） 高い 高い 性能分離◎、運用面△ Schema per Tenant 高い（論理分離） 中程度 中程度（自動化必須） 中程度 Shared Schema + RLS 高い（設計次第） 低い 低い 高い（設計次第） Database per Tenant テナントごとに独立したデータベースを持つ。 ...