멀티테넌시 모델

https://dev.gmarket.com/64

 

멀티네넌시 모델 ( Multi Tenancy Model) 

 

테이블을 설계하던 중 고민해본 내용을 정리한 글입니다.

 

ERP 솔루션 서비스를 기획하고 테이블을 설계하던 중 아래와 같은 고민거리가 생겼습니다.

기획중인 내용 중 "각 고객별로 맞춤화된 환경을 제공합니다" 라는 내용이 있는데 이게 가능할지 의문이 들었습니다.

 

고객별 맞춤화된 환경을 제공한다는 말에 의미는 아래와 같습니다.

• [  예) "발주목록"  ] 과 같은 기본으로 제공하는 테이블에 컬럼을 추가하거나 컬럼을 삭제할 수 있습니다.
• 솔루션을 사용하는 유저들의 권한 ( 사내 직원들의 세부 권한 ) 을 설정할 수 있습니다. 예를들어 기본 제공하는 3단계의 권한 이외에 세부적인 권한을 추가할 수 있습니다.

 

이러한 문제상황을 어떤식으로 처리할지 고민이 생겼습니다.

검색을 해보니 이러한 솔루션을 개발할 때 거의 대부분 생기는 문제라고 합니다.

 

해결방안은 아래와 같습니다.

 

 

1.  커스터마이징이 불가능하도록 하기

제일 쉽고 간단한 방법입니다. 모든 사용자들이 같은 UI 같은 데이터 구조 형식을 사용하도록 강제하는 것 입니다.

이 방법은 개발하기도 편하고 에러 핸들링 할 때도 편합니다.

 

하지만 커스터마이징을 원하는 고객이 생길 시 서비스 불만족으로 이어질 수 있습니다.

 

 

2. 테이블 수준의 분리

데이터베이스 서비스는 하나를 사용하고, 각 테넌트 마다 새로운 테이블을 만들어주는 형태입니다.

예) ACompany_Users 혹은 Users_ACompany  형태로 테이블이 어떠한 테넌트가 사용할 테이블인지 구분해주는 방법 입니다.

데이터를 각 사용자에 맞게 어느정도 분리해서 저장할 수 있고 Join 등 쿼리에도 큰 문제가 없습니다.

 

하지만 테이블이 무수히 많아질 수 있습니다. 

이는 오히려 서비스 복잡성을 키울 수 있습니다.

그리고 새로운 테넌트가 추가/삭제 될 때마다 이를 위한 테이블을 생성하고 삭제 해줘야 합니다.

 

3. 스키마 수준의 분리

데이터베이스 서비스는 하나를 사용하지만 이 서비스 내의 데이터베이스를 여러개 만들어주는 형태 입니다.

예를들어 사용자가 솔루션을 사용하려고 결제를 하면 해당 사용자를 위한 데이터베이스를 새로 만들어주는 형태입니다.

 

어떤 테넌트의 데이터인지 파악하기 쉬운 편이고, 각 테넌트는 서로 다른 데이터베이스 커넥션을 사용하기에 멀티테넌스 아키텍처에 종속된 로직을 작성하지 않아도 됩니다.

 

 

4. 식별자로 분리

하나의 데이터베이스와 하나의 테이블을 사용하지만 이를 특정한 식별자로 구분하는 방법 입니다.

예를들어 각 테넌트의 id를 식별자로 사용해서 각 row에 이를 추가해주는 방법 입니다.

 

구분이 필요한 모든 데이터에 식별자를 입력할 컬럼이 있어야 합니다.

구현하기 쉽고 추후 전체 통계, 업종별 통계 등을 낼 때도 큰 문제 없이 처리 가능합니다.

 

하지만 모든 데이터가 하나의 테이블에 들어있어서 한눈에 보기가 어렵고, 개발자의 실수로 타 업체의 데이터가 전송될 수 있다는 문제가 있습니다.

 

5. 데이터베이스 서비스 수준의 분리

각 테넌스마다 고유한 데이터베이스 서비스를 사용합니다.

예를들어 RDS의 인스턴스를 각 테넌스마다 하나씩 할당받는 형태입니다.

 

이는 특정 인스턴스가 문제가 생겼을 때 다른 테넌스들은 영향을 받지 않는다는 장점이 있습니다.

데이터를 확실하게 분리 저장 할 수 있으며, 더 많은 트래픽을 감당할 수 있습니다.

 

하지만 돈이 많이 듭니다.

인스턴스가 여러개 생기기에 관리 요소가 늘어나는 느낌을 받을 수 있습니다.

테넌트 추가/삭제 시 새로운 인스턴스가 만들어져야 하기에 많은 비용이 발생합니다.

 

 

 

 

여러가지 방법이 있지만 마음에 드는 방법이 딱히 없다.

한참을 고민해보다가 관계형 DB와 NoSQL DB를 함께 사용하면 어떨까 하는 생각이 들었다.

 

6. RDBMS with NoSQL

기본 제공하는 컬럼들은 RDBMS에서 처리하고 이후 추가되는 커스텀 컬럼들은 MongoDB 같은 NoSQL DB로 처리하는 방법입니다.

예를들어  | 원가 | 상품명 | 주문날짜 |  와 같은 기본 제공 컬럼이 있는데 사용자가 "메모" 컬럼을 추가하고 싶다고 가정하겠습니다.

 

이때 관계형 데이터베이스의 구조에는 손을 대지 않고 미리 만들어준 식별용 컬럼에 커스텀 컬럼이 있다는 식별자 혹은 커스텀 컬럼이 몇개있는지에 대한 정보만 업데이트 해줍니다.

 

이후 MongoDB에서 { name:"메모", isVisible:true } 형태로 저장합니다.

이 방법은 처음 생각했을 땐 이상적인 방법이라 생각했는데 여러가지 문제가 있을 것 같습니다.
각 데이터베이스의 데이터 동기화가 제대로 이루어지는지 장담할 수 없을 것 같고, 트랜잭션 처리가 까다로울 것 같습니다.

인터넷을 검색하다 한가지 글을 발견했습니다.

몇십년전 글이지만 ERP를 커스터마이징 하는것에 대한 내용이였는데, 처음엔 맞춤형으로 사용할 수 있어 좋지만 이후 추가 패치 과정에서 심각한 문제가 생기거나 아예 패치를 할 수 없거나 하는 문제가 생겨서 골치아프다는 글이였습니다.

 

아마 저 시기에는 설치식으로 설치해주는 형태였을 것이라 생각되는데, 클라우드로 서비스를 제공해도 별반 다를게 없어보인다는 생각이 들었습니다. 코드베이스는 어차피 하나이고 로직도 확장성 있는 공통된 로직일텐데, 고객별로 가진 데이터 구조가 모두 다르고 컬럼갯수 데이터 형태 등 모두 다르다면 아예 고객 맞춤형으로 방문하여 세팅 해주는 형태가 더 좋을 수도 있겠다는 생각이 들었습니다.

 

또한 업계에서 표준화된 구조를 따르는게 더 좋고 추후 솔루션 업체 변경 시에도 표준화된 구조의 솔루션을 사용하면 즉각적으로 업무를 시작할 수 있어 오히려 더 유연하다 라는 내용도 있었습니다.

 

 

 

커스터마이징에 발목을 잡혀서 며칠째 고민만 하고 진행을 못하고 있었는데 때론 기획을 변경하는게 더 올바른 선택이 될 지도 모르겠다는 생각이 들어 커스터마이징은 나중에 생각하기로 하고 업계 표준에 대해 찾아보고 타 솔루션에서 넘어올만한 편의기능에 집중 해야겠습니다.