Multi-tenancy

Multi-tenancy

멀티테넌시는 단일 애플리케이션 인스턴스 및 인프라를 여러 고객 (테넌트) 이 공유하면서도, 데이터, 설정, UI 등을 논리적으로 분리해 독립적인 사용자 경험을 제공하는 클라우드 기반 아키텍처이다. 공유 스키마, 개별 스키마, 전용 DB 등 다양한 데이터 격리 모델을 통해 비용 절감과 확장성을 달성하며, 인증·인가, 운영 모니터링, CI/CD 자동화 등 보안 및 운영 전략이 필수적으로 요구된다. 구현 방식에 따라 Soft/Hard Tenancy 또는 Hybrid 모델로 분류되며, SaaS 플랫폼의 효율성과 유연성을 확보하기 위한 핵심 설계 원칙으로 작용한다.

등장 배경 및 발전 과정

등장 배경

멀티테넌시는 1960 년대 메인프레임 시대의 타임 쉐어링 시스템 (TSS) 에서 유래한 리소스 공유 개념에서 출발했다.
이후 1990 년대에는 ASP(Application Service Provider) 모델이 등장하며 웹 기반 애플리케이션을 여러 고객에게 제공하는 시도가 이루어졌으나, 보안과 유지보수의 어려움으로 확산에는 한계가 있었다.
2000 년대에 들어서면서 Salesforce를 필두로 한 SaaS 모델이 등장했고, 하나의 인프라와 애플리케이션 인스턴스를 여러 고객이 공유하되, 데이터와 설정은 논리적으로 분리하는 멀티테넌시 아키텍처가 SaaS 의 핵심 패턴으로 자리 잡게 되었다.

발전 과정

목적 및 필요성

목적

멀티테넌시의 목적은 하나의 애플리케이션 인스턴스와 공통 인프라를 통해 다수의 고객에게 서비스를 제공하면서도, 유지보수, 배포, 업데이트 등을 중앙 집중식으로 처리하여 운영 효율성과 개발 생산성을 극대화하는 데 있다. 이를 통해 서비스 일관성 유지, 비용 절감, 고객 맞춤형 기능 제공이 가능해진다.

필요성

• 비용 최적화: 인프라, 운영, 라이선스 비용을 다수 고객이 분담하여 TCO 를 절감
• 확장성 확보: 테넌트 증가 시 별도 인프라 없이 빠르게 서비스 확장 가능
• 운영 효율성: 단일 인스턴스 관리로 업데이트, 패치, 모니터링 등 유지보수가 단순화
• 비즈니스 민첩성: 고객별 설정 기반 맞춤 서비스 제공으로 시장 대응력 향상
• 보안 및 규제 대응: 데이터 격리, 인증/인가, 감사 로그 등 보안 요구사항에 유연하게 대응
• 글로벌 서비스 및 디지털 전환 대응: 멀티 리전 운영 및 클라우드 네이티브 전략과의 자연스러운 결합

핵심 개념

핵심 개념과 실무 구현 연관성

멀티테넌시 계층 구조 설계

멀티테넌시 시스템은 일반적으로 다음과 같은 계층 구조를 기반으로 설계된다:

flowchart TD
    UI[Presentation Layer<br/>Web / API Gateway]
    App[Application Layer<br/>Business Logic]
    SVC[Service Layer<br/>Tenant-Aware Services]
    DBL[Persistence Layer<br/>ORM / Query Builder]
    DB[Database Layer<br/>Shared or Separate DB]
    Infra[Infrastructure Layer<br/>Kubernetes, CI/CD, Monitoring]

    UI --> App
    App --> SVC
    SVC --> DBL
    DBL --> DB
    Infra --> App
    Infra --> DB

계층별 구조 및 설명

계층 설계 + 사례 매핑 요약

주요 기능 및 역할

주요 기능

멀티테넌시 시스템이 제공하는 구현 메커니즘이다.

주요 역할

이 기능이 실질적으로 달성하고자 하는 비즈니스적/운영적 목적이다.

각 기능별 구현 기술 스택 매핑

각 기능은 SaaS 구조에서 API Gateway → Middleware → App Layer → Infra Layer에 걸쳐 구현됨

특징

멀티테넌시는 논리적 격리와 물리적 공유를 기반으로 하며, 효율적인 운영, 확장성, 보안, 사용자 맞춤화의 균형을 추구한다. 모든 테넌트는 동일한 코드와 인프라를 사용하지만 데이터, 설정, 권한 등은 분리되어 있어 독립된 사용자 경험이 가능하다. 테넌트별 커스터마이징, 모니터링, 버전 관리, SLA 분리는 확장성 있는 SaaS 운영을 위한 핵심 전략이다.

멀티테넌시의 핵심은 논리적 격리와 자원 공유의 균형이다. 격리 측면에서는 테넌트별 데이터 보호, 접근 제어, 인증 분리가 필수이며, 자원 측면에서는 서버/DB 를 공유하면서도 비용을 최적화하고 운영을 단순화할 수 있다. 또한, UI/기능 수준의 유연한 커스터마이징, CI/CD 기반의 일괄 배포, SLA 분리 등은 대규모 SaaS 운영의 핵심 전략이다. 마지막으로, 온보딩~해지까지의 전체 테넌트 라이프사이클을 정책적으로 다룰 수 있어야 멀티테넌시의 강점을 극대화할 수 있다.

핵심 원칙

멀티테넌시 시스템의 핵심 원칙은 강력한 격리, 보안 중심 설계, 운영 자동화, 자원 효율성, 유연한 커스터마이징, 그리고 테넌트 독립성 보장에 기반한다. 모든 요청은 테넌트 컨텍스트 하에서 처리되며, 자원은 공유하되 논리적으로 철저히 분리되어야 한다. 장애, 성능, 데이터 관점의 격리를 통해 공정한 서비스 품질을 유지하고, 자동화된 온보딩·업데이트·할당 체계를 갖추어야 안정적인 대규모 운영이 가능하다. 보안, 감사, 데이터 주권 등 정책 요소 역시 설계 초기부터 반영되어야 한다.

• 격리 원칙은 멀티테넌시 시스템의 신뢰성과 안정성을 결정하는 핵심으로, 데이터·장애·성능 등 모든 측면에서 테넌트 간 완전한 분리가 보장되어야 한다.
• 보안 원칙은 인증·인가, RBAC, 암호화, 감사 추적 등 보안 메커니즘이 시스템 전반에 일관되게 적용되어야 함을 의미한다.
• 운영 원칙은 자동화된 테넌트 할당, 기능 제어, 배포 관리 등 지속적 운영과 변화 대응을 위한 핵심 전략을 포함한다.
• 유연성과 효율성은 자원 공유 기반 운영 구조를 유지하면서도 각 테넌트의 맞춤 요구사항을 수용할 수 있는 아키텍처적 유연성을 의미한다.
• 투명성/독립성은 하나의 시스템 내에서 다수의 고객이 존재하더라도 각자가 독립적인 서비스를 받고 있다고 느끼도록 만들어주는 원칙이다.

주요 원리 및 작동 원리

주요 원리

graph TD
    Req[Request]
    Req --> ID[테넌트 식별자 추출]
    ID --> CTX[테넌트 컨텍스트 생성]
    CTX --> AUTH[인증 및 권한 확인]
    AUTH --> FILTER[데이터 및 리소스 필터링]
    FILTER --> ROUTE[비즈니스 로직 라우팅]
    ROUTE --> RESP[테넌트 전용 응답 반환]

작동 원리

graph TB
    A[User 요청]
    A --> B[API Gateway]
    B --> C[Tenant Context Resolver]
    C --> D["Application (Shared Logic)"]
    D --> E{데이터 격리}
    E --> F1["Shared DB (Row Filter)"]
    E --> F2[Schema per Tenant]
    E --> F3[DB per Tenant]
    D --> G[테넌트 정책/기능 적용]

