멀티테넌시

소프트웨어 멀티테넌시(software multitenancy)라는 용어는 소프트웨어 아키텍처의 하나를 가리키며, 여기에서 하나의 소프트웨어 인스턴스가 한 대의 서버 위에서 동작하면서 여러 개의 테넌트(tenant)를 서비스한다. 여기에서 테넌트란 소프트웨어 인스턴스에 대해 공통이 되는 특정 접근 권한을 공유하는 사용자들의 그룹이다. 멀티테넌트 구조에서 응용 소프트웨어는 데이터, 구성, 사용자 관리, 테넌트 개별 기능 및 비기능 속성을 포함하여, 모든 테넌트에게 인스턴스의 일부분을 단독적으로 제공하기 위해 설계되어 있다. 멀티테넌시는 개개의 소프트웨어 인스턴스들이 각기 다른 테넌트를 위해 운영되는 멀티인스턴스 구조와는 상반된다.^[1]

일부 평론가들은 멀티테넌시를 클라우드 컴퓨팅의 중요한 기능으로 간주한다.^[2][3]

채택

멀티테넌트 애플리케이션의 역사

멀티테넌트 애플리케이션은 세 가지 유형의 서비스에서 진화하고 일부 특성을 결합하여 발전했다.

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

가상화와의 차별화

멀티테넌시 환경에서 복수의 고객들은 동일한 데이터 스토리지 매커니즘과 함께 동일한 하드웨어의 동일한 운영 체제에서 실행되는 동일한 응용 프로그램을 공유한다. 고객 간의 구별은 응용 프로그램 설계 중에 수행되므로 고객들은 각 고객의 데이터를 보거나 공유하지 못한다. 이는 구성 요소가 이양됨으로써 각 고객 애플리케이션이 별도의 가상 머신에서 구동되는 것처럼 보이게 하는 가상화와 비교된다.^[5]

경쟁적 차별화

일부 기업은 멀티테넌시 원칙을 적극적으로 홍보하고 이를 경쟁 차별화의 원천으로 활용한다. 멀티테넌시의 사용은 나날이 증가하고 있다.^[6]

멀티테넌시의 경제성

비용 절감

멀티테넌시는 IT 자원을 단일 운영으로 통합하여 달성할 수 있는 기본적인 규모의 경제를 넘어선 비용 절감을 가능하게 한다.^[7] 애플리케이션 인스턴스는 일반적으로 특정 양의 메모리와 처리 오버헤드를 발생시키는데, 특히 고객이 소규모인 경우 많은 고객에게 곱해지면 상당할 수 있다. 멀티테넌시는 이 오버헤드를 많은 고객에게 분산시켜 줄인다. 추가 비용 절감은 기본 소프트웨어(예: 운영 체제 및 데이터베이스 관리 시스템)의 라이선스 비용에서 발생할 수 있다. 간단히 말해, 모든 것을 단일 소프트웨어 인스턴스에서 실행할 수 있다면 소프트웨어 사용권 하나만 구매하면 된다. 비용 절감은 수요가 증가함에 따라 단일 인스턴스를 확장하는 어려움으로 인해 가려질 수 있다. 단일 서버에서 인스턴스의 성능을 높이는 것은 더 빠른 하드웨어(예: 빠른 CPU, 더 많은 메모리, 더 빠른 디스크 시스템)를 구매함으로써만 가능하며, 일반적으로 이러한 비용은 거의 동일한 총 용량을 가진 여러 서버 간에 로드가 분할되는 경우보다 빠르게 증가한다. 또한, 멀티테넌트 시스템의 개발은^[8] 더 복잡하며, 여러 고객의 데이터가 혼합되므로 보안 테스트가 더 엄격한다.

복잡성

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

릴리스 관리

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

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

모범 사례

마크 브루커에 따르면, 멀티테넌트 아키텍처에서는 서로 관련 없고 상관관계가 없는 워크로드를 함께 그룹화해야 한다. 이는 서로 다른 요구 사항과 패턴을 가진 다양한 워크로드를 혼합하면 각 워크로드의 패턴이 숨겨지기 때문이다. 워크로드를 그룹화하면 전체 시스템의 피크 대 평균 비율이 줄어든다. 개별 워크로드는 피크 시간 동안 더 많은 리소스를 활용할 수 있으며, 시스템의 전체 비용 구조를 크게 증가시키지 않으므로 궁극적으로 더 많은 비용 효율성을 달성하는 데 도움이 된다. 동일한 애플리케이션, 고객 또는 산업에서 발생하는 여러 워크로드는 단일 워크로드처럼 작동하는 경향이 있다. ^[10]

요구 사항

사용자 정의

멀티테넌트 애플리케이션은 일반적으로 각 대상 조직의 요구 사항을 지원하기 위해 높은 수준의 사용자 정의를 제공해야 한다. 사용자 정의는 일반적으로 다음 측면을 포함한다.

• 브랜딩: 각 조직이 애플리케이션의 모양과 느낌을 기업 브랜딩에 맞게 사용자 정의할 수 있도록 한다(종종 별도의 "스킨"이라고 불림).
• 워크플로: 광범위한 잠재 고객이 사용할 워크플로의 차이를 수용한다.
• 데이터 모델 확장: 애플리케이션이 관리하는 데이터 요소를 고객이 특정 요구 사항에 맞게 사용자 정의할 수 있는 기능을 제공하기 위해 확장 가능한 데이터 모델을 지원한다.
• 접근 제어: 각 클라이언트 조직이 각 사용자에 대한 접근 권한 및 제한을 독립적으로 사용자 정의할 수 있도록 한다.

서비스 품질

멀티테넌트 애플리케이션은 여러 테넌트 간에 적절한 보안, 견고성 및 성능을 제공할 것으로 예상되며^[11] 이는 다중 인스턴스 애플리케이션의 경우 애플리케이션 아래 계층에서 제공된다.

가상화

멀티테넌시를 위해 애플리케이션을 재설계하는 비용은 상당할 수 있으며, 특히 온프레미스 단일 테넌트 버전의 제품을 계속 제공하는 소프트웨어 공급업체의 경우 더욱 그렇는다. 결국 그들은 모든 결과 비용과 함께 두 가지 별개의 제품을 지원해야 한다.

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