멀티테넌시(Multi-Tenancy) 아키텍처는 하나의 애플리케이션 인스턴스가 여러 개의 고객(테넌트, tenant)를 지원할 수 있도록 설계된 소프트웨어 아키텍처.
여기서 "테넌트"란, 세입자란 뜻으로 어플리케이션 자원을 사용하는 독립된 사용자 그룹 또는 조직을 의미함.
각 테넌트는 자신의 데이터, 사용자, 설정을 갖고 있지만, 물리적으로는 같은 애플리케이션과 인프라를 공유합니다.
멀티테넌시 아키텍처의 유형별 정리
1. 공용 데이터베이스, 공용 스키마 (Shared Database, Shared Schema)
하나의 데이터베이스와 하나의 스키마(테이블 구조)를 모든 테넌트가 공유하는 구조. 모든 테넌트의 데이터는 동일한 테이블에 저장되며, 이를 구분하기 위해 각 테이블에는 tenant_id와 같은 컬럼이 추가됨. 시스템은 요청 시 해당 테넌트의 식별자를 기준으로 데이터를 필터링하여 처리.
이 구조는 멀티테넌시를 처음 도입하는 데 가장 쉽고 간단한 형태로, 단일 DB로 모든 테넌트를 지원할 수 있어 운영 및 비용 측면에서 유리.
장점
- 인프라 비용이 낮음
- 구조가 단순하고 개발/운영이 쉬움
- 테넌트 추가가 빠르고 용이함
단점
- 테넌트 간 데이터가 완전히 분리되지 않음 (보안 이슈 발생 가능)
- 테넌트별 데이터 관리, 커스터마이징이 어려움
- 데이터 양이 많아질수록 성능 이슈 가능
2. 공용 데이터베이스, 분리된 스키마 (Shared Database, Separate Schema)
하나의 데이터베이스는 여러 테넌트가 공유하지만, 각 테넌트는 독립된 스키마를 가지는 구조. 스키마란 해당 테넌트만의 테이블 그룹을 의미하며, tenant_a.users, tenant_b.users처럼 테넌트별로 같은 구조의 테이블을 따로 운영함.
이 방식은 공통된 DB 자원을 활용하면서도 테넌트별로 논리적 분리를 제공하여 보안성과 유지보수 측면에서 균형 잡힌 방식을 제공
장점
- 테넌트 간 데이터가 분리되어 보안성과 격리성이 높음
- 테넌트별 커스터마이징이 어느 정도 가능함
- 여전히 하나의 DB 관리로 운영 효율이 있음
단점
- 테넌트 수가 많아지면 스키마 관리가 복잡해짐
- 마이그레이션, 백업 등 작업이 번거로울 수 있음
- 일부 DBMS에서 스키마 수에 제한이 있을 수 있음
3. 분리된 데이터베이스 (Separate Database)
테넌트마다 완전히 별도의 데이터베이스를 사용하는 방식. 각 테넌트는 물리적으로 분리된 DB를 가지므로, 다른 테넌트와 자원을 전혀 공유하지 않으며, 각 DB는 독립적으로 구성되고 운영.
이 방식은 가장 높은 수준의 데이터 격리와 보안을 제공하며, 테넌트마다 맞춤형 설정 및 확장이 가능. 대신 비용과 운영의 복잡성은 가장 큼.
장점
- 테넌트 간 완전한 데이터 격리 보장
- 보안성과 안정성이 매우 높음
- 테넌트별로 DB 설정, 기능 등을 자유롭게 커스터마이징 가능
단점
- 인프라 및 운영 비용이 높음
- 테넌트 수가 많아질수록 관리 복잡도 증가
- 백업, 모니터링, 배포 자동화 필요
멀티테넌시 환경에서 성능 격리의 중요성 (출처: Cloudflare 사례)
멀티테넌시 아키텍처에서는 여러 테넌트가 하나의 시스템 리소스를 공유하기 때문에, 아키텍처 설계뿐만 아니라 운영 중 발생할 수 있는 성능 문제도 중요한 고려 요소임.
공용 데이터베이스 구조(Shared DB) 를 사용하는 경우(분리된 DB는 상관 없음) 하나의 테넌트가 과도한 부하를 발생시키면, 다른 테넌트의 서비스 품질에 영향을 미칠 수 있음. 이처럼 하나의 테넌트가 시스템 전체에 영향을 주는 현상을 흔히 "시끄러운 이웃(Spoiler Tenant)" 문제라고 부름.
Cloudflare는 실제 멀티테넌트 운영 환경에서 이런 문제를 어떻게 해결했는지에 대한 사례를 공유함.
Cloudflare의 멀티테넌트 운영 전략
Cloudflare는 PostgreSQL 기반 환경에서 다수의 테넌트를 운영하고 있었고, 다음과 같은 문제가 발생함.
- 특정 테넌트가 비효율적인 쿼리나 대량의 트랜잭션을 일으켜 다른 테넌트의 성능을 저하시킴
- 이러한 상황이 발생해도 즉각적으로 제어하거나 격리하기 어려움
문제를 해결하기 위해 Cloudflare가 도입한 전략
1. PgBouncer 기반의 연결 제한 및 동적 조정
Cloudflare는 PgBouncer를 활용해 테넌트별 연결 수를 제한하고, 필요 시 런타임 중에도 제한 값을 동적으로 조정할 수 있도록 시스템을 구성. 이를 통해 부하가 큰 테넌트가 전체 시스템에 미치는 영향을 줄이고, 시스템 안정성을 유지함.
2. 게이트웨이 단 스로틀링 및 대기열 설계
추가로, 단순한 연결 풀로 사용하는 것을 넘어, 테넌트별 쿼리 실행 순서를 제어할 수 있는 우선순위 큐 기능을 설계. 이는 시스템이 과부하 상태일 때도 중요 테넌트의 요청이 우선 처리되도록 하는 전략.
3. 리소스 할당량 및 혼잡 제어 알고리즘 도입 계획
Cloudflare는 앞으로 테넌트별 CPU 및 메모리 할당량을 설정하고, 일정 기준을 초과하는 요청에 대해 자동으로 스로틀링을 적용할 예정. 또한 TCP Vegas와 같은 혼잡 제어 알고리즘을 적용하여, 각 테넌트의 동시성 수준을 동적으로 조정하는 방안도 고려하고 있습니다.
TCP Vegas 혼잡 회피 알고리즘이란?
TCP Vegas는 네트워크 혼잡을 감지하고 제어하기 위한 혼잡 제어 알고리즘.
혼잡이 터지기 전에 미리 조심하는 알고리즘.
패킷이 유실되기 전에 RTT(왕복 시간) 지연을 기반으로 전송 속도를 조절해서,
보다 안정적이고 예측 가능한 네트워크 성능을 유지하려는 방식.
참고
멀티테넌트 데이터베이스 성능 보장을 위한 격리(isolation) 설계 방법
Cloudflare 멀티테넌시 데이터베이스 아키텍처
maily.so
'개발 고민' 카테고리의 다른 글
| SaaS와 멀티테넌시 (0) | 2025.04.02 |
|---|