SaaS 멀티 테넌트 아키텍처 정의 오해와 진실

멀티 테넌시와 SaaS 라는 용어는 종종 긴밀하게 연결됩니다. 때로는 어떤 조직에서 “SaaS는 곧 멀티 테넌시” 라고 설명하기도 합니다. 물론 이 설명이 자연스러운 것처럼 보일 수 있지만, SaaS와 멀티 테넌시를 동일시하는 것은 여러분의 팀이 SaaS 를 기술 적인 관점으로만 바라보게 합니다. 실제로는 SaaS 는 아키텍처 전략이 아니라 비즈니스 모델인데 말이죠.

이 개념을 더 잘 이해하기 위해서 전통적인 멀티 테넌시 관점부터 살펴 보겠습니다. 이 순전히 인프라 중심적인 관점에서는 멀티 테넌시는 테넌트가 리소스를 서로 공유하여 민첩성과 비용 효율성을 증진하는 방법으로 설명됩니다.

예를 들어, 여러 테넌트가 사용하는 마이크로서비스 또는 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스가 있다면, 이 서비스는 멀티 테넌시 모델에서 실행된다고 볼 수 있습니다. 왜냐하면 테넌트들이 이 서비스를 실행하는 인프라를 공유하기 때문입니다.

이러한 정의의 문제점은 기술적인 멀티 테넌시 개념을 SaaS와 너무 직접적으로 연결한다는 것입니다. 이는 SaaS의 결정적인 특징이 자원을 서로 공유하는 멀티 테넌트 인프라를 반드시 갖추어야 한다는 가정을 만들어 버립니다. 이런식의 SaaS에 대한 관점은 다른 환경에서 SaaS가 구현되는 다양한 방식을 볼 때 그 논리가 무너지기 시작 합니다.(*즉, SaaS가 단순히 기술적인 멀티 테넌시 측면에서만 이해될 수 없으며, 다양한 환경에서 다양한 형태로 구현될 수 있다는 것을 의미합니다.)

다음 다이어그램은 우리가 멀티 테넌시를 정의하는 데 어려움을 겪을 수 있는 경우를 보여 줍니다.

이전에 설명한 클래식한 SaaS 모델 처럼, 여러 테넌트를 관리하고 운영할 수 있는 공통 서비스(회색 박스, 예, Onboarding, Identity, Billing and metering 등)로 둘러싸인 일련의 애플케이션 서비스들이 있습니다.

다이어그램을 보면 애플리케이션 서비스들은 제품, 주문 및 카탈로그라는 세 가지 샘플 마이크로서비스로 구성되어 있습니다. 각 서비스의 테넌시 모델을 자세히 살펴보면, 서로 약간은 다른 테넌시 패턴이 적용되었다는 사실을 알 수 있습니다.

제품 서비스는 모든 테넌트와 컴퓨팅 및 스토리지를 공유합니다. 이는 멀티 테넌시의 클래식한 정의와 일치합니다. 그러나 주문 서비스를 살펴보면, 공유하는 컴퓨팅이 있지만 각 테넌트별로 별도의 스토리지가 사용 되고 있음을 알 수 있습니다.

카탈로그 서비스는 각 테넌트에 대해 컴퓨팅이 별도로 지정되어 있지만 (각 테넌트마다 별도의 마이크로서비스 배포), 모든 테넌트는 스토리지를 공유합니다.

이러한 종류의 변형은 사실 SaaS 환경에서 흔하게 나타납니다. 시끄러운 이웃 문제, 티어링 모델, 격리 요구 등 다양한 이유로 SaaS 솔루션의 일부를 선택적으로 공유하거나 서로 분리(silo)할 수 있습니다.

이러한 변형 과 이런 모습을 만들어 낼 또 다른 가능성들을 고려하면 전통적인 관점의 멀티 테넌시 용어를 사용하여 이런 환경을 설명 하는 것이 더 어려워집니다. 즉 고객(테넌트) 입장에서는 전반적으로 멀티 테넌트 환경이라고 할 수 있습니다. 그러나 조금 더 기술적으로 깊이 들어가보면, 이 환경의 일부는 멀티 테넌트이고 일부는 아니라는 겁니다.

그렇기 때문에 멀티 테넌시 용어를 사용하여 SaaS 환경을 특성화 하거나 일반화 하는 것을 피할 필요가 있습니다. 대신, 멀티 테넌트 라는 용어를 사용해야 한다면, 아키텍처 일부가 공유되고 일부가 공유되지 않을 수 있다는 점을 염두에 두고 시스템 전체 적인 관점에서 SaaS 환경을 멀티 테넌트로 설명 하는 것이 더 의미가 있습니다.(*이미 제품과 주문 서비스의 컴퓨팅 환경 뿐 아니라 onboarding, Identity 와 같은 SaaS 컨트롤 플레인의 구성 서비스들이 공통 자원 형태로 제공 되고 있기 때문 입니다)

