다중 테넌트 앱의 테넌시 모델

소프트웨어 서비스(SaaS) 애플리케이션을 개발하는 문맥에서 다중 테넌트 애플리케이션을 만드는 것의 중요성을 자주 듣습니다.

"다중 테넌트 앱"의 개념과 그것을 개발하는 다양한 모델에 대한 혼동이 있습니다. 이 기사에서는 이러한 용어들을 보다 실용적인 방식으로 자세히 살펴보았습니다.

기술 관점에서 서로 다른 테넌시 모델 이해하기#

단일 테넌트 아키텍처#

단일 테넌트 아키텍처는 소프트웨어 또는 클라우드 컴퓨팅 모델로, 각 고객 또는 테넌트가 애플리케이션 또는 서비스의 전용 인스턴스를 갖는 것입니다. B2B 비즈니스 모델의 기원을 살펴보면, 각 소프트웨어 인스턴스가 단 하나의 고객 또는 조직을 위해 제공되기 시작합니다.

특성#

• 격리: 각 고객 또는 테넌트는 전용 리소스, 데이터베이스 및 구성을 갖춘 고립된 환경에서 운영됩니다.
• 맞춤화: 단일 테넌트 아키텍처는 종종 특정 고객 요구를 충족시키기 위해 더 큰 맞춤화와 유연성을 허용합니다.
• 보안: 향상된 보안 및 데이터 프라이버시, 고객 데이터가 다른 테넌트와 혼합되지 않습니다.
• 확장성: 각 테넌트의 인스턴스를 독립적으로 조정할 수 있으므로 리소스와 용량을 쉽게 확장할 수 있습니다.
• 유지보수: 하나의 테넌트 환경에서 변경이 다른 테넌트에 영향을 미치지 않기 때문에 독립적인 유지보수 및 업데이트가 가능합니다.
• 비용: 각 테넌트에 대해 별도의 인스턴스를 유지해야 하는 필요 때문에 보통 더 높은 인프라 및 운영 비용이 발생합니다.

예#

• 전용 호스팅: 전통적인 웹 호스팅 제공자는 각 클라이언트가 자체 리소스, 데이터베이스 또는 구성을 얻는 단일 테넌트 아키텍처를 제공합니다.
• 온프레미스 소프트웨어: 고객 관계 관리(CRM) 또는 인적 자원 관리 시스템(HRMS)과 같은 일부 엔터프라이즈급 소프트웨어 애플리케이션은 엄격한 데이터 보안 및 맞춤화 요구 사항을 가진 조직을 위해 단일 테넌트 배포 옵션을 제공합니다.
• 프리미엄 등급이 있는 SaaS: 일부 소프트웨어 서비스(SaaS) 제품에서는 프리미엄 또는 엔터프라이즈 등급이 향상된 보안, 규정 준수 또는 맞춤화를 요구하는 고객을 위한 단일 테넌트 옵션을 제공합니다.

단일 테넌트 아키텍처는 규정 준수가 매우 중요하거나 맞춤형 보안 요구 사항이 필요한 경우 자주 사용됩니다. 예를 들어, 금융, 의료, 정부와 같은 엄격한 규제 요구 사항이 있는 산업에서는 규정 준수를 보장하기 위해 단일 테넌트 솔루션을 선호합니다.

그러나 단일 테넌트 아키텍처는 다중 테넌트 아키텍처에 비해 더 많은 리소스를 소모하고 관리가 복잡할 수 있음을 유의하는 것이 중요합니다. 결과적으로, 더 적지만 더 큰 고객을 보유한 애플리케이션이나 맞춤화와 격리가 중요한 경우에 더 적합할 수 있습니다.

다중 테넌트 아키텍처#

소프트웨어 다중 테넌시는 한 대의 서버에서 소프트웨어 인스턴스 하나가 여러 테넌트를 서비스하는 소프트웨어 아키텍처입니다. 이렇게 설계된 시스템은 "전용" 또는 "고립"되지 않고 "공유"됩니다. 테넌트는 소프트웨어 인스턴스에 대한 특정 권한을 가진 공통 액세스를 공유하는 사용자 그룹입니다. 다중 테넌트 아키텍처에서는 소프트웨어 애플리케이션이 각 테넌트에게 인스턴스(데이터, 구성, 사용자 관리, 테넌트 개별 기능 및 비기능 요구 사항을 포함하여)의 전용 부분을 제공하도록 설계됩니다. -- 위키백과

특성#

• 공유 리소스: 여러 테넌트가 서버, 데이터베이스, 네트워크 리소스를 포함한 동일한 인프라를 공유하여 리소스 활용을 최적화합니다.
• 격리: 테넌트의 데이터 및 구성이 논리적으로 분리되어 데이터 프라이버시와 보안을 보장합니다.
• 규모의 경제: 다중 테넌시는 비용 효율적일 수 있으며, 여러 사용자 간에 오버헤드를 분배하여 운영 및 인프라 비용을 절감합니다.
• 확장성: 증가하는 테넌트와 사용자 수를 수용하기 위해 가로 또는 세로로 확장할 수 있습니다.
• 유지보수: 업데이트 및 유지보수가 단순화되어 모든 테넌트에 균일하게 변경 사항이 적용되어 관리가 용이합니다.
• 맞춤화: 일부 맞춤화가 가능하지만 시스템 전체의 일관성을 유지하기 위해 단일 테넌트 아키텍처에 비해 제한되는 경우가 많습니다.

예#

