다음을 통해 공유

다중 테넌트 및 Azure Cosmos DB

  • 아티클

이 문서에서는 다중 테넌트 시스템에 사용할 수 있는 Azure Cosmos DB의 기능을 설명합니다. 다중 테넌트 솔루션에서 Azure Cosmos DB를 사용하는 방법에 대한 지침과 예제를 제공합니다.

다중 테넌트 요구 사항

다중 테넌트 솔루션을 계획할 때 다음 두 가지 주요 요구 사항이 있습니다.

  • 테넌트 간의 강력한 격리를 보장하고 필요한 사용자에 대한 엄격한 보안 요구 사항을 충족하는 데 도움이 됩니다.
  • 테넌트당 저렴한 비용을 유지 관리합니다. 공급자는 애플리케이션을 실행하는 비용이 확장됨에 따라 지속 가능한 상태를 유지하도록 합니다.

이러한 두 요구 사항은 종종 충돌하고 다른 요구 사항보다 우선 순위를 지정해야 하는 절충을 도입할 수 있습니다. 이 문서의 지침은 이러한 요구 사항을 해결하기 위해 수행해야 하는 장단 사항을 더 잘 이해하는 데 도움이 될 수 있습니다. 이 문서는 다중 테넌트 솔루션을 디자인할 때 정보에 입각한 결정을 내릴 수 있도록 이러한 고려 사항을 탐색하는 데 도움이 됩니다.

격리 모델

테넌트 간에 필요한 격리 수준을 결정합니다. Azure Cosmos DB는 다양한 격리 모델을 지원하지만 대부분의 솔루션에서는 다음 전략 중 하나를 사용하는 것이 좋습니다.

  • 테넌트당 파티션 키는 B2C SaaS(Business-to-Consumer Software as a Service) 솔루션과 같은 완전 다중 테넌트 솔루션에 자주 사용됩니다.
  • 테넌트당 데이터베이스 계정은 B2B(Business-to-Business) SaaS 솔루션에 자주 사용됩니다.

가장 적절한 격리 모델을 선택하려면 비즈니스 모델 및 테넌트의 요구 사항을 고려합니다. 예를 들어 비즈니스에서 제품 또는 서비스를 개별 고객에게 직접 판매하는 일부 B2C 모델의 경우 강력한 성능 격리가 우선 순위가 아닐 수 있습니다. 그러나 B2B 모델은 강력한 보안 및 성능 격리의 우선 순위를 지정할 수 있으며 테넌트에 자체 프로비전된 데이터베이스 계정이 필요할 수 있습니다.

다양한 고객 요구에 맞게 여러 모델을 결합할 수도 있습니다. 예를 들어 엔터프라이즈 고객에게 판매하는 B2B SaaS 솔루션을 빌드하고 잠재 신규 고객을 위한 무료 평가판을 제공한다고 가정해 보겠습니다. 강력한 보안 및 격리 보장이 필요한 유료 엔터프라이즈 테넌트에 대해 별도의 데이터베이스 계정을 배포할 수 있습니다. 또한 데이터베이스 계정을 공유하고 파티션 키를 사용하여 평가판 고객을 격리할 수 있습니다.

테넌트당 파티션 키 모델 및 테넌트별 데이터베이스 계정 모델은 다중 테넌트 솔루션에 대한 가장 일반적인 격리 모델입니다. 이러한 모델은 테넌트 격리와 비용 효율성 간에 최상의 균형을 제공합니다.

테넌트당 파티션 키 모델

파티션 키로 테넌트를 격리하는 경우 처리량은 테넌트 간에 공유되고 동일한 컨테이너 내에서 관리됩니다.

참고 항목

RU(요청 단위)는 데이터베이스 작업 또는 쿼리 비용의 논리적 추상화입니다. 일반적으로 처리량이라고 하는 워크로드에 대해 초당 정의된 초당 요청 단위 수(RU/s)를 프로비전합니다.

