솔루션에서 테넌트 작업을 고려하는 방법에는 여러 가지가 있습니다. 방법 선택은 테넌트 간에 리소스를 공유하는지 여부와 방법에 따라 달라집니다. 직관적으로 리소스를 공유 하지 않으려는 경우 비즈니스 규모가 확장되고 더 많은 테넌트가 등록되면 이러한 접근 방식이 빠르게 비용이 많이 듭니다.
다양한 다중 테넌트 모델을 고려할 때 먼저 조직의 테넌트 정의 방법, 비즈니스 드라이버 및 솔루션 크기 조정 계획을 고려하는 것이 좋습니다. 이 문서에서는 기술 의사 결정자가 테넌시 모델 및 해당 장단을 평가하는 데 도움이 되는 지침을 제공합니다.
테넌트 정의
먼저 조직의 테넌트 정의가 필요합니다. 고객이 누구인지 고려합니다. 즉, 누구에게 서비스를 제공하고 있나요? 두 가지 일반적인 모델은 다음과 같습니다.
- B2B(Business to Business). 고객이 다른 조직인 경우 테넌트는 해당 고객에게 매핑할 수 있습니다. 그러나 고객에게 부서(팀 또는 부서)가 있는지 여부와 여러 국가/지역에 있는지 여부를 고려합니다. 이러한 하위 그룹에 대한 요구 사항이 서로 다른 경우 단일 고객을 여러 테넌트에 매핑해야 할 수 있습니다. 마찬가지로 고객은 두 개의 서비스 인스턴스를 유지 관리하여 개발 및 프로덕션 환경을 서로 분리할 수 있습니다. 일반적으로 단일 테넌트에는 여러 사용자가 있습니다. 예를 들어 고객의 모든 직원은 단일 테넌트 내의 사용자입니다.
- B2C(Business to Consumer). 고객이 소비자인 경우 고객, 테넌트 및 사용자 간의 관계가 더 복잡한 경우가 많습니다. 일부 시나리오에서는 각 소비자가 별도의 테넌트일 수 있습니다. 그러나 가족, 친구 그룹, 클럽, 협회 또는 데이터를 함께 액세스하고 관리해야 할 수 있는 다른 그룹에서 솔루션을 사용할 수 있는지 여부를 고려합니다. 예를 들어 음악 스트리밍 서비스는 개별 사용자와 가족 모두를 지원할 수 있으며 이러한 계정 유형을 테넌트로 구분할 때 각 계정 유형을 다르게 처리할 수 있습니다.
테넌트에 대한 정의는 솔루션을 설계할 때 고려하거나 강조해야 하는 몇 가지 사항에 영향을 줍니다. 예를 들어 다음과 같은 유형의 테넌트가 있다고 생각해 보세요.
- 테넌트가 개인 또는 가족인 경우 개인 데이터를 처리하는 방법과 귀하가 봉사하는 각 관할권 내의 데이터 주권법에 대해 특히 염려해야 할 수 있습니다.
- 테넌트가 비즈니스인 경우 고객의 규정 준수 요구 사항, 데이터 격리 및 가동 시간 또는 서비스 가용성과 같은 지정된 SLO(서비스 수준 목표)를 충족하는지 확인해야 할 수 있습니다.
사용할 모델을 어떻게 결정하나요?
테넌트 모델을 선택하는 것은 단순히 기술적으로 결정하는 것이 아닙니다. 이는 상업적인 결정이기도 합니다. 다음과 같은 질문을 고려해야 합니다.
- 비즈니스 목표는 무엇인가요?
- 고객이 모든 형태의 다중 테넌시를 수락하나요? 각 다중 테넌트 모델은 규정 준수 요구 사항 또는 고객의 규정 준수 요구 사항에 어떤 영향을 미치나요?
- 단일 테넌트 솔루션이 향후 성장 포부에 맞게 스케일링될까요?
- 운영 팀이 얼마나 크고 얼마나 많은 인프라 관리를 자동화할 수 있나요?
- 고객이 SLA(서비스 수준 계약)를 충족할 것으로 예상합니까, 아니면 목표로 하는 SLO가 있나요?
비즈니스가 많은 고객으로 확장되기를 기대하는 경우 공유 인프라를 배포하는 것이 중요합니다. 그렇지 않으면 대규모로 증가하는 리소스 인스턴스를 유지 관리해야 합니다. 각 테넌트에 대한 전용 구독을 프로비전하고 사용하지 않는 한 각 고객에 대해 개별 Azure 리소스를 배포하는 것은 지속 불가능할 수 있습니다. 여러 테넌트 에서 동일한 Azure 구독을 공유하는 경우 Azure 리소스 할당량 및 제한이 적용될 수 있으며 이러한 리소스를 배포하고 재구성하는 운영 비용은 새 고객마다 증가합니다.
반대로, 비즈니스에 소수의 고객만 있을 것으로 예상하는 경우 각 고객 전용 단일 테넌트 리소스를 사용하는 것이 좋습니다. 또한 고객의 격리 요구 사항이 높은 경우 비용이 많이 들더라도 단일 테넌트 인프라 접근 방식이 적절할 수 있습니다.
테넌트 및 배포
다음으로 특정 솔루션에 대한 테넌트 의미와 논리 테넌 트와 배포를 구분해야 하는지 여부를 결정해야 합니다.
예를 들어 음악 스트리밍 서비스를 고려합니다. 처음에는 수천(또는 수만 명)의 사용자를 쉽게 처리할 수 있는 솔루션을 빌드할 수 있습니다. 그러나 계속 성장함에 따라 새로운 고객 수요로 확장하기 위해 솔루션 또는 일부 구성 요소를 복제해야 할 수 있습니다. 즉, 솔루션의 특정 인스턴스에 특정 고객을 할당하는 방법을 결정해야 합니다. 고객을 임의로 또는 지리적으로 할당하거나 단일 인스턴스를 채운 다음 다른 인스턴스(bin 압축)를 시작하여 할당할 수 있습니다. 그러나 트래픽을 올바른 인프라로 라우팅할 수 있도록 고객의 레코드와 해당 데이터 및 애플리케이션을 사용할 수 있는 인프라를 유지 관리해야 할 수 있습니다. 이 예제에서는 각 고객을 별도의 테넌트로 표현한 다음, 데이터를 포함하는 배포에 사용자를 매핑할 수 있습니다. 테넌트와 배포 간에 일대다 매핑이 있으며, 원하는 판단에 따라 배포 간에 테넌트를 이동할 수 있습니다.
반면 법률 회사를 위한 클라우드 소프트웨어를 만드는 회사를 고려해 보세요. 고객은 규정 준수 표준을 유지하기 위해 자체 전용 인프라를 보유해야 할 수 있습니다. 따라서 처음부터 솔루션의 다양한 인스턴스를 배포하고 관리할 준비를 해야 합니다. 이 예제에서 배포에는 항상 단일 테넌트가 포함되며 테넌트는 자체 전용 배포에 매핑됩니다.
테넌트와 배포의 주요 차이점은 격리가 적용되는 방식입니다. 여러 테넌트가 단일 배포(인프라 집합)를 공유하는 경우 일반적으로 각 테넌트의 데이터를 별도로 유지하기 위해 데이터베이스에 있는 애플리케이션 코드 및 테넌트 식별자를 사용합니다. 자체 전용 배포를 사용하는 테넌트가 있는 경우 자체 인프라가 있으므로 코드가 다중 테넌트 환경에서 작동한다는 사실을 인식하는 것이 덜 중요할 수 있습니다.
배포를 상위 테넌트 또는 스탬프라고도 합니다.
특정 테넌트에 대한 요청을 받으면 다음과 같이 해당 테넌트의 데이터를 보유하는 배포에 매핑해야 합니다.
자세한 내용은 테넌트에 대한 맵 요청을 참조 하세요.
테넌트 격리
다중 테넌트 아키텍처 디자인에서 가장 큰 고려 사항 중 하나는 각 테넌트에 필요한 격리 수준입니다. 격리는 다양한 의미를 가질 수 있습니다.
- 애플리케이션의 별도 인스턴스와 각 테넌트에 대한 별도의 데이터베이스가 있는 단일 공유 인프라가 있습니다.
- 몇 가지 일반적인 리소스를 공유하지만 각 테넌트에 대해 다른 리소스를 별도로 유지합니다.
- 별도의 물리적 인프라에 데이터를 유지. 클라우드에서 이 구성에는 각 테넌트에 대해 별도의 Azure 리소스가 필요할 수 있습니다. 극단적인 상황에서는 전용 호스트를 사용하여 별도의 물리적 인프라를 배포하는 것을 의미할 수도 있습니다.
격리를 불연속 속성으로 생각하기보다는 연속체에 있는 것으로 생각해야 합니다. 요구 사항에 따라 동일한 아키텍처의 다른 구성 요소보다 더 또는 덜 격리된 아키텍처 구성 요소를 배포할 수 있습니다. 다음 다이어그램은 격리의 연속체를 보여 줍니다.
격리 수준은 다음을 포함하여 아키텍처의 여러 측면에 영향을 줍니다.
- 보안. 여러 테넌트 간에 인프라를 공유하는 경우 다른 테넌트에 대한 응답을 반환할 때 한 테넌트에서 데이터에 액세스하지 않도록 특히 주의해야 합니다. ID 전략에 대한 강력한 기반이 필요하며 권한 부여 프로세스에서 테넌트 및 사용자 ID를 모두 고려해야 합니다.
- 비용 공유 인프라는 여러 테넌트에서 사용할 수 있으므로 비용이 저렴합니다.
- 성능. 인프라를 공유하는 경우 리소스가 더 빨리 사용될 수 있으므로 더 많은 고객이 인프라를 사용할수록 시스템 성능이 저하될 수 있습니다. 성능 문제는 비정상적인 사용 패턴을 가진 테넌트에 의해 악화될 수 있습니다.
- 신뢰성. 단일 공유 인프라 집합을 사용하는 경우 하나의 구성 요소에 문제가 있으면 모든 테넌트에 중단이 발생할 수 있습니다.
- 개별 테넌트 요구 사항에 대한 응답성. 하나의 테넌트에 전용인 인프라를 배포하는 경우 리소스에 대한 구성을 해당 특정 테넌트의 요구 사항에 맞게 조정할 수 있습니다. 가격 책정 모델에서 이 기능을 고려할 수도 있으므로 고객이 격리된 배포에 대해 더 많은 비용을 지불할 수 있습니다.
솔루션 아키텍처는 격리를 위해 사용 가능한 옵션에 영향을 줄 수 있습니다. 예를 들어 3계층 솔루션 아키텍처를 고려합니다.
- 사용자 인터페이스 계층은 모든 테넌트가 단일 호스트 이름에 액세스하는 공유 다중 테넌트 웹앱일 수 있습니다.
- 중간 계층은 공유 메시지 큐가 있는 공유 애플리케이션 계층일 수 있습니다.
- 데이터 계층은 격리된 데이터베이스, 테이블 또는 Blob 컨테이너일 수 있습니다.
각 계층에서 서로 다른 수준의 격리를 사용하는 것이 좋습니다. Azure 할당량 및 한도에 도달하기 전에 배포할 수 있는 리소스 수, 비용, 복잡성, 고객의 요구 사항, 배포할 수 있는 리소스 수를 포함하여 공유되는 항목과 격리된 항목에 대해 결정해야 합니다.
일반적인 테넌트 모델
요구 사항을 설정한 후 몇 가지 일반적인 테넌트 모델 및 해당 배포 패턴에 대해 평가합니다.
자동화된 단일 테넌트 배포
자동화된 단일 테넌트 배포 모델에서는 다음 예제와 같이 각 테넌트에 대한 전용 인프라 집합을 배포합니다.
애플리케이션은 각 테넌트의 리소스 배포를 시작하고 조정하는 작업을 담당합니다. 일반적으로 이 모델을 사용하는 솔루션은 인프라를 IaC(코드) 또는 Azure Resource Manager API로 광범위하게 사용합니다. 각 고객에 대해 완전히 별도의 인프라를 프로비저닝해야 하는 경우 이 방법을 사용할 수 있습니다. 배포를 계획할 때 배포 스탬프 패턴을 사용하는 것이 좋습니다.
혜택: 이 방법의 주요 이점은 각 테넌트에 대한 데이터가 격리되어 실수로 누출될 위험을 줄일 수 있다는 것입니다. 이 보호 장치는 규정 준수 오버헤드가 높은 일부 고객에게 중요할 수 있습니다. 또한 테넌트는 서로의 시스템 성능에 영향을 줄 가능성이 낮으며, 이 문제를 노이즈 네이버 문제라고도 합니다. 업데이트 및 변경 내용을 테넌트 전체에 점진적으로 롤아웃하여 시스템 전체 가동 중단 가능성을 줄일 수 있습니다.
위험: 이 방법을 사용하는 경우 테넌트 간에 인프라를 공유하지 않으므로 비용 효율성이 낮습니다. 단일 테넌트에 특정 인프라 비용이 필요한 경우 100개의 테넌트에는 해당 비용의 100배가 필요할 수 있습니다. 또한 지속적인 유지 관리(예: 새 구성 또는 소프트웨어 업데이트 적용)는 시간이 오래 걸릴 수 있습니다. 운영 프로세스를 자동화하고 환경을 통해 변경 내용을 점진적으로 적용하는 것이 좋습니다. 또한 전체 플릿의 보고 및 분석과 같은 다른 배포 간 작업을 고려해야 합니다. 마찬가지로 여러 배포에서 데이터를 쿼리하고 조작하는 방법을 계획해야 합니다.
완전 다중 테넌트 배포
반대로 모든 구성 요소가 공유되는 완전 다중 테넌트 배포를 고려할 수 있습니다. 다음 다이어그램과 같이 배포 및 유지 관리할 인프라 집합이 하나뿐이며 모든 테넌트가 이를 사용합니다.
이점: 이 모델은 공유 구성 요소가 있는 솔루션을 운영하는 것이 각 테넌트에 개별 리소스를 사용하는 것보다 저렴하기 때문에 매력적입니다. 증가된 부하를 고려하여 더 높은 계층 또는 리소스 SKU를 배포해야 하는 경우에도 전체 배포 비용은 단일 테넌트 리소스 집합의 비용보다 여전히 낮은 경우가 많습니다. 또한 사용자 또는 테넌트가 데이터를 다른 테넌트로 이동해야 하는 경우 테넌트 식별자와 키를 업데이트할 수 있으며 두 개의 별도 배포 간에 데이터를 마이그레이션할 필요가 없을 수도 있습니다.
위험:
각 테넌트에 대한 데이터를 구분하고 테넌트 간에 데이터를 누출하지 않도록 해야 합니다. 분할 데이터를 관리해야 할 수도 있습니다. 또한 개별 테넌트가 전체 시스템에 미칠 수 있는 영향에 대해 염려해야 할 수도 있습니다. 예를 들어 대규모 테넌트가 많은 쿼리 또는 작업을 수행하려고 하면 다른 테넌트에 영향을 줄 수 있습니다.
Azure 비용을 추적하고 테넌트에 연결하는 방법을 결정합니다( 이렇게 하는 것이 중요한 경우).
하나의 리소스 집합만 업데이트하면 되므로 단일 배포를 사용하면 유지 관리가 더 간단해질 수 있습니다. 그러나 변경 내용이 전체 고객 기반에 영향을 줄 수 있으므로 위험하기도 합니다.
규모를 고려해야 할 수도 있습니다. 공유 인프라 집합이 있는 경우 Azure 리소스 확장 제한에 도달할 가능성이 더 높습니다. 예를 들어 솔루션의 일부로 스토리지 계정을 사용하는 경우 확장이 증가함에 따라 해당 스토리지 계정에 대한 요청 수가 스토리지 계정에서 처리할 수 있는 제한에 도달할 수 있습니다. 리소스 할당량 한도에 도달하지 않도록 리소스의 여러 인스턴스 풀(예: 여러 AKS 클러스터 또는 스토리지 계정)을 배포하는 것이 좋습니다. 여러 Azure 구독에 배포하는 리소스에 테넌트 배포를 고려할 수도 있습니다.
단일 배포의 크기를 조정할 수 있는 정도에는 제한이 있을 수 있으며, 이렇게 하면 비선형으로 비용이 증가할 수 있습니다. 예를 들어 단일 공유 데이터베이스가 있는 경우 매우 높은 규모로 실행하면 처리량을 소진할 수 있으며 수요에 따라 처리량 증가에 대해 더 많은 비용을 지불해야 할 수 있습니다.
수직 분할된 배포
이러한 비늘의 극단 중 하나를 선택할 필요는 없습니다. 대신 다음 방법을 사용하여 테넌트 분할을 세로로 지정할 수 있습니다.
- 단일 테넌트 및 다중 테넌트 배포의 조합을 사용합니다. 예를 들어 다중 테넌트 인프라에는 대부분의 고객의 데이터 및 애플리케이션 계층이 있지만, 더 높은 성능 또는 데이터 격리가 필요한 고객을 위해 단일 테넌트 인프라를 배포할 수 있습니다.
- 솔루션의 여러 인스턴스를 지리적으로 배포하고 각 테넌트를 특정 배포에 매핑합니다. 이 방법은 서로 다른 지역에 테넌트가 있는 경우에 특히 효과적입니다.
다음은 일부 테넌트에 대한 공유 배포 및 다른 테넌트에 대한 단일 테넌트 배포를 보여 주는 예제입니다.
이점: 여전히 일부 인프라를 공유하고 있으므로 공유 다중 테넌트 배포를 사용하면 비용의 이점을 얻을 수 있습니다. 평가판으로 서비스를 평가하는 고객과 같은 특정 고객을 위해 저렴한 공유 리소스를 배포할 수 있습니다. 단일 테넌트 배포를 사용하기 위해 고객에게 더 높은 요금을 청구할 수도 있으므로 일부 비용을 복구하는 데 도움이 됩니다.
위험: 코드베이스는 다중 테넌트 및 단일 테넌트 배포를 모두 지원하도록 설계되어야 합니다. 배포 간 마이그레이션을 허용하려는 경우 고객을 다중 테넌트 배포에서 자체 단일 테넌트 배포로 마이그레이션하는 방법을 고려해야 합니다. 또한 시스템 문제 또는 업그레이드에 대한 정보를 관련 고객에게 전달할 수 있도록 각 배포에 있는 테넌트도 알아야 합니다.
수평 분할된 배포
배포를 수평 분할하는 것도 고려할 수 있습니다. 수평 배포에서는 일부 공유 구성 요소가 있지만 단일 테넌트 배포를 사용하여 다른 구성 요소를 유지 관리합니다. 예를 들어 이 다이어그램과 같이 단일 애플리케이션 계층을 빌드한 다음 각 테넌트에 대한 개별 데이터베이스를 배포할 수 있습니다.
이점: 수평 분할된 배포는 시끄러운 인접 문제를 완화하는 데 도움이 될 수 있습니다. 시스템의 부하 대부분이 특정 구성 요소에 의해 발생한다는 것을 식별하면 각 테넌트에 대해 별도의 구성 요소를 배포할 수 있습니다. 예를 들어 데이터베이스는 쿼리 부하가 높기 때문에 시스템의 부하 대부분을 흡수할 수 있습니다. 단일 테넌트가 솔루션에 많은 수의 요청을 보내는 경우 데이터베이스 성능에 부정적인 영향을 미칠 수 있지만 다른 테넌트의 데이터베이스(및 애플리케이션 계층과 같은 공유 구성 요소)는 영향을 받지 않습니다.
위험: 수평 분할 배포에서는 구성 요소, 특히 단일 테넌트에서 사용하는 구성 요소의 자동화된 배포 및 관리를 고려해야 합니다.
격리 모델 테스트
어떤 격리 모델을 선택하든 솔루션을 테스트하여 한 테넌트의 데이터가 실수로 다른 테넌트에 유출되지 않고 시끄러운 인접 효과가 허용되는지 확인해야 합니다. Azure Chaos Studio를 사용하여 실제 중단을 시뮬레이션하는 오류를 의도적으로 도입하고 구성 요소가 오작동하는 경우에도 솔루션의 복원력을 확인하는 것이 좋습니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- John Downs | 주요 소프트웨어 엔지니어
기타 기여자:
- Chad Kittel | 주 소프트웨어 엔지니어
- Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.
다음 단계
테넌트 수 명 주기 고려