멀티테넌트 SaaS 아키텍처의 3가지 데이터 격리 모델을 비교 분석해 초기 선택이 이후 운영 복잡도에 미치는 영향 규명

Context

멀티테넌트 아키텍처의 격리 모델은 화이트보드에서는 단순해 보이지만 프로덕션 환경에서는 복잡한 결과를 초래한다. 초기에 잘못된 격리 모델을 선택하거나 의도적으로 선택하지 않으면 나중에 되돌리기 어려운 문제들이 발생한다.

Technical Solution

• Separate databases per tenant 모델 도입: 테넌트마다 별도 데이터베이스 인스턴스를 할당해 완전한 데이터 격리와 깔끔한 테넌트 오프보딩 달성
• Separate schemas, shared database 모델 도입: 단일 데이터베이스 서버에서 각 테넌트마다 스키마를 할당하고 PgBouncer의 search_path를 요청별로 설정해 운영 오버헤드 감소
• Shared schema, shared database 모델에서 Row-Level Security 도입: 모든 테이블에 tenant_id 컬럼을 추가하고 PostgreSQL RLS 정책으로 current_setting('app.current_tenant_id')를 통해 데이터베이스 계층에서 강제 격리
• 테넌트 컨텍스트 해결 방법 구현: Subdomain 기반(acme.yourapp.com), Path 기반(yourapp.com/t/acme), Token 기반(JWT/세션 토큰) 중 선택해 요청이 어느 테넌트인지 식별
• 스키마 마이그레이션 자동화: tenant_migrations 테이블을 관리 데이터베이스에 생성해 각 테넌트의 마이그레이션 상태를 추적하고 배포 파이프라인에서 병렬 실행 및 부분 롤아웃 실패 처리
• 테넌트 격리 검증 테스트 구현: CI 파이프라인에서 두 개의 테스트 테넌트를 생성해 한 테넌트로 인증 후 다른 테넌트의 데이터 접근을 차단하는지 확인하는 통합 테스트 실행

Key Takeaway

멀티테넌트 아키텍처의 격리 모델 선택은 운영 비용, 마이그레이션 복잡도, 보안 위험 사이의 트레이드오프를 명확히 이해한 후 의도적으로 결정해야 한다. 테넌트 격리는 설계 선택사항이 아닌 정확성 속성이므로 CI 파이프라인에서 지속적으로 검증해야 한다.