이점

  • 비용 효율성: 모든 테넌트는 테넌트 ID로 분할되는 하나의 컨테이너에 배치합니다. 이 방법에는 여러 테넌트 간에 RU를 프로비전하고 공유하는 청구 가능한 리소스가 하나만 있습니다. 이 모델은 일반적으로 각 테넌트에 대해 별도의 계정을 갖는 것보다 비용 효율적이고 관리하기 쉽습니다.

  • 간소화된 관리: 관리할 Azure Cosmos DB 계정이 적습니다.

장단점

  • 리소스 경합: 동일한 컨테이너에 있는 테넌트 간 공유 처리량(RU/s)은 사용량이 많은 동안 경합이 발생할 수 있습니다. 이 경합은 테넌트에 워크로드가 높거나 겹치는 경우 시끄러운 인접 문제 및 성능 문제를 일으킬 수 있습니다. 단일 테넌트에서 보장된 RU가 필요하고 처리량을 공유할 수 있는 워크로드에 이 격리 모델을 사용합니다.

  • 제한된 격리: 이 방법은 물리적 격리가 아닌 논리적 격리를 제공합니다. 성능 또는 보안 관점에서 엄격한 격리 요구 사항을 충족하지 못할 수 있습니다.

  • 유연성 감소: 파티션 키 또는 데이터베이스 또는 컨테이너로 격리하는 경우 각 테넌트에 대해 지역 복제, 지정 시간 복원 및 고객 관리형 키와 같은 계정 수준 기능을 사용자 지정할 수 없습니다.

다중 테넌트용 Azure Cosmos DB 기능

  • 처리량 제어: 파티션 키를 사용하여 테넌트를 격리할 때 시끄러운 인접 문제를 제어하는 데 도움이 되는 기능을 살펴봅니다. Java SDK에서 처리량 재할당, 버스트 용량 및 처리량 제어와 같은 기능을 사용합니다.

  • 계층적 파티션 키: 각 논리 파티션의 크기가 최대 20GB까지 증가할 수 있도록 Azure Cosmos DB를 사용합니다. 20GB 이상의 데이터를 저장해야 하는 단일 테넌트가 있는 경우 여러 논리 파티션에 데이터를 분산하는 것이 좋습니다. 예를 들어 단일 파티션 키를 Contoso갖는 대신 테넌트에 대한 여러 파티션 키(예: Contoso1 Contoso2및 )를 만들어 파티션 키를 배포할 수 있습니다.

    테넌트에 대한 데이터를 쿼리할 때 절을 WHERE IN 사용하여 모든 파티션 키를 일치시킬 수 있습니다. 계층적 파티션 키를 사용하여 테넌트 카디널리티가 높은 경우 큰 테넌트에 20GB보다 큰 스토리지를 제공할 수도 있습니다. 이 메서드에 대해 테넌트당 가상 파티션 키 또는 여러 파티션 키 값을 사용할 필요가 없습니다.

    파티션 키로 테넌트를 격리하는 워크로드가 있다고 가정합니다. 한 테넌트인 Contoso는 다른 테넌트보다 더 크고 쓰기가 많으며 계속해서 크기가 커집니다. 이 테넌트에 대한 더 많은 데이터를 수집하지 못할 위험을 방지하기 위해 계층적 파티션 키를 사용할 수 있습니다. 첫 번째 수준 키로 지정 TenantID 한 다음 , 같은 두 번째 수준을 추가합니다 UserId. 20GB 제한을 초과하는 논리 파티션을 생성하기 위해 조합 및 UserID 조합을 예상 TenantID 하는 경우 다음과 같은 SessionID다른 수준으로 더 아래로 분할할 수 있습니다. 둘 중 하나 TenantID 또는 둘 다를 TenantID 지정하고 UserID 관련 데이터가 포함된 실제 파티션의 하위 집합으로만 효과적으로 라우팅되는 쿼리는 전체 팬아웃 쿼리를 방지합니다. 컨테이너에 1,000개의 실제 파티션이 있지만 특정 TenantId 값이 5개의 실제 파티션에만 있는 경우 쿼리는 더 적은 수의 관련 실제 파티션으로 라우팅됩니다.

    첫 번째 수준에 카디널리티가 충분히 높지 않고 파티션 키에 대한 20GB 논리 파티션 제한에 도달하는 경우 계층적 파티션 키 대신 가상 파티션 키를 사용하는 것이 좋습니다.