SaaS 설계 시 주요 원리 적용 시나리오

시나리오 핵심 요약 매핑

구조 및 아키텍처

멀티테넌시 아키텍처는 하나의 공유된 애플리케이션 인스턴스와 인프라를 여러 고객 (테넌트) 이 동시에 사용하면서도, 각 테넌트의 데이터, 설정, 인증, UI, 리소스가 완전히 분리되도록 구성된다.

핵심 구조는 애플리케이션 공유 + 데이터 격리 + 테넌트 컨텍스트 처리 + 운영 자동화를 기반으로 하며, 보안, 확장성, 유연성을 모두 보장해야 한다.

테넌트 식별은 미들웨어에서 시작되어 전체 요청 흐름에 유지되며, 데이터는 테넌트별로 스키마 혹은 DB 수준에서 분리되고, 자원 사용량은 Kubernetes 기반 쿼터 및 오토스케일링 등으로 통제된다.

고급 아키텍처에서는 테넌트별 커스터마이징, 과금, 백업, 다중 리전 대응까지 포함하여 설계된다.

flowchart TD
    subgraph Client
        Browser[Web/Mobile/API Client]
    end

    subgraph Edge Layer
        Gateway[API Gateway]
        WAF[WAF / Rate Limiter]
    end

    subgraph Middleware Layer
        Middleware[Tenant Context Middleware]
    end

    subgraph App Layer
        App[Shared Application Service]
        Auth[Authentication & Authorization]
        Config[Customization Engine]
        Monitor[Monitoring & Logging]
        Billing[Billing / Usage Tracker]
    end

    subgraph Data Layer
        SharedDB[(Shared DB)]
        SchemaPerTenant[(Schema-per-Tenant)]
        DBPerTenant[(DB-per-Tenant)]
    end

    subgraph Infra Layer
        K8s[Kubernetes + Resource Quota]
        CI[CI/CD + Versioning]
        Backup[Backup & Recovery]
        ShardCtrl[Shard Controller]
    end

    Browser --> Gateway --> WAF --> Middleware
    Middleware --> App
    Middleware --> Auth
    App --> SharedDB
    App --> SchemaPerTenant
    App --> DBPerTenant
    App --> Config
    App --> Monitor
    App --> Billing
    App --> K8s
    App --> ShardCtrl
    App --> CI
    App --> Backup

구성 요소

구성 요소별 장애 대응 전략

• 장애 대응은 격리성 + 이중화 + 모니터링의 삼박자를 갖춰야 한다. 단일 장애가 전체 테넌트에 전파되지 않도록 벌크헤드 패턴, Circuit Breaker, 테넌트 그룹화가 유용하게 작동한다.

구현 기법 및 방법

Shared Schema 방식

시스템 구성 예시:

graph LR
    A[Application] --> B[(Shared Database)]
    B --> C[customers table]
    B --> D[orders table]
    B --> E[products table]
    
    C --> C1[tenant_id + customer_data]
    D --> D1[tenant_id + order_data]
    E --> E1[tenant_id + product_data]

코드 구현 예시: Python + SQLAlchemy 예시

1
2
3
4
5
6
7
8
9

# tenant_context.py
from contextvars import ContextVar
tenant_id = ContextVar('tenant_id')

def set_tenant(tid):
    tenant_id.set(tid)

def get_tenant():
    return tenant_id.get()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# models.py
from sqlalchemy import Column, Integer, String, ForeignKey
from sqlalchemy.ext.declarative import declarative_base
from tenant_context import get_tenant

Base = declarative_base()

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    tenant_id = Column(String, index=True)
    email = Column(String)
    name = Column(String)

    @staticmethod
    def get_tenant_query(session):
        return session.query(User).filter(User.tenant_id == get_tenant())

Separate Schema 방식

시스템 구성 예시:

graph TB
    A[Application] --> B[(Database)]
    B --> C[tenant1 schema]
    B --> D[tenant2 schema]
    B --> E[tenant3 schema]
    
    C --> C1[customers]
    C --> C2[orders]
    D --> D1[customers]
    D --> D2[orders]

코드 구현 예시: Python + Django Router

1
2
3
4
5
6
7
8
9

# routers.py
class TenantRouter:
    def db_for_read(self, model, **hints):
        tenant_schema = get_current_tenant_schema()  # 예: 'tenant_a'
        return f'{tenant_schema}_db'

    def db_for_write(self, model, **hints):
        tenant_schema = get_current_tenant_schema()
        return f'{tenant_schema}_db'

1
2
3
4
5
6

# settings.py
DATABASES = {
    'tenant_a_db': {…},
    'tenant_b_db': {…},
}
DATABASE_ROUTERS = ['routers.TenantRouter']

Separate DB 방식

시스템 구성 예시:

graph TB
    A[Application] --> B[Connection Router]
    B --> C[(Tenant A DB)]
    B --> D[(Tenant B DB)]
    B --> E[(Tenant C DB)]
    
    C --> C1[Schema A]
    D --> D1[Schema B]
    E --> E1[Schema C]

코드 구현 예시: JavaScript + Node.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// dbManager.js
const connections = new Map();

function getTenantDb(tenantId) {
  if (!connections.has(tenantId)) {
    connections.set(
      tenantId,
      new Sequelize(`tenant_${tenantId}_db`, 'user', 'pass', { dialect: 'postgres' })
    );
  }
  return connections.get(tenantId);
}

module.exports = { getTenantDb };

1
2
3
4

// usage
const { getTenantDb } = require('./dbManager');
const db = getTenantDb('tenant_123');
const users = await db.models.User.findAll();

K8s 기반 자원 제어

코드 구현 예시: Namespace + Limit

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: v1
kind: Namespace
metadata:
  name: tenant-a

---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

Shared vs. Separate 모델 선택 기준

주요 모델은 Shared Schema, Separate Schema, Separate Database 로 분류되고, 필요에 따라 Hybrid 모델도 구성 가능하다.

• 모델 선택은 격리 수준 vs 비용/운영 간 Trade-off가 핵심이다. 민감한 고객이 많다면 Separate DB 또는 Schema 기반이 적합하다.

장점

• 운영 효율성은 멀티테넌시의 가장 큰 강점 중 하나로, 단일 인스턴스로 모든 테넌트를 관리하면서도 패치, 배포, 모니터링을 중앙에서 일괄적으로 처리할 수 있어 유지보수 비용이 현저히 감소한다.
• 비용 절감은 자원을 다수의 테넌트가 공유함으로써 발생하는 경제적 이점으로, 초기 투자와 운영비 부담이 크게 완화된다.
• 확장성과 민첩성은 새로운 고객을 빠르게 온보딩하거나 시장 변화에 민감하게 대응할 수 있게 해주며, SaaS 의 핵심 경쟁력이 된다.
• 서비스 품질/일관성은 모든 테넌트가 동일한 소프트웨어 구조를 사용하기 때문에 기능 배포와 정책 적용의 일관성을 유지할 수 있다.
• 분석 및 가시성 향상은 테넌트 단위의 데이터 수집 및 분석이 가능해 운영 통계, 과금, SLA 관리까지 통합적으로 관리할 수 있게 해준다.
• 사용자 맞춤화 유연성은 테넌트마다 요구되는 UI, 기능, 정책을 설정 기반으로 손쉽게 제어할 수 있어 대규모 사용자 요구사항을 유연하게 수용할 수 있다.

단점과 문제점 그리고 해결방안

단점

