하나의 코드베이스, 수백 개의 테넌트, 데이터 유출 제로 — 모든 확장 가능한 SaaS 비즈니스의 기반입니다.

단일 배포로 여러 고객에게 서비스를 제공하는 플랫폼을 구축하고 있습니다. 각 고객은 격리된 데이터, 브랜드화된 경험, 테넌트별 청구를 기대하지만, 각각의 인프라를 개별적으로 운영할 여유는 없습니다. 전용 시스템의 격리 보장과 공유 인프라의 경제성이 모두 필요합니다. 이는 SaaS 아키텍처의 근본적인 긴장이며, 초기에 격리 모델을 잘못 설정하는 것은 플랫폼 개발에서 가장 값비싼 실수 중 하나입니다.
멀티테넌트 SaaS 아키텍처는 기본 컴퓨팅, 스토리지 및 네트워킹 리소스를 공유하면서 테넌트 간의 논리적 또는 물리적 분리를 제공합니다. 이 패턴은 테넌트 프로비저닝, 데이터 격리, 기능 관리, 청구 측정 및 화이트 라벨 커스터마이징을 포함합니다. 핵심 설계 결정은 격리 모델입니다: 행 수준 보안(row-level security)이 있는 공유 데이터베이스, 테넌트별 스키마(schema-per-tenant) 또는 테넌트별 데이터베이스(database-per-tenant). 각 모델은 격리 강도와 운영 복잡성 및 비용 효율성 사이에서 절충합니다.
Explore more design patterns and system architectures
최적의 선택은 테넌트 격리 요구사항과 규모에 따라 달라집니다. MicrocosmWorks는 일반적으로 대부분의 B2B SaaS 제품에 대해 비용 효율성과 데이터 격리의 균형을 맞출 수 있기 때문에 공유 데이터베이스, 개별 스키마 방식을 권장합니다. 단, 의료 또는 금융과 같이 엄격한 데이터 분리가 의무화된 규제 산업의 고객에게는 테넌트별 데이터베이스를 구현합니다. 당사의 아키텍트들은 적절한 테넌시 모델을 권장하기 전에 고객의 규정 준수 요구사항, 예상 테넌트 수 및 쿼리 패턴을 평가합니다.
MicrocosmWorks는 noisy-neighbor problems를 방지하기 위해 tenant-aware rate limiting, per-tenant quotas가 적용된 connection pooling, 그리고 compute layer에서의 resource isolation을 구현합니다. 저희는 weighted fair queuing 및 tenant-specific caching tiers와 같은 기술을 사용하여 한 고객의 갑작스러운 spike가 다른 고객에게 latency로 이어지지 않도록 합니다. enterprise-tier tenants의 경우, 공유 control plane을 그대로 유지하면서 전용 compute partitions를 프로비저닝할 수 있습니다.
MicrocosmWorks는 요구되는 복잡성과 팀의 경력 수준에 따라 시간당 $15~$45의 컨설팅 요율로 아키텍처 설계 및 구현 서비스를 제공합니다. 일반적인 멀티테넌트 SaaS 아키텍처 프로젝트는 database 설계, tenant isolation, authentication, deployment pipelines를 아우르며, 교차 기능 팀과 함께 8~16주가 소요됩니다. 저희는 모든 프로젝트의 범위 설정을 위해 고정 가격의 초기 탐색 단계를 거치므로, 고객께서는 본격적인 구축에 착수하기 전에 전체 비용을 명확하게 파악하실 수 있습니다.
MicrocosmWorks는 새로운 가입 후 몇 분 이내에 스키마 생성, DNS 구성, 기능 플래그 초기화 및 초기 데이터 배포를 처리하는 자동화된 테넌트 프로비저닝 파이프라인을 구축합니다. 우리는 Terraform 또는 Pulumi와 같은 infrastructure-as-code 도구를 이벤트 기반 워크플로우와 결합하여, 각 신규 테넌트가 수동 개입 없이 완전히 구성된 환경을 얻도록 합니다. 이러한 접근 방식을 통해 당사 고객은 온보딩 프로세스를 변경하지 않고 10개의 테넌트에서 10,000개로 확장할 수 있습니다.
MicrocosmWorks는 `feature flags`, `tenant-specific metadata`, 그리고 `plugin architecture`를 사용하여 `code branching` 없이 테넌트별 동작을 가능하게 하는 구성 기반 맞춤화 계층을 구현합니다. 저희는 `UI theming`, `workflow engine` 및 통합 계층에 확장성 지점을 설계하여 테넌트가 고유한 브랜딩, 비즈니스 규칙 및 타사 연결을 가질 수 있도록 하며, 이 모든 것은 구성을 통해 관리됩니다. 이를 통해 엔지니어링 팀은 `single codebase`를 유지하면서 다양한 고객 요구 사항을 지원할 수 있습니다.
시스템은 세 가지 계층으로 구성됩니다. 테넌트 인식 게이트웨이는 인증, 테넌트 확인(서브도메인, JWT 클레임 또는 API 키를 통해) 및 요청 라우팅을 처리합니다. 애플리케이션 계층은 완전히 테넌트 컨텍스트 내에서 작동합니다. 모든 쿼리, 모든 캐시 키, 모든 큐 메시지는 확인된 테넌트에 범위가 지정됩니다. 데이터 계층은 행 수준 보안(row-level security) 정책, 테넌트별 연결 풀링 및 저장 시 암호화된 파티셔닝을 통해 스토리지 수준에서 격리를 시행합니다.
tenant_id로 모든 쿼리를 필터링하는 PostgreSQL 정책. 스키마별 테넌트의 경우: 연결 풀 관리와 함께 동적 연결 라우팅. 데이터베이스별 테넌트의 경우: Terraform/Pulumi를 사용한 프로비저닝 자동화.acme.yourapp.com)은 화이트 라벨 제품에 더 깔끔하며 테넌트별 TLS 인증서를 허용합니다. 경로 기반(yourapp.com/acme/)은 구현이 더 간단하고 와일드카드 DNS 복잡성을 피할 수 있습니다. MicrocosmWorks는 화이트 라벨 요구 사항이 있는 B2B SaaS의 경우 서브도메인 확인을, 내부 멀티테넌트 도구의 경우 경로 기반을 권장합니다.tenant_id에 범위가 지정되어야 합니다. 이는 분명해 보이지만, 테넌트 간의 캐시 키 충돌은 가장 흔한 멀티테넌트 버그 중 하나입니다. 우리는 테넌트 컨텍스트를 자동으로 접두사로 붙이는 캐시 키 팩토리를 통해 이를 강제합니다.| 계층 | 기술 |
|---|---|
| 컴퓨팅 | Node.js (NestJS), Python (FastAPI), ECS Fargate 또는 Kubernetes에서 컨테이너화 |
| 데이터 | RLS를 사용하는 PostgreSQL, Redis (테넌트 범위 지정), S3 (테넌트 분할 버킷) |
| ID | 테넌트 범위 조직을 사용하는 Clerk, Auth0 또는 Okta |
| 결제 | Stripe Connect (마켓플레이스 모델), Stripe Billing (측정 기반 구독) |
| 관측 가능성 | 테넌트 차원 태그가 있는 Datadog, 모든 항목에 tenant_id가 있는 구조화된 로깅 |
| 사용 시기 | 피해야 할 시기 |
|---|---|
| 공유 인프라에서 10개 이상의 고객에게 서비스를 제공하는 B2B 플랫폼을 구축할 때 | 각 고객이 완전히 전용 인프라를 요구하는 경우 (규정 준수/계약상) |
| 화이트 라벨 브랜딩, 사용자 지정 도메인 및 테넌트별 기능 제어가 필요한 경우 | 고객이 3명 미만인 경우 — 더 간단한 고객별 배포로 충분할 수 있습니다 |
| 사용량 기반 또는 계층형 가격 책정에 테넌트별 측정이 필요한 경우 | 제품이 조직 수준 테넌트가 아닌 사용자 수준 계정을 가진 소비자 앱인 경우 |
| 하나의 배포 파이프라인, 하나의 모니터링 스택, 하나의 온콜 로테이션을 원하는 경우 | 테넌트가 (단순한 구성이 아닌) 근본적으로 다른 스키마 또는 비즈니스 로직을 가지고 있는 경우 |
MicrocosmWorks는 멀티테넌시를 기능이 아닌 교차 관심사(cross-cutting concern)로 다룹니다. 우리는 미들웨어 수준에서 테넌트 컨텍스트 전파를 구현하여 애플리케이션 코드가 테넌트별로 수동으로 필터링하지 않도록 합니다 — 이는 프레임워크에 의해 강제됩니다. 우리의 RLS 구현에는 모든 CI 실행에서 테넌트 간 데이터 액세스를 시도하는 자동화된 테스트 스위트가 포함됩니다. 우리는 공유 인프라에서 500개 이상의 테넌트에 서비스를 제공하는 멀티테넌트 플랫폼을 데이터 유출 사고 없이 구축했으며, 스트랭글러 피그(strangler fig) 패턴을 사용하여 단일 테넌트 모놀리스를 멀티테넌트 아키텍처로 마이그레이션했습니다.
모델은 스스로 작동하지 않습니다. 모델을 훈련하고, 검증하고, 배포하고, 모니터링하는 파이프라인이 실제 제품입니다. 모델은 단지 하나의 아티팩트일 뿐입니다.