극단적인 경우

테넌시 개념을 더 잘 강조하기 위해, 자원을 전혀 공유하지 않는 테넌트를 가진 SaaS 모델을 살펴보겠습니다. 다음 다이어그램은 일부 SaaS 제공업체에서 사용하는 예시 SaaS 환경을 보여줍니다.

이 다이어그램 에서는 여전히 테넌트를 둘러싼 공통 환경이(예, Onboarding, Identity 등) 있습니다. 그러나 각 테넌트는 전용 자원들로(*테넌트 별 제품 주문 서비스) 배포됩니다. 이 모델에서 테넌트들 간에는 아무것도 공유되지 않습니다.

이 예제는 멀티 테넌트의 의미에 대해서 다시 한번 고민하게 합니다. 자원이 전혀 공유되지 않는데도 이 환경은 멀티 테넌트 환경 일까요? 이 시스템을 사용하는 테넌트들은 자원을 공유하며 사용해야 하는 SaaS 환경에서 기대하는 수준과 동일한 기대를 가지고 있을 겁니다. 사실, 이들 테넌트들은 SaaS 환경의 내부에서 자신들의 자원이 공유 되던 분리 되던 어떻게 배포 되는지를 인식할 필요가 없을 수도 있습니다.

이 예시의 테넌트들을 위한 서비스는 격리된 인프라 자원에서 실행되지만 여전히 공동으로 관리되고 운영됩니다. 즉 회색 박스와 같은 통합된 Onboarding, Identity, Metrics and analytics, Billing and metering, DevOps and deployment 같은 서비스를 공유합니다. 또한 새 버전이 출시되면 모든 테넌트에 똑같이 배포됩니다. 특정 테넌트를 위한 배포를 위해 일회성 커스터마이제이션을 허용하지 않습니다..

이 극단적인 예제는 멀티 테넌트 SaaS 개념을 새롭게 정의하기에 좋은 기회를 제공 합니다. 공유 인프라로 인한 모든 효율성을 실현 하지는 않을 수 있지만, 이런 형태 역시 완전히 유효한 멀티 테넌트 SaaS 환경입니다. 어떤 경우에는 일부 고객에게는 별도 도메인을 제공하여 위와 같은 독립된 자원으로 구성된 모델을 제공할 수 도 있습니다. 그렇다고 이런 케이스가 SaaS가 아니다 라고 할 수 없습니다. 공유 서비스를 사용하고 모든 테넌트가 동일한 버전의 서비스 실행하는 경우, 이는 여전히 SaaS 가 요구하는 기본적인 원리와 원칙을 따르고 있다고 볼 수 있습니다.

이상에서 살펴본 다양한 케이스와 좀 더 넓은 범위의 SaaS 정의를 고려하면, 멀티 테넌트 라는 용어를 사용하는 방식을 좀더 바꿀 필요가 있습니다. 이제는 관리 및 운영이 공동으로 이루어지는 모든 SaaS 시스템을 멀티 테넌트로 참조하는 것이 더 합리적 입니다. 그런 다음, SaaS 솔루션 안에서 어떻게 리소스가 공유되거나 전용으로 사용 되는지 설명하기 위해 다른 접근과 세분화된 용어나 개념을 사용할 수 있을 겁니다.

🐶안녕하세요 오늘 주간 SaaS 는 멀티 테넌시 정의 다시 하기 라는 제목으로 발행된 AWS Whitepaper를 소개 했습니다.

SaaS 대한 흔한 오해 중 하나가 SaaS 아키텍처를 구성하는 모든 자원이 모든 테넌트들에게 공유 되어야 하며 그렇지 않을 경우 이건 SaaS 가 아니다! 입니다. 이런 오해는 SaaS 와 멀티 테넌시를 동일시 하기 때문에 발생 합니다.

SaaS 아키텍처에는 테넌트에게 통합된 사용자 경험을 제공함과 동시에 테넌트를 온보딩, 운영, 분석 그리고 관리할 수 있는 환경이 포함되어 있어야 합니다. 때로는 이런 환경을 SaaS 컨트롤플레이니 이라고 하기도 합니다.그리고 좋은 SaaS 아키텍처는 테넌트 마다 개별 적인 아티팩트를 갖기 보다 신속하게 테넌트를 온보딩 하고 서비스를 업데이트할 수 있도록 하는 효율성과 민첩함을 우선시 하며 이를 바탕으로 SaaS 아키텍처는 SaaS 비즈니스의 빠른 혁신과 성장 그리고 비용 효율성을 달성할 수 있도록 지원해야 합니다.

이런 관점에서 SaaS 아키텍처를 바라 보고 테넌트의 요구 사항과 우리 비즈니스 목표의 접점에서 테넌트 자원을 공유 하거나 분리 하는 유연한 접근이 필요 합니다.

오늘 주제에 대한 여러분의 생각이 궁금 합니다!

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요