테넌트별 데이터베이스 계정 모델

데이터베이스 계정으로 테넌트를 격리하는 경우 각 테넌트에는 데이터베이스 수준 또는 컨테이너 수준에서 프로비전된 자체 처리량이 있습니다.

이점

  • 높은 격리: 이 방법은 고유한 테넌트당 RU를 프로비전한 전용 Azure Cosmos DB 계정 및 컨테이너로 인해 경합 또는 간섭을 방지합니다.

  • SLA(사용자 지정 서비스 수준 계약): 각 테넌트에는 자체 계정이 있으므로 처리량을 위해 각 테넌트의 데이터베이스 계정을 독립적으로 조정할 수 있으므로 특정 맞춤형 리소스, 고객 관련 SLA 및 보증을 제공할 수 있습니다.

  • 향상된 보안: 물리적 데이터 격리는 고객이 테넌트당 계정 수준에서 고객 관리형 키를 사용하도록 설정할 수 있으므로 강력한 보안을 보장하는 데 도움이 됩니다. 각 테넌트의 데이터는 동일한 컨테이너에 있지 않고 계정에 의해 격리됩니다.

  • 유연성: 테넌트는 필요에 따라 지역 복제, 지정 시간 복원 및 고객 관리형 키와 같은 계정 수준 기능을 사용하도록 설정할 수 있습니다.

장단점

  • 관리 강화: 이 방법은 여러 Azure Cosmos DB 계정을 관리하기 때문에 더 복잡합니다.

  • 높은 비용: 계정이 많을수록 각 테넌트의 계정 내에서 데이터베이스 또는 컨테이너와 같은 각 리소스에 대한 처리량을 프로비전해야 합니다. 리소스가 RU를 프로비전할 때마다 Azure Cosmos DB 비용이 증가합니다.

  • 쿼리 제한 사항: 모든 테넌트는 서로 다른 계정에 있으므로 여러 테넌트 쿼리 애플리케이션에는 애플리케이션 논리 내에서 여러 호출이 필요합니다.

다중 테넌트용 Azure Cosmos DB 기능

  • 보안 기능: 이 모델은 Azure RBAC를 통해 향상된 데이터 액세스 보안 격리를 제공합니다. 또한 이 모델은 고객 관리형 키를 통해 테넌트 수준에서 데이터베이스 암호화 보안 격리를 제공합니다.

  • 사용자 지정 구성: 테넌트의 요구 사항에 따라 데이터베이스 계정의 위치를 구성할 수 있습니다. 또한 지역 복제 및 고객 관리 암호화 키와 같은 Azure Cosmos DB 기능의 구성을 각 테넌트의 요구 사항에 맞게 조정할 수 있습니다.

테넌트당 전용 Azure Cosmos DB 계정을 사용하는 경우 Azure 구독당 Azure Cosmos DB 계정의 최대 수를 고려합니다.

격리 모델 전체 목록

