멀티테넌시

Multitenancy

소프트웨어 멀티 테넌시(Multi-tenancy)는 단일 소프트웨어 인스턴스가 서버에서 실행되고 여러 테넌트를 서비스하는 소프트웨어 아키텍처다. 그러한 방식으로 설계된 시스템은 ("전용" 또는 "단절"이 아닌) "공유"된다. 테넌트는 소프트웨어 인스턴스에 대한 특정 권한으로 공통 액세스를 공유하는 사용자 그룹이다. 멀티테넌트 아키텍처를 사용하는 소프트웨어 애플리케이션은 데이터, 구성, 사용자 관리, 테넌트 개별 기능 및 비기능 속성을 포함한 인스턴스의 전용 공유를 모든 테넌트에 제공하도록 설계된다. 멀티 테넌시(Multi-tenancy)는 별도의 소프트웨어 인스턴스가 서로 다른 테넌트를 대신하여 작동하는 멀티인스턴스 아키텍처와 대비된다. [1]

일부 의견제출자들은 멀티테넌시를 클라우드 컴퓨팅의 중요한 특징으로 여긴다.[2][3]

입양

멀티테넌트 응용 프로그램 기록

멀티테넌트 애플리케이션은 다음과 같은 세 가지 유형의 서비스로부터 진화하여 몇 가지 특성을 결합하였다.

  1. 시간 공유: 1960년대부터 기업들은 메인프레임 컴퓨터의 공간과 처리 능력(시간 공유)을 임대하여 컴퓨팅 비용을 절감했다. 또한 기존 응용프로그램을 재사용하는 경우가 많았는데, 로그온 화면에 별도의 입력 필드가 있어 고객 계정 ID를 지정할 수 있다. 이 ID를 기반으로, 메인프레임의 회계사들은 실제로 발생한 CPU, 메모리, 디스크/테이프 사용에 대해 개별 고객에게 요금을 청구할 수 있다.
  2. 호스팅된 애플리케이션: 1990년대부터 고객을 대신하여 애플리케이션을 호스팅(당시 존재하는)하는 전통적인 애플리케이션 서비스 제공업체(ASP)가 있었다. 기본 애플리케이션의 한계에 따라 ASP는 별도의 시스템(동일한 물리적 시스템에서 여러 애플리케이션 인스턴스를 실행할 수 없는 경우) 또는 별도의 프로세스로 애플리케이션을 호스팅하도록 강제되었다. 멀티테넌트 애플리케이션은 보다 성숙한 아키텍처를[4] 나타내며, 낮은 운영비로 유사한 서비스를 가능하게 한다.
  3. 웹 애플리케이션: 모든 고객에게 서비스를 제공하는 단일 애플리케이션 인스턴스와 함께 개발된 인기 있는 소비자 지향 웹 애플리케이션(예: Hotmail) 멀티테넌트 애플리케이션은 이 모델로부터 자연적인 진화를 나타내며, 동일한 클라이언트 조직 내의 사용자 그룹에 추가 사용자 정의를 제공한다.

가상화와의 차별화

멀티 테넌시 환경에서 여러 고객은 동일한 운영 체제, 동일한 하드웨어에서 실행되는 동일한 애플리케이션을 동일한 데이터 스토리지 메커니즘으로 공유한다. 고객들 간의 구별은 애플리케이션 설계 중에 이루어지기 때문에, 고객들은 서로의 데이터를 공유하거나 보지 않는다. 각 고객 애플리케이션을 개별 가상 머신에서 실행할 수 있도록 각 구성 요소가 변환되는 가상화와 비교해 보십시오.[5]

경쟁력 차별화

멀티 테넌시(Multi-tenancy) 원칙을 적극적으로 홍보해 경쟁 차별화의 원천으로 활용하는 기업도 있다. 멀티 테넌시(Multi-tenancy)의 사용이 나날이 증가하고 있다.[6]

멀티테넌스의 경제

비용 절감