멀티테넌시 구조는 공유 인프라 기반으로 운영 효율성과 비용을 절감하지만, 보안, 성능 간섭, 맞춤화 제약, 장애 전파 위험, 운영 복잡성이라는 핵심적인 단점을 내포한다. 이러한 단점은 다층 보안, 격리 기술, 자동화 도구, 기능 확장 아키텍처 등을 통해 완화할 수 있다.

문제점

멀티테넌시 시스템의 문제점은 주로 데이터 유출, 성능 병목, 배포 리스크, 설정 충돌, 규정 위반으로 나타난다. 이를 해결하려면 Row-level 보안, 자원 분리, 점진적 배포 전략, 설정 검증 프로세스, 리전 기반 설계 등의 전략적 기술적 조치가 필요하다.

대응 전략별 기술 매핑

• 보안/데이터 격리는 Row-Level Security, OPA, 암호화, RBAC 등과 같은 정책 기반 제어로 실현해야 함.
• 성능 문제는 Kubernetes 자원 제어, Autoscaling, Rate Limiting 등으로 격리 또는 탄력적으로 대응.
• 장애 전파 방지에는 Circuit Breaker, Retry, 분산 배치 등 고가용성 설계가 필수.
• 운영 자동화와 테넌트 온보딩은 IaC + CI/CD 체계를 결합해 반복 가능하게 구성.
• 설정 충돌이나 배포 위험은 Feature Flag, Canary, Helm override 등의 안전한 변경 경로 확보가 중요.
• 글로벌 SaaS에서는 리전별 컴플라이언스 분기 처리를 전략적으로 포함해야 한다.

도전 과제

• 데이터 보안 및 규정 준수
  각 테넌트의 데이터가 철저히 분리되고 보안 및 규정 준수를 자동화해야 하는 구조가 필수적이다. 암호화, 접근 제어, 감사 추적은 필수 요소다.

• 성능 및 자원 격리
  여러 테넌트가 공존할 경우 하나의 테넌트가 시스템 전체에 영향을 미치지 않도록 자원 격리가 선행돼야 한다. Auto-scaling 과 Rate-limiting 은 기본 설계 요소다.

• 운영 복잡성 및 자동화
  수십, 수백 테넌트를 운영할 때는 수작업 배포나 설정은 치명적이다. IaC, 온보딩 자동화, GitOps 기반 배포 구조가 권장된다.

• 맞춤화 및 확장성
  테넌트마다 요구가 다를 경우, 플러그인 및 Feature Flag 등 유연한 아키텍처 확장이 중요하다.

• 관측성 및 문제 진단
  장애 발생 시, 테넌트별로 빠르게 원인을 진단할 수 있어야 하며, 이를 위해 로그와 메트릭은 테넌트 단위로 수집되고 분석돼야 한다.

• 확장성 및 구조 유연성
  스키마 분리나 인프라 격리로 전환이 필요한 시점이 반드시 오므로, 구조 전환의 유연성과 자동 마이그레이션 도구 준비가 필수다.

• 신기술 및 특수 워크로드 대응
  GPU, AI, 엣지 등 특수 요구 테넌트는 기존 아키텍처로는 대응이 어려우므로 별도의 격리 및 리전 전략이 요구된다.

분류 기준에 따른 종류 및 유형

• 데이터 격리 방식:
  멀티테넌시의 핵심인 데이터 분리는 비용 - 보안 - 운영 효율성 간의 균형을 결정하는 요소다. Shared Schema 는 가장 효율적이지만 보안에 취약하며, Separate Database 는 가장 안전하지만 비용이 크다. Hybrid 는 유연한 구조를 지향하는 전략적 방식이다.

• 애플리케이션 배포 모델:
  모든 테넌트를 하나의 인스턴스에서 처리하는 방식은 효율적이지만, 장애 격리나 커스터마이징에 한계가 있다. 반면 Instance per Tenant 는 유연성은 높지만 리소스 소비가 크다.

• 서비스 환경:
  Single-Tenant 는 독립적인 고객을 위한 환경으로 보안 및 맞춤화에 강하고, Multi-Tenant 는 운영 효율성과 빠른 스케일링에 적합하다.

• 자원 공유 수준:
  완전 공유는 비용 절감에 유리하나, 성능 간섭과 보안 리스크를 내포하며, 전용 자원은 고객별 SLA 와 규정 준수 요구사항을 만족시킨다.

• 커스터마이징 수준:
  요금제 또는 고객 세그먼트에 따라 테넌트별 설정 정도를 나누며, 고가 고객에게는 Full Customization 이 요구되는 경우가 많다.

• 운영 강도 (Soft vs Hard):
  Soft 는 논리적 테넌시 분리로 성능은 좋지만 보안 취약성이 존재하고, Hard 는 인프라 단위의 격리로 가장 강력한 보안을 제공한다. 서비스 특성에 맞게 선택해야 한다.

멀티테넌시 vs. 싱글테넌시 비교

참고: 금융, 보건 분야처럼 보안 규제 요구가 높다면 싱글테넌시 고려, 일반 SaaS 서비스는 멀티테넌시가 유리하다.

테넌트 관리 플랫폼 구축

• 필요성: 테넌트 수가 증가하면 수동 관리가 한계에 도달
• 기능 예시:
  • 테넌트 생성/수정/삭제 API
  • 리소스 사용량 대시보드
  • 테넌트 상태 모니터링, 알림 설정
• 적용 기술: Admin UI, Backoffice Portal, Self-service Onboarding

테넌트 ID 전달 방식

• 실무 권장: 내부 시스템용은 Header 기반, 퍼블릭 SaaS 는 Subdomain 기반이 가장 많이 사용됨

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

• 아키텍처 및 설계: 테넌트 식별/데이터 분리를 구조적으로 명확히 해야 전체 시스템 일관성과 보안을 확보할 수 있다.

• 보안 및 격리: 인증과 데이터 보호는 다층적 구조로 구성하고, 테넌트 스코프의 강제 검증이 필수다.

• 테넌트 관리: 자동화된 온보딩과 신뢰성 있는 오프보딩 체계는 운영 복잡성을 줄여준다.

• 자동화 운영: IaC 기반 Helm/Terraform 스크립트는 일관된 배포와 복구에 필수다.

• 성능 격리: 테넌트 간 자원 간섭을 막기 위한 Rate Limit, 캐시 분리 등은 필수 성능 보장 메커니즘이다.

• 모니터링: 테넌트별 지표, 로그, 알림을 별도로 수집하고 분석해야 SLA 준수를 보장할 수 있다.

• 사용자 경험: 커스터마이징은 기능 플래그나 메타데이터로 분기해야 유지보수가 용이하다.

• 테스트 및 에러 처리: 장애 확산을 막고 테넌트 경계 테스트를 자동화하는 구조를 갖추는 것이 중요하다.

• 과금 전략: 사용량 기반 과금과 요금제 기반 제한은 시스템 연동 구조로 설계되어야 자동화가 가능하다.

DDD 기반 테넌트 경계 설계

** 도메인 주도 설계 (DDD)** 를 활용하여 테넌트 간 경계를 명확히 하고 업무 중심으로 모델을 분리

graph TD
  Tenant1 --> AppContext1 --> Domain1
  Tenant2 --> AppContext2 --> Domain2
  Domain1 --> SharedKernel
  Domain2 --> SharedKernel

전략 구성

예시: 테넌트마다 도메인 다르게 설계

병원 테넌트

1
2
3

class Patient:
    def __init__(self, name, medical_record):
        …

학교 테넌트

1
2
3

class Student:
    def __init__(self, name, enrollment_info):
        …

공통 커널 (결제)

1
2
3

class Subscription:
    def __init__(self, plan_id, start_date):
        …

적용 팁

멀티테넌시 시스템 설계 시 의사결정 가이드

