멀티 테넌시 및 Azure Cosmos DB

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

멀티테넌시 요구 사항

다중 테넌트 솔루션을 계획할 때 다음 두 가지 주요 요구 사항을 충족해야 합니다.

  • 테넌트 간의 보안 및 성능 격리를 보장합니다. 공급자는 보안 요구 사항을 충족하고 각 테넌트가 성능 요구 사항을 충족하는지 확인해야 합니다.

  • 각 테넌트에 대해 저렴한 비용을 유지 관리합니다. 공급자는 애플리케이션을 실행하는 비용이 확장됨에 따라 지속 가능한 상태를 유지해야 합니다.

이러한 두 요구 사항은 종종 충돌하며 다른 요구 사항보다 우선 순위를 지정해야 합니다. 이 문서의 지침은 다중 테넌트 솔루션을 설계할 때 이러한 장단 사항을 이해하고 정보에 입각한 결정을 내리는 데 도움이 됩니다.

격리 모델

테넌트 간에 필요한 격리 수준을 결정합니다. 대부분의 솔루션의 경우 워크로드에 따라 다음 전략 중 하나를 사용하는 것이 좋습니다.

  • B2C SaaS(소프트웨어 서비스로서) 솔루션은 일반적으로 각 테넌트에 대해 파티션 키를 사용합니다. 이러한 유형의 솔루션의 한 가지 예는 사용자 채팅 기록을 Azure Cosmos DB 저장하는 대화형 챗봇 애플리케이션입니다.

  • B2B(Business-to-Business) SaaS 솔루션은 일반적으로 각 테넌트에 대해 데이터베이스 계정을 사용합니다. 이러한 유형의 솔루션의 한 가지 예는 기업이 디지털 콘텐츠를 게시하기 위해 구매하는 CMS(콘텐츠 관리 시스템)입니다.

가장 적절한 격리 모델을 선택하려면 비즈니스 모델 및 테넌트의 요구 사항을 고려합니다. 예를 들어 B2C 모델에서 비즈니스는 제품 또는 서비스를 개별 고객에게 직접 판매합니다. 각 개별 고객에 대한 강력한 보안 및 성능 격리는 일반적으로 필요하지 않습니다. 가장 높은 비용 효율성을 위해 이러한 애플리케이션은 동일한 컨테이너에 있는 모든 테넌트에 대한 데이터를 저장할 수 있으며 파티션 키는 논리적 격리를 제공합니다.

그러나 B2B 모델에서 공급자는 다양한 성능 수준, SLA(서비스 수준 계약) 보장 또는 격리 요구 사항에 해당하는 다양한 SKU를 판매합니다. 공급자는 고객에게 자체 암호화 키(테넌트 간 또는 고객 관리형 키라고도 함)를 관리할 수 있는 옵션을 제공하려고 합니다. 이러한 애플리케이션의 경우 각 고객에 대한 성능을 조정하고 보장할 수 있도록 각 테넌트에 대해 별도의 데이터베이스 계정을 사용합니다. 별도의 데이터베이스 계정을 사용하는 경우 고객 관리형 키를 제공할 수도 있습니다. 이 기능은 Azure Cosmos DB 데이터베이스 계정 수준에서만 사용할 수 있습니다.

테넌트당 파티션 키 모델

테넌트당 파티션 키 모델에서 동일한 Azure Cosmos DB 컨테이너는 /TenantId 같은 파티션 키를 사용하여 테넌트에 대한 모든 데이터를 저장합니다. 테넌트는 컨테이너의 처리량을 공유합니다.

참고

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

이점

  • 간소화된 관리: 모든 테넌트는 테넌트 ID가 분할하는 하나의 컨테이너에 배치합니다. 이 방법은 여러 테넌트 간에 RU/s를 프로비전하고 공유하는 청구 가능한 리소스를 하나만 만듭니다. 이 모델은 하나의 RU/s 설정만 전체 다중 테넌트 워크로드에 대한 비용에 영향을 주므로 관리하기 쉽습니다.