멀티 테넌시(Multi-tenancy)를 통해 IT 리소스를 단일 운영으로 통합함으로써 달성할 수 있는 규모의 기본 경제 전반에 걸쳐 비용을 절감할 수 있다.[7] 애플리케이션 인스턴스는 특히 고객이 작은 경우 많은 고객이 곱할 때 상당한 양의 메모리와 처리 오버헤드를 유발한다. 멀티 테넌시(Multitenancy)는 이러한 오버헤드를 많은 고객에게 분산시킴으로써 절감한다. 추가 비용 절감은 기본 소프트웨어(운영 체제 및 데이터베이스 관리 시스템 등)의 라이센스 비용에서 발생할 수 있다. 간단히 말해서, 만약 당신이 모든 것을 단일 소프트웨어 인스턴스에서 실행할 수 있다면, 당신은 하나의 소프트웨어 라이센스만 구입하면 된다. 수요가 증가함에 따라 단일 인스턴스를 확장하는 어려움으로 비용 절감 효과를 줄일 수 있음 - 단일 서버에서 인스턴스의 성능을 높이는 것은 빠른 CPU, 더 많은 메모리, 더 빠른 디스크 시스템과 같은 더 빠른 하드웨어를 구입해야만 할 수 있으며, 일반적으로 이러한 비용은 여러 서비스 간에 로드가 분할된 경우보다 더 빠르게 증가한다.거의 동일한 총 용량을 가진 [citation needed]er 또한 멀티테넌트 시스템[8] 개발은 더욱 복잡하고, 여러 고객의 데이터가 통신되고 있어 보안 테스트가 더욱 엄격하다.

데이터 집계/데이터 마이닝

벤더/ISV가 멀티 테넌시를 활용하는 가장 강력한 이유 중 하나는 고유한 데이터 통합 이점 때문이다. 다른 데이터베이스 스키마가 잠재적으로 다른 여러 데이터 소스에서 데이터를 수집하는 대신, 모든 고객을 위한 모든 데이터는 단일 데이터베이스 스키마에 저장된다. 따라서 고객 간에 질의 실행, 데이터 마이닝, 동향 파악 등이 훨씬 간단하다. 핵심 멀티 테넌시 요구사항 중 하나가 서비스 제공업체가 고객(tenant) 정보에 액세스하지 못하도록 해야 하기 때문에 이러한 이유가 과도하게 강조되었을 수 있다. 또한 운영 데이터베이스와 마이닝 데이터베이스(일반적으로 워크로드 특성이 다르기 때문에)를 분리하는 것이 일반적이어서 논쟁은 더욱 약화된다.

복잡성

추가적인 사용자 정의 복잡성과 테넌트당 메타데이터를 유지해야 하는 필요성 때문에 멀티테넌트 애플리케이션은 더 큰 개발 노력이 필요하다. 벡터 기반 데이터 시퀀싱, 암호화 가능한 알고리즘 인프라 및 가상화된 제어 인터페이스와 같은 고려사항이 반드시 고려되어야 한다.[9]

불출관리

멀티 테넌시(Multi-tenancy)를 통해 릴리스 관리 프로세스 간소화 전통적인 릴리스 관리 프로세스에서는 코드 및 데이터베이스 변경 사항이 포함된 패키지가 클라이언트 데스크톱 및/또는 서버 머신에 배포되며, 단일 인스턴스의 경우 고객당 하나의 서버 머신이 될 수 있다. 이 패키지는 각 개별 시스템에 설치해야 한다. 멀티테넌트 모델에서는 패키지는 일반적으로 단일 서버에만 설치하면 된다. 이는 릴리즈 관리 프로세스를 크게 단순화하며, 그 규모는 더 이상 고객 수에 의존하지 않는다.

동시에 멀티 테넌시는 새로운 릴리스 버전을 적용함에 내재된 위험과 영향을 증가시킨다. 여러 테넌트를 지원하는 단일 소프트웨어 인스턴스가 있으므로 이 인스턴스의 업데이트는 업데이트를 요청하고 하나의 테넌트에만 유용하더라도 모든 테넌트의 다운타임을 유발할 수 있다. 또한, 새로운 릴리스의 적용으로 인한 일부 버그와 문제는 다른 테넌트의 애플리케이션 개인화 관점에서 나타날 수 있다. 다운타임으로 인해 둘 이상의 테넌트의 시간 사용 일정에 따라 릴리스 적용 순간이 제한될 수 있다.

요구 사항들

사용자 지정