graph TD
  A[시스템 요구사항 정의] --> B{보안/규제 필요 여부}
  B -->|높음| C[Single-Tenancy 또는 DB 격리 구조]
  B -->|보통| D{테넌트 수}
  D -->|많음| E[Shared Schema 또는 Shared DB/Schema]
  D -->|적음| F[Separate Schema 또는 DB]
  C --> G[통합 또는 분리 배포 전략 설계]
  E --> G
  F --> G
  G --> H[테넌트 Onboarding 자동화]
  H --> I[리소스 제한/분리 정책 수립]

확장성과 유지보수를 위한 전략

멀티테넌시 마이그레이션 전략

목표: Shared Schema 에서 Separate Schema 또는 DB 로 전환

하이브리드 구조를 유지하면서 상황에 따라 유연하게 전환할 수 있도록 설계해야 다운타임 없이 확장 가능합니다.

성능 튜닝 포인트 및 운영 최적화 전략

보안 및 규제 대응 전략

멀티테넌시 SaaS 운영 시 DevOps 전략

멀티테넌시 환경에서 테넌트 수 증가, 고객 맞춤형 설정, 리소스 분리를 DevOps 관점에서 자동화·최적화하는 전략

핵심 전략 정리

예시: GitOps 기반 테넌트 배포

1
2
3
4
5

# 신규 테넌트 생성 자동화 (예: devops/tenants/tenant-a-values.yaml)
helm upgrade --install tenant-a ./charts/app \
  --namespace tenant-a \
  --create-namespace \
  -f tenants/tenant-a-values.yaml

보안 전략

• 테넌트마다 KMS Key 분리
• JWT 에 테넌트 context 포함
• Vault → tenant_id 기준으로 Secret path 분리

모니터링 구성 (Prometheus + Loki + Grafana)

• 각 로그/메트릭에 tenant_id 라벨 포함
• Grafana Dashboard 에서 테넌트별 필터 제공

멀티테넌시 구조에서 테넌트별 요금제, 과금 (Billing) 처리

테넌트의 리소스 사용량 기반 요금 산정 및 구간별 요금제 제공

구조 다이어그램

graph TD
  Tenant --> UsageTracker
  UsageTracker --> BillingEngine
  BillingEngine --> PaymentGateway
  BillingEngine --> InvoiceDB
  AdminPortal --> BillingEngine

요금제 처리 전략

사용량 수집 예시 (Prometheus + Pushgateway)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 테넌트별 API 호출 수 증가
from prometheus_client import Counter

api_requests = Counter(
    'api_requests_total',
    'Total API requests per tenant',
    ['tenant_id']
)

api_requests.labels(tenant_id='tenant_a').inc()

Stripe 기반 Subscription 연동 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import stripe
stripe.api_key = "sk_test_…"

def create_customer_and_subscription(email, plan_id):
    customer = stripe.Customer.create(email=email)
    subscription = stripe.Subscription.create(
        customer=customer.id,
        items=[{"price": plan_id}],
    )
    return subscription.id

테넌트 과금 처리 고려 사항

요금제에 따른 멀티테넌시 아키텍처 매핑

요금제는 테넌트의 기능 요구, 보안 요구, 성능 요구에 따라 멀티테넌시 아키텍처를 다단계로 구분하여 설계할 수 있다.

최적화하기 위한 고려사항 및 주의할 점

• 쿼리 및 DB 최적화는 테넌트 수 증가에 따른 성능 저하 방지를 위한 가장 핵심적인 영역으로, 파티셔닝 및 슬로우 쿼리 분석이 중요하다.

• 캐싱 전략은 테넌트 간 데이터 충돌 방지와 성능 향상 측면에서 테넌트 분리 네임스페이스 및 TTL 제어가 필수적이다.

• 리소스 관리 및 격리는 noisy neighbor 방지 및 사용량 기반 유연한 확장을 위한 기반이며, 자동 스케일링과 정책 기반 리소스 할당이 권장된다.

• 보안 및 접근 제어는 다중 테넌트를 보호하는 핵심 요소로, RBAC 및 암호화 체계 설계가 중요하다.

• 확장성 및 배포 전략은 고도화된 SaaS 의 핵심 운영 전략으로, 배포 충돌 방지와 유연한 기능 롤아웃 설계가 필요하다.

• 장애 대응 및 회복력은 테넌트 장애 격리 및 전체 시스템 안정성을 위한 설계 요소로, 패턴 및 리전 분산 구조가 효과적이다.

• 관측성 및 운영 자동화는 운영 복잡도를 낮추고 대응 속도를 높이기 위한 핵심 요소이며, 로그, 모니터링, IaC 도입이 중요하다.

• 국제화 및 SLA 고려는 글로벌 SaaS 환경 및 중요 고객 대응을 위한 전략으로, 설정 유연성과 우선순위 기반 리소스 보장이 필요하다.

SaaS 성장 단계에 따른 테넌시 분리 전략 변화

SaaS 시스템은 비용 중심 → 유연성 중심 → 보안/규제 중심으로 성장함에 따라 멀티테넌시 구조를 점진적으로 진화시켜야 한다.

• 초기에는 Shared Schema + 단일 앱 인스턴스 로 시작해, 요구에 따라 Schema 분리 → DB 분리 → 인스턴스 분리 로 진화하는 것이 이상적이다.
• SaaS 성장 전략은 테넌시 구조를 단계적으로 고도화하여, 낮은 비용, 높은 보안, 빠른 확장성을 균형 있게 확보해야 한다.
• 기술적 전환은 항상 자동화 (IaC, Helm, Terraform) 및 **정책 중심 설계 (OPA, Feature Flag)**와 함께 이루어져야 한다.

성장 단계 기준 아키텍처 분기

flowchart TD
    Start([Start: MVP])
    PMF([2단계: Product-Market Fit])
    Scale([3단계: 확장기])
    Enterprise([4단계: 엔터프라이즈 대응])
    Regulated([5단계: 규제 산업/다국가])

    Start --> PMF
    PMF --> Scale
    Scale --> Enterprise
    Enterprise --> Regulated

    Start -->|Shared Schema| A1[Low-cost Multi-tenancy]
    PMF -->|Shared DB + Separate Schema| A2[기능 토글, 설정 기반 분기]
    Scale -->|DB-per-Tenant| A3[성능/보안 분리]
    Enterprise -->|App + DB 격리| A4[Dedicated Namespace]
    Regulated -->|Multi-Region / HA| A5[Hard Multi-Tenancy]

실무 사용 예시

• SaaS 플랫폼은 다수의 고객 (테넌트) 을 대상으로 하는 일반적 구조로, 운영 효율성과 배포 전략 측면에서 가장 대표적인 멀티테넌시 활용 사례다.

• B2B 클라우드 서비스는 특정 도메인 (회계, 데이터 시각화 등) 에 특화된 기능을 각 테넌트에게 분리 제공하면서도 공통 인프라를 유지한다.

• 교육 플랫폼은 학습 콘텐츠를 공유하면서도 학교/기관마다의 학사 운영 환경을 완전히 분리하여 멀티테넌시 설계가 자연스럽게 적용된다.

• 전자상거래 플랫폼은 브랜드 단위 또는 테넌트 단위의 UI, 상품 카탈로그, 결제 모듈이 분리되어야 하므로 고도의 설정 분리 구조가 요구된다.

• 보안 중심 SaaS는 금융, 헬스케어, 공공기관과 같은 민감 데이터를 다루는 환경으로, 데이터 격리, 키 관리, 감사 로그가 필수적이다.

• 커스터마이징 가능한 SaaS는 기능 온/오프, 플래그 기반 설정 등을 통해 고객별 니즈에 맞춘 차별화된 서비스를 제공한다.

