Multi-Tenant 아키텍쳐란?
단일 소프트웨어 인스턴스에서 여러 사용자 그룹을 구분해 서비스를 제공하는 소프트웨어 아키텍쳐를 말합니다.
여러 사용자 그룹을 가진 SaaS 애플리케이션과 클라우드 시스템에서 주로 사용하는 아키텍쳐로써 Single-Tenant 아키텍쳐는 사용자 그룹별로 개별 애플리케이션을 만들거나 데이터베이스를 분리하는 방식으로 인프라 관리 비용이 증가하고 비즈니스를 빠르게 확장할 수 없다는 문제를 Multi-Tenant 아키텍쳐가 해결할 수 있습니다.
Multi-Tenant를 이해하려면 은행 업무 방식을 생각해 보면 됩니다. 여러 사람이 한 은행에 돈을 예치할 수 있고, 같은 곳에 예치하기는 하지만, 자산이 완전히 분리됩니다. 은행 고객은 서로 상호 작용하지 않고 다른 고객의 돈에 접근할 수 없으며 서로를 인식하지도 못합니다. 마찬가지로, 퍼블릭 클라우드 컴퓨팅에서도 클라우드 벤더의 고객은 동일한 인프라(일반적으로 동일한 서버)를 사용하면서도 데이터와 비즈니스 로직을 분리하고 안전하게 유지합니다.
Tenant란?
서비스의 최종 사용자를 일컫는 용어로써 SaaS 애플리케이션에선 일반적으로 개별 “구독자”, “그룹” 등을 말합니다.
Tenant의 예시:
1.
SaaS 애플리케이션:
•
Salesforce의 경우, 각 고객 조직이 tenant입니다. 고객은 자체 데이터, 사용자 계정, 사용자 정의 필드 및 워크플로우를 가지고 있습니다.
•
Slack의 경우 각 워크스페이스가 tenant로 구분할 수 있습니다.
•
Microsoft Office 365에서 각 구독 회사는 tenant로 간주됩니다. 각 회사는 자체 사용자, 문서 및 설정을 가지고 있습니다.
2.
클라우드 서비스 제공업체:
•
Amazon Web Services (AWS)에서 각 AWS 계정은 tenant입니다. 각 계정은 자체 리소스, 사용자 및 권한을 가지고 있습니다.
•
Google Cloud Platform (GCP)에서 각 GCP 프로젝트는 tenant로 간주될 수 있습니다. 각 프로젝트는 자체 리소스, 사용자 및 액세스 제어를 가지고 있습니다.
3.
멀티테넌트 데이터베이스:
•
단일 데이터베이스 서버에서 여러 고객 또는 애플리케이션의 데이터를 호스팅하는 경우, 각 고객 또는 애플리케이션은 tenant가 됩니다.
•
각 tenant는 자체 데이터 세트를 가지고 있으며, 다른 tenant의 데이터와 격리되어 있습니다.
4.
멀티테넌트 이커머스 플랫폼:
•
Shopify와 같은 이커머스 플랫폼에서 각 온라인 상점은 tenant입니다.
•
각 상점은 자체 제품, 고객 데이터, 테마 및 결제 설정을 가지고 있습니다.
Slack의 워크스페이스 예시
아키텍쳐 비교
tenant.png
Single-tenant
•
각 tenant는 자체 인프라, 리소스 및 인스턴스를 가지고 있습니다. 리소스는 tenant 간에 공유되지 않습니다.
•
각 tenant에 대해 별도의 인스턴스와 리소스가 필요하므로 확장성이 제한될 수 있습니다.
•
유지보수 측면에서 각 tenant별 유지 관리가 필요하므로 훨씬 번거로울 수 있습니다.
Multi-tenant
•
여러 tenant가 동일한 인프라, 리소스 및 소프트웨어 인스턴스를 공유합니다. 리소스는 tenant 간에 효율적으로 공유됩니다.
•
단일 인스턴스에서 여러 tenant를 수용할 수 있으므로 더 쉽게 확장할 수 있습니다.
•
단일 인스턴스에서 업데이트 및 유지 관리가 가능하므로 효율적인 유지보수가 가능합니다.
아키텍쳐 구현 방식
1. Shared database
•
모든 tenant가 동일한 데이터베이스와 스키마를 공유합니다.
•
각 테이블에는 tenant를 식별하는 “tenant ID” 열이 포함됩니다.
•
애플리케이션은 쿼리에 tenant ID를 포함하여 각 tenant의 데이터를 필터링합니다.
•
장점: 구현이 간단하고 자원 효율성이 높습니다.
•
단점: tenant 간 데이터 격리가 적절히 이루어지지 않아 보안 위험이 있을 수 있습니다.
예시
select count (*) from lbox.user where tenant_id = 1 # lbox
select count (*) from lbox.user where tenant_id = 2 # lfind
SQL
복사
2. One database per tenant
•
각 tenant는 자체 데이터베이스를 가집니다.
•
각 데이터베이스는 해당 tenant에 특정한 데이터만 포함합니다.
•
애플리케이션은 tenant에 따라 적절한 데이터베이스 연결을 동적으로 전환합니다.
•
장점: tenant 간 완전한 데이터 격리와 보안을 제공합니다.
•
단점: 각 tenant에 대해 별도의 데이터베이스 인스턴스가 필요하므로 자원 오버헤드가 크고 비용이 높을 수 있습니다.
예시
select count (*) from user.lbox_user # lbox
select count (*) from user.lfind_user # lfind
SQL
복사
3. One schema per tenant
•
모든 tenant가 동일한 데이터베이스를 공유하지만 각 tenant는 자체 스키마를 가집니다.
•
각 tenant의 데이터는 해당 tenant에 특정한 테이블 세트에 저장됩니다.
•
애플리케이션은 tenant에 따라 적절한 스키마를 동적으로 전환합니다.
•
장점: tenant 간 데이터 격리가 향상되어 보안이 강화됩니다.
•
단점: 스키마 관리 및 마이그레이션이 더 복잡해질 수 있습니다.
### 예시
select count (*) from lbox.user # lbox
select count (*) from lfind.user # lfind
SQL
복사
결론
•
1.Shared Database 방식은 간단하고 자원 효율적이지만 데이터 격리가 약함
•
2.One Database per Tenant 방식은 완전한 데이터 격리와 보안을 제공하지만 자원 오버헤드와 비용이 더 높다.
•
3.One Schema per Tenant 방식은 두 가지 방식의 중간 지점으로, 데이터 격리와 자원 효율성 사이에서 균형을 유지합니다.