워크로드 필요 테넌트당 파티션 키(권장) 테넌트당 컨테이너(공유 처리량) 테넌트당 컨테이너(전용 처리량) 테넌트당 데이터베이스 테넌트당 데이터베이스 계정(권장)
테넌트 간 쿼리 간편(컨테이너는 쿼리의 경계 역할을 합니다.) 하드 하드 하드 하드
테넌트 밀도 높음(테넌트당 최저 비용) 중간 낮음 낮음 낮음
테넌트 데이터 삭제 쉬움 간편(테넌트가 떠날 때 컨테이너 삭제) 간편(테넌트가 떠날 때 컨테이너 삭제) 간편(테넌트가 떠날 때 데이터베이스 삭제) 간편(테넌트가 떠날 때 데이터베이스 삭제)
데이터 액세스 보안 격리 애플리케이션 내에서 구현해야 합니다. 컨테이너 RBAC 컨테이너 RBAC 데이터베이스 RBAC RBAC
지역에서 복제 테넌트별 지역 복제 불가능 요구 사항에 따라 데이터베이스 계정 내에서 테넌트 그룹화 요구 사항에 따라 데이터베이스 계정 내에서 테넌트 그룹화 요구 사항에 따라 데이터베이스 계정 내에서 테넌트 그룹화 요구 사항에 따라 데이터베이스 계정 내에서 테넌트 그룹화
노이지 네이버 방지 아니요 아니요 예 예 예
새 테넌트 만들기 대기 시간 직접 실행 빠름 빠름 중간 느림
데이터 모델링 이점 None 엔터티 공동 배치 엔터티 공동 배치 테넌트 엔터티를 모델링하는 여러 컨테이너 테넌트를 모델링하는 여러 컨테이너 및 데이터베이스
암호화 키 모든 테넌트에서 동일 모든 테넌트에서 동일 모든 테넌트에서 동일 모든 테넌트에서 동일 테넌트당 고객 관리형 키
처리량 요구 사항 >테넌트당 0RU >테넌트당 100RU >테넌트당 100RU(자동 크기 조정만 사용, 그렇지 않은 경우 >테넌트당 400RU) >테넌트당 400RU >테넌트당 400RU
사용 사례 B2C 앱 B2B 앱용 표준 제안 B2B 앱용 프리미엄 제안 B2B 앱용 프리미엄 제안 B2B 앱용 프리미엄 제안

테넌트별 컨테이너 모델

각 테넌트에 대한 전용 컨테이너를 프로비전할 수 있습니다. 전용 컨테이너는 테넌트에 대해 저장하는 데이터를 단일 컨테이너로 결합할 수 있는 경우에 적합합니다. 이 모델은 테넌트당 파티션 키 모델보다 더 큰 성능 격리를 제공합니다. 또한 Azure RBAC를 통해 향상된 데이터 액세스 보안 격리를 제공합니다.

각 테넌트에 컨테이너를 사용하는 경우 데이터베이스 수준에서 처리량을 프로비전하여 다른 테넌트와 처리량을 공유하는 것이 좋습니다. 데이터베이스의 최소 RU 수와 데이터베이스의 최대 컨테이너 수에 대한 제한 사항과 제한을 고려합니다. 또한 테넌트에 보장된 수준의 성능이 필요한지 여부와 노이즈 이웃 문제에 취약한지 여부를 고려합니다. 데이터베이스 수준에서 처리량을 공유하는 경우 모든 컨테이너의 워크로드 또는 스토리지는 상대적으로 균일해야 합니다. 그렇지 않으면 하나 이상의 큰 테넌트가 있는 경우 시끄러운 인접 문제가 있을 수 있습니다. 필요한 경우 워크로드 패턴을 기반으로 하는 다른 데이터베이스로 이러한 테넌트의 그룹화 계획을 세워야 합니다.

또는 각 컨테이너에 대해 전용 처리량을 프로비전할 수 있습니다. 이 방법은 더 큰 테넌트 및 시끄러운 인접 문제의 위험이 있는 테넌트에 적합합니다. 그러나 각 테넌트에 대한 기준 처리량이 더 높으므로 이 모델의 최소 요구 사항 및 비용 영향을 고려하세요.