균형의 문제 및 고려 사항

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

  • 제한된 격리: 이 방법은 물리적 격리가 아닌 논리적 격리를 제공합니다. 성능 보장이 필요하지 않거나 각 테넌트에 대해 고객이 관리하는 키가 필요하지 않은 워크로드에는 이 격리 모델을 사용합니다.

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

다중 테넌트용 Azure Cosmos DB 기능

Azure Cosmos DB 성능을 최적화하고 다중 테넌트 솔루션에 대한 비용을 관리하는 데 도움이 되는 몇 가지 기능을 제공합니다. 이러한 기능은 시끄러운 인접 문제와 같은 일반적인 문제를 해결하고 테넌트 간에 데이터를 효율적으로 저장하고 쿼리하는 데 도움이 됩니다.

처리량 제어

다음 기능은 파티션 키를 사용하여 테넌트를 격리하거나 동일한 공유 컨테이너를 사용하는 여러 워크로드가 있는 경우 시끄러운 인접 문제를 제어하는 데 도움이 됩니다.

Feature Description
순간 처리 용량 지난 5분 동안 컨테이너의 사용되지 않은 용량을 활용하여 향후 급증에 대비합니다.
우선 순위 기반 실행 요청당 수준에서 높은 우선 순위 또는 낮은 우선 순위를 지정합니다. 컨테이너 수준에서 처리량 경합이 발생하면 우선 순위가 높은 요청의 우선 순위가 지정됩니다. 일괄 처리 작업과 실시간 사용자 요청을 제공하는 API와 같이 여러 워크로드의 성능 요구 사항이 서로 다른 경우 이 기능을 사용합니다.
처리량 버킷(미리 보기) 요청 집합에서 사용할 수 있는 특정 RU/s 비율을 할당합니다. 예를 들어 일괄 처리 작업의 요청은 컨테이너 총 RU/s의 최대 10%만 사용할 수 있지만 중요한 사용자 연결 API는 컨테이너의 총 RU/s 중 최대 100개% 사용할 수 있도록 지정합니다.
처리량 재배포(프리뷰) 이 API를 사용하여 핫 물리적 파티션에 더 많은 RU/s를 할당합니다.

계층적 파티션 키

일반적으로 테넌트별로 쿼리하는 읽기 작업이 많은 워크로드의 경우 계층적 파티션 키를 사용하여 다음과 같은 이점을 달성하는 것이 좋습니다.

  • 각 테넌트에 대한 무제한 스토리지: 각 테넌트에 무제한 스토리지가 보장되도록 첫 번째 수준 키 및 상위 카디널리티 필드(예/TenantId: 두 번째 수준 키)로 설정합니다/id. 워크로드에 다른 계층이 있을 수 있습니다. 예를 들어 각 테넌트에 각 사용자의 데이터를 저장해야 할 수 있습니다. 이 시나리오에서는 테넌트에서 각 사용자에 대해 무제한 스토리지를 보장하기 위해 첫 번째 수준 키/TenantId, 두 번째 수준 키 및 /UserId 세 번째 수준 키로 설정합니다/id.

    참고

    저장 프로시저 및 원자성 일괄 처리 트랜잭션과 같은 Azure Cosmos DB 기능은 전체 논리 파티션 키 수준에서만 사용할 수 있습니다. 계층형 파티션 키를 사용하고 마지막 수준 키로 /id로 파티션할 경우, 저장 프로시저 실행이나 구간 수준에서의 원자성 일괄 처리 트랜잭션을 수행할 수 없습니다.

    예를 들어, /TenantId, /UserId, /id로 분할하는 경우, /TenantId만 지정하거나 /TenantId, /UserId만 지정하여 저장 프로시저를 실행하거나 원자성 배치 트랜잭션을 수행할 수 없습니다. 이러한 기능을 사용해야 하는 경우 마지막 수준 키로 설정 /id 하지 마세요.

  • 효율적인 쿼리:/TenantId 또는 /TenantId와 /UserId을 지정한 쿼리는 관련 데이터를 포함하는 실제 파티션의 일부에만 효율적으로 라우팅되어 전체 팬아웃 쿼리를 방지합니다. 컨테이너에 1,000개의 실제 파티션이 있지만 특정 /TenantId 값이 5개의 실제 파티션에만 있는 경우 쿼리는 더 적은 수의 관련 실제 파티션으로 라우팅됩니다.

