[설계] 멀티 테넌트 아키텍처 (Multi-Tenant Architecture) 살펴보기

멀티 테넌트 아키텍처(Multi-Tenant Architecture)란?

멀티 테넌트 아키텍처는 '멀티 테넌시(Multi-tenancy)' 시스템을 구현하는 구체적인 설계 방식이나 구조를 말한다.

 

멀티 테넌시는 하나의 애플리케이션이 여러 고객들에게 서비스를 제공할 수 있도록 하는 소프트웨어 아키텍처이다.

여기서 고객은 테넌트(tenant)라는 개념으로 다루어지는데, 특정 접근 권한을 공유하는 사용자들의 그룹을 나타낸다. 예를 들어, B2B 서비스로 제공되는 '재고관리 전산시스템'이 클라우드 시스템으로 제공되는 상황을 가정해보자. 해당 서비스를 사용하는 기업 A와 B가 있을 때, 양 기업은 서로의 데이터와 환경에 접근할 수 없으며 서비스를 실제로 사용하는 기업의 구성원들은 본인이 속한 기업의 데이터에 접근할 수 있다.

 

즉, 멀티테넌시를 통해 고객별로 각각 다른 시스템을 구축할 필요 없이 하나의 애플리케이션으로 모든 고객을 서비스할 수 있다.

 

 

 

멀티 테넌시의 장점과 단점

멀티 테넌트 아키텍처는 다음과 같은 장점을 가지고 있다.

• 비용 절감 
  멀티 테넌시는 하나의 인스턴스로 여러 테넌트에게 서비스를 제공할 수 있게 해주어, 인프라 운영에 도움이 된다.
  여러 테넌트가 소프트웨어 유지보수, 데이터 센터, 인프라 환경을 공유하기 때문에 싱글 테넌시 대비 운영 비용이 더 낮다.
  
  
• 테넌트 확장성
  멀티테넌트 아키텍처는 요청에 따라 고객을 늘릴 수 있다. 추가적인 서버 장비 및 인프라 구축 없이 기존 운영환경에서 손쉽게 테넌트를 추가하여 서비스 제공이 가능하다.
  
  
• 개발없이 맞춤 설정하기
  멀티 테넌시 솔루션 서비스는 각 테넌트 고객이 비즈니스 요구사항에 맞춰 애플리케이션을 커스터마이징할 수 있도록 높은 수준의 설정 기능을 제공한다. 이는 개별 커스텀 개발보다 훨씬 쉬우며, 위험을 최소화하고 작업시간과 비용을 절감한다.
  
  
• 효율적인 업데이트와 유지보수
  소프트웨어 공급업체는 소프트웨어에 대한 패치와 업데이트 책임이 존재한다. 멀티테넌시는 한번의 패치 및 업데이트로 수정사항을 모든 고객사에게 동시에 적용할 수 있다. 이와 달리 싱글 테넌시는 각 고객사의 인스턴스마다 별도의 업데이트를 진행해야 하기 때문에 멀티 테넌트 아키텍처를 사용하면 벤더의 운영 효율성이 높아진다.

 

단점은 다음과 같다.

• 보안위험(Security Risk) 증가
  싱글 테넌트 아키텍처에서 보안 사고가 발생하면 하나의 고객사만 영향을 받는다. 하지만 멀티 테넌트 아키텍처는 테넌트끼리 리소스를 공유하기 때문에 다른 고객사들 역시 보안 사고에 피해를 입을 수 있다. 예를 들어, 고객사들의 정보를 데이터베이스에 저장할 때 외부에서 시스템에 침입할 경우 모든 고객사의 정보가 노출될 수 있다. 
  
  
• 성능 간섭 문제
  멀티테넌트 아키텍처는 같은 시스템 자원을 사용하기 때문에 서버가 겪는 부하(load)도 함께 적용받는다. 예를 들어, 한 고객사에 의해 부하가 급격히 증가할 경우 이 충격은 서버 환경을 공유하는 다른 고객사에게도 영향을 준다.

 

 

적용 방법

멀티테넌트 아키텍처는 크게 3가지 방식을 통해 적용할 수 있다.

 

1. 모든 테넌트의 데이터베이스 공유

 모든 테넌트가 단일 데이터베이스 인스턴스를 공유하는 방식이다. 데이터베이스의 각 레코드에는 테넌트 간 데이터 격리를 보장하기 위해 테넌트 식별자가 포함된다.

 

