SAP BTP가 SaaS 멀티테넌시 아키텍처에서 테넌트당 독립 HDI 컨테이너 + XSUAA 기반 테넌트 격리로 스키마별 완전한 데이터 격리 구현

Context

SaaS 애플리케이션에서 여러 고객(테넌트)을 단일 배포로 서빙하면서도 데이터 격리, 독립적 설정, 테넌트별 확장성을 동시에 보장해야 한다. 기존 Spring Boot/Hibernate 멀티테넌시는 수동 테넌트 해석 및 스키마 마이그레이션 관리가 필요했다.

Technical Solution

• 테넌트 격리 패턴: 테넌트당 독립 HDI 컨테이너 생성 (Schema-Per-Tenant 패턴) → TENANT_A_HDI, TENANT_B_HDI 등 완전한 데이터베이스 레벨 격리 구현
• XSUAA 기반 테넌트 라우팅: URL 서브도메인(tenant-a.my-saas-app.com)에서 테넌트 추출 → XSUAA 아이덴티티 존으로 매핑 → JWT의 zid(Zone ID) 클레임으로 쿼리 라우팅
• SaaS Provisioning Service(saas-registry) 콜백: PUT /subscriptions/tenants/{tenantId} 엔드포인트로 테넌트 구독 시 HDI 컨테이너 자동 생성 및 스키마 배포
• CAP의 MTX 프레임워크: @sap/cds-mtxs로 자동 테넌트 해석 및 데이터 격리 처리 (Spring Boot의 MultiTenantConnectionProvider + CurrentTenantIdentifierResolver 대체)
• 테넌트별 연결 풀 관리: Hikari 풀 설정(per-tenant 5개 연결) × 테넌트 수 = 전체 HANA 연결 풀 규모 사전 계획

Impact

GDPR 준수: 테넌트 삭제 = HDI 컨테이너 드롭으로 전체 데이터 완전 삭제 가능. 예시로 100개 테넌트 × 테넌트당 5개 연결 = 500개 HANA 데이터베이스 연결 필요.

Key Takeaway

SAP BTP의 멀티테넌시는 XSUAA 아이덴티티 존 + HDI 컨테이너 + saas-registry의 3계층 조합으로 애플리케이션 코드 수정 없이 테넌트 격리를 운영체제 수준에서 자동화한다. 그러나 테넌트 수 증가에 따른 HANA 연결 풀 폭증과 스키마 마이그레이션의 모든 컨테이너 동기화 오버헤드를 반드시 초기 설계 단계에서 고려해야 한다.