값의 카디널리티가 높고 첫 번째 수준 키에 대한 요청 볼륨의 균일한 분포가 있는 경우 계층적 파티션 키를 사용합니다. 다중 테넌트 설정에서는 많은 테넌트가 있어야 하며, 이상적으로는 수백에서 수천 개 이상의 테넌트 순으로 테넌트에 비슷한 사용 패턴이 있어야 합니다.

다음 시나리오에서는 핫 파티션 및 성능 저하가 발생할 수 있습니다.

  • 소수의 테넌트와 함께 일합니다.

  • 계층적 파티션 키를 사용할 때에도 한 테넌트가 다른 테넌트들보다 훨씬 더 많은 RU/s를 지속적으로 사용하는 불균형한 워크로드에 대응합니다.

각 테넌트에 대해 카디널리티가 높지 않거나 쓰기 성능을 최적화해야 하는 워크로드에는 계층적 파티션 키를 사용하지 마세요. 이러한 시나리오에서는 합성 파티션 키를 사용하거나 /id을 통해서만 분할하는 것이 좋습니다. 이러한 접근 방식을 사용하면 모든 실제 파티션에 쓰기를 균등하게 분산할 수 있습니다.

일부 쿼리에 최적화하는 방식으로 가상 키를 생성할 수 있습니다. 예를 들어 가상 키는 TenantId_UserId 모든 파티션에서 데이터의 균일한 분포를 약간 줄이지만 전체 파티션 키를 지정할 때 테넌트에서 특정 사용자를 효율적으로 쿼리할 수 있습니다. 쿼리 최적화는 /id 대신에 가상 키를 사용할 때의 주요 장점입니다.

그러나 워크로드가 쓰기 처리량을 최적화하는 경우 쿼리는 관련이 없을 수 있습니다. 워크로드를 간소화하기 위해서만 /id 분할할 수 있습니다.

다른 테넌트보다 더 높은 요청 볼륨이 지속적으로 필요한 몇 개의 대규모 테넌트를 사용하는 경우 해당 테넌트를 자체 데이터베이스 계정으로 격리하는 것이 좋습니다. 나머지 테넌트를 공유 컨테이너에 유지합니다.

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

테넌트별 데이터베이스 계정 모델에서 각 테넌트의 데이터는 자체 Azure Cosmos DB 데이터베이스 계정에 저장됩니다. 각 계정 내에서 여러 워크로드 또는 마이크로 서비스에 대한 여러 컨테이너가 테넌트에 대한 데이터에 액세스합니다. 각 컨테이너에는 전용 처리량(RU/s)이 있습니다.

이점

  • 고 격리: 이 방법은 각 테넌트의 데이터가 자체 전용 Azure Cosmos DB 계정에 있으므로 경합 또는 시끄러운 인접 문제를 방지합니다. 계정 내의 각 컨테이너에는 전용 RU/s가 있습니다.

  • 사용자 지정 SLA: 각 테넌트에는 고유한 계정이 있으므로 특정 맞춤형 리소스, 고객 관련 SLA 및 보장을 제공할 수 있습니다. 각 테넌트의 데이터베이스 계정에서 리소스를 독립적으로 조정하여 성능 요구 사항을 충족할 수 있기 때문입니다.

  • 향상된 보안: 이 방법을 사용하면 데이터베이스 계정 수준에서 고객 관리형 키를 사용할 수 있으므로 공급자는 각 테넌트에 대해 고객 관리형 키를 제공할 수 있습니다. 고객 관리형 키가 필요한 경우 테넌트별 데이터베이스 계정 격리를 사용해야 합니다.

  • 유연성: 필요에 따라 테넌트별(데이터베이스 계정) 수준에서 지역 복제, 지정 시간 복원 및 고객 관리형 키와 같은 계정 수준 기능을 설정할 수 있습니다.

