[SaaS] Enterprise 환경으로 확장하기 쉬운 Multi-Tenancy 서비스 구축하기

Context

SaaS 제품이 엔터프라이즈 고객으로 확장되면서 전체 테넌트에 공통으로 적용되는 서비스와 테넌트별로 독립적으로 운영해야 하는 서비스를 구분 관리해야 했다. 초기에는 통합 데이터베이스 환경에서 시작하되, 향후 테넌트별 독립 DB로 마이그레이션할 때 스키마 변경을 최소화해야 했다.

Technical Solution

• Common 서비스와 Tenant 서비스 분리: 회원가입, 로그인 등 전체 테넌트 공통 기능은 Common 서비스로, 병원별 직원관리·시술관리 등 테넌트 고유 기능은 Tenant 서비스로 구분
• Kubernetes Manifest를 gomplate 템플릿으로 관리: 단일 YAML 템플릿에서 환경 변수 기반 파라미터화(NAMESPACE, IMAGE_TAG, AWS_SERVICE_ACCOUNT_ARN, SHOULD_INIT, ENV)를 통해 gomplate로 최종 Manifest 생성
• 엔터프라이즈별 Namespace 격리: Kubernetes Namespace로 테넌트별 리소스 분리
• ServiceAccount + AWS IAM Role(IRSA) 연동: 각 서비스가 AWS 서비스 접근 권한을 가진 IAM Role을 ServiceAccount 어노테이션을 통해 부여
• MongoDB tenantId suffix 전략: 논리적 Collection 이름에 tenantId를 suffix로 추가하여 물리적 Collection 생성(예: service_a_collection_{tenantId}), 스키마 관리는 Application Code로만 수행, 향후 독립 DB 마이그레이션 시 suffix 기반 Collection만 추출하여 dump 수행
• Semantic versioning 기반 다중 버전 관리: git tag를 참조하여 Container Image를 Build하고, Deployment의 Image tag 변경만으로 파트너별 다른 버전 배포

Key Takeaway

멀티테넌시 환경에서 즉시적인 엔터프라이즈 격리와 향후 데이터 마이그레이션 유연성을 동시에 확보하려면, Kubernetes Namespace 격리와 MongoDB의 동적 Collection 생성 특성을 활용한 애플리케이션 레벨의 tenantId suffix 전략이 DDL 변경 없이 스케일링을 가능하게 한다.