다음을 통해 공유

다중 테넌트 및 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 솔루션을 빌드하고 잠재 신규 고객을 위한 무료 평가판을 제공하고 있다고 가정해 보겠습니다. 데이터베이스 계정을 공유하고 평가판 고객을 격리하기 위해 파티션 키를 사용하는 동안 강력한 보안 및 격리 보장이 필요한 유료 엔터프라이즈 테넌트에 대해 별도의 데이터베이스 계정을 배포할 수 있습니다.

테넌트당 파티션 키

파티션 키로 테넌트를 격리하면 처리량이 테넌트 간에 공유되고 동일한 컨테이너 내에서 그룹화됩니다.

이점:

  • 비용 효율성: 모든 테넌트는 테넌트 ID로 분할되는 하나의 컨테이너 내에 배치됩니다. 여러 테넌트 간에 RU/s가 프로비전되고 공유되는 청구 가능한 리소스는 하나뿐이므로 이 방법은 일반적으로 테넌트당 별도의 계정을 갖는 것보다 비용 효율적이고 관리하기 쉽습니다.
  • 간소화된 관리: 관리할 Azure Cosmos DB 계정 수가 줄어듭니다.

장단점:

  • 리소스 경합: 동일한 컨테이너의 테넌트 간에 처리량(RU/s)을 공유하면 사용량이 많은 동안 경합이 발생할 수 있으며, 이로 인해 테넌트에 워크로드가 높거나 겹치는 경우 노이시 네이버 문제가 발생할 수 있습니다. 이 격리 모델은 단일 테넌트에서 보장된 RU/s가 필요하고 공유할 수 있는 워크로드에 적합합니다.
  • 제한된 격리: 이 방법은 물리적 격리가 아닌 논리적 격리를 제공합니다. 성능 및 보안 관점에서든 엄격한 격리 요구 사항을 충족하지 못할 수 있습니다.
  • 유연성 감소: 파티션 키(또는 데이터베이스/컨테이너)로 격리하는 경우 테넌트당 지역 복제, PITR(지정 시간 복원) 및 CMK(고객 관리형 키)와 같은 계정 수준 기능을 사용자 지정할 수 없습니다.

관련 Azure Cosmos DB 기능:

  • 처리량 제어: Java SDK의 처리량 재할당, 버스트 용량 및 처리량 제어와 같이 파티션별로 테넌트를 모델링할 때 시끄러운 인접 문제를 제어하는 데 도움이 되는 기능을 탐색합니다.

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

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

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

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

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

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

이점:

  • 높은 격리: 이 방법은 고유 테넌트당 프로비전된 RU/s가 있는 전용 Azure Cosmos DB 계정 및 컨테이너로 인한 경합 또는 간섭을 방지합니다.
  • 사용자 지정 SLA: 각 테넌트에 고유한 계정이 있기 때문에 특정 맞춤형 리소스, 고객 관련 SLA 및 보장을 제공할 수 있습니다. 각 테넌트의 데이터베이스 계정은 처리량을 위해 독립적으로 조정될 수 있기 때문입니다.
  • 보안 강화: 물리적 데이터 격리는 고객이 테넌트당 계정 수준에서 고객 관리형 키를 사용하도록 설정할 수 있으므로 강력한 보안을 보장합니다. 각 테넌트의 데이터는 동일한 컨테이너에 있지 않고 계정에 의해 격리됩니다.
  • 유연성: 테넌트는 필요에 따라 지역 복제, PITR(특정 시점 복원), CMK(고객 관리형 키)와 같은 계정 수준 기능을 사용하도록 설정할 수 있습니다.

장단점:

  • 관리 강화: 이 방법은 여러 Azure Cosmos DB 계정을 관리하기 때문에 더 복잡합니다.
  • 높은 비용: 계정이 많을수록 계정 내의 각 리소스(데이터베이스 및/또는 컨테이너)에서 각 테넌트에 대한 처리량(RU/s)을 프로비전하는 것을 의미합니다. 리소스가 RU/s를 프로비전할 때마다 Azure Cosmos DB 비용이 증가합니다.
  • 쿼리 제한 사항: 모든 테넌트가 서로 다른 계정 내에 있으므로 여러 테넌트에 대해 쿼리할 때 각 테넌트에 대한 애플리케이션 논리 내에서 여러 호출이 필요합니다.