균형의 문제 및 고려 사항

  • 관리할 더 많은 계정: 이 방법은 각각 테넌트 또는 고객을 나타내는 여러 Azure Cosmos DB 계정이 있기 때문에 더 복잡할 수 있습니다. 그러나 Azure Cosmos DB 플릿을 사용하여 여러 데이터베이스 계정에서 처리량(RU/s)을 공유하여 계정 관리를 간소화할 수 있습니다. 플릿 분석을 사용하여 사용량을 대규모로 모니터링할 수도 있습니다.

  • 테넌트 간 쿼리 제한 사항: 모든 테넌트는 서로 다른 계정에 있으므로 여러 테넌트에 쿼리하는 애플리케이션에는 애플리케이션의 논리 내에서 여러 호출이 필요합니다. 일반적으로 이러한 테넌트 간 쿼리는 각 테넌트에 서비스를 제공하는 핵심 트랜잭션 워크로드의 일부가 아닙니다. 대신 공급자가 다양한 테넌트 또는 고객의 광범위한 추세와 사용량을 이해하는 데 도움이 되는 분석 워크로드의 일부입니다. 이러한 사용 사례의 경우 Microsoft Fabric의 미러링을 사용합니다.

다중 테넌트용 Azure Cosmos DB 기능

워크로드 필요성 테넌트당 파티션 키 모델 테넌트별 데이터베이스 계정 모델
비용 효율성 워크로드에 대해 하나의 컨테이너 RU/s를 최적화합니다. 플릿 풀 내에서 RU/s를 공유하여 비용을 최적화합니다.
새 테넌트 만들기 대기 시간 즉시 즉시, 새 테넌트에 JIT(Just-In-Time) 할당이 있는 빈 데이터베이스 계정을 만드는 경우
테넌트 데이터 삭제 파티션별 삭제 키 기능을 사용하여 테넌트에 대한 모든 데이터를 삭제합니다. 테넌트가 떠날 때 데이터베이스 계정을 삭제합니다.
데이터 액세스 보안 격리 애플리케이션 내에서 격리를 구현해야 합니다. RBAC
지리적 복제 테넌트별 지역 복제는 불가능합니다. 각 데이터베이스 계정에는 사용자 지정 지역을 구성할 수 있습니다.
시끄러운 이웃 방지 아니요 예
암호화 키 모든 테넌트에서 동일 각 테넌트에 대한 고객 관리형 키
처리량 요구 사항 테넌트당 RU가 0보다 많음 테넌트당 100RU 이상
테넌트 간 질의 컨테이너는 쿼리의 경계 역할을 합니다. 분석 쿼리에 Fabric 미러링을 사용합니다.
사용 사례 B2C 앱 B2B 앱에 대한 프리미엄 또는 엔터프라이즈 제품

대부분의 다중 테넌트 시나리오에 대해 테넌트당 파티션 키 및 테넌트별 데이터베이스 계정 격리 모델을 사용하는 것이 좋습니다. 컨테이너 또는 데이터베이스에 의한 격리가 가능하지만 이러한 접근 방식에는 일반적으로 권장되는 격리 모델이 보다 효과적으로 해결하는 절충안이 있습니다.

테넌트별 컨테이너 모델

각 테넌트에 대해 고유한 RU/s가 있는 전용 컨테이너를 프로비전하고 Azure Cosmos DB 데이터베이스 계정에 배치할 수 있습니다. 각 데이터베이스 계정에는 제한된 수의 컨테이너만 포함될 수 있으므로 모든 테넌트에 대한 데이터를 저장하려면 여러 계정이 필요할 수 있습니다. 각 고객에 대한 데이터가 포함된 데이터베이스 계정을 추적해야 하므로 애플리케이션이 복잡해집니다.

