멀티테넌시 아키텍처란?

최근에 신규 사이드 프로젝트를 진행하고 있다.

하나의 서버, DB로 격리된 다른 이용자들을 격리하여 처리하는 목적으로 알아보다가,

멀티테넌시 아키텍처를 알게되었고, 이를 도입했다.

 

구체적으로 어떤면에서 좋고, 어떤점을 주의해야할지 학습해보자.

 

 

 

---

 

1. 정의

Multi-Tenancy(멀티테넌시) 는

• Multi: “여러 개의”
• Tenancy: “세입자” 또는 “고객(tenant)”

 

이라는 단어가 합쳐진 형태다.

즉,

여러 명의 고객(Tenant) 이 하나의 애플리케이션 인스턴스나 인프라를 함께 사용하되,
각자의 데이터와 설정은 독립적으로 격리된 구조를 말한다.

 

 

 

말이 어렵지만,

우리 개발자들이 자주 사용하는 Slack, Confluence, Notion 같은 서비스들이
대표적인 멀티테넌시 구조를 가지고 있다.

 

컨플루언스

https://my-companay.atlassian.net/

https://my-side-project.atlassian.net/

 

노션

https://www.notion.so/companay-12hfsdfh8123hc1

https://www.notion.so/football-club19gfdkln

 

모두 동일한 플랫폼(Confluence, Notion)의 서버 위에서 동작하지만
각 회사나 프로젝트 단위로 독립된 데이터, 권한, 환경을 가진다.

 

 

 

 

멀티태넌시 3줄요약

1. 하나의 시스템을 여러 고객이 공유
2. 각 고객의 데이터는 독립적으로 관리
3. 인프라 자원을 효율적으로 관리하지만, 보안, 유지보수에 복잡성이 생김

 

 

 

---

 

2. 장단점

인프라 효율성이나 운영 편의성을 높이지만 분명한 단점도 존재한다.

 

 

A고객의 데이터를 B고객에게 노출한다거나,

쿼리 실수로 인한 데이터처리가 잘못된다면 책임지지 못할 큰 혼란을 야기할 수 있다.

 

 

단일 테넌시 환경과, 멀티 테넌시 환경을 비교해보며 알아보자.

 

 

단일 테넌시 vs 멀티 테넌시

구분	단일 테넌시 (Single-Tenant)	멀티 테넌시 (Multi-Tenant)
서버	각각의 서버	하나의 서버에 다수의 고객
데이터베이스	각각의 DB 필요	DB 공유 또는 테넌트별 스키마 분리
유지보수	개별 배포 필요	중앙(서버) 집중 배포
확장성	제한적	고확장 구조
보안	물리적 격리로 안전	논리적 격리로 설계 필요

 

 

멀티 테넌시 아키텍처의 가장 큰 장점은 운영 효율성과 비용 절감이다. 

 

예를 들어 우리 서비스에 1000개의 고객사가 존재한다고 했을 때 ,

단일 코드베이스로 한 번 배포하면 모든 고객에게 동시에 기능을 제공할 수 있다.

 

그 외에도

 

• 버그 수정, 보안 패치, 신규 기능 배포를 중앙에서 일괄 관리
• 기능, UI, 정책이 통일되어 서비스 품질이 균일하게 유지
• 사용 데이터를 하나의 시스템에서 집계할 수 있어서비스 개선이나 마케팅 전략 수립에 유용

등 중앙 집중 처리의 장점들이 많이 도드라진다.

 

 

 

 

 

반면에 단점도 존재한데,

 

- 보안 및 데이터 격리 위험

• 여러 테넌트가 같은 DB나 서버를 공유하기 때문에,
  잘못된 쿼리, 버그, 혹은 ORM 설정 오류로 인해 다른 테넌트의 데이터에 접근할 가능성 존재

 

- 성능 병목 및 리소스 공유 문제

• 테넌트가 같은 서버 리소스(CPU, 메모리, I/O) 를 공유하므로,
  일부 대형 테넌트의 트래픽 급증이 다른 테넌트의 성능 저하로 이어질 수 있음

 

- 스키마 및 구조 변경의 복잡성

• 하나의 코드와 DB 구조를 여러 테넌트가 공유하므로,
  DB 마이그레이션 시 전체 테넌트에 동시에 영향을 미침

 

- 테넌트 맞춤 요구에 대한 유연성 저하

• 모든 테넌트가 같은 코드베이스를 공유하므로,
  한 테넌트가 “특정 기능만 다르게 해달라”고 요청하면 대응이 어렵다.

 

즉, 간략하게 요약하자면

 

하나의 서버, DB에서 관리를 하는 장점의 양날의 검으로

변경의 유연성이 적고, 장애를 모두 같이 맞게 된다는 단점이 있다.

 

 

 

---

그렇다면 멀티테넌시 아키텍처를 채택한다면 어떤식으로 개발하는 방법이 있을까?

 

 

1. 단일 데이터베이스, 공유 스키마 (Shared Database, Shared Schema)

 

• 하나의 DB와 하나의 스키마를 여러 테넌트가 공유함
• 테이블마다 분리 식별자를 두고 데이터를 구분함

ex) SELECT * FROM members WHERE tenant_id = 101;

 

 

- 장점

• 단일 DB사용으로 리소스 최소화
• 신규 테넌트 추가가 용이하고 빠름

 

- 단점

• 데이터의 격리 수준이 매우 낮음 (컬럼 수준 격리)
• 테넌트별 커스터마이징이 어려움

 

- 결론

• SaaS 초창기에 선택되는 방식이나,
  빠른 확장에 포커싱되어 초기 단계에서 많이 사용된다.

 

 

 

 

 

 

2. 단일 데이터베이스, 개별 스키마 (Shared Database, Isolated Schema)

 

• 같은 DB 내에서 각 테넌트마다 독립된 스키마를 생성

ex)
SELECT * FROM tenant_1.members WHERE member_id = 123;
SELECT * FROM tenant_2.members WHERE member_id = 456;

 

 

- 장점

• 테넌트별 데이터 완전 격리
• 테넌트 단위의 쿼리 튜닝, 백업등이 가능
• 커스터마이징의 유연성 증가

 

- 단점

• 테넌트가 많아졌을 경우 스키마 관리가 복잡함
• 마이그레이션 시 전체 스키마를 순회해야 함

 

- 결론

• ERP, 회계 시스템과 같이 고객별로 데이터가 완전히 분리되어야하는 SaaS에 주로 사용됨

 

 

 

 

3. 개별 데이터베이스 (Isolated Database)

 

• 보안성과 안정성이 가장 높지만, 운영비용이 가장 큰 환경

ex)
tenant_1_db,
tenant_2_db

 

 

- 장점

• 데이터 및 리소스 완전 격리
• 성능, 장애 등 문제등을 개별적으로 제어 가능
• 테넌트별로 서로 다른 버전으로 운영 갸능

 

- 단점

• DB 관리 비용과 인프라 리소스 급증
• 신규 테넌트 추가 시 자동화 필요
• 공통 기능 업데이트 시 배포 복잡도 증가

 

- 결론

• 대규모 B2B SaaS에서 주로 사용되는 방법(Slack Enterprise등)

 

 

 

 

 

총평

멀티 테넌시 아키텍처는 아무래도 설계 방식을 가장 신중히 선택해야한다.
운영 효율성과 비용 절감의 장점과 데이터 격리 위험을 동시에 고려하여 채택해보자.

끝