API Management PaaS에서 Multi-tenancy 구현하기

개요

안녕하세요. 지마켓에서 개발자분 업무의 편의를 도모하기 위한 클라우드 플랫폼 업무를 담당하고 있는 김지형입니다.
이번 글에서는 API 관리형 서비스인 Red Hat 3Scale 제품을 이용해 개발 팀 간 멀티테넌시 구축을 위해 고려한 부분과, 실 적용 과정에 대해 글을 쓰고자 합니다.

 

멀티테넌시 (Multi-tenancy)

멀티테넌시 (Multi-tenancy)는 하나의 소프트웨어 어플리케이션을 여러 고객에게 일관된 경험으로 서비스할 수 있게 하는 아키텍처를 말합니다. 클라우드 컴퓨팅이 발전하면서 가상화 및 컨테이너화를 통해 각각의 고객이 분리된 각각의 데이터를 이용할 수 있게 되었고 동일한 호스트 노드 내 단일 인스턴스지만 각각 별도의 앱을 이용하는 것처럼 구현할 수 있게 되었습니다.

Single Tenant vs Multitenant

 

인프라 멀티테넌시 구현을 위해 직면해야 할 문제

"똑같은 앱을 여럿이서 사용하게 하는 것"은 SaaS에서는 이미 많은 분들이 경험해보셨을 겁니다. 회원가입 및 로그인을 통해 개인 만이 볼 수 있는 격리된 데이터를 생성, 조회, 수정, 삭제할 수 있게 하고 개인의 명의로 게시판을 글을 쓰는 과정이 모두 일종의 멀티테넌시라고 할 수 있겠습니다. 하지만 인프라에서 멀티테넌시 구현을 위해 인프라를 여러 고객이 공평하게, 독립적으로 이용할 수 있게 하는 것은 다소 쉽지 않은 문제입니다. 멀티테넌시 아키텍처는 등장한 지 10년이 넘어간, 그래도 상당 기간동안 많은 수준까지 발전한 아키텍처입니다. 그러나 아직 어려워 보이는 문제들이 존재합니다.

 

문제 1: 고객마다 다른 요구사항이 존재한다

한국에만 수백 개의 온라인 소호 쇼핑몰이 존재하는데, 그리고 얼핏 보기엔 동일한 서비스 로직(상품 설명, 수량 선택, 결제 등등)이 존재할 것 같은데 쇼핑몰 홈페이지는 왜 다 중구난방 다를까요? 비슷한 틀의 홈페이지를 로고와 컨텐츠만 바꿔서 제작할 수는 없을까요? 왜 쇼핑몰마다 각각 다른 외주업체, 프리랜서에 맡겨서 매번 새롭게 로직을 개발하는 걸까요? 이 업계에 조금만 발을 들여다 보신 분이면 아실 겁니다. 저렴한 가격에 정해진 틀의 홈페이지를 판매하는 업체도 있지만 이것들은 쇼핑몰 사장님들의 마음을 살 수 없을 것이라는 걸.

API 관리 서비스도 마찬가지입니다. 얼핏 보면 개발자분들은 백엔드 서버의 호출가능한 엔드포인트를 외부에 정제된 형태로 보여주게 하는 일관된 형태의 API 관리 서비스를 요구하시는 것 같지만 API 토큰을 헤더에 간편하게 넣고 간편하게 난독화를 할 수 있는 서비스를 기대하기도 하고, 업데이트 별로 독립된 버전 관리를 목적으로 서비스를 이용하려 하시는 팀도 계십니다. 한편으론 많은 기능보다는 작동만 잘 되게, API 게이트웨이에서 에러를 컨트롤하지 않고 싶은 마음에서 이용하려고도 하시죠. 멀티테넌시를 구현하기 위해서는 다양한 고객의 요구사항을 적절하게 수용하고 우선순위에 따라 구현해야 하는 문제가 있고, 없는 기능을 개발하기 위해서는 상당한 비용과 인력이 소요되는 부분이기도 합니다. 그리고 더 좋은 기능과 UX를 위해 업데이트를 하면 모든 고객에게 영향을 미치므로 오히려 불편함을 야기시킬 수도 있습니다.

 