Azure Cosmos DB는 메타데이터 작업의 처리량과 각 계정의 데이터베이스 또는 컨테이너 수를 제한합니다. 메타데이터 작업에는 계정의 데이터베이스 또는 컨테이너 목록을 읽고 컨테이너 설정을 읽고 업데이트하는 작업이 포함됩니다. 이러한 제한 때문에 이 모델은 권장하지 않습니다. 단일 계정에 여러 테넌트가 있는 경우 메타데이터 작업의 볼륨이 증가하고 효과적으로 확장되지 않을 수 있습니다. 또한 이 모델을 사용하려면 여러 테넌트의 균형을 맞추기 위해 여러 계정을 관리해야 할 수 있으므로 다중 테넌트 솔루션의 복잡성이 증가합니다.

컨테이너 수준에서 전용 RU/s를 설정하여 테넌트별 컨테이너 모델을 사용하여 각 테넌트에 대한 성능 격리를 달성할 수 있습니다. AZURE RBAC를 사용하여 보안을 강화할 수도 있습니다. 그러나 테넌트별 컨테이너 모델은 고객 관리형 키를 지원하지 않습니다. 고객 관리형 키는 데이터베이스 계정 수준에서만 사용할 수 있습니다.

데이터베이스 계정에 많은 컨테이너가 있고 Azure Cosmos DB 데이터 평면 RBAC를 사용하여 각 컨테이너에 역할을 할당해야 하는 경우 계정당 역할 할당 수에 제한에 도달할 수 있습니다.

성능 격리 또는 고객 관리형 키가 필요한 경우 테넌트별 데이터베이스 계정 모델 및 플릿 풀을 사용하여 각 테넌트에 대한 비용을 최적화하는 것이 좋습니다. 이러한 기능이 필요하지 않은 경우 테넌트당 파티션 키 모델을 사용하는 것이 좋습니다.

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

각 테넌트에 대해 데이터베이스를 프로비전하고 동일한 데이터베이스 계정에 배치할 수 있습니다. 테넌트별 컨테이너 모델과 마찬가지로 테넌트가 속한 데이터베이스 계정을 추적하기 위해 모든 테넌트 및 사용자 지정 애플리케이션 논리에 대한 데이터를 보관하려면 여러 데이터베이스 계정이 필요할 수 있습니다.

데이터베이스 수준에서 공유 RU/s를 설정하거나 각 컨테이너에 대해 전용 RU/s를 설정하여 테넌트별 데이터베이스 모델을 사용하여 각 테넌트에 대한 성능 격리를 달성할 수 있습니다. AZURE RBAC를 사용하여 보안을 강화할 수도 있습니다. 그러나 테넌트별 데이터베이스 모델은 고객 관리형 키를 지원하지 않습니다. 또한 일반적으로 데이터베이스의 각 컨테이너에 대한 성능이 보장되지 않으므로 트래픽이 많은 워크로드의 경우 데이터베이스 수준에서 공유 RU/s를 권장하지 않습니다.

성능 격리 또는 고객 관리형 키가 필요한 경우 테넌트별 데이터베이스 계정 모델 및 플릿 풀을 사용하여 각 테넌트에 대한 비용을 최적화하는 것이 좋습니다. 이러한 기능이 필요하지 않은 경우 테넌트당 파티션 키 모델을 사용하는 것이 좋습니다.

테넌트별 컨테이너 모델과 마찬가지로 메타데이터 작업에 대한 의 Azure Cosmos DB 제한과 각 계정의 데이터베이스 또는 컨테이너 수 때문에 이 모델을 권장하지 않습니다.

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

다중 테넌트 솔루션에서 다음 Azure Cosmos DB 기능을 사용합니다.

분할

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

