클라우드 컴퓨팅의 단일 테넌트 대 다중 테넌트 이해

클라우드 컴퓨팅에서 테넌트라는 용어는 스토리지, 서버 및 애플리케이션과 같은 컴퓨팅 리소스의 공유 풀에 액세스할 수 있는 그룹 또는 개별 사용자를 나타냅니다. 리소스는 클라우드 서비스 공급자가 제공합니다.

각 테넌트는 다른 테넌트와 격리되어 서로의 데이터나 리소스에 액세스할 수 없습니다. 여러 테넌트가 자신의 개인 정보 보호 및 보안을 유지하면서 동일한 인프라를 공유할 수 있습니다. 테넌트는 개인, 조직 또는 조직 내의 부서일 수 있습니다.

리소스와 인프라가 하나의 테넌트에만 전용되는 경우 이러한 아키텍처를 단일 테넌트라고 합니다. 서로 다른 여러 테넌트가 동일한 리소스를 공유하는 경우 이는 다중 테넌트 아키텍처를 나타냅니다.

그러나 단일 테넌트와 다중 테넌트 아키텍처의 차이점은 약간 더 까다롭습니다. 예를 들어 AWS를 클라우드 서비스 공급자로 사용하여 단일 테넌트 아키텍처와 다중 테넌트 아키텍처를 설정할 수 있습니다. 차이점은 세부 사항에 있습니다. 여기 있습니다.

원천: blogs.sap.com

이제 자세히 알아보기 전에 두 아키텍처의 요약을 살펴보겠습니다.

기능단일 테넌트 아키텍처멀티 테넌트 아키텍처리소스 공유다른 사람과 공유되지 않음여러 고객 사이에서 공유사용자 지정높은 사용자 지정 가능제한된 사용자 지정비용일반적으로 더 비쌉니다일반적으로 저렴합니다보안향상된 보안낮은 보안 수준성능예측 가능한 성능확장성 영향유지 관리고객이 리소스를 유지 관리합니다클라우드 공급자가 유지 관리를 처리협업제한된 협업더 큰 협업컴플라이언스특정 규정을 더 잘 준수합니다모든 테넌트에 대한 표준 프로세스

단일 테넌트 아키텍처

단일 테넌트 클라우드 애플리케이션은 단일 고객 또는 조직에 서비스를 제공하고 다른 고객과 공유되지 않는 전용 리소스를 제공하도록 설계되었습니다.

원천: cncf.io

단일 고객 또는 테넌트가 클라우드의 서버, 애플리케이션 또는 인프라에 독점적으로 액세스하는 모델입니다. 이 모델에서 고객은 리소스를 완벽하게 제어하고 특정 요구 사항에 맞게 리소스를 사용자 지정할 수 있습니다. 이는 클라우드 리소스가 해당 고객 전용임을 의미합니다.

이 단일 테넌트는 특정 요구 사항을 충족하도록 리소스를 사용자 지정할 수 있습니다. 이것은 자원에 대한 더 큰 유연성과 제어를 의미합니다.

고객이 전용 리소스에 대해 비용을 지불하기 때문에 일반적으로 다중 테넌트 아키텍처보다 비용이 많이 듭니다.

다음은 AWS 클라우드에서 종단 간 단일 테넌트 아키텍처를 구축할 수 있는 방법의 예입니다.

가상 사설망(VPC)을 생성하여 단일 테넌트의 리소스를 격리합니다. VPC는 네트워크 격리 및 보안을 제공합니다.

IAM(Identity and Access Management)을 사용하여 단일 테넌트의 리소스에 대한 액세스를 관리합니다. IAM은 테넌트가 액세스할 수 있는 리소스를 정의하는 정책을 생성합니다.

Elastic Compute Cloud(EC2)를 사용하여 단일 테넌트에 대한 가상 머신을 프로비저닝합니다. EC2는 특정 구성으로 인스턴스를 생성하고 리소스에 대한 완전한 제어를 제공합니다.

EBS(Elastic Block Store)를 사용하여 가상 머신에 대한 블록 수준 스토리지를 제공합니다.

관계형 데이터베이스 서비스(RDS)를 사용하여 단일 테넌트에 대한 관리형 데이터베이스 서비스를 제공합니다. 테넌트에 대해 격리 및 보안을 제공하는 별도의 데이터베이스 인스턴스를 생성할 수 있습니다.

