Tenant

Tenant(테넌트)

웹 개발에 입문하면 낯선 기술 용어들을 많이 접하게 됩니다. 하나를 알면 또 다른 용어를 알아야 하고 꼬리에 꼬리를 물고 따라가다가 새로운 용어의 숲에서 길을 잃어버립니다. 내가 지금 무엇을 하고 있나? 하면서요.

이번 포스팅에서 특히나 늘 애매하게 이해될듯 말듯한 ‘Tenant’ 대해서 정리해 보겠습니다. 먼저 이해를 돕기 위해서 간단한 비즈니스 사례가 있으면 좋겠죠? 만들려는 비즈니스 사례는 이렇습니다. 어떤 기업이 OTT(over-the-top media service) 서비스를 운영하고 있고

OTT 서비스를 구독하는 사용자들에게 과금하기 위한 사용자관리 용도의 서비스가 필요하다고 가정해 보겠습니다. 인증/권한관리를 통합 관리하는 개념을 IAM(Identity and Access Management)이라고 하는데요.

이번 포스트에서 설명할 IAM은 OTT서비스 제공 사업자가 OTT서비스 컨텐츠에 대한 사용자 로그인 인증 및 접근 권한을 제어하기 위한 관리기능입니다.

그림에서처럼 사용자가 로그인을 시도하는데 인가된 사용자이면 서비스 구독자이고 등급에 맞는 OTT컨텐츠를 제공할 것입니다. 만약 그렇지 않다면 접속이 거부되겠죠. 여기서 OTT 서비스는 Netflix 같은 서비스이고 사용자는 요금을 내고 컨텐츠를 구독하는 구독자라고 생각하면 될거 같습니다.

그런데 Netflix는 한 사람이 가입하면 여러명이 같이 사용할 수 있습니다. 즉, 요금을 지불하는 한 사람이 있고 몇명의 사용자들이 해당 요금으로 같이 컨텐츠를 시청할 수 있다는 것입니다. 소프트웨어 시스템에서는 이러한 개념을 테넌트(Tenant)란 개념을 적용하여 설계에 반영합니다.

예를 들면 위 왼쪽 그림처럼 가족의 경우 아버지인 ‘Hong’이 요금을 지불하고 어머니 ‘kim’과 아들 ‘Hong’이 OTT서비스를 구독하는 경우 아버지 ‘Hong’은 테넌트가 됩니다. 위 오른쪽 그림처럼 기업의 경우 조직(Group)이 있고 조직내 조직 구성원들이 있는 경우가 일반적입니다. 이 경우 조직들의 모든 비용을 지불하는 ‘Samsung’이라는 기업이 테넌트가 됩니다. 테넌트의 비즈니스적인 해석은 앞서 설명했던 내용과 같습니다. 소프트웨어 시스템 측면에서의 테넌트에 대한 해석은 위키 멀티테넌시를 참고하시면 됩니다.

테넌트의 위계(Hierarchy)관계가 정립되었다면 테넌트와 그룹, 사용자들의 속성정보를 생각해 보겠습니다. 적어도 구성원을 과금 구성원을 식별하기 위한 ‘ID’와 ‘이름’, ‘설명’, ‘등록일’, ‘수정일’ 등은 최소한 필요할 것입니다. 그럼 최소한의 속성만 정의해 보겠습니다.

위 그림처럼 위계 관계와 각 구성원들이 가질수 있는 속성도 모두 정의하였습니다. 이제 OTT사용자 ‘가입서비스’를 만들 수 있는 준비가 되었습니다. 물론 빠뜨린게 있긴 합니다. 바로 ‘역할’과 ‘정책’같은 개념인데요.

지금까지는 요금을 지불하는 서비스 사용자 입장에서 사용자 그룹을 만들고 테넌트를 지정하였습니다. 서비스 제공자 입장에서는 사용자 그룹이나 테넌트 단위로 사용료를 지불하는 사용자들에게 요금에 부합하는 서비스를 제공해야 합니다. 사용요금에 따른 서비스 정책을 적용해야 한다는 것입니다. 물론 단위 사용자 단위로 서비스 정책을 적용 할 수 있지만 그렇게 하면 여러 관리 문제가 있을 수 있습니다. 사용자별 정책을 하나하나 제어하는 것이 좋아 보이지 않습니다. 그래서 역할이란 개념을 두고 사용자 그룹에게 부여합니다. 역할에는 정책들이 포함 될 것입니다.