uEngine solutions

오픈클라우드엔진 - 성공적 클라우드 서비스 구축을 위한 가장 빠른 방법

uEngine GW 리팩토링 4. 멀티 테넌트와 룰엔진의 선택

24 Jul 2017 » api-gateway

멀티 테넌트와 룰엔진의 선택

uengine-gw, 싱글레톤 서비스냐? 멀티 테넌시 서비스냐?

유엔진 GW 를 싱글레톤 서비스(설치형), 멀티 테넌시 서비스(클라우드) 둘 중 어느 형태로 개발하냐에 따라 아키텍쳐는 현저하게 틀려진다는 판단이 든다.

일단 Kong 과 Netflix 는 싱글레톤 서비스이다.

Kong 은 yml 파일로, Netflix 는 yml 파일 또는 github yml 파일을 사용한다.

정확히 말하면,

  • Kong
    • yml : Ngnix Configuration
    • cassandra/postgress : Api 엔드포인트 관리, 분석 수집
  • Netflix
    • spring cloud config : Api 엔드포인트 관리, Configuration

아래는 Netflix 의 동적 Config 업데이트 시나리오이다. 하지만 멀티 테넌시는 아니고, Config 를 로드 후 스프링 프레임워크 내에서 싱글레톤으로 동작한다.

그럼 하나의 Api 플랫폼을으로 다수의 조직 및 기업들에게 서비스 할 수 있게 하려면?

멀티테넌시 를 서비스 하기 위해 Tyk 는 다음과 같은 아키텍쳐를 사용한다.

위의 그림에서, MongoDB 의 역할은 테넌트 별 룰을 관리하고, 룰이 업데이트 되었을 때, 프락시를 수행하는 Tyk Node 의 In Memory 가 업데이트 될 수 있도록 메시지 큐 기능도 함께 수행한다.

현재 유엔진 GW 는 애매한 상태이다. DB 설계는 멀티테넌시로 되어있지만, 룰이 업데이트 되었을 경우 Api-gw 노드들로 메세지 큐를 수행하지도 않고, 업데이트 요청 받은 노드만 캐쉬를 업데이트 하고있다.

유엔진 GW 를 Netflix 기반으로 다시 제작하기로 하였다면, 아래의 그림처럼 Zull 필터의 확장이 필요하다.

  • 기존 Netflix zull proxy 필터

  • uengine gw zull proxy 필터

멀티 테넌시를 하기 위해 그냥 DB 에 테넌트 필드로 관리하면 되지 않느냐?

No! Api gateway 의 선두주자들이 괜히 In Memory 로 관리하는게 아니다. Api gateway 중요 경쟁지표 중 하나가 룰 처리 속도인데, Api request 마다 테넌트 고유 프로퍼티들을 DB 에서 가져오는 건 좀 아닌듯..

그래서 Tyk 초기모델에서는 Redis 로 테넌트 룰을 로딩하다가, Redis 리퀘스트 타임도 경쟁력에서 떨어진다는 판단에 인메모리 방식으로 바뀌었다.

룰 엔진, BPM 은 오버스펙인가?

기존 uengine-gw 의 BPM 방식에 대해 솔직하게 평가해보자.

  • 아무도 안쓸듯한 UI
  • BPM 을 이해하며 작성할 바에는, AWS lambda 처럼 한번에 작성하는 방식을 선호할 듯.
  • 대부분 사용자의 요구사항은 Before, After 필터, 두가지이다.
  • Auth, Api 쿼터, 로드밸런싱, Target Url 등의 필수요소들은 자동으로 모든 Api 에 적용되길 바라고있다.

그럼, 위의 비판들을 수용해 보완한다고 쳐보자.

  • AWS lambda 처럼 한번에 처리하게 하는 스크립트 창을 주자.

  • Auth, Api 쿼터, 로드밸런싱, Target Url 등의 필수요소들은 Static 한 페이지로 제공한다.
  • Before, After 필터가 필요한 사람만 추가적인 BPM 설정을 하도록 한다.

위와 같은 개선을 한다고 해도, Api gw 에 BPM 의 이점을 굳이 찾지 못한다면, 차라리 기능을 빼버리는게 낫다. 단, 스크립트 엔진 부분은 Lambda 처럼 서버리스한 Api 를 제작할 수 있는 괜찮은 포인트임으로 가지고 가는게 어떨까?

만약, BPM 을 계속 가져간다고 하면, 다음과 같은 그림으로 아키텍쳐가 업그레이드 되겠다.