Amazon S3를 사용하여 이미지, 비디오 및 문서와 같은 정적 자산을 저장합니다. 테넌트만 액세스할 수 있는 테넌트에 대한 별도의 버킷을 생성할 수 있습니다.

Elastic Load Balancer(ELB)를 사용하여 테넌트 전용 리소스 내에서 애플리케이션의 여러 인스턴스 간에 트래픽을 분산합니다.

클라우드 애플리케이션의 예

다음은 단일 테넌트 아키텍처에 사용할 수 있는 가장 잘 알려진 클라우드 애플리케이션 중 일부입니다.

Workday는 고객에게 단일 테넌트 아키텍처를 제공하는 클라우드 기반 인적 자원 및 재무 관리 소프트웨어입니다.
SAP HANA 클라우드 기반 플랫폼.
오라클 클라우드 아키텍처.
전용 리소스가 포함된 IBM Cloud Dedicated는 다른 고객과 공유되지 않습니다.
랙스페이스 프라이빗 클라우드.

단일 테넌트 클라우드 아키텍처의 장점

단일 테넌트 클라우드 아키텍처는 다중 테넌트 아키텍처에 비해 몇 가지 이점이 있습니다.

리소스가 단일 고객 전용이므로 보안이 강화됩니다. 고객은 리소스의 보안을 완벽하게 제어할 수 있습니다. 다중 테넌트 환경에서 잠재적으로 발생할 수 있는 데이터 유출 또는 무단 액세스의 위험을 제거합니다.

더 큰 사용자 정의는 또 다른 이점입니다. 특정 요구 사항을 충족하도록 리소스를 사용자 정의하여 성능과 효율성을 높일 수 있습니다. 또한 소프트웨어 및 하드웨어 선택 측면에서 더 큰 유연성을 갖게 됩니다.

리소스가 단일 고객 전용이므로 예측 가능한 성능. 높은 수준의 성능과 안정성이 필요한 애플리케이션에 중요한 일관된 성능 부하를 기대할 수 있습니다.

리소스가 한 테넌트만을 위한 것이므로 특정 규정 또는 표준을 더 잘 준수합니다.

고객이 필요에 따라 리소스를 확장 또는 축소할 수 있기 때문에 확장성이 향상됩니다.

그러나 단일 테넌트 아키텍처는 일반적으로 다중 테넌트 아키텍처보다 비용이 더 많이 들기 때문에 모든 조직에 최선의 선택은 아닙니다.

단일 테넌트 클라우드 아키텍처의 실제 사용 사례

단일 테넌트 아키텍처에 대한 최상의 사용 사례는 다음과 같습니다.

의료 기관은 높은 수준의 보안 및 개인 정보 보호를 요구하는 HIPAA와 같은 엄격한 규정을 준수해야 합니다. 단일 테넌트 아키텍처를 통해 의료 기관은 리소스를 완벽하게 제어하고 환자와 직원의 요구 사항에 맞는 보안 조치를 구현할 수 있습니다.
금융 기관은 PCI DSS와 같은 엄격한 규정을 준수해야 합니다. 따라서 단일 테넌트 아키텍처는 좋은 솔루션입니다.
정부 조직은 높은 수준의 보안 및 규정 준수를 요구하는 FISMA와 같은 엄격한 규정을 준수해야 합니다.
연구 조직은 리소스에 대해 높은 수준의 사용자 지정 및 성능이 필요한 경우가 많습니다.
전자 상거래 조직은 단일 테넌트 아키텍처의 또 다른 사용 사례입니다. 고객의 변화하는 요구 사항을 충족하기 위해 필요에 따라 리소스를 확장하거나 축소할 수 있습니다.

다중 테넌트 아키텍처

원천: aws.amazon.com

다중 테넌트 아키텍처는 높은 보안 및 사용자 지정 요구 사항보다 비용 절감, 확장성 및 협업을 우선시하는 조직에 가장 적합한 솔루션인 경우가 많습니다.

여러 고객이 클라우드에서 동일한 리소스를 공유합니다. 이는 리소스가 특정 고객 전용이 아니며 모든 고객 간에 공유됨을 의미합니다.
다중 테넌트 아키텍처는 단순히 공유 리소스의 특성으로 인해 일반적으로 단일 테넌트 아키텍처보다 비용이 저렴합니다.
얼마나 많은 사용자 정의를 수행할 수 있는지에 대한 제한이 있습니다. 이는 고도로 맞춤화된 리소스가 필요한 고객에게는 단점이 될 수 있습니다.