멀티테넌트 애플리케이션은 일반적으로 각 대상 조직의 요구를 지원하기 위한 높은 수준의 사용자 정의가 필요하다. 사용자 정의에는 일반적으로 다음과 같은 측면이 포함된다.

  • 브랜딩: 각 조직이 자신의 기업 브랜딩(흔히 구별되는 "피부"라고 함)과 일치하도록 응용프로그램의 외관과 느낌을 사용자 정의할 수 있도록 허용한다.
  • 워크플로우: 광범위한 잠재 고객이 사용할 워크플로우 차이 수용
  • 데이터 모델 확장: 고객이 애플리케이션에 의해 관리되는 데이터 요소를 특정 요구에 맞게 사용자 정의할 수 있는 확장 가능한 데이터 모델 지원
  • 액세스 제어: 각 클라이언트 조직이 각 사용자에 대한 액세스 권한 및 제한을 독립적으로 사용자 정의할 수 있도록 허용.

서비스 품질

멀티테넌트 애플리케이션은 멀티인스턴스 애플리케이션의 경우 애플리케이션 아래 계층이 제공하는 다중 테넌트 사이의 보안, 건전성 및 성능의[10] 적절한 격리를 제공할 것으로 예상된다.

가상화

멀티 테넌시(Multi-tenancy)를 위한 애플리케이션 재설계 비용은 특히 자사 제품의 사내 단일 테넌트 버전을 계속 제공하는 소프트웨어 공급업체의 경우 상당히 클 수 있다. 그들은 결과적으로 발생하는 모든 비용을 가지고 두 개의 뚜렷한 제품을 지원하도록 강요 받는다.

상당한 아키텍처 변경의 필요성을 제거하는 멀티 테넌시(Multi-tenancy)에 대한 점점 더 실행 가능한 대체 루트는 가상화 기술을 사용하여 하나 이상의 서버에서 격리된 여러 애플리케이션 인스턴스를 호스팅하는 것이다. 실제로 애플리케이션이 가상 어플라이언스로 재패킹되는 경우 동일한 어플라이언스 이미지가 ISV 호스팅, 사내 또는 신뢰할 수 있는 타사 위치에 배포될 수 있으며 시간이 지남에 따라 한 배포 사이트에서 다른 배포 사이트로 마이그레이션될 수도 있다.

참고 항목

참조

  1. ^ Krebs, Rouven (2012). "Architectural Concerns in Multi-tenant SaaS Applications" (PDF). Proceedings of the 2nd International Conference on Cloud Computing and Services Science (CLOSER 2012). Conference on Cloud Computing and Services Science. SciTePress. Archived from the original (PDF) on 21 February 2015. Retrieved 21 February 2015.
  2. ^ Wainewright, Phil (30 October 2010). "Defining the true meaning of cloud". ZDNet. CBS Interactive. Retrieved 17 March 2016. Multi-tenancy. Sharing a single, pooled, operational instance of the entire top-to-bottom infrastructure is more than simply a vendor convenience; it's the only way to really achieve cloud scale.
  3. ^ Wilder, Bill (2012). Cloud Architecture Patterns: Using Microsoft amit. O'Reilly Media, Inc. p. 78. ISBN 9781449357993. In the cloud, multitenant services are standard: data services, DNS services, hardware for virtual machines, load balancers, identity management, and so forth.
  4. ^ SaaS 아키텍처 성숙도 모델이란? 포브스 2019년 11월 20일
  5. ^ [1] 멀티 테넌시(Multi-tenancy)에 대한 어리석은 논쟁
  6. ^ 서비스형 소프트웨어: 그 다음으로 큰 컴퓨터월드 2006년 3월 23일
  7. ^ "Web-to-Print Technology, Recuce Costs, Increase Sales, Integration with Salesforce and Metrix". Presscentric.com. Retrieved 20 January 2014.
  8. ^ "Building SaaS App with Codeigniter MVC". Computer Technology News Blog. Retrieved 5 May 2016.
  9. ^ Aulbach, S (2011). "Extensibility and data sharing in evolving multi-tenant databases". 2011 IEEE 27th International Conference on Data Engineering: 99–110. doi:10.1109/ICDE.2011.5767872. ISBN 978-1-4244-8959-6. S2CID 17242970.
  10. ^ Zeng, Jiaan (2014). Multi-Tenant Fair Share in NoSQL Data Stores. 2014 IEEE International Conference on Cluster Computing (CLUSTER). IEEE. doi:10.1109/CLUSTER.2014.6968761.