장점으로 다음과 같은 특징을 갖는다.

1. 단순성: 단일 DB 운영이 다수의 DB 운영보다 훨씬 쉽고 스키마 구조 변경도 쉽게 적용할 수 있다.

2. 비용 효율성: 인프라 비용을 낮출 수 있기 때문에 스타트업이나 소규모 기업에게 적합하다.

3. 쉬운 유지보수: 업데이트와 패치 작업을 공유 데이터베이스에 한번만 적용하면 돼서 유지보수 작업을 단순화할 수 있다. 

 

수반하는 단점은 다음과 같다.

1. 데이터 유출 위험: 테넌트의 데이터가 다른 테넌트에게 노출될 수 있는 위험이 존재한다.

2. 리소스 간섭 문제: 한 테넌트의 과도한 부하(load)로 인한 성능 저하 문제는 다른 테넌트들에게도 영향을 끼친다. 

3. 복잡한 쿼리 로직: 개발자들은 항상 테넌트 식별자를 쿼리에 포함시켜야 하며, 이는 코드를 복잡하게 만들고 오류를 발생시킬 가능성이 있다.

 

 

2. 각 테넌트 별 데이터베이스 사용

이 모델에서 테넌트들은 각각 별도의 데이터베이스 인스턴스를 갖는다. 테넌트 별로 분리된 데이터베이스는 완전한 데이터 격리를 보장한다.

 

테넌트마다 DB를 가지는 모델의 장점은 다음과 같다.

1. 강화된 보안: 분리된 데이터베이스를 통해서 데이터 유출의 위험성은 사실상 사라진다.

2. 성능 격리: DB가 분리되어 있기 때문에 다른 테넌트의 서비스 이용 성능에 영향을 주지 않는다.

3. 커스텀 편의성: 다른 테넌트에 대한 영향없이 DB 스키마나 설정을 커스텀할 수 있다.

 

다음의 단점을 갖는다.

1. 복잡성 증가: 테넌트 수가 증가할수록, 다수의 DB 운영은 더욱 복잡해진다.

2. 높은 비용: 추가 DB 인스턴스 운영은 인프라 비용을 상승시킨다.

3. 복잡한 스키마 구조 변경: 어떠한 유형의 DB 스키마 변경도 모든 테넌트 DB에 똑같이 적용되어야 하는데, 이는 매우 반복적이고 장애가 발생할 수 있는 작업이다.

 

 

3. 하이브리드 (Mix)

하이브리드 모델은 데이터베이스를 공유하는 방식과 분리하는 방식의 특성을 결합하여 사용하는 방식이다. 예를 들어, 일부 테넌트는 데이터베이스를 공유하는 반면에 다른 테넌트들은 필요에 따라 각각 별도의 데이터베이스를 갖는다.

 

하이브리드 모델의 장점은 다음과 같다.

1. 유연성: 민감하거나 높은 부하를 요구하는 테넌트들에게는 격리를 유지하면서도 필요에 따라 리소스 공유가 가능하다.

2. 확장성: 하나의 모델에 완전히 의존하지 않고 테넌트 요구사항에 따라 리소스를 확장할 수 있는 옵션을 제공한다.

 

다음의 단점을 갖는다.

1. 복잡한 관리: 하이브리드 모델은 서로 다른 유형의 데이터베이스를 관리하고 일관된 성능을 보장하는 데 복잡성을 야기한다.

2. 혼동 가능성: 개발자들은 어떤 테넌트가 공유 리소스를 사용하고 어떤 테넌트가 전용 리소스를 사용하는지 명확히 구분해야 하며, 그렇지 않으면 설정 오류가 발생할 수 있다.

 

 

 

 

References

• 멀티테넌시 [위키피디아] - https://en.wikipedia.org/wiki/Multitenancy
• 서비스형 소프트웨어 [위키피디아] -
• 멀티테넌시 재정의 [AWS] - https://docs.aws.amazon.com/ko_kr/whitepapers/latest/saas-architecture-fundamentals/re-defining-multi-tenancy.html
• 멀티테넌시란? [Red Hat] - https://www.redhat.com/ko/topics/cloud-computing/what-is-multitenancy
• Complete Guide to Multi-Tenant Architecture [Medium] https://medium.com/@seetharamugn/complete-guide-to-multi-tenant-architecture-d69b24b518d6
• Multi-Tenant Architecture: How It Works, Pros, and Cons [frontegg] https://frontegg.com/guides/multi-tenant-architecture