테넌트 데이터 모델에 둘 이상의 엔터티가 필요하고 모든 엔터티가 동일한 파티션 키를 공유할 수 있는 경우 동일한 컨테이너에 공동 배치할 수 있습니다. 그러나 테넌트 데이터 모델이 더 복잡하고 동일한 파티션 키를 공유할 수 없는 엔터티가 필요한 경우 테넌트당 데이터베이스 또는 테넌트별 데이터베이스 계정 모델을 고려합니다. 자세한 내용은 Azure Cosmos DB의 모델 및 파티션 데이터를 참조 하세요.

컨테이너를 테넌트에 헌정하는 경우 일반적으로 수명 주기 관리가 더 간단합니다. 공유 및 전용 처리량 모델 간에 테넌트를 쉽게 이동할 수 있습니다. 테넌트를 프로비전 해제하면 컨테이너를 빠르게 삭제할 수 있습니다.

테넌트별 데이터베이스 모델

동일한 데이터베이스 계정의 각 테넌트에 대해 데이터베이스를 프로비전할 수 있습니다. 테넌트별 컨테이너 모델과 마찬가지로 이 모델은 테넌트당 파티션 키 모델보다 성능 격리를 더 크게 제공합니다. 또한 Azure RBAC를 통해 향상된 데이터 액세스 보안 격리를 제공합니다.

테넌트별 계정 모델과 마찬가지로 이 방법은 최고 수준의 성능 격리를 제공하지만 가장 낮은 테넌트 밀도를 제공합니다. 각 테넌트에서 테넌트별 컨테이너 모델에서 실현 가능한 것보다 더 복잡한 데이터 모델이 필요한 경우 이 옵션을 사용합니다. 또는 새 테넌트 생성이 빠르고 오버헤드가 없어야 하는 경우 이 방법을 따릅니다. 일부 소프트웨어 개발 프레임워크의 경우 테넌트별 데이터베이스 모델은 프레임워크에서 지원하는 유일한 수준의 성능 격리일 수 있습니다. 이러한 프레임워크는 일반적으로 엔터티(컨테이너) 수준 격리 및 엔터티 공동 배치를 지원하지 않습니다.

다중 테넌트를 지원하는 Azure Cosmos DB의 기능

분할

Azure Cosmos DB 컨테이너와 함께 파티션을 사용하여 여러 테넌트가 공유하는 컨테이너를 만듭니다. 일반적으로 테넌트 식별자를 파티션 키로 사용하지만 단일 테넌트에 여러 파티션 키를 사용하는 것도 고려할 수 있습니다. 잘 계획된 분할 전략은 분할 패턴을 효과적으로 구현합니다. 큰 컨테이너가 있는 경우 Azure Cosmos DB는 테넌트를 여러 실제 노드에 분산하여 높은 수준의 규모를 달성합니다.

다중 테넌트 솔루션의 성능을 향상시키는 데 도움이 되도록 계층적 파티션 키를 고려합니다. 계층적 파티션 키를 사용하여 여러 값을 포함하는 파티션 키를 만듭니다. 예를 들어 높은 카디널리티 GUID와 같은 테넌트 식별자를 포함하는 계층적 파티션 키를 사용하여 거의 바인딩되지 않은 크기를 허용할 수 있습니다. 또는 쿼리에서 자주 사용하는 속성을 포함하는 계층적 파티션 키를 지정할 수 있습니다. 이 방법을 사용하면 파티션 간 쿼리를 방지할 수 있습니다. 계층적 파티션 키를 사용하여 파티션 키 값당 20GB의 논리 파티션 제한을 초과하여 크기를 조정하고 비용이 많이 드는 팬아웃 쿼리를 제한합니다.

자세한 내용은 다음 리소스를 참조하세요.

RU 관리

Azure Cosmos DB 가격 책정 모델은 프로비전하거나 사용하는 RU/s 수를 기반으로 합니다. Azure Cosmos DB는 처리량을 프로비전하는 몇 가지 옵션을 제공합니다. 다중 테넌트 환경에서 선택은 Azure Cosmos DB 리소스의 성능과 가격에 영향을 줍니다.