다음은 AWS 클라우드에서 종단 간 다중 테넌트 아키텍처를 구축할 수 있는 방법의 예입니다.

각 테넌트의 리소스를 격리할 VPC를 생성합니다. 각 테넌트는 네트워크 격리 및 보안을 제공하는 자체 VPC를 갖게 됩니다.

IAM을 사용하여 각 테넌트의 리소스에 대한 액세스를 관리합니다. IAM은 정책과 각 테넌트가 액세스할 수 있는 리소스를 정의합니다. 테넌트마다 정책이 다를 수 있습니다.

ELB를 사용하여 애플리케이션의 여러 인스턴스에 트래픽을 분산하십시오. 어떤 트래픽이 어떤 테넌트로 가는지 제어합니다.

RDS를 사용하여 각 테넌트에 대한 관리형 데이터베이스 서비스를 제공합니다. 별도의 데이터베이스 권한 및 데이터 콘텐츠를 사용하여 각 테넌트에 대해 별도의 데이터베이스 인스턴스를 만듭니다. 동일한 데이터베이스 클러스터를 사용할 수 있습니다. 이것은 테넌트에게 격리 및 보안을 제공합니다.

Amazon S3를 사용하여 이미지, 비디오 및 문서와 같은 정적 자산을 저장합니다. 테넌트의 버킷에 대한 액세스를 제어할 수 있습니다. 여러 계정 간에 공유하거나 필요한 경우 분리할 수 있습니다.

CloudFront를 사용하여 정적 자산을 사용자에게 배포합니다. 격리 및 보안을 제공하는 각 테넌트에 대해 별도의 배포를 만듭니다.

클라우드 애플리케이션의 예

다음은 다중 테넌트 클라우드 애플리케이션의 몇 가지 실제 예입니다.

Salesforce는 여러 조직이 데이터를 분리하고 안전하게 유지하면서 동일한 인프라를 사용할 수 있도록 하는 클라우드 기반 CRM(고객 관계 관리) 플랫폼입니다.
Dropbox는 여러 사용자가 동일한 파일을 공동 작업할 수 있는 클라우드 기반 파일 저장 및 공유 서비스입니다.
Microsoft Office 365는 여러 사용자가 동일한 문서, 스프레드시트 및 프레젠테이션에서 공동 작업할 수 있는 클라우드 기반 생산성 제품군입니다.
Google Workspace는 Microsoft와 유사한 또 다른 클라우드 기반 생산성 제품군입니다.
AWS는 여러 조직이 데이터를 분리하고 안전하게 유지하면서 동일한 인프라를 사용할 수 있도록 하는 클라우드 기반 인프라 플랫폼입니다.

멀티 테넌트 아키텍처의 장점

다중 테넌트 클라우드 아키텍처에는 몇 가지 특정한 이점이 있습니다.

이 아키텍처는 일반적으로 단일 테넌트 아키텍처보다 저렴합니다. 여러 고객이 리소스를 공유합니다.
확장성 영향이 더 큽니다. 리소스를 함께 공유할 때 고객의 변화하는 요구 사항을 충족하기 위해 필요에 따라 리소스를 확장하거나 축소합니다. 그것은 동시에 그들 모두를 위해 확장될 것입니다.
이 아키텍처는 유지 관리가 덜 필요합니다. 클라우드 공급자는 모든 테넌트에 대해 동일한 리소스를 유지 관리할 책임이 있습니다. 따라서 유지 관리는 한 번만 수행합니다.
고객이 동일한 리소스를 공유하고 있기 때문에 고객 간에 더 큰 협업이 가능합니다. 고객은 프로젝트에서 함께 작업하고 데이터를 보다 효율적으로 공유할 수 있습니다.
이 아키텍처는 표준화를 촉진합니다. 클라우드 공급자는 표준 프로세스 및 절차를 구현하고 모든 테넌트에 동시에 적용할 수 있습니다.

그러나 조직에서 높은 수준의 보안, 규정 준수 또는 사용자 지정이 필요한 경우 다중 테넌트 아키텍처가 최선의 선택이 아닐 수 있습니다. 공유 자원은 이들 모두의 기회를 낮추고 있습니다.

