멀티테넌시(multi-tenancy)는 하나의 서비스가 여러 고객(테넌트, tenant)의 데이터를 함께 다루는 구조다. 핵심 설계 질문은 테넌트 사이의 데이터를 얼마나 강하게 떼어 놓을 것인가이고, 한쪽 끝은 공유 DB, 반대쪽 끝은 테넌트 전용 DB다.
격리 수준
| 공유 DB + 행 구분 | 스키마 분리 | 전용 DB(dedicated) | |
|---|---|---|---|
| 구조 | 한 테이블에 tenant_id로 구분 | 테넌트마다 스키마 | 테넌트마다 DB·인스턴스 |
| 격리 | 논리적 | 중간 | 물리적 |
| 비용·운영 | 싸고 단순 | 중간 | 비싸고 복잡 |
| 위험 | 필터 한 줄 실수 = 유출 | 마이그레이션 반복 | 테넌트 수만큼 마이그레이션 |
- 공유 DB에서는 애플리케이션이 모든 쿼리에
tenant_id조건을 붙여야 한다. 깜빡하면 남의 데이터가 보인다. 이를 DB 수준에서 강제하는 장치가 RLS다 - 전용 DB는 애초에 남의 데이터에 닿을 수 없어 금융·의료처럼 격리가 중요한 고객에게 제공한다
- 실무에서는 "기본은 공유 DB + RLS, 보안 요구가 큰 대형 고객만 전용 DB"인 하이브리드가 흔하다
공유 배포와 단일 테넌트 배포
테넌트(tenant)는 원래 세입자·입주자라는 뜻이다. 한 건물을 여러 입주자가 나눠 쓰듯, 멀티테넌트는 코드와 인프라를 여러 고객이 함께 쓰고 데이터만 테넌트별로 가른다. 반대인 싱글테넌트는 고객마다 소프트웨어와 인프라를 통째로 따로 둔다.
- 공유 배포의 이점: 자원을 나눠 쓰니 고객당 비용이 낮다. 배포 대상이 하나라서 코드를 한 번 배포하면 모든 테넌트에 반영된다. 새 고객은 인프라를 새로 세우지 않고 테넌트 하나만 추가하면 되니 온보딩이 빠르다
- 공유 배포의 위험: 공유 구성 요소 하나의 장애가 모든 테넌트의 장애가 된다. 성능 문제나 잘못된 변경도 고객 전체가 함께 떠안는다
- 단일 테넌트 배포의 이점: 한 테넌트의 무거운 사용이 다른 테넌트 성능을 깎는 시끄러운 이웃(noisy neighbor) 문제를 피한다. 변경을 테넌트별로 점진 배포할 수 있어 시스템 전체 장애 가능성이 줄어든다. 대신 비용 효율이 낮고 업데이트 운영이 무겁다
"dedicated"의 다른 뜻
dedicated DB는 표준 용어가 아니라 맥락에 따라 뜻이 갈린다.
- 용도 전용: 분석·로그·검색 소스처럼 무거운 작업을 핵심 DB에서 떼어 낸 DB. 워크로드 격리(workload isolation)가 목적이다(읽기 전용 복제본)
- 테넌트 전용: 위의 멀티테넌시 의미
- 인스턴스 전용: 클라우드 플랜에서 다른 사용자와 하드웨어를 공유하지 않는 등급. "시끄러운 이웃(noisy neighbor)" 영향을 피한다
공통 트레이드오프는 "격리·성능·보안을 얻는 대신 비용과 운영 복잡도가 오른다"다. 테넌트가 아주 많아지면 샤딩으로 이어지고, 서비스 경계를 나누는 관점은 바운디드 컨텍스트와도 닿는다.
출처: Azure Architecture Center - Tenancy models for a multitenant solution