Share via

다중 테넌트 및 Azure Cosmos DB

  • 아티클

이 페이지에서는 다중 테넌트 시스템을 사용할 때 유용한 Azure Cosmos DB의 몇 가지 기능에 대해 설명합니다. 또한 다중 테넌트 솔루션에서 Azure Cosmos DB를 사용하는 방법에 대한 지침 및 예제에 연결합니다.

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

분할

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

계층적 파티션 키를 사용하여 다중 테넌트 솔루션의 성능을 향상시키는 것이 좋습니다. 계층적 파티션 키를 사용하면 여러 값을 포함하는 파티션 키를 만들 수 있습니다. 예를 들어 테넌트 식별자와 저장하려는 데이터 형식을 포함하는 계층적 파티션 키를 사용할 수 있습니다. 이 방법을 사용하면 파티션 키 값당 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 계정을 사용하여 배포해야 합니다.

추가 정보:

격리 모델

Azure Cosmos DB를 사용하는 다중 테넌트 시스템으로 작업하는 경우 사용하려는 격리 수준에 대한 결정을 내려야 합니다. B2B(Business-to-Business)는 비즈니스에 대한 판매를 의미합니다. B2C(Business-to-Consumer)는 제품 또는 서비스를 사용하는 개별 고객에게 직접 판매하는 것을 의미합니다. Azure Cosmos DB는 다음과 같은 여러 격리 모델을 지원합니다.

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

테넌트당 파티션 키

여러 테넌트에 단일 컨테이너를 사용하는 경우 Azure Cosmos DB 분할 지원을 사용할 수 있습니다. 각 테넌트에 대해 별도의 파티션 키를 사용하여 단일 테넌트에 대한 데이터를 쉽게 쿼리할 수 있습니다. 여러 테넌트가 별도의 파티션에 있더라도 여러 테넌트 간에 쿼리할 수도 있습니다. 그러나 파티션 간 쿼리는 단일 파티션 쿼리보다 RU(요청 단위) 비용이 더 높습니다.

이 방법은 각 테넌트에 대해 저장된 데이터의 양이 적을 때 잘 작동하는 경향이 있습니다. 무료 계층을 포함하는 가격 책정 모델을 빌드하는 경우와, B2C(기업-소비자) 솔루션에 적합할 수 있습니다. 일반적으로 공유 컨테이너를 사용하면 테넌트의 밀도가 가장 높으므로 테넌트당 가격이 가장 낮습니다.

컨테이너의 처리량을 고려하는 것이 중요합니다. 모든 테넌트는 컨테이너의 처리량을 공유하므로 테넌트에 워크로드가 높거나 겹치는 워크로드가 있으면 그런 노이지 네이버 문제로 인해 성능 문제를 일으킬 수 있습니다. 경우에 따라 테넌트 하위 집합을 다른 컨테이너로 그룹화하고 각 테넌트 그룹에 호환되는 사용 패턴이 있는지 확인하여 이 문제를 완화할 수 있습니다. 또는 하이브리드 다중 및 단일 테넌트 모델을 고려할 수 있습니다. 소규모 테넌트가 공유 분할된 컨테이너로 그룹화되고 대규모 고객에게 전용 컨테이너를 제공합니다. 또한 Java SDK의 처리량 재할당, 버스트 용량 및 처리량 제어와 같이 파티션별로 테넌트를 모델링할 때 노이지 네이버 문제를 제어하는 데 도움이 되는 기능이 있습니다.

각 논리 파티션에 저장하는 데이터의 양을 고려하는 것도 중요합니다. Azure Cosmos DB를 사용하면 각 논리 파티션을 최대 20GB까지 늘릴 수 있습니다. 20GB 이상의 데이터를 저장해야 하는 단일 테넌트가 있는 경우 여러 논리 파티션에 데이터를 분산하는 것이 좋습니다. 예를 들어 Contoso의 단일 파티션 키를 사용하는 대신 테넌트에 대한 여러 파티션 키(예: Contoso1, Contoso2 등)를 만들어 파티션 키를 솔트할 수 있습니다. 테넌트에 대한 데이터를 쿼리할 때 WHERE IN 절을 사용하여 모든 파티션 키를 일치시킬 수 있습니다. 또한 계층적 파티션 키는 가상 파티션 키 또는 테넌트당 여러 파티션 키 값을 사용하지 않고도 스토리지가 20GB를 초과하는 대규모 테넌트도 지원하는 데도 사용할 수 있습니다.

