한국어
다중 테넌트 앱의 테넌시 모델
"다중 테넌시"라는 개념을 더욱 깊이 탐구하고 그것에 대한 통찰력을 공유합니다.
Guamian
Product & Design
Product & Design
"다중 테넌시"라는 개념을 더욱 깊이 탐구하고 그것에 대한 통찰력을 공유합니다.
소프트웨어 서비스(SaaS) 애플리케이션을 개발하는 문맥에서 다중 테넌트 애플리케이션을 만드는 것의 중요성을 자주 듣습니다.
"다중 테넌트 앱"의 개념과 그것을 개발하는 다양한 모델에 대한 혼동이 있습니다. 이 기사에서는 이러한 용어들을 보다 실용적인 방식으로 자세히 살펴보았습니다.
단일 테넌트 아키텍처는 소프트웨어 또는 클라우드 컴퓨팅 모델로, 각 고객 또는 테넌트가 애플리케이션 또는 서비스의 전용 인스턴스를 갖는 것입니다. B2B 비즈니스 모델의 기원을 살펴보면, 각 소프트웨어 인스턴스가 단 하나의 고객 또는 조직을 위해 제공되기 시작합니다.
단일 테넌트 아키텍처는 규정 준수가 매우 중요하거나 맞춤형 보안 요구 사항이 필요한 경우 자주 사용됩니다. 예를 들어, 금융, 의료, 정부와 같은 엄격한 규제 요구 사항이 있는 산업에서는 규정 준수를 보장하기 위해 단일 테넌트 솔루션을 선호합니다.
그러나 단일 테넌트 아키텍처는 다중 테넌트 아키텍처에 비해 더 많은 리소스를 소모하고 관리가 복잡할 수 있음을 유의하는 것이 중요합니다. 결과적으로, 더 적지만 더 큰 고객을 보유한 애플리케이션이나 맞춤화와 격리가 중요한 경우에 더 적합할 수 있습니다.
소프트웨어 다중 테넌시는 한 대의 서버에서 소프트웨어 인스턴스 하나가 여러 테넌트를 서비스하는 소프트웨어 아키텍처입니다. 이렇게 설계된 시스템은 "전용" 또는 "고립"되지 않고 "공유"됩니다. 테넌트는 소프트웨어 인스턴스에 대한 특정 권한을 가진 공통 액세스를 공유하는 사용자 그룹입니다. 다중 테넌트 아키텍처에서는 소프트웨어 애플리케이션이 각 테넌트에게 인스턴스(데이터, 구성, 사용자 관리, 테넌트 개별 기능 및 비기능 요구 사항을 포함하여)의 전용 부분을 제공하도록 설계됩니다. -- 위키백과
아키텍처 관점에서 정의를 제공하여 다중 테넌트와 단일 테넌트 디자인을 명확하게 구분했습니다. 그러나 이는 기술적 정의에 더 가깝습니다. 테넌시 모델을 설계할 때 실제 개발 환경에서 이러한 정의를 사용할 경우, 다중 테넌트 앱은 순전히 공유된, 다중 테넌트 인프라를 가져야 한다는 사고방식을 가정합니다.
그러나 비즈니스와 제품은 많은 케이스별 요구 사항을 가지고 있어 만능 해결책은 없습니다.
테넌트가 공유 인프라 리소스를 사용하고 있지만, 특정 비즈니스 요구로 인해 시스템의 한두 부분이 그들에게만 전적으로 전담되어야 하는 시나리오를 상상해 보세요. 이러한 전담되는 부분은 데이터베이스, 인스턴스 또는 기타 구성 요소의 조합일 수 있으며, 전체 인프라를 공유합니다. 이것이 믹스드 테넌트 아키텍처가 필요한 곳입니다.
실용적인 SaaS 제품 개발에서는 주로 일반적인 다중 테넌시 모델로 설계된 제품을 만나게 되는 경우가 흔합니다. 그러나 아키텍처나 일부 리소스의 특정 측면은 "단일 테넌시" 접근 방식으로 나아갈 수 있습니다.
AWS는 이 개념을 전달하기 위해 다음과 같은 사례를 사용했습니다: 다중 테넌시는 광범위한 개념이며, 공유 리소스와 데이터 격리를 달성하려는 목표를 정의하기 위한 적절한 전략을 케이스별로 결합하고 선택합니다.
다시 말해, 많은 사람들은 여전히 이 모델을 "다중 테넌시"라고 부르기도 하지만, 다중 테넌시 전체의 정의에서는 솔루션의 모든 구성 요소가 공유되어야 한다는 것을 암시하지 않습니다. 오히려 솔루션의 적어도 일부 구성 요소가 여러 테넌트 간에 재사용됨을 나타냅니다.
이 용어를 넓게 이해함으로써 클라이언트의 필요와 출발점을 더 잘 이해할 수 있습니다.
단일 아키텍처 모델에 갇히기보다 다중 테넌시는 실제 세계에서 SaaS 제품의 아키텍처의 실용성을 반영합니다. 우리는 다중 테넌트 앱을 언급할 때 애플리케이션이 한 가지 아키텍처 모델을 고수한다는 것을 반드시 의미하는 것은 아닙니다. 다양한 테넌시 전략을 사용할 수 있으며, 적어도 그 일부 구성 요소가 공유된다는 것을 보여줍니다.
여기서 질문이 나옵니다. 내 제품에 대한 테넌시 전략을 어떻게 제안할 수 있을까요? 생각해야 할 중요한 질문은 다음과 같습니다:
제품에서 순전히 다중 테넌트 또는 단순히 단일 테넌트 모델을 선택해야 하는 엄격한 구분이 없다는 점을 기억하십시오. 귀하의 결정은 제품의 아키텍처 구성 요소를 어떻게 나누느냐와 고객이나 비즈니스에 필요한 특정 격리 수준에 따라 다릅니다. 그런 다음 각기 다른 접근 방식을 적용할 수 있습니다.
우리는 "새로운" 다중 테넌트 앱의 정의에 대해 이야기했지만, 테넌트 격리, 정체성, 그리고 너의 정체성이 고립되어야 하는지 여부를 어떻게 결정하나요? "고립된" 정체성이란 무엇을 의미하나요?
실제 환경에서 한 명의 사용자가 두 개의 다른 정체성을 갖는 상황에서 혼란이 자주 발생합니다. 이러한 상황을 "정체성 고립"으로 레이블을 붙이는 것이 적절한가요?
이 질문들은 곧 다가올 우리의 시리즈 기사에서 다루어지겠습니다. 계속 지켜봐 주세요!