Tyk 멀티테넌시 (Multi-tenancy)

10/15/202Jun Hwang

멀티 테넌시 (Multi-tenancy)

멀티 테넌시는 하나의 타이크 전개로써 여러 테넌트들을 수용하는 기능
데이터는 하나의 DB에 저장, 사용하지만 각 테넌트들은 자신이 소속된 Organisation의 데이터에만 접근가능하도록 멀티 테넌시를 지원
테넌트 (tenant)와 조직 (organisation)은 같은 의미로 사용

조직 (Organisations)
하나의 organisation은 타이크 내에서 단일의 테넌트를 의미
Organisations는 타이크 오브젝트의 계층구조 내에서 root 오브젝트로 간주
타이크 데이터베이스에서 가지고 있는 오브젝트들은 하나의 organisaiton에 대한 레퍼런스이고, 그것의 org_id 필드가 해당 organisation과 연관된 데이터를 가리키는 (indicate) 것.
한 오브젝트는 오직 하나의 조직 (organisation)에만 소속된다.
일반적으로 대시보드 사용자는 자신과 연결된 조직의 데이터에만 접근가능. 특정 대시보드 사용자에게 여러 개의 조직에 접근허용하는 설정 방법:
a. 사용자를 복수의 조직들에서 동일한 이메일 주소를 사용하여 사용자 계정을 생성
b. 여러 조직에 접근허용 되더라도 한 번에 한 조직에만 접속가능
c. 사용자가 접근 인가된 후에 어떤 조직을 접근할 지를 반드시 선택해야만 함
d. 사용자가 자신에게 허용된 다른 조직으로 접근할 때는 다시 인가를 받아야만 됨

다중 조직 접근을 생성하는 것은 사용자들의 계정을 각 조직에 대하여 별도로 만듦으로써 가능
다중 조직 사용자를 활성화 하려면:
a. 대시보드 라이선스가 최소한 2 개 이상의 게이트웨이를 가질 수 있어야 되고 (Tyk에 질의해야 함) b. 대시보드의 conf 파일의 enable_multi_org_users 플래그의 값을 true로 설정하여야 함

Super Users

수퍼 유저들은 대시보드 내의 모든 조직들과 모든 데이터에 대해 접근 권한을 가짐 전체 데이터 셋에 대한 리포팅에 유용하게 사용 수퍼 유저들의 사용자 데이터베이스 내의 org_id는 빈값이며, 그들이 아무 조직과도 연결되지 않음 수퍼 유저는 일반 UI나 API를 통하여 생성될 수 없고, 오직 특별한 대시보드 어드민 API를 통해서만 생성될 수 있음 수퍼 유저는 데이터를 쓰기를 허용하지 않고 읽기만 권장: 수퍼 유저가 생성하는 데이터에 대해 org_id 값이 생성되지 않으므로 유효성 검증에 실패할 수 있음

data ownership.png

  1. 사용자 Wile E.Coyote는 조직 1001 (Acme Corporation)에만 접근허용되고, API 2001, 2002만 보거나 관리할 수 있고, 2000 My API는 볼 수도 없음.
  2. 사용자 Martin은 조직 1000에 접근 가능하므로 My API만 보거나 관리
  3. 수퍼 유저는 org_id가 없으므로 어느 조직에도 속하지 않고, 모든 API를 볼 수도 관리할 수도 있음

Listen Path Collisions (청취 경로 충돌)

단일의 Tyk 설치로 다중 테넌트를 운용하는 경우에는 API 정의들이 같은 릿슨 패스를 사용하여 생성되는 일이 생길 수 있는데; 이것을 청취경로충돌 이라고 한다.

게이트웨이가 청취경로충돌을 감지하면:

  1. 애플리케이션 로그에 에러를 기록 (API 정의의 상세정보를 포함)
  2. 충돌을 일으킨 모든 API들의 청취경로를 변경 (API Definition ID를 청취경로에 추가함으로써 각 청취경로를 유니크하게 만드는 방식)

Listening path collison.png

위의 예시처럼, API A와 API B가 ‘/my-api’ 라는 같은 청취경로를 사용한다면;

  1. 게이트웨이가 이 API들을 로드할 때 청취경로충돌을 감지

  2. API ID를 사용하여 새로운 청취경로를 생성

    청취경로충돌을 피하기 위한 방법

    1. MDCB를 사용하면, 게이트웨이는 단일 Org에 종속되므로, 전체 테넌트들에 걸쳐 충돌이 발생할 수 없는 구조
    2. API를 Sharding 하여 API Definitions를 다른 게이트웨이에 분리하면 각 게이트웨이가 자신에게 할당된 API 정의를 로드하기 때문에 충돌을 방지할 수 있으나, API Sharding을 하기 위해 tag 를 맞게 입력해야 하기 때문에 이 때 휴먼 에러가 생길 수 있음
    3. 커스텀 도메인을 사용하여 중복된 청취경로를 서로 구별할 수 있음 (각 도메인 명을 청취경로의 prefix로 사용하는 방식)
    4. 대시보드 설정에서 enable_duplicate_slugs 의 설정값을 false 로 하여 대시보드가 같은 조직 내에서 청취경로충돌을 방지 (다중 테넌트에서는 역할 못하므로 MDCB가 필요)