• 멀티리전/오케스트레이션 환경은 고가용성과 글로벌 사용자 대응이 핵심으로, 지역/조직별 배포, 성능 분산 구조 설계가 필요하다.

• 헬스케어 플랫폼은 규정 준수 (HIPAA 등) 를 위한 강력한 격리 전략과 역할 기반 접근 제어가 중점이다.

• IoT 및 데이터 분석 플랫폼은 실시간 분석과 대시보드 분리로 테넌트마다 다른 데이터를 처리하고 시각화하는 구조가 일반적이다.

활용 사례

사례 1: 교육 플랫폼

시나리오: 여러 학교 또는 기관이 동일 LMS(학습관리 시스템) 를 사용하되, 각 기관은 자체 정보와 대시보드, 사용자 관리 등을 독립적으로 갖고자 함.

시스템 구성:

• Control plane: 테넌트 온보딩, 인증/권한관리, 요금 청구
• Data plane: 테넌트별 스키마 혹은 DB 격리 + 공통 앱 서버
• Middleware: 요청 시 테넌트 context 삽입
• 분석 레이어: 중앙 로그 분석 및 테넌트별 리포트

graph LR
  User --> LB
  LB --> Middleware --> AppServer
  AppServer --> SchemaA[(DB Schema A)]
  AppServer --> SchemaB[(DB Schema B)]
  AppServer --> SchemaC[(DB Schema C)]
  AppServer --> CentralAnalytics[(Analytics DB)]
  ControlPlane --> Middleware

Workflow:

• 사용자 로그인 → 멀티테넌트 미들웨어가 tenant-id 식별
• 요청은 해당 테넌트 스키마로 라우팅
• 분석 이벤트는 중앙 데이터베이스 수집

역할:

• Middleware: tenant-id 기반 요청 분기
• AppServer: 공통 비즈니스 로직 실행
• DB Layer: 테넌트 데이터 분리 처리
• ControlPlane: 관리 API, 분석, 온보딩

유무에 따른 차이점:

• Multi‑tenant 도입 시: 단일 코드 유지, 공통 업데이트, 리포트 일관성
• Single‑tenant 시: 각 테넌트 별 서버 관리 필요, 운영 복잡도 증가

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# tenant-aware 미들웨어 예시 (Python Flask)
from flask import request, g
def tenant_middleware():
    g.tenant_id = request.headers.get("X-Tenant-ID")
    if not valid_tenant(g.tenant_id):
        abort(403)

@app.before_request
def before():
    tenant_middleware()

@app.route("/data")
def data():
    conn = get_db_connection(tenant_id=g.tenant_id)
    result = conn.query("SELECT * FROM items WHERE tenant_id=%s", g.tenant_id)
    return jsonify(result)

사례 2: 전자상거래 플랫폼을 위한 멀티 테넌트 재고 관리 시스템

시나리오: 전자상거래 플랫폼을 위한 멀티 테넌트 재고 관리 시스템

시스템 구성:

• API Gateway (Kong/Nginx)
• 마이크로서비스 아키텍처 (Node.js/Express)
• PostgreSQL 데이터베이스 (Row-Level Security)
• Redis 캐시 (테넌트별 네임스페이스)
• Elasticsearch 검색 엔진
• Docker 컨테이너화

graph TB
    subgraph "Client Layer"
        CA[Store A Client]
        CB[Store B Client] 
        CC[Store C Client]
    end
    
    subgraph "API Gateway"
        GW[Kong Gateway]
        AUTH[JWT Authentication]
    end
    
    subgraph "Application Services"
        INV[Inventory Service]
        ORD[Order Service]
        PROD[Product Service]
    end
    
    subgraph "Data Layer"
        PG[(PostgreSQL with RLS)]
        RD[(Redis Cache)]
        ES[(Elasticsearch)]
    end
    
    CA --> GW
    CB --> GW
    CC --> GW
    
    GW --> AUTH
    AUTH --> INV
    AUTH --> ORD
    AUTH --> PROD
    
    INV --> PG
    ORD --> PG
    PROD --> PG
    
    INV --> RD
    ORD --> RD
    PROD --> ES

Workflow:

• 클라이언트 요청 시 JWT 토큰에서 테넌트 ID 추출
• API Gateway 에서 테넌트별 라우팅 및 인증 처리
• 마이크로서비스에서 테넌트 컨텍스트 설정
• PostgreSQL RLS 를 통한 자동 데이터 필터링
• Redis 에서 테넌트별 네임스페이스로 캐시 관리
• Elasticsearch 에서 테넌트별 인덱스로 검색 처리

역할:

• API Gateway: 테넌트 식별 및 초기 인증/인가
• 마이크로서비스: 비즈니스 로직과 테넌트 컨텍스트 관리
• 데이터베이스: Row-Level Security 를 통한 데이터 격리
• 캐시 시스템: 성능 최적화와 테넌트별 격리

유무에 따른 차이점:

• 멀티 테넌시 적용 시: 단일 인스턴스로 1000+ 스토어 지원, 95% 비용 절감
• 단일 테넌시: 스토어별 독립 배포 필요, 관리 복잡성 10 배 증가

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

// Express.js 멀티 테넌트 미들웨어
const tenantMiddleware = (req, res, next) => {
    try {
        const token = req.headers.authorization?.split(' ')[1];
        const decoded = jwt.verify(token, process.env.JWT_SECRET);
        
        // 테넌트 컨텍스트 설정
        req.tenant = {
            id: decoded.tenant_id,
            name: decoded.tenant_name,
            schema: `tenant_${decoded.tenant_id}`
        };
        
        // PostgreSQL RLS 설정
        req.db.query('SET row_security = on');
        req.db.query('SET current_tenant = $1', [req.tenant.id]);
        
        next();
    } catch (error) {
        res.status(401).json({ error: 'Invalid tenant context' });
    }
};

// 테넌트별 재고 조회 API
app.get('/api/inventory', tenantMiddleware, async (req, res) => {
    try {
        // RLS가 자동으로 테넌트 필터 적용
        const inventory = await req.db.query(`
            SELECT product_id, quantity, location 
            FROM inventory 
            WHERE status = 'active'
        `);
        
        res.json(inventory.rows);
    } catch (error) {
        res.status(500).json({ error: 'Database error' });
    }
});

// Redis 캐시 (테넌트별 네임스페이스)
const getCacheKey = (tenantId, key) => `tenant:${tenantId}:${key}`;

const cacheGet = async (tenantId, key) => {
    return await redis.get(getCacheKey(tenantId, key));
};

const cacheSet = async (tenantId, key, value, ttl = 3600) => {
    return await redis.setex(getCacheKey(tenantId, key), ttl, value);
};

사례 3: SaaS 회계 서비스

시나리오: 다수 기업에 SaaS 회계 서비스를 제공하는 클라우드 애플리케이션. 각 기업의 데이터는 완전히 분리 (스키마/테이블 기반), 테넌트별 맞춤 기능 지원, 통합 인증/권한 제어.

시스템 구성:

• 프론트엔드: 테넌트별 로그인, UI 커스텀 마이징
• API 서버: 테넌트 인증 및 데이터 접근 제어
• 데이터베이스: 테넌트별 스키마/테이블/행 분리
• 모니터링 및 관리 시스템

graph TD
    A[User/Company A] --> B[Custom UI/API]
    A2[User/Company B] --> B2[Custom UI/API]
    B -- Tenant Auth --> C[App Logic]
    B2 -- Tenant Auth --> C
    C -- Schema A --> D[DB Schema A]
    C -- Schema B --> D2[DB Schema B]
    C -.-> E[Monitoring & Management]

Workflow:

• 사용자는 테넌트 지정 로그인 → 인증 → 요청마다 테넌트 식별 → 해당 데이터만 접근 → 커스텀 기능만 보임

역할:

• 사용자 인증 및 권한 제어, 테넌트별 데이터 보장, 비용 절감, 빠른 신규 서비스 도입

유무에 따른 차이점:

• 멀티테넌시 적용 시 신규 고객 추가·자원 확장이 손쉽고 비용이 절감됨
• 미적용 시 각 테넌트 별도 시스템·DB 필요, 관리 복잡도·비용 증가

구현 예시: Python + PostgreSQL Row Level Security

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# PostgreSQL에서 테넌트별 데이터 RLS 적용 예시
-- 테넌트 id 필드를 포함한 테이블 생성
CREATE TABLE records (
    id SERIAL PRIMARY KEY,
    tenant_id INT NOT NULL,
    data TEXT
);

-- row-level security 정책 활성화
ALTER TABLE records ENABLE ROW LEVEL SECURITY;

-- RLS 정책 정의: 자신의 테넌트 데이터만 접근 가능
CREATE POLICY tenant_isolation_policy ON records
    USING (tenant_id = current_setting('app.current_tenant')::INT);

-- 코드에서 쿼리 실행 전 테넌트 정보 설정
import psycopg2

def run_as_tenant(tenant_id, sql, params):
    with psycopg2.connect(...) as conn:
        with conn.cursor() as cur:
            cur.execute(f"SET app.current_tenant = {tenant_id};")
            cur.execute(sql, params)

사례 4: 진료 기록 SaaS

시나리오: 여러 병원에 진료 기록 SaaS 를 제공하면서 테넌트별 데이터 격리와 맞춤 UI 를 지원

시스템 구성:

• 공통 API 게이트웨이
• Flask 기반 REST 서비스
• PostgreSQL - Separate Schema 방식
• Redis 캐시
• Vault 로 암호화 키 관리

graph TD
  PatientClient --> API_Gateway
  API_Gateway --> TenantMiddleware
  TenantMiddleware --> FlaskService
  FlaskService --> Pg[PostgreSQL]
  Pg --> Schema_TenantA
  Pg --> Schema_TenantB
  FlaskService --> RedisCache
  FlaskService --> Vault[Key Vault]

Workflow:

• 클라이언트 인증 → API Gateway → Middleware 로 테넌트 식별 → Schema 기반 쿼리 수행 → 캐시 조회/비즈니스 로직 실행 → 응답 반환

역할:

• Middleware 는 테넌트 컨텍스트 관리
• FlaskService 는 테넌트 -aware 비즈니스 로직 수행
• Separate Schema 는 테넌트 간 데이터 독립성 보장
• Vault 는 암호화 키 안전 관리

유무에 따른 차이점:

• 있을 경우: 병원별 데이터 철저 분리, 맞춤 UI 가능, 보안 감사 가능
• 없을 경우: 데이터 혼합 위험, 보안 취약, 병원 요구사항 대응 어려움

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# middleware.py
from flask import request, g
def tenant_middleware():
    token = request.headers.get("Authorization")
    tenant_id = parse_tenant_from_token(token)
    if not tenant_id:
        abort(401)
    g.tenant_id = tenant_id

# service.py
def get_patient_records(patient_id):
    tid = g.tenant_id
    # 테넌트별 schema 지정
    query = f"SELECT * FROM schema_{tid}.patient WHERE id=%s"
    return db.execute(query, (patient_id,))

# customization.py
def get_dashboard_settings():
    tid = g.tenant_id
    return customization_store.get(tid, default_settings)

사례 5: SaaS 기반 프로젝트 관리 플랫폼

시나리오: 글로벌 SaaS 기반 프로젝트 관리 플랫폼

시스템 구성:

• Frontend: React 기반 웹 애플리케이션 (테넌트별 브랜딩)
• API Gateway: Kong 또는 AWS API Gateway (테넌트 라우팅)
• Backend Services: Node.js 마이크로서비스 (Docker 컨테이너)
• Database: PostgreSQL (테넌트별 스키마 분리)
• Cache: Redis (테넌트별 네임스페이스)
• Message Queue: Apache Kafka (테넌트 태깅)
• Monitoring: Prometheus + Grafana (테넌트별 메트릭)

graph TB
    subgraph "Client Layer"
        WEB[Web App - Tenant A]
        WEB2[Web App - Tenant B]
    end
    
    subgraph "API Layer"
        GATEWAY[API Gateway]
        AUTH[Auth Service]
    end
    
    subgraph "Service Layer"
        PROJECT[Project Service]
        USER[User Service]
        NOTIFY[Notification Service]
    end
    
    subgraph "Data Layer"
        DB[(PostgreSQL)]
        REDIS[(Redis Cache)]
        KAFKA[Kafka Queue]
    end
    
    WEB --> GATEWAY
    WEB2 --> GATEWAY
    GATEWAY --> AUTH
    GATEWAY --> PROJECT
    GATEWAY --> USER
    GATEWAY --> NOTIFY
    
    PROJECT --> DB
    USER --> DB
    NOTIFY --> KAFKA
    
    PROJECT --> REDIS
    USER --> REDIS

Workflow:

• 사용자 로그인 → 테넌트 식별 → JWT 토큰에 테넌트 ID 포함
• API 요청 → 게이트웨이에서 테넌트 검증 → 해당 스키마로 라우팅
• 데이터 조회 → 테넌트별 스키마에서 데이터 반환
• 알림 발송 → 테넌트별 설정에 따른 개인화된 메시지

역할:

• API Gateway: 테넌트 식별과 라우팅, 인증 및 Rate Limiting
• 마이크로서비스: 테넌트 컨텍스트 유지하며 비즈니스 로직 처리
• 데이터베이스: 스키마별 데이터 격리와 테넌트별 설정 저장
• 캐시 시스템: 테넌트별 세션 관리와 성능 최적화

유무에 따른 차이점:

• Multi-tenancy 적용: 100 개 테넌트를 1 개 인스턴스로 서비스, 월 운영비 $10,000
• Single-tenancy: 100 개 독립 인스턴스 필요, 월 운영비 $150,000
• 확장성: 새 테넌트 추가 시 5 분 vs 2-3 일 소요
• 유지보수: 1 회 배포로 모든 테넌트 업데이트 vs 100 회 개별 배포

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

# Tenant Context Middleware
class TenantContextMiddleware:
    def __init__(self, app):
        self.app = app
    
    async def __call__(self, scope, receive, send):
        # Extract tenant from subdomain or header
        host = dict(scope["headers"]).get(b"host", b"").decode()
        tenant_id = self.extract_tenant_from_host(host)
        
        # Set tenant context for the request
        scope["tenant_id"] = tenant_id
        
        # Add tenant to database connection
        with get_tenant_db_connection(tenant_id) as db:
            scope["db"] = db
            await self.app(scope, receive, send)
    
    def extract_tenant_from_host(self, host):
        # Extract from subdomain: tenant1.myapp.com
        if "." in host:
            return host.split(".")[0]
        return "default"

# Tenant-aware Database Service
class ProjectService:
    def __init__(self, db_connection, tenant_id):
        self.db = db_connection
        self.tenant_id = tenant_id
        self.schema = f"tenant_{tenant_id}"
    
    async def get_projects(self, user_id):
        query = f"""
        SELECT * FROM {self.schema}.projects 
        WHERE user_id = %s AND tenant_id = %s
        """
        return await self.db.fetch_all(query, [user_id, self.tenant_id])
    
    async def create_project(self, project_data):
        project_data["tenant_id"] = self.tenant_id
        query = f"""
        INSERT INTO {self.schema}.projects 
        (name, description, tenant_id, created_at)
        VALUES (%s, %s, %s, %s)
        """
        return await self.db.execute(query, [
            project_data["name"],
            project_data["description"], 
            project_data["tenant_id"],
            datetime.utcnow()
        ])