계층적 파티션 키를 사용하여 다중 테넌트 솔루션의 성능을 향상시키는 것이 좋습니다. 계층적 파티션 키를 사용하여 여러 값을 포함하는 파티션 키를 만듭니다. 예를 들어 테넌트 ID를 포함하는 키를 첫 번째 수준 키로 사용하고 다음 수준과 같은 /id 높은 카디널리티 필드를 사용하여 각 테넌트에 대해 무제한 스토리지를 보장할 수 있습니다. 또는 쿼리에서 자주 사용하는 속성을 포함하는 계층적 파티션 키를 지정할 수 있습니다. 이 방법을 사용하면 파티션 간 쿼리를 방지할 수 있습니다. 계층적 파티션 키를 사용하여 파티션 키 값당 20GB의 논리 파티션 제한을 초과하여 크기를 조정하고 비용이 많이 드는 팬아웃 쿼리를 제한합니다. 계층적 파티션 키는 테넌트 카디널리티가 높고 읽기가 많은 워크로드를 최적화해야 하는 경우에 가장 적합합니다.

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

Fleet 풀

Azure Cosmos DB 플릿의 기능인 플릿 풀을 사용하여 테넌트별 데이터베이스 계정 모델과 함께 제공되는 성능 및 보안 격리의 이점을 얻을 수 있습니다. 동일한 풀의 여러 계정에서 RU/s를 공유하여 비용을 최적화할 수 있습니다. 유사한 유형의 테넌트를 동일한 플릿 풀로 그룹화하고 풀을 설정하여 최소 및 최대 RU 수 간에 자동으로 크기를 조정합니다.

각 계정의 컨테이너는 전용 RU/s를 유지하지만 풀에 있는 경우 필요할 때 공유 풀에서 추가 RU/s를 자동으로 사용합니다. 이 방법을 사용하면 과잉 프로비전을 방지할 수 있습니다. 비용이 많이 들 수 있는 최대 RU/s에 대해 모든 테넌트의 컨테이너를 프로비전하는 대신 일반적인 RU/s 컨테이너당 값을 설정하고 풀의 공유 용량을 사용하여 급증을 처리할 수 있습니다. 시끄러운 이웃으로부터 보호하기 위해 컨테이너에 프로비전된 처리량은 전용이며 항상 해당 컨테이너에서 사용할 수 있도록 보장됩니다. 컨테이너에 더 많은 처리량이 필요한 경우 공유 풀에서 RU/s를 사용할 수 있습니다.

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

차량군 분석 (미리보기)

Azure Cosmos DB 플릿의 기능인 fleet 분석을 사용하여 플릿의 데이터베이스 계정의 장기 추세를 분석합니다. 플릿 분석은 성능, 사용량 및 비용 데이터를 매시간 주기로 오픈 소스 Apache Delta Lake 테이블로서 Azure Data Lake Storage 및 Microsoft OneLake에 제공합니다.

이 데이터를 사용하여 가장 활성 상태인 계정, 시간에 따른 리소스 크기 조정 방법, 비용이 가장 높은 데이터베이스 계정 또는 테넌트, 액세스 키의 가장 최근 회전과 같은 추세를 추적합니다. 데이터를 사용하여 사용자 지정 쿼리를 작성하거나 Power BI 대시보드를 빌드하여 플릿을 분석할 수도 있습니다.

RU 관리

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

보장된 성능 및 보안 격리가 필요한 테넌트의 경우 데이터베이스 계정으로 테넌트 격리, 테넌트에 전용 RU/s 할당, 플릿 풀을 사용하여 추가 용량 요구 사항을 처리하는 것이 좋습니다. 덜 엄격한 요구 사항이 있는 테넌트에서는 파티션 키로 테넌트 격리를 권장합니다. 이 모델을 사용하여 테넌트 간에 RU/s를 공유하고 각 테넌트에 대한 비용을 최적화합니다.

또한 Azure Cosmos DB는 간헐적이거나 예측할 수 없는 트래픽이 있는 워크로드에 적합한 서버리스 계층을 제공합니다.

참고

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