솔루션의 운영 측면과 테넌트 수명 주기의 다양한 단계를 고려합니다. 예를 들어 테넌트가 전용 가격 책정 계층으로 이동하는 경우 데이터를 다른 컨테이너로 이동해야 할 수 있습니다. 테넌트가 프로비전 해제되면 컨테이너에서 삭제 쿼리를 실행하여 데이터를 제거해야 하며, 대규모 테넌트의 경우 이 쿼리가 실행되는 동안 상당한 양의 처리량을 사용할 수 있습니다.

테넌트별 컨테이너

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

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

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

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

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

테넌트당 데이터베이스

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

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

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

Azure Cosmos DB를 사용하면 각 테넌트에 대해 별도의 데이터베이스 계정을 프로비전할 수 있습니다. 이 계정은 가장 높은 수준의 격리를 제공하지만 밀도는 가장 낮습니다. 위의 테넌트당 컨테이너 및 테넌트당 데이터베이스 모델과 마찬가지로, 이 모델은 테넌트당 파티션 키 모델보다 더 나은 성능 격리를 제공합니다. 또한 Azure RBAC를 통해 향상된 데이터 액세스 보안 격리를 제공합니다. 또한 이 모델은 고객 관리형 키를 통해 테넌트 수준에서 데이터베이스 암호화 보안 격리를 제공합니다.

단일 데이터베이스 계정은 테넌트 전용이므로 노이지 네이버 문제가 발생하지 않습니다. 테넌트의 요구 사항에 따라 데이터베이스 계정의 위치를 구성할 수 있습니다. 또한 지역 복제 및 고객 관리 암호화 키와 같은 Azure Cosmos DB 기능의 구성을 각 테넌트의 요구 사항에 맞게 조정할 수 있습니다. 테넌트당 전용 Azure Cosmos DB 계정을 사용하는 경우 Azure 구독당 최대 Azure Cosmos DB 계정 수를 고려합니다.

이 모델을 사용하는 경우 애플리케이션이 새 테넌트 생성을 얼마나 빨리 수행해야 하는지 고려해야 합니다. Azure Cosmos DB에서 계정을 만드는 데 몇 분 정도 걸릴 수 있으므로 계정을 미리 만들어야 할 수 있습니다. 이 방법을 사용할 수 없는 경우 테넌트당 데이터베이스 모델을 고려합니다.

테넌트가 공유 계정에서 전용 Azure Cosmos DB 계정으로 마이그레이션하도록 허용하는 경우 이전 계정과 새 계정 간에 테넌트의 데이터를 이동하는 데 사용할 마이그레이션 방법을 고려합니다.

하이브리드 접근 방식

다양한 테넌트의 요구 사항 및 가격 책정 모델에 맞게 위의 방법을 조합하여 고려할 수 있습니다. 다음은 그 예입니다.

  • 공유 컨테이너 내에서 모든 평가판 고객을 프로비전하고 테넌트 ID 또는 가상 키 파티션 키를 사용합니다.
  • 테넌트별 전용 컨테이너를 배포하지만 데이터베이스에서 공유 처리량을 사용하는 유료 Bronze 계층을 제공합니다.
  • 테넌트의 컨테이너에 대한 전용 처리량을 프로비전하는 더 높은 Silver 계층을 제공합니다.
  • 가장 높은 Gold 계층을 제공하고 테넌트에 대한 전용 데이터베이스 계정을 제공하므로 테넌트가 배포에 대한 지역을 선택할 수도 있습니다.

참가자

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

주요 작성자:

  • Paul Burpo | 주요 고객 엔지니어, FastTrack for Azure
  • John Downs | FastTrack for Azure 수석 고객 엔지니어

기타 기여자:

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

다음 단계

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

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

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