• 클라우드 기반 SaaS: Google 워크스페이스, Salesforce와 같은 대부분의 소프트웨어 서비스(SaaS) 애플리케이션은 공유 플랫폼에서 여러 조직이나 사용자를 제공하기 위해 다중 테넌시를 사용합니다.
• 공유 호스팅: 웹 호스팅에서, 공유 호스팅 서비스는 동일한 서버에 여러 웹사이트를 호스팅하며, 각각 다른 고객이나 조직에 속합니다.
• 퍼블릭 클라우드 서비스: AWS나 Azure와 같은 퍼블릭 클라우드 제공자는 공유 데이터 센터 내의 고립된 가상화된 리소스를 통해 다양한 클라이언트를 제공합니다.
• 엔터프라이즈 전체 인프라 솔루션: 조직 내 여러 사업 부서가 사용하는 공유 Kubernetes 클러스터와 같은 경우입니다.

현실 세계에서 다중 테넌트 앱 재정의하기#

아키텍처 관점에서 정의를 제공하여 다중 테넌트와 단일 테넌트 디자인을 명확하게 구분했습니다. 그러나 이는 기술적 정의에 더 가깝습니다. 테넌시 모델을 설계할 때 실제 개발 환경에서 이러한 정의를 사용할 경우, 다중 테넌트 앱은 순전히 공유된, 다중 테넌트 인프라를 가져야 한다는 사고방식을 가정합니다.

그러나 비즈니스와 제품은 많은 케이스별 요구 사항을 가지고 있어 만능 해결책은 없습니다.

테넌트가 공유 인프라 리소스를 사용하고 있지만, 특정 비즈니스 요구로 인해 시스템의 한두 부분이 그들에게만 전적으로 전담되어야 하는 시나리오를 상상해 보세요. 이러한 전담되는 부분은 데이터베이스, 인스턴스 또는 기타 구성 요소의 조합일 수 있으며, 전체 인프라를 공유합니다. 이것이 믹스드 테넌트 아키텍처가 필요한 곳입니다.

실용적인 SaaS 제품 개발에서는 주로 일반적인 다중 테넌시 모델로 설계된 제품을 만나게 되는 경우가 흔합니다. 그러나 아키텍처나 일부 리소스의 특정 측면은 "단일 테넌시" 접근 방식으로 나아갈 수 있습니다.

AWS는 이 개념을 전달하기 위해 다음과 같은 사례를 사용했습니다: 다중 테넌시는 광범위한 개념이며, 공유 리소스와 데이터 격리를 달성하려는 목표를 정의하기 위한 적절한 전략을 케이스별로 결합하고 선택합니다.

다시 말해, 많은 사람들은 여전히 이 모델을 "다중 테넌시"라고 부르기도 하지만, 다중 테넌시 전체의 정의에서는 솔루션의 모든 구성 요소가 공유되어야 한다는 것을 암시하지 않습니다. 오히려 솔루션의 적어도 일부 구성 요소가 여러 테넌트 간에 재사용됨을 나타냅니다.

이 용어를 넓게 이해함으로써 클라이언트의 필요와 출발점을 더 잘 이해할 수 있습니다.

단일 아키텍처 모델에 갇히기보다 다중 테넌시는 실제 세계에서 SaaS 제품의 아키텍처의 실용성을 반영합니다. 우리는 다중 테넌트 앱을 언급할 때 애플리케이션이 한 가지 아키텍처 모델을 고수한다는 것을 반드시 의미하는 것은 아닙니다. 다양한 테넌시 전략을 사용할 수 있으며, 적어도 그 일부 구성 요소가 공유된다는 것을 보여줍니다.

테넌시 모델 전략을 결정하기 위한 주요 고려 사항#

여기서 질문이 나옵니다. 내 제품에 대한 테넌시 전략을 어떻게 제안할 수 있을까요? 생각해야 할 중요한 질문은 다음과 같습니다:

• 비즈니스 목표는 무엇인가요?
• 단일 테넌트 솔루션이 귀하의 미래 성장 계획을 지원할 수 있나요?
• 운영 팀의 규모는 얼마나 크며, 인프라 관리를 얼마나 자동화할 수 있나요? 민첩성과 비용 효율성을 신경 쓰나요?
• 고객이 다양한 다중 테넌시 옵션에 편안하나요?
• 각 옵션이 귀하와 고객 모두에게 얼마나 규정 준수에 영향을 미치나요?
• 서비스 수준 계약(SLA)을 충족하거나 특정 서비스 수준 목표(SLO)를 목표로 하고 있나요?
• 보안, 비용, 성능, 신뢰성 및 개별 테넌트 요구에 대한 반응성을 전체적으로 고려했나요?

제품에서 순전히 다중 테넌트 또는 단순히 단일 테넌트 모델을 선택해야 하는 엄격한 구분이 없다는 점을 기억하십시오. 귀하의 결정은 제품의 아키텍처 구성 요소를 어떻게 나누느냐와 고객이나 비즈니스에 필요한 특정 격리 수준에 따라 다릅니다. 그런 다음 각기 다른 접근 방식을 적용할 수 있습니다.

다음#

우리는 "새로운" 다중 테넌트 앱의 정의에 대해 이야기했지만, 테넌트 격리, 정체성, 그리고 너의 정체성이 고립되어야 하는지 여부를 어떻게 결정하나요? "고립된" 정체성이란 무엇을 의미하나요?

실제 환경에서 한 명의 사용자가 두 개의 다른 정체성을 갖는 상황에서 혼란이 자주 발생합니다. 이러한 상황을 "정체성 고립"으로 레이블을 붙이는 것이 적절한가요?

이 질문들은 곧 다가올 우리의 시리즈 기사에서 다루어지겠습니다. 계속 지켜봐 주세요!