PostgreSQL 멀티테넌시 구성 전략 (ft. SaaS 구성)
멀티테넌시의 의미를 알아보고 PostgreSQL 에서 멀티테넌시를 구성하는 방법에 대해서 알아봅니다.
멀티테넌시(Multi-Tenancy) 란?
먼저, 테넌시(Tenancy)란 '차용, 소작'을 의미합니다. 하나의 인스턴스로 여러 고객에게 서비스를 제공할 수 있는 소프트웨어 아키 텍처를 '멀티테넌시(Multi-Tenancy)'라고 합니다. 반대되는 개념으로 단일 인스턴스 - 단일 고객인 경우 단일 테넌시라고 합니다.
다시 말해, 멀티 테넌시는 하나의 서비스 내에서 '고객의 정보를 분리/관리'하는 것으로 이해할 수 있습니다.
멀티테넌시 구성 전략
멀티테넌시를 구성하는 전략은 대표적으로 Silo 모델, Pool 모델, Bridge 모델 3가지가 있습니다.
| Silo Model | Bridge Model | Pool Model | |
|---|---|---|---|
| Database | Schema | ||
 |  |  |  |
Silo Model (사일로 모델)
사일로 모델은 각 테넌트에 대해 별도의 DB Instance 를 부여하는 방법입니다. 물리적/논리적으로 테넌트 간의 서로 상관 관계가 존재하지 않습니다. 보안 문제나 규제로 인해 고객이 추가 비용을 지불하고 데이터의 완전 분리를 원하는 경우 제공할 수 있는 서비스 형태입니다.
Pool Model (풀 모델)
풀 모델은
단일 DB Instance, 행 수준 보안(RTS)
를 사용하여 구현됩니다. tenant_id 또는 org_id 와 같은 Foreign Key를 통해 테넌트 데이터의 격리를 유지합니다. 사일로 모델에 비해 운영 오버헤드가 더 적은 장점이 있습니다. 테넌트별 리소스 관리(분리) 및 분석이 어렵다는 단점이 있습니다.
Bridge Model (브릿지 모델)
브릿지 모델은 사일로 모델과 풀 모델을 조합한 방식입니다. 단일 DB Instance 내부에서 논리적 Database 분할 또는 테넌트별로 Schema 생성 및 관리 합니다. 풀 모델의 결합 정도를 끊어내고, 물리적으로는 동일한 DB Instance를 사용하기에 각각의 단점을 보완할 수 있는 방법입니다.
PostgreSQL의 경우 Database 와 Table 사이 Schema 라는 일종의 네임스페이스를 구성할 수 있습니다.멀티테넌시 구성 비교
| - | Silo Model | Pool Model | Bridge Model |
|---|---|---|---|
| 테넌트 구성 시간 | 🐌매우 느림 | ⚡️매우 빠름 | 🐢 느림(스키마 생성, 테이블 생성) |
| 데이터 유출 위험 | 안전(independent) | 위험(tenant_id) | 덜 위험(query) |
| 공유테이블 생성, 테넌트 병합 | SQL로 수행 불가 | 매우 쉬움 | SQL로 수행 가능 |
| DB 마이그레이션 | 🐌매우 느림 | ⚡️매우 빠름 | 🐢 느림(스키마 생성, 테이블 생성) |
| 운영 오버헤드 | 수작업 | 거의 없음 | 가끔 발생 |
| 복잡성 | ... | tenent_id로 관리 | search_path 및 PG 기능으로 커버 |
| 테넌트별 데이터 추출 | 쉬움 | 번거로운 작업 | 쉬움 |
| 테넌트별 구조 커스터마이징 | 가능 | 문제 | 가능 |
선호하는 전략
BackEnd 는 역할별로 (DBA) DB + SQL / (BE) DTO + DAO + Controller / (API) API 로 구분됩니다.
전통적인 Role 중심의 구조와는 달리 서비스의 확장성, 다양성, 무결성을 타협할 수 있다면, Schema가 분리된 브릿지 모델을 ORM(SQLAlchemy, Prisma, TypeORM)을 통해 관리하는 방식을 선호하는 편입니다.
이 방식은 ORM을 통해 기본 Schema를 생성하고 테넌 트가 유입될 시, 해당 Schema를 복제하는 방법으로 테넌트별 데이터를 격리하는 방식입니다. 주의할 점으로는 SQL(Raw Query)로 직접 Schema 를 관리하게 되면, Schema 별로 다른 ERD 구성이 나올 수 있습니다. 때문에 ORM을 통해 기본 ERD 를 수정 및 마이그레이션 하는 전략을 선호합니다.