보장된 성능 및 보안 격리가 필요한 테넌트에서는 데이터베이스 계정으로 테넌트 격리를 수행하고 테넌트에 RU를 할당하는 것이 좋습니다. 덜 엄격한 요구 사항이 있는 테넌트에서는 파티션 키로 테넌트 격리를 권장합니다. 이 모델을 사용하여 테넌트 간에 RU를 공유하고 테넌트당 비용을 최적화합니다.

Azure Cosmos DB에 대한 대체 테넌트 모델에는 공유 데이터베이스 내의 각 테넌트에 대해 별도의 컨테이너를 배포하는 작업이 포함됩니다. Azure Cosmos DB를 사용하여 모든 컨테이너가 RU를 공유할 수 있도록 데이터베이스에 대한 RU를 프로비전합니다. 테넌트 워크로드가 일반적으로 겹치지 않는 경우 이 방법이 운영 비용을 줄이는 데 유용할 수 있습니다. 그러나 이 방법은 단일 테넌트의 컨테이너가 프로비전된 공유 RU의 불균형 금액을 소비할 수 있기 때문에 시끄러운 인접 문제에 취약합니다. 이 문제를 완화하려면 먼저 시끄러운 테넌트 식별합니다. 그런 다음, 특정 컨테이너에 프로비전된 처리량을 선택적으로 설정할 수 있습니다. 데이터베이스의 다른 컨테이너는 처리량을 계속 공유하지만 노이지 테넌트는 자체 전용 처리량을 사용합니다.

또한 Azure Cosmos DB는 간헐적이거나 예측할 수 없는 트래픽이 있는 워크로드에 적합한 서버리스 계층을 제공합니다. 또는 자동 크기 조정을 사용하여 프로비전된 처리량의 크기 조정을 지정하는 정책을 구성할 수 있습니다. Azure Cosmos DB 버스트 용량을 활용하여 프로비전된 처리량 용량의 사용량을 최대화할 수도 있습니다. 그렇지 않으면 속도 제한에 의해 제한됩니다. 다중 테넌트 솔루션에서는 이러한 모든 방법을 결합하여 다양한 유형의 테넌트를 지원할 수 있습니다.

참고 항목

Azure Cosmos DB 구성을 계획할 때 서비스 할당량 및 제한을 고려 합니다.

각 테넌트와 연결된 비용을 모니터링하고 관리하려면 Azure Cosmos DB API를 사용하는 모든 작업에 사용된 RU가 포함되어 있습니다. 이 정보를 사용하여 각 테넌트가 사용하는 실제 RU를 집계하고 비교할 수 있습니다. 그런 다음 성능 특성이 다른 테넌트 식별할 수 있습니다.

자세한 내용은 다음 리소스를 참조하세요.

고객 관리형 키

일부 테넌트는 자체 암호화 키를 사용해야 할 수 있습니다. Azure Cosmos DB는 고객 관리형 키 기능을 제공합니다. Azure Cosmos DB 계정 수준에서 이 기능을 적용합니다. 따라서 테넌트에 자체 암호화 키가 필요한 경우 전용 Azure Cosmos DB 계정을 사용하여 테넌트 배포를 수행해야 합니다.

자세한 내용은 Azure Key Vault를 사용하여 Azure Cosmos DB 계정에 대한 고객 관리형 키 구성을 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

  • Tara Bhatia | 프로그램 관리자, Azure Cosmos DB
  • Paul Burpo | 주요 고객 엔지니어, FastTrack for Azure
  • John Downs | 소프트웨어 수석 엔지니어

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

다음에서 다중 테넌트 및 Azure Cosmos DB에 대해 자세히 알아보세요.

다른 Azure Cosmos DB 아키텍처 시나리오 중 일부를 참조하세요.