문제 2: 데이터 보안이 쉽지 않을 수 있다

고도로 민감한 데이터를 다루는 서비스들을 단일 어플리케이션을 통해 서비스하게 하는 부분도 쉽지 않은 문제입니다. 실제로 고객의 개인정보와 기업의 서비스 데이터를 분리보관해야 할 것을 국내 개인정보보호법에서는 명시하고 있으므로 대부분의 기업이 망분리를 통해 별도의 인프라 클러스터를 통해 서비스되고 있습니다. 일부러 분리 통제해둔 클러스터를 하나의 서비스로 향하게 하는 것이 이론상 가능하지만 현실적으로 쉽지 않은 문제입니다. 크로스 테넌트 공격이라고 불리는 클라우드 취약점의 문제, 관리자의 부실한 액세스 제어 및 설정 오류로 인한 리스크를 완벽하게 통제하기란 어렵습니다.

철저한 보안을 위해 제한된 포트 오픈, DNS 주소 관리 및 방화벽 구성이 까다로운 편이라면 이 역시 멀티테넌트 구현의 관점에서는 쉽지 않은 허들이 될 수 있습니다. 단일 테넌트를 위한 서비스에서는 외부 통신을 위한 라우트 및 포트가 직관적이지만 멀티테넌시 서비스에서는 이러한 부분들이 동적으로 구성되어야 하기 때문에 일부 고객의 서비스와 연결되어있는 도메인 승인 여부, 또는 외부 접근 정책이 누락되어있기라도 한다면 그 원인을 추적하기가 더 복잡해집니다.

 

문제 3: 장애 확산의 우려가 있다

이는 멀티테넌시의 문제라기 보다는 마이크로서비스 아키텍처로 인한 문제로서 여겨지는 부분이라고 할 수 있습니다만 단일 인스턴스에서 단일 서비스로 이루어지는 부분이기 때문에 인스턴스, 서버, 또는 서비스의 장애가 나면 그 영향력이 클 수 있습니다. 병목현상이 쉽게 일어날 수 있고 이를 해결하기 위한 서킷 브레이커(Circuit Breaker) 역시 정교하게 설계되어야할 필요가 있습니다. API 관리 서비스에서는, 외부 API 통신 시도가 있으면 외부 통신이 실패하는지 여부를 판단하고 타임아웃, 지연, 서버 오류 등의 상태에 따라 즉각적으로 반응할 수 있어야 하며 아이덴티티와 인증 등의 IAM 시스템을 명확히 해야할 필요성이 단일 테넌트 시스템보다 더 대두됩니다.

 

Red Hat 3Scale 제품을 이용한 멀티테넌시 구성

지마켓의 수많은 마이크로서비스 운영을 위해 인프라 팀에서는 Red Hat Openshift 4 버전대의 인프라 플랫폼과 Red Hat 3Scale API Management PaaS를 이용하고 있습니다. 최대한 클라우드 네이티브의 범용 관점에서 글을 서술하겠지만, 실제 저희 인프라 팀에서 구축한 사례를 통해 어떻게 위의 문제를 해결하여 구축할 수 있었는지 서술해보도록 하겠습니다.

https://learn.microsoft.com/ko-kr/azure/architecture/guide/multitenant/considerations/tenancy-models

 

분리된 백엔드 네임스페이스

기본적으로 API 관리 서비스에 붙여지는 백엔드 엔드포인트들은 개발 팀별로 쿠버네티스 시스템 간 네임스페이스를 분리시키는 것부터 시작합니다. Openshift를 이용한다면 3Scale 콘솔에서 동일한 클러스터 내의 백엔드 서비스를 조회할 수 있는 기능이 존재하는데 이를 이용해 원천적으로 하나의 테넌트는 단일 네임스페이스의 백엔드 엔드포인트만을 호출할 수 있게 구현할 수 있습니다. 이 기능을 이용하지 않아도 정식 서비스 전에 각각의 URL이 어느 서비스를 가르키고 있는지 검토하고 불필요한 엔드포인트과 포트는 차단하고 있습니다. 네임스페이스를 통해 네트워크 분리 뿐만 아니라 스토리지, 컨테이너 런타임 등 또한 분리시킬 수 있어 분리된 서비스 제공을 가능하게 합니다.

 