# Tenant Configuration Management
class TenantConfigService:
    def __init__(self, redis_client):
        self.redis = redis_client
    
    async def get_tenant_config(self, tenant_id):
        config = await self.redis.get(f"tenant:{tenant_id}:config")
        if config:
            return json.loads(config)
        
        # Fallback to database
        return await self.load_config_from_db(tenant_id)
    
    async def update_tenant_config(self, tenant_id, config):
        # Update cache
        await self.redis.set(
            f"tenant:{tenant_id}:config", 
            json.dumps(config),
            ex=3600  # 1 hour TTL
        )
        
        # Persist to database
        await self.save_config_to_db(tenant_id, config)

사례 6: B2B SaaS 서비스

시나리오: 국내외 B2B SaaS 서비스에서, 고객사별로 데이터는 논리적으로 격리하고, 동일한 앱 인스턴스와 인프라를 공유함.

시스템 구성:

• 공통 App 인스턴스
• Shared DB, tenant_id 기반 row-level 데이터 분리
• 인증/인가 모듈
• Logging, Monitoring, Billing 등

graph TD
    GW[API Gateway]
    APP[Shared App Instance]
    AUTH[Auth Service]
    DB[Shared DB]
    LOG[Log/Monitor]
    BILL[Billing Engine]

    GW --> APP
    GW --> AUTH
    APP --> DB
    APP --> LOG
    APP --> BILL

Workflow:

• 사용자가 GW 로 인증 요청
• 인증/인가 확인 후 App 에 접근
• App 에서 tenant_id 로 데이터 분리 처리
• 운영, 장애 모니터링 및 과금도 tenant 단위로 수행

역할:

• GW: 요청 라우팅 및 인증
• APP: 서비스 로직 실행, 테넌트별 분기
• DB: row-level 데이터 격리
• LOG/BILL: 테넌트별 모니터링, 과금

유무에 따른 차이점:

• 미적용 시: 데이터 유출 가능성·비용 증가·운영 복잡성 증가.
• 적용 시: 보안적 데이터 분리·운영 효율화·비용 절감.

구현 예시: Python, Flask + SQLAlchemy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 테넌트 분리 기반 쿼리 예시
from flask import g, request
from sqlalchemy.orm import Session

def get_current_tenant():
    # 인증 미들웨어에서 tenant_id 추출 후 g.tenant에 저장
    return g.tenant

def fetch_user_data(user_id: int, db: Session):
    tenant_id = get_current_tenant()
    # Row-level Security: tenant_id 필터 적용
    return db.query(User).filter_by(id=user_id, tenant_id=tenant_id).first()

사례 7: FastAPI 기반 멀티테넌시 구조 설계

• Header 기반 테넌트 식별 (X-Tenant-ID)
• SQLAlchemy + Dependency Injection 방식
• Pydantic 모델 사용
• Shared Schema 방식

구조:

graph TD
  Client --> API[FastAPI API]
  API --> Middleware
  Middleware --> ServiceLayer
  ServiceLayer --> DBLayer[SQLAlchemy ORM]
  DBLayer --> SharedDB[PostgreSQL]

디렉토리 구조:

1
2
3
4
5
6
7
8

fastapi_app/
├── main.py
├── dependencies.py
├── db.py
├── models.py
├── schemas.py
└── routers/
    └── customer.py

코드 예시:

• main.py

  1 2 3 4 5 6 7

  from fastapi import FastAPI from routers import customer from dependencies import tenant_dependency app = FastAPI(dependencies=[tenant_dependency]) app.include_router(customer.router)

• dependencies.py

  1 2 3 4 5 6 7 8 9 10 11 12 13

  from fastapi import Request, HTTPException, Depends from contextvars import ContextVar tenant_context: ContextVar[str] = ContextVar("tenant_id", default=None) async def tenant_dependency(request: Request): tenant_id = request.headers.get("X-Tenant-ID") if not tenant_id: raise HTTPException(status_code=400, detail="Missing tenant header") tenant_context.set(tenant_id) def get_current_tenant(): return tenant_context.get()

• db.py

  1 2 3 4 5 6

  from sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker SQLALCHEMY_DATABASE_URL = "postgresql://user:password@localhost/tenantdb" engine = create_engine(SQLALCHEMY_DATABASE_URL) SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

• models.py

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

  from sqlalchemy import Column, Integer, String from sqlalchemy.ext.declarative import declarative_base from dependencies import get_current_tenant Base = declarative_base() class Customer(Base): __tablename__ = "customers" id = Column(Integer, primary_key=True, index=True) name = Column(String, index=True) tenant_id = Column(String, index=True) @classmethod def filter_by_tenant(cls, db): return db.query(cls).filter(cls.tenant_id == get_current_tenant())

• routers/customer.py

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  from fastapi import APIRouter, Depends from db import SessionLocal from models import Customer from pydantic import BaseModel router = APIRouter() class CustomerCreate(BaseModel): name: str @router.post("/customers") def create_customer(data: CustomerCreate): db = SessionLocal() tenant_id = get_current_tenant() new_customer = Customer(name=data.name, tenant_id=tenant_id) db.add(new_customer) db.commit() return {"id": new_customer.id, "name": new_customer.name} @router.get("/customers") def list_customers(): db = SessionLocal() return Customer.filter_by_tenant(db).all()

사례 8: Flask + Celery 로 테넌트별 비동기 작업 처리

시나리오:

• 각 테넌트별 비동기 이메일 발송, 리포트 생성 등을 Celery 로 처리
• 테넌트 context 를 Task 에 전달하여 분기 처리

구조:

graph TD
  Flask --> CeleryTaskQueue --> Worker
  Worker --> DB
  Worker --> EmailAPI

디렉토리 구조:

1
2
3
4
5

flask_app/
├── app.py
├── tasks.py
├── celery_worker.py
└── config.py

구현 예시:

• config.py

  1 2	broker_url = 'redis://localhost:6379/0' result_backend = 'redis://localhost:6379/0'

• tasks.py

  1 2 3 4 5 6 7 8 9 10 11

  from celery import Celery from config import broker_url, result_backend celery = Celery(__name__, broker=broker_url, backend=result_backend) @celery.task def send_email(tenant_id, to, subject, body): # 테넌트 ID 기반 설정 분기 smtp_config = get_smtp_config(tenant_id) print(f"[{tenant_id}] 이메일 발송: {to} / {subject}") # 실제 이메일 전송 로직 수행

• app.py

  1 2 3 4 5 6 7 8 9 10 11

  from flask import Flask, request, jsonify from tasks import send_email app = Flask(__name__) @app.route("/send-email", methods=["POST"]) def trigger_email(): data = request.get_json() tenant_id = request.headers.get("X-Tenant-ID") send_email.delay(tenant_id, data["to"], data["subject"], data["body"]) return jsonify({"status": "queued"}), 202

• celery_worker.py

  1 2 3 4

  from tasks import celery if __name__ == '__main__': celery.worker_main()

사례 9: 테넌트별 RBAC (역할 기반 접근 제어)

• 각 테넌트 안에서 사용자에게 역할 (Role) 을 부여하고, 그 역할에 따라 자원 접근을 제한
• 테넌트 간 사용자는 절대 교차 접근 불가

RBAC 모델 구조:

1
2
3
4
5
6
7
8
9

# Role Table 예시
Role: id | name | tenant_id

# User Table
User: id | username | tenant_id | role_id

# Permission Table (선택)
Permission: id | action | resource
RolePermission: role_id | permission_id