각 테넌트와 관련된 비용을 모니터링하고 관리하려면 Azure Cosmos DB API를 사용하는 모든 작업에는 사용된 RU가 포함되어 있습니다. 이 정보를 사용하여 각 테넌트가 사용하는 실제 RU를 집계하고 비교할 수 있습니다. 그런 다음 성능 특성이 다른 테넌트 식별할 수 있습니다. 일부 테넌트에 훨씬 더 높은 성능 또는 격리 요구 사항이 있는 경우 전용 컨테이너 RU/s를 사용하여 자체 계정으로 격리하는 것이 좋습니다. 테넌트 ID로 분할된 컨테이너를 사용하여 나머지 테넌트에 대한 데이터를 저장할 수 있습니다.

리소스 거버넌스 기능

파티션 키를 사용하여 테넌트를 격리할 때 시끄러운 인접 문제를 제어하는 데 도움이 되는 기능을 살펴봅니다.

Feature Description
순간 처리 용량 지난 5분 동안 컨테이너의 사용되지 않은 용량을 활용하여 향후 급증에 대비합니다.
우선 순위 기반 실행 요청당 수준에서 높은 우선 순위 또는 낮은 우선 순위를 지정합니다. 컨테이너 수준에서 처리량 경합이 발생하면 우선 순위가 높은 요청의 우선 순위가 지정됩니다. 일괄 처리 작업과 실시간 사용자 요청을 제공하는 API와 같이 여러 워크로드의 성능 요구 사항이 서로 다른 경우 이 기능을 사용합니다.
처리량 버킷(미리 보기) 요청 집합에서 사용할 수 있는 특정 RU/s 비율을 할당합니다. 예를 들어 일괄 처리 작업의 요청은 컨테이너 총 RU/s의 최대 10%만 사용할 수 있지만 중요한 사용자 연결 API는 컨테이너의 총 RU/s 중 최대 100개% 사용할 수 있도록 지정합니다.
처리량 재배포(프리뷰) 이 API를 사용하여 핫 물리적 파티션에 더 많은 RU/s를 할당합니다.

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

고객 관리형 키

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

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

기여자

Microsoft는 이 문서를 유지 관리합니다. 이 문서를 작성한 기여자는 다음과 같습니다.

주요 작성자:

기타 기여자:

  • Mark Brown | 수석 PM 관리자, Azure Cosmos DB
  • 빅 페르다나 | 클라우드 솔루션 설계자, Azure ISV
  • Theo van Kraay | 선임 프로그램 관리자, Azure Cosmos DB
  • Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
  • Thomas Weiss | 수석 프로그램 관리자

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

다중 테넌트 및 Azure Cosmos DB 대한 자세한 내용은 다음 비디오를 시청하세요.

  • Azure Cosmos DB를 사용하는 다중 테넌트 앱을 위한 확장 가능한 데이터 계층을 디자인합니다. 이는 Azure Cosmos DB에서 다중 테넌트를 위한 디자인 방법을 안내하는 Build 2025의 세션입니다. 실제 독립 소프트웨어 공급업체의 모범 사례를 알아봅니다.

  • Azure Cosmos DB: 다중 테넌트 애플리케이션에 대한 성능 격리, 비용 관리, 일관성, 대기 시간, 가용성 장단분 및 보안 패턴을 다루는 빌드 2019의 세션입니다.

  • Azure Cosmos DB 및 Azure: 다중 테넌트 SaaS 스타트업인 Whally가 Azure Cosmos DB 및 Azure 처음부터 최신 플랫폼을 빌드하는 방법에 대한 실제 사례 연구입니다. Whally는 분할, 데이터 모델링, 보안 멀티테넌시, 성능 및 변경 피드에서 SignalR로의 실시간 스트리밍과 관련하여 디자인 및 구현 결정을 내립니다. 이러한 모든 솔루션은 Azure 앱 Service에서 ASP.NET Core를 사용합니다.

다른 Azure Cosmos DB 아키텍처 시나리오를 검토하려면 다음 문서를 참조하세요.

  • Last updated on