다중 테넌트 아키텍처의 실제 사용 사례

다음은 다중 테넌트 아키텍처에 대한 몇 가지 최상의 사용 사례입니다.

중소기업(SMB)은 예산과 리소스가 제한된 경우가 많기 때문에 다중 테넌트 아키텍처가 매력적인 옵션입니다.
SaaS(Software as a Service) 공급자는 다중 테넌트 아키텍처를 사용하여 여러 고객에게 서비스를 제공합니다.
소셜 미디어 플랫폼에는 높은 수준의 확장성과 협업이 필요합니다. 다중 테넌트 아키텍처를 통해 소셜 미디어 플랫폼은 사용자의 변화하는 요구 사항을 충족하기 위해 필요에 따라 리소스를 확장하거나 축소할 수 있습니다.
교육 기관은 IT 인프라를 위한 비용 효율적인 솔루션이 필요한 경우가 많습니다. 다중 테넌트 아키텍처를 통해 교육 기관은 리소스 비용을 다른 기관과 공유하여 비용을 절감할 수 있습니다.
퍼블릭 클라우드 공급자는 다중 테넌트 아키텍처를 사용하여 여러 고객에게 서비스를 제공합니다.

AWS 클라우드는 어디에 적합합니까?

원천: prod.workshops.aws

위에서 설명한 것처럼 AWS를 단일 및 다중 테넌트 아키텍처로 설정할 수 있습니다.

단일 고객 또는 조직을 위한 전용 인프라를 생성할 수 있습니다. 예를 들어 AWS에는 단일 고객 전용 물리적 서버를 제공하는 EC2 전용 호스트가 있습니다. 이를 통해 고객은 기본 하드웨어를 완벽하게 제어할 수 있습니다.

AWS에는 고객이 AWS 클라우드 내에서 격리된 가상 네트워크를 생성할 수 있는 Virtual Private Cloud(VPC)도 있습니다.

그러나 AWS는 공유 인프라를 생성하는 데 사용할 수 있는 다양한 서비스를 제공할 수 있습니다. 예를 들어 AWS는 여러 고객이 공유할 수 있는 가상 서버를 제공하는 EC2 인스턴스(전용 아님)를 제공합니다. 그런 다음 고유한 개인 정보 보호 및 보안을 유지하면서 동일한 기본 하드웨어 및 인프라를 공유합니다.

또는 Amazon S3와 같은 서비스를 사용하여 여러 고객 간에 동일한 스토리지를 공유할 수 있습니다. 고객은 공유 환경에서 데이터를 저장하고 검색할 수 있습니다.

AWS의 RDS 데이터베이스와 관련하여 다양한 방법으로 설정할 수 있는 옵션이 있습니다. 각 테넌트에 대해 별도의 데이터베이스 인스턴스를 생성할 수 있습니다. 단일 테넌트에 대한 전용 데이터베이스 클러스터 및 인스턴스를 생성할 수도 있습니다.

마지막으로 RDS를 사용하여 여러 테넌트를 위한 공유 데이터베이스 서비스를 생성할 수 있습니다. 그런 다음 이러한 데이터베이스 인스턴스는 여러 테넌트를 지원하며 궁극적으로 사용자 정의 또는 성능 수준을 제한합니다.

즉, 단일 또는 다중 테넌트 아키텍처를 사용할지 여부를 결정하는 것은 플랫폼이 아닙니다. 플랫폼을 구성하고 설정하는 방법에 관한 것입니다.

마지막 말

단일 테넌트와 다중 테넌트 아키텍처 간의 선택은 고객의 특정 요구 사항에 따라 다릅니다. 단일 테넌트 아키텍처는 일반적으로 높은 수준의 보안, 규정 준수 및 사용자 지정이 필요한 조직을 선호합니다. 다중 테넌트 아키텍처는 비용 절감과 확장성을 우선시하는 조직을 선호합니다.

예를 들어 AWS와 같은 클라우드 플랫폼은 시간이 지남에 따라 마음을 바꿀 수 있는 가능성을 제공합니다. 또한 이를 사용하여 각 케이스가 고유한 위치를 갖고 함께 잘 작동하는 하이브리드 환경을 만들 수 있습니다.

다음으로 설명된 클라우드 컴퓨팅의 다중 테넌시를 확인하십시오.