이 글에서 얻는 것
- 멀티테넌시에서 가장 중요한 것(보안 격리/운영/비용)을 기준으로, Shared/Schema/DB 분리 전략을 선택할 수 있습니다.
- “테넌트 데이터 유출” 사고를 막기 위한 강제 장치(애플리케이션/DB/관측)를 설계할 수 있습니다.
- 테넌트별 마이그레이션/백업/과금 같은 운영 문제를 시스템적으로 풀어가는 감각을 얻습니다.
0) 멀티테넌시는 ‘기능’이 아니라 ‘제약’이다
멀티테넌시는 결국 다음을 동시에 만족해야 합니다.
- 테넌트 간 데이터 격리(보안/규정)
- 운영 효율(한 플랫폼으로 여러 고객을 운영)
- 비용 효율(전용 인프라를 테넌트마다 둘 수는 없음)
어떤 격리 모델을 선택하든, 이 셋의 트레이드오프가 있습니다.
1) 격리 모델 3가지(실무 비교)
1-1) Shared DB + Shared Schema(tenant_id 컬럼)
- 장점: 가장 저렴, 운영 단순(스키마 하나)
- 단점: 격리 사고 리스크가 가장 큼(필터 누락이 곧 유출), noisy neighbor(핫 테넌트)
1-2) Shared DB + Separate Schema(테넌트별 스키마)
- 장점: 논리적 격리가 더 명확, 테넌트별 마이그레이션/인덱스 제어 가능
- 단점: 스키마 수가 늘며 운영 복잡도 증가
1-3) Separate DB(테넌트별 DB/인스턴스)
- 장점: 격리/보안/성능 측면에서 강함, 핫 테넌트 분리에 유리
- 단점: 비용/운영 부담 큼(백업/모니터링/마이그레이션을 테넌트 수만큼)
실무에서 자주 쓰는 결론:
- 대부분은 (1)로 시작하고,
- 규모/요구가 커지면 (2) 또는 “핫 테넌트만 (3)”으로 하이브리드로 갑니다.
2) 격리 강제: ‘실수로 유출되는 길’을 닫아라
2-1) 애플리케이션 레벨 강제
- 모든 요청에 tenantId가 “컨텍스트로” 들어오고, 리포지토리/쿼리에서 자동 적용되게 만든다
- 사람(개발자)이 매번 필터를 붙이게 하지 않는다(언젠가 빠진다)
2-2) DB 레벨 강제(가능하면)
DB가 지원한다면 Row Level Security 같은 정책으로 “필터 누락을 구조적으로 차단”하는 것이 가장 강력합니다.
2-3) 관측/감사
- 로그/트레이스에 tenantId를 항상 태깅
- “다른 테넌트 데이터 접근”이 의심되는 패턴을 탐지할 수 있어야 합니다
3) 성능/인덱스: tenant_id는 설계의 중심이 된다
Shared schema 모델에서 tenant_id는 거의 모든 쿼리에 들어갑니다.
- 인덱스도 tenant_id를 포함한 복합 인덱스가 필요할 때가 많습니다.
- 핫 테넌트가 있으면 특정 파티션/인덱스가 과부하가 될 수 있습니다.
결국 멀티테넌시는 “쿼리 플랜과 파티셔닝”까지 포함한 설계가 필요합니다.
4) 마이그레이션/배포: 테넌트 수만큼 반복되는 문제
테넌트가 많아질수록 아래가 어려워집니다.
- 스키마 변경을 언제/어떻게 적용할지(롤링, 버전 관리)
- 테넌트별로 데이터 크기가 달라 마이그레이션 시간이 제각각
- 실패했을 때 특정 테넌트만 롤백/복구해야 함
실무 팁:
- 스키마/애플리케이션 버전을 분리해 단계적 적용(expand/contract)
- 마이그레이션 작업은 멱등/재개 가능하게(중단해도 이어서)
5) 백업/복구/삭제: 테넌트 단위 운영을 준비하라
- 테넌트별 데이터 export/삭제 요구(규정/GDPR)가 생길 수 있습니다.
- “특정 테넌트만 복구”가 가능한지(논리 백업/파티션/스키마 분리 여부)가 중요해집니다.
6) 과금/쿼터: 플랫폼 운영의 현실
멀티테넌시는 보통 “요금제/제한”이 필요해집니다.
- 테넌트별 요청 수/스토리지/사용량 메트릭
- 쿼터/레이트 리밋(테넌트 단위)로 noisy neighbor 방지
연습(추천)
- 내 서비스가 멀티테넌시라면 “격리 요구사항”을 숫자로 정의해보기(예: 다른 테넌트 데이터 접근 0, 핫 테넌트가 전체 p99에 영향 주면 안 됨 등)
- Shared schema 모델을 가정하고, tenant_id 필터 누락이 불가능하게 만드는 구조(ORM 필터/DB 정책/테스트)를 설계해보기
- 핫 테넌트가 생겼을 때 하이브리드(핫 테넌트만 분리 DB)로 이동하는 절차를 시나리오로 써보기
💬 댓글