관련 Azure Cosmos DB 기능:

  • 보안 기능: 이 모델은 Azure RBAC를 사용하여 향상된 데이터 액세스 보안 격리를 제공합니다. 또한 이 모델은 고객 관리형 키를 통해 테넌트 수준에서 데이터베이스 암호화 보안 격리를 제공합니다.
  • 사용자 지정 구성: 테넌트의 요구 사항에 따라 데이터베이스 계정의 위치를 구성할 수 있습니다. 또한 지역 복제 및 고객 관리 암호화 키와 같은 Azure Cosmos DB 기능의 구성을 각 테넌트의 요구 사항에 맞게 조정할 수 있습니다.

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

격리 모델 전체 목록

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

테넌트별 컨테이너

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

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

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

테넌트 데이터 모델에 둘 이상의 엔터티가 필요한 경우 모든 엔터티가 동일한 파티션 키를 공유할 수 있는 한, 동일한 컨테이너에 공동 배치될 수 있습니다. 그러나 테넌트 데이터 모델이 더 복잡하고 동일한 파티션 키를 공유할 수 없는 엔터티가 필요한 경우 아래의 테넌트당 데이터베이스 또는 테넌트당 데이터베이스 계정 모델을 고려합니다. 자세한 지침은 실제 예제를 사용하여 Azure Cosmos DB에서 데이터를 모델링하고 분할하는 방법에 대한 문서를 살펴보세요.

컨테이너가 테넌트 전용인 경우 일반적으로 수명 주기 관리가 더 간단합니다. 공유 처리량 모델과 전용 처리량 모델 간에 테넌트를 쉽게 이동할 수 있으며 테넌트를 프로비전 해제할 때 컨테이너를 신속하게 삭제할 수 있습니다.

테넌트당 데이터베이스

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

테넌트별 계정 모델과 마찬가지로 이 방법은 가장 높은 수준의 성능 격리를 제공하지만 가장 낮은 테넌트 밀도를 제공합니다. 그러나 이 옵션은 각 테넌트가 테넌트당 컨테이너 모델에서 실현 가능한 것보다 더 복잡한 데이터 모델이 필요한 경우에 가장 적합합니다. 또는 테넌트 계정을 미리 생성하기 위해 새로운 테넌트를 신속하게 생성하거나 오버헤드가 없어야 하는 경우에는 이 방법을 따라야 합니다. 사용 중인 특정 소프트웨어 개발 프레임워크의 경우 테넌트당 데이터베이스가 해당 프레임워크에서 인식되는 유일한 성능 격리 수준일 수도 있습니다. 엔터티(컨테이너) 수준 격리 및 엔터티 공동 배치는 일반적으로 이러한 프레임워크에서 기본 지원되지 않습니다.

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

분할

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

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

추가 정보:

요청 단위 관리

Azure Cosmos DB 가격 책정 모델은 프로비전하거나 사용하는 초당 요청 단위 수를 기반으로 합니다. 요청 단위는 데이터베이스 작업 또는 쿼리 비용의 논리적 추상화입니다. 일반적으로 처리량이라고 하는 워크로드에 대해 정의된 초당 요청 단위 수를 프로비전합니다. Azure Cosmos DB는 처리량을 프로비전하는 방법에 대한 몇 가지 옵션을 제공합니다. 다중 테넌트 환경에서 선택한 항목은 Azure Cosmos DB 리소스의 성능과 가격에 영향을 줍니다.

보장된 성능 및 보안 격리가 필요한 테넌트에서는 데이터베이스 계정으로 테넌트 격리 및 테넌트에 요청 단위를 할당하는 것이 좋습니다. 덜 엄격한 요구 사항이 있는 테넌트에서는 테넌트 간에 요청 단위를 공유할 수 있도록 하고 테넌트당 저렴한 비용을 최적화하는 데 도움이 되는 파티션 키로 테넌트를 격리하는 것이 좋습니다.

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

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

참고

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

각 테넌트와 연결된 비용을 모니터링하고 관리하기 위해 Azure Cosmos DB API를 사용하는 모든 작업에는 사용된 요청 단위가 포함됩니다. 이 정보를 사용하여 각 테넌트에서 사용하는 실제 요청 단위를 집계하고 비교한 다음, 다양한 성능 특성을 가진 테넌트 식별할 수 있습니다.

추가 정보:

고객 관리형 키

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

추가 정보:

참가자

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

주요 작성자:

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

기타 기여자:

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

다음 단계

다중 테넌시에 대한 스토리지 및 데이터 접근 방식을 검토합니다.

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

다음과 같은 몇 가지 Cosmos DB 아키텍처 시나리오를 참조하세요.