분리된 클러스터 내에서만 이용할 수 있는 멀티테넌시 서비스 구현

문제 2: 데이터 보안의 관점에서 분리된 클러스터의 서비스를 타 클러스터의 API 관리 서비스로 통신하게 하기에는 사내 보안 정책과도 상충되는 부분이자 리스크가 크다고 판단했습니다. 인프라 자원의 효율화 관점에서는 단일 클러스터에서 단일 인스턴스만의 API 관리 서비스를 운영하는 것이 최적이겠으나, 보안을 위해 API 관리 서비스만을 위한 별도의 Openshift 클러스터를 다수 구축하고 제한된 통신만을 허용하게 구성하였습니다. 분리된 망에서 다른 망으로 통신할 우려가 없게 구성되어 있으며, 인터넷과 연결되는 API에 대해서는 Active/Active 형태의 복수 클러스터를 구성해 재해 복구를 위한 시스템도 포함하고 있습니다.

 

불필요한 개발자 Role 제거

3Scale에서는 다양한 고객의 니즈를 충족하기 위해 서비스 내 다양한 Role을 구축해두었고, 마스터, 관리자, 개발자 등의 Role 별로 독립된 대시보드와 설정 페이지를 구성해두고 있습니다. 3Scale에서 정의해준 대로 인프라 팀에서 마스터, 관리자의 Role을 가져가고, 개발 팀에서 개발자의 Role을 가져가는 것은 우리 조직의 프로세스과 맞지 않았습니다. 개발 팀에서 자유롭게 엔드포인트를 추가하고, 권한 설정 및 헤더 값 수정 등의 자유로운 활동을 하기에는 개발자 Role이 많이 제한적으로 다가왔기 때문입니다. 또한 개발자 Role에서 수정할 수 있는 API 문서, Echo API 서비스 등이 개발팀의 요구사항은 아니었기 떄문에,Swagger와 같이 편리한 문서화를 지원해주는 부분도 아니었기 때문에 개발자 콘솔은 아얘 지원하지 않는 방향으로 운영되고 있습니다.

정리하자면 인프라 팀에서 마스터로서 모든 관리자 콘솔 및 설정을 관리하고 있고, 개발 팀별로 독립된 관리자 콘솔, 설정을 운용함으로써 멀티테넌시 시스템을 이뤄내고 있습니다.

 

통합 모니터링 및 통합 Single Sign-On

철저히 독립적인 클러스터의 구조는 가져가되, 수많은 클러스터를 효과적으로 운영하기 위해서는 통합 시스템 구축, 통합 멀티테넌시 시스템이 필요한 단계이기는 합니다. 다소 보수적으로 접근하고는 있으나, 상대적으로 장애 확산이 적은 서비스인 모니터링 서비스와 인증 서비스 등은 같은 망의 클러스터 간 동일 서비스를 이용할 수 있는 멀티테넌시 형태로 변화해나가고 있으며 빠르게 클러스터 노드와 자원의 상태를 체크해나갈 수 있는 시스템을 만들어나가고 있습니다.

 

정리

서두를 멀티테넌시의 단점과 한계로 시작을 해서 이 글이 '왜 멀티테넌시를 구현하는 거야?'라는 의문점을 남길 수 있었겠다라는 생각이 듭니다. 하지만 갈수록 많은 기업이 클라우드 컴퓨팅을 적용하고 있는 이유와 일맥상통하게 멀티테넌시의 다양한 장점이 있기에 적용할만한 가지가 있다고 필자는 느꼈습니다. 처음에는 가시적으로 보이지는 않을 수 있지만 비용 절감 효과, 유연성, 효율성의 측면에서 멀티테넌시 아키텍처는 클라우드 시스템이 나아가야할 방향일 것입니다.