FastAPI 예시: RBAC + 테넌시 결합

• auth/rbac.py

  1 2 3 4 5 6 7 8 9

  from fastapi import HTTPException def has_permission(user, permission: str): if permission not in user["permissions"]: raise HTTPException(status_code=403, detail="Access denied") def is_same_tenant(user, tenant_id): if user["tenant_id"] != tenant_id: raise HTTPException(status_code=403, detail="Tenant mismatch")

• main.py

  1 2 3 4 5 6 7

  @app.get("/admin/users") def get_users(request: Request, current_user: dict = Depends(get_current_user)): tenant_id = request.headers.get("X-Tenant-ID") is_same_tenant(current_user, tenant_id) has_permission(current_user, "view_users") # DB 조회 및 응답 return {"message": "Access granted"}

Django 예시: RBAC + Middleware 기반

• models.py

  1 2 3 4 5 6 7 8 9 10 11

  class Role(models.Model): name = models.CharField(max_length=50) tenant = models.ForeignKey("Tenant", on_delete=models.CASCADE) class User(AbstractUser): tenant = models.ForeignKey("Tenant", on_delete=models.CASCADE) role = models.ForeignKey("Role", on_delete=models.SET_NULL, null=True) class Permission(models.Model): code = models.CharField(max_length=50) role = models.ManyToManyField(Role)

• decorators.py

  1 2 3 4 5 6 7 8 9 10 11 12 13

  from django.http import JsonResponse def tenant_rbac(permission_code): def decorator(view_func): def _wrapped_view(request, *args, **kwargs): user = request.user if user.tenant.id != request.headers.get("X-Tenant-ID"): return JsonResponse({"error": "Tenant mismatch"}, status=403) if not user.role or not user.role.permission_set.filter(code=permission_code).exists(): return JsonResponse({"error": "Access Denied"}, status=403) return view_func(request, *args, **kwargs) return _wrapped_view return decorator

• views.py

  1 2 3 4

  @tenant_rbac("manage_users") def admin_users(request): # 접근 허용된 사용자만 여기 도달 ...

RBAC 적용 팁:

사례 10: 멀티테넌시 (Multi-Tenancy) 환경에서 Celery Queue 분리 전략

시나리오: 멀티테넌시 (Multi-Tenancy) 환경에서 Celery Queue 분리 전략 (QoS 기반 Multi-Queue 구성) 에 대한 심화 설계

목적:

• 테넌트 간 비동기 작업 처리 충돌 방지
• 프리미엄/일반 고객 간 SLA 차등 적용 (속도, 우선순위)
• 큐를 통한 트래픽 분산, 장애 격리, 성능 보장 달성

아키텍처:

graph TD
  UserA[Premium Tenant A] --> API
  UserB[Basic Tenant B] --> API
  API --> Redis
  Redis --> CeleryWorkerHigh[celery@premium_queue]
  Redis --> CeleryWorkerLow[celery@basic_queue]
  CeleryWorkerHigh --> DB
  CeleryWorkerLow --> DB

• Premium 테넌트 요청은 premium_queue 로 분리 처리
• 일반 테넌트는 basic_queue 에서 후순위로 처리
• 각 워커는 독립적인 처리 성능, 우선순위 설정 가능

설정 및 구성 전략:

1. Celery 작업 큐 선언 (FastAPI / Django 공통)

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   # tasks.py from celery import Celery celery = Celery( "app", broker="redis://localhost:6379/0", backend="redis://localhost:6379/1" ) @celery.task(name="tasks.send_email", queue="basic") def send_email_basic(tenant_id: str): print(f"[BASIC] Email task for {tenant_id}") @celery.task(name="tasks.send_email_premium", queue="premium") def send_email_premium(tenant_id: str): print(f"[PREMIUM] Email task for {tenant_id}")

2. 워커 별 큐 구분 실행

   1 2 3 4 5

   # basic 테넌트 전용 워커 celery -A tasks worker --loglevel=info -Q basic -n worker.basic # premium 테넌트 전용 워커 (우선 처리) celery -A tasks worker --loglevel=info -Q premium -n worker.premium --concurrency=8

   • 워커 간 컨커런시 수 차등 설정 가능 (--concurrency)
   • 스케일링도 독립적 설정 (예: Premium 은 더 많은 worker pod)

3. QoS 기반 분기 처리 (API 레이어)

   1 2 3 4 5 6 7 8 9 10 11

   @app.post("/notify") def notify(request: Request): tenant_id = request.headers.get("X-Tenant-ID") tenant_type = get_tenant_tier(tenant_id) # "premium" or "basic" if tenant_type == "premium": send_email_premium.delay(tenant_id) else: send_email_basic.delay(tenant_id) return {"status": "queued"}

4. Redis 설정 최적화 (선택사항)

   • Redis 는 하나의 브로커를 사용하되, 큐 이름 기준으로 논리적 격리
   • 또는 Redis 클러스터 구성 시 큐별 물리적 분리 가능 (고급 QoS 필요 시)

큐 분리 전략 설계:

추가 고급 전략:

1
2
3
4

celery.conf.task_routes = {
    "tasks.*_premium": {"queue": "premium"},
    "tasks.*_basic": {"queue": "basic"},
}

운영 팁:

정리 및 학습 가이드

내용 정리

멀티테넌시 (Multi-Tenancy) 는 단일 애플리케이션 인스턴스로 여러 고객 (테넌트) 을 서비스하는 SaaS 및 클라우드 환경의 핵심 아키텍처이다.
이 구조는 비용 효율성, 빠른 확장성, 유지보수 단순화 등의 이점을 제공하며, 핵심적으로 다음 원칙을 충족해야 한다:

• 테넌트 식별 및 격리: URL, Header, 토큰 등을 통한 식별과 DB/Schema/Row 수준의 격리
• 성능 격리: 리소스 제한, Rate Limiting, HPA 등을 통한 스파이크 대응
• 보안 및 규정 준수: GDPR, HIPAA 등 글로벌 법규 대응과 데이터 거주지 관리
• 운영 자동화: Helm, Terraform, GitOps 기반 DevOps 파이프라인
• 사용자 커스터마이징: 기능 플래그, 테마 분리, 정책 기반 기능 제한
• 테넌트 수명주기 관리: Onboarding → Plan 관리 → Offboarding

최신 기술 동향 분석

학습 항목 정리

• 아키텍처: 멀티테넌시 확장성과 유지보수를 위해 스키마/DB 분리 전략과 CQRS/Event 기반 설계는 핵심이다. 특히 API 게이트웨이 기반 라우팅은 실무 적용의 중심이 된다.

• 보안: OAuth 2.0 및 SAML 기반 인증, RBAC 기반 접근 제어, 데이터 암호화/마스킹은 모든 멀티테넌시 환경에서 필수적인 보안 수단이다.

• 데이터베이스: 테넌트 격리에 따른 스키마/테이블/행 분리 전략은 설계 초기부터 결정되어야 하며, 샤딩/파티셔닝은 고성능 운영의 열쇠다.

• 운영/DevOps: 테넌트별 CI/CD 와 Canary Release 전략은 안전한 배포의 기본이며, IaC 기반 인프라 자동화는 유지보수 효율성을 높인다.

• 성능 최적화: 캐싱, 로드밸런싱, 자원 분산을 통해 테넌트 증가에 따른 성능 저하를 방지할 수 있다.

• 컴플라이언스: GDPR, HIPAA 같은 규정은 테넌시 구조의 설계 원칙에 영향을 주므로 초기에 반영해야 한다.

• 격리성과 SLA: 노이즈 네이버 방지, 예측 기반 스케일링, 테넌트별 SLA 정책은 안정성과 신뢰성을 위한 필수 구성이다.

용어 정리