데이터 분할 전략

이 문서에서는 다양한 Azure 데이터 저장소에서 데이터를 분할하기 위한 몇 가지 전략을 설명합니다. 데이터 분할 시기 및 모범 사례에 대한 일반적인 지침은 데이터 분할참조하세요.

Azure SQL Database 분할

단일 SQL 데이터베이스에는 포함할 수 있는 데이터 볼륨에 제한이 있습니다. 처리량은 아키텍처 요소 및 지원하는 동시 연결 수에 의해 제한됩니다.

탄력적 풀 SQL 데이터베이스에 대한 수평 크기 조정을 지원합니다. 탄력적 풀을 사용하여 데이터를 여러 SQL 데이터베이스에 분산된 분할된 데이터베이스로 분할할 수 있습니다. 처리해야 하는 데이터의 양이 늘어나고 축소됨에 따라 분할된 데이터베이스를 추가하거나 제거할 수도 있습니다. 탄력적 풀은 데이터베이스 간에 부하를 분산하여 경합을 줄일 수도 있습니다.

각 분할된 데이터베이스는 SQL 데이터베이스로 구현됩니다. 분할된 데이터베이스는 둘 이상의 데이터 세트(shardlet라고 함)를 보유할 수 있습니다. 각 데이터베이스는 포함된 shardlet을 설명하는 메타데이터를 유지 관리합니다. shardlet은 단일 데이터 항목이거나 동일한 shardlet 키를 공유하는 항목 그룹일 수 있습니다. 예를 들어 다중 테넌트 애플리케이션에서 shardlet 키는 테넌트 ID일 수 있으며 테넌트의 모든 데이터는 동일한 shardlet에 보관할 수 있습니다.

클라이언트 애플리케이션은 데이터 세트를 shardlet 키와 연결해야 합니다. 별도의 SQL Database는 전역 분할된 데이터베이스 맵 관리자 역할을 합니다. 이 데이터베이스에는 시스템의 모든 샤드 및 샤드렛 목록이 있습니다. 애플리케이션은 샤드 맵 관리자 데이터베이스에 연결하여 샤드 맵의 복사본을 가져옵니다. 분할된 데이터베이스 맵을 로컬로 캐시하고 맵을 사용하여 데이터 요청을 적절한 분할된 데이터베이스로 라우팅합니다. 이 기능은 Java 및 .NET에서 사용할 수 있는 Elastic Database 클라이언트 라이브러리포함된 일련의 API 뒤에 숨겨집니다.

탄력적 풀에 대한 자세한 내용은 Azure SQL Database 스케일 아웃을 참조하세요.

대기 시간을 줄이고 가용성을 높이기 위해 글로벌 샤드 맵 관리자 데이터베이스를 복제할 수 있습니다. 프리미엄 가격 책정 계층을 사용하면 다른 지역의 데이터베이스에 데이터를 지속적으로 복사하도록 활성 지역 복제를 구성할 수 있습니다.

또는 Azure SQL 데이터 동기화 사용하거나 Azure Data Factory 사용하여 지역 간에 분할된 데이터베이스 맵 관리자 데이터베이스를 복제합니다. 이 형식의 복제는 주기적으로 실행되며 분할된 데이터베이스 맵이 자주 변경되지 않고 프리미엄 계층이 필요하지 않은 경우에 더 적합합니다.

Elastic Database는 데이터를 shardlet에 매핑하고 이를 샤드에 저장하기 위한 두 가지 체계를 제공합니다.

• 목록 분할된 데이터베이스 맵은 단일 키를 shardlet에 연결할 있습니다. 예를 들어 다중 테넌트 시스템에서 각 테넌트의 데이터를 고유 키와 연결하고 자체 shardlet에 저장할 수 있습니다. 격리를 보장하기 위해 각 샤드렛은 자체 샤드 내에 보관할 수 있습니다.

  테넌트 데이터를 별도의 분할된 데이터베이스에 저장하는 목록 분할된 데이터베이스 맵을 보여 주는

  이 다이어그램의 Visio 파일 다운로드합니다.

• 범위 분할된 데이터베이스 맵 연속 키 값 집합을 shardlet에 연결합니다. 예를 들어 동일한 shardlet 내에서 테넌트 집합(각각 고유 키를 가진)에 대한 데이터를 그룹화할 수 있습니다. 테넌트가 데이터 스토리지를 공유하지만 격리가 적기 때문에 이 체계는 첫 번째 스키마보다 저렴합니다.

  분할된 데이터베이스에 있는 테넌트 범위에 대한 데이터를 저장하는 범위 분할된 데이터베이스 맵을 보여 주는

  이 다이어그램의 Visio 파일 다운로드

단일 샤드는 여러 샤드렛에 대한 데이터를 포함할 수 있습니다. 예를 들어, 서로 다른 비연속적인 테넌트의 데이터를 동일한 샤드에 저장하기 위해 리스트 샤드렛을 사용할 수 있습니다. 범위 shardlet을 혼합하고 동일한 분할된 데이터베이스에 shardlet을 나열할 수도 있지만 다른 맵을 통해 처리됩니다. 다음 다이어그램에서는 이 방법을 보여 줍니다.

여러 분할된 데이터베이스 맵을 보여 주는

이 다이어그램의 Visio 파일 다운로드합니다.

탄력적 풀을 사용하면 데이터 볼륨이 줄어들고 증가함에 따라 분할된 데이터베이스를 추가하고 제거할 수 있습니다. 클라이언트 애플리케이션은 분할된 데이터베이스를 동적으로 만들고 삭제하고 분할된 데이터베이스 맵 관리자를 투명하게 업데이트할 수 있습니다. 그러나 분할된 데이터베이스를 제거하는 것은 해당 분할된 데이터베이스의 모든 데이터를 삭제해야 하는 파괴적인 작업입니다.

애플리케이션이 샤드를 두 개의 개별 샤드로 분할하거나 샤드를 결합해야 하는 경우 분할-병합 도구을 사용합니다. 이 도구는 Azure 웹 서비스로 실행되며 분할된 데이터베이스 간에 데이터를 안전하게 마이그레이션합니다.

분할 체계는 시스템의 성능에 큰 영향을 줄 수 있습니다. 분할된 데이터베이스를 추가하거나 제거해야 하는 속도 또는 분할된 데이터베이스 간에 데이터를 다시 분할해야 하는 속도에도 영향을 줄 수 있습니다. 다음 사항을 고려합니다.

• 동일한 분할된 데이터베이스에서 함께 사용되는 데이터를 그룹화하고 여러 분할된 데이터베이스의 데이터에 액세스하는 작업을 방지합니다. 분할된 데이터베이스는 자체적으로 SQL 데이터베이스이며 클라이언트 쪽에서 데이터베이스 간 조인을 수행해야 합니다.

  SQL Database는 데이터베이스 간 조인을 지원하지 않지만 Elastic Database 도구를 사용하여 다중 분할된 데이터베이스 쿼리를수행할 수 있습니다. 샤드 여러 개를 사용하는 쿼리는 각 데이터베이스에 개별 쿼리를 보내고 결과를 병합합니다.

• 분할된 데이터베이스 간에 종속성이 있는 시스템을 디자인하지 마세요. 한 데이터베이스의 참조 무결성 제약 조건, 트리거 및 저장 프로시저는 다른 데이터베이스의 개체를 참조할 수 없습니다.

• 쿼리에서 자주 사용하는 참조 데이터가 있는 경우 분할된 데이터베이스에서 이 데이터를 복제하는 것이 좋습니다. 이 방법을 사용하면 데이터베이스 간에 데이터를 조인할 필요가 없습니다. 이상적으로 이러한 데이터는 정적 또는 느리게 이동하여 복제 작업을 최소화하고 부실해질 가능성을 줄여야 합니다.

• 동일한 분할된 데이터베이스 맵에 속하는 Shardlet에는 동일한 스키마가 있어야 합니다. 이 규칙은 SQL Database에서 적용되지 않지만 각 shardlet에 다른 스키마가 있는 경우 데이터 관리 및 쿼리가 매우 복잡해집니다. 대신 각 스키마에 대해 별도의 분할된 데이터베이스 맵을 만듭니다. 다른 shardlet에 속하는 데이터는 동일한 분할된 데이터베이스에 저장할 수 있습니다.

• 트랜잭션 작업은 분할된 데이터베이스가 아닌 분할된 데이터베이스 내의 데이터에 대해서만 지원됩니다. 트랜잭션은 동일한 분할된 데이터베이스의 일부인 한 shardlet에 걸쳐 있을 수 있습니다. 따라서 비즈니스 논리가 트랜잭션을 수행해야 하는 경우 데이터를 동일한 분할된 데이터베이스에 저장하거나 최종 일관성을 구현합니다.

• 데이터에 액세스하는 사용자와 가까운 곳에 샤드를 배치합니다. 이 전략은 대기 시간을 줄이는 데 도움이 됩니다.

• 활성 상태가 높고 상대적으로 비활성 분할된 데이터베이스가 혼합되지 않도록 합니다. 부하를 데이터베이스 샤드에 균등하게 분산해 보세요. 이렇게 하려면 분할 키를 해시해야 할 수 있습니다. 분할된 데이터베이스를 지리적으로 찾는 경우 해시된 키가 해당 데이터에 액세스하는 사용자 가까이에 저장된 분할된 데이터베이스에 보관된 shardlet에 매핑되는지 확인합니다.

Azure Table Storage 분할

Azure Table Storage는 분할을 중심으로 설계된 키-값 저장소입니다. 모든 엔터티는 파티션에 저장되고 파티션은 Azure Table Storage에서 내부적으로 관리됩니다. 테이블에 저장된 각 엔터티는 다음을 포함하는 두 부분으로 구성된 키를 제공해야 합니다.

• 파티션 키. Azure Table Storage에서 엔터티를 배치할 파티션을 결정하는 문자열 값입니다. 파티션 키가 동일한 모든 엔터티는 동일한 파티션에 저장됩니다.

• 행 키. 파티션 내의 엔터티를 식별하는 문자열 값입니다. 파티션 내의 모든 엔터티는 이 키를 기준으로 어휘적으로 오름차순으로 정렬됩니다. 파티션 키/행 키 조합은 각 엔터티에 대해 고유해야 하며 길이가 1KB를 초과할 수 없습니다.

이전에 사용하지 않은 파티션 키가 있는 테이블에 엔터티가 추가되면 Azure Table Storage는 이 엔터티에 대한 새 파티션을 만듭니다. 동일한 파티션 키를 가진 다른 엔터티는 동일한 파티션에 저장됩니다.

이 메커니즘은 자동 스케일 아웃 전략을 효과적으로 구현합니다. 각 파티션은 단일 파티션에서 데이터를 검색하는 쿼리가 신속하게 실행되도록 하기 위해 Azure 데이터 센터의 동일한 서버에 저장됩니다.

Microsoft는 Azure Storage에 대한 확장성 목표를 게시했습니다. 시스템에서 이러한 제한을 초과할 가능성이 있는 경우 엔터티를 여러 테이블로 분할하는 것이 좋습니다. 세로 분할을 사용하여 필드를 함께 액세스할 가능성이 가장 큰 그룹으로 나눕니다.

다음 다이어그램은 예제 스토리지 계정의 논리적 구조를 보여 줍니다. 스토리지 계정에는 고객 정보, 제품 정보 및 주문 정보의 세 가지 테이블이 포함되어 있습니다.

각 테이블에는 여러 파티션이 있습니다.

• 고객 정보 테이블에서 데이터는 고객이 있는 도시에 따라 분할됩니다. 행 키에는 고객 ID가 포함됩니다.
• 제품 정보 테이블에서 제품은 제품 범주별로 분할되고 행 키에는 제품 번호가 포함됩니다.
• 주문 정보 테이블에서 주문은 주문 날짜별로 분할되고 행 키는 주문을 받은 시간을 지정합니다. 모든 데이터는 각 파티션의 행 키로 정렬됩니다.

Azure Table Storage에 대한 엔터티를 디자인할 때 다음 사항을 고려합니다.

• 데이터에 액세스하는 방법에 따라 파티션 키 및 행 키를 선택합니다. 대부분의 쿼리를 지원하는 파티션 키/행 키 조합을 선택합니다. 가장 효율적인 쿼리는 파티션 키와 행 키를 지정하여 데이터를 검색합니다. 파티션 키와 행 키 범위를 지정하는 쿼리는 단일 파티션을 검색하여 완료할 수 있습니다. 이는 데이터가 행 키 순서로 유지되므로 비교적 빠릅니다. 쿼리에서 검색할 파티션을 지정하지 않으면 모든 파티션을 검색해야 합니다.

• 엔터티에 하나의 자연 키가 있는 경우 파티션 키로 사용하고 빈 문자열을 행 키로 지정합니다. 엔터티에 두 개의 속성으로 구성된 복합 키가 있는 경우 가장 느린 변경 속성을 파티션 키로 선택하고 다른 하나는 행 키로 선택합니다. 엔터티에 두 개 이상의 키 속성이 있는 경우 속성의 연결을 사용하여 파티션 및 행 키를 제공합니다.

• 파티션 및 행 키 이외의 필드를 사용하여 데이터를 조회하는 쿼리를 정기적으로 수행하는 경우 인덱스 테이블 패턴구현하거나 Azure Cosmos DB와 같은 인덱싱을 지원하는 다른 데이터 저장소를 사용하는 것이 좋습니다.

• 단조 시퀀스(예: "0001", "0002", "0003")를 사용하여 파티션 키를 생성하고 각 파티션에 제한된 양의 데이터만 포함된 경우 Azure Table Storage는 동일한 서버에서 이러한 파티션을 물리적으로 그룹화할 수 있습니다. Azure Storage는 애플리케이션이 연속된 파티션 범위(범위 쿼리)에서 쿼리를 수행할 가능성이 가장 높다고 가정하고 이 경우에 최적화되어 있습니다. 그러나 새 엔터티의 모든 삽입이 연속 범위의 한쪽 끝에 집중될 가능성이 높기 때문에 이 방법은 핫스팟으로 이어질 수 있습니다. 확장성을 줄일 수도 있습니다. 부하를 더 균등하게 분산하려면 파티션 키를 해시하는 것이 좋습니다.

• Azure Table Storage는 동일한 파티션에 속하는 엔터티에 대한 트랜잭션 작업을 지원합니다. 트랜잭션에 100개 이상의 엔터티가 포함되지 않고 요청 페이로드가 4MB를 초과하지 않는 한 애플리케이션은 여러 삽입, 업데이트, 삭제, 바꾸기 또는 병합 작업을 원자 단위로 수행할 수 있습니다. 여러 파티션에 걸쳐 있는 작업은 트랜잭션이 아니며 최종 일관성을 구현해야 할 수 있습니다. 테이블 스토리지 및 트랜잭션에 대한 자세한 내용은 엔터티 그룹 트랜잭션 수행참조하세요.

• 파티션 키의 세분성을 고려합니다.

  • 모든 엔터티에 대해 동일한 파티션 키를 사용하면 하나의 서버에 보관되는 단일 파티션이 생성됩니다. 이렇게 하면 파티션이 확장되지 않고 단일 서버에 부하가 집중됩니다. 따라서 이 방법은 소수의 엔터티를 저장하는 데만 적합합니다. 그러나 모든 엔터티가 엔터티 그룹 트랜잭션에 참여할 수 있는지 확인합니다.

  • 모든 엔터티에 고유한 파티션 키를 사용하면 Table Storage 서비스가 각 엔터티에 대해 별도의 파티션을 만들 수 있으므로 많은 수의 작은 파티션이 발생할 수 있습니다. 이 방법은 단일 파티션 키를 사용하는 것보다 확장성이 높지만 엔터티 그룹 트랜잭션은 불가능합니다. 또한 둘 이상의 엔터티를 가져오는 쿼리에는 둘 이상의 서버에서 읽는 작업이 포함될 수 있습니다. 그러나 애플리케이션이 범위 쿼리를 수행하는 경우 파티션 키에 단조 시퀀스를 사용하면 이러한 쿼리를 최적화하는 데 도움이 될 수 있습니다.

  • 엔터티의 하위 집합에서 파티션 키를 공유하면 동일한 파티션에서 관련 엔터티를 그룹화할 수 있습니다. 엔터티 그룹 트랜잭션을 사용하여 관련 엔터티를 포함하는 작업을 수행할 수 있으며, 단일 서버에 액세스하여 관련 엔터티 집합을 가져오는 쿼리를 충족할 수 있습니다.

자세한 내용은 Azure Storage 테이블 디자인 가이드 및 확장 가능한 분할 전략 참조하세요.

Azure Blob Storage 분할

Azure Blob Storage를 사용하면 큰 이진 개체를 보유할 수 있습니다. 대량의 데이터를 신속하게 업로드하거나 다운로드해야 하는 경우 시나리오에서 블록 Blob을 사용합니다. 데이터 부분에 대한 직렬 액세스가 아닌 임의로 필요한 애플리케이션에 페이지 Blob을 사용합니다.

각 Blob(블록 또는 페이지)은 Azure Storage 계정의 컨테이너에 보관됩니다. 컨테이너를 사용하여 동일한 보안 요구 사항이 있는 관련 Blob을 그룹화할 수 있습니다. 이 그룹화는 물리적인 것이 아니라 논리적입니다. 컨테이너 내에서 각 Blob에는 고유한 이름이 있습니다.

Blob의 파티션 키는 계정 이름 + 컨테이너 이름 + Blob 이름입니다. 파티션 키는 데이터를 범위로 분할하는 데 사용되며 이러한 범위는 시스템 전체에서 부하가 분산됩니다. Blob에 대한 액세스를 확장하기 위해 여러 서버에 걸쳐 Blob을 배포할 수 있지만 단일 Blob은 단일 서버에서만 제공될 수 있습니다.

명명 체계에서 타임스탬프 또는 숫자 식별자를 사용하는 경우 과도한 트래픽이 하나의 파티션으로 이동하여 시스템이 효과적으로 부하 분산을 제한할 수 있습니다. 예를 들어 yyyy-mm-dd같은 타임스탬프가 있는 Blob 개체를 사용하는 매일 작업이 있는 경우 해당 작업에 대한 모든 트래픽은 단일 파티션 서버로 이동합니다. 대신 이름 앞에 3자리 해시를 접두사로 지정하는 것이 좋습니다. 자세한 내용은 파티션 명명 규칙 참조하세요.

단일 블록 또는 페이지를 작성하는 작업은 원자성이지만 블록, 페이지 또는 Blob에 걸쳐 있는 작업은 그렇지 않습니다. 블록, 페이지 및 Blob에서 쓰기 작업을 수행할 때 일관성을 유지해야 하는 경우 Blob 임대를 사용하여 쓰기 잠금을 수행합니다.

Azure Storage 큐 분할

Azure Storage 큐를 사용하면 프로세스 간에 비동기 메시징을 구현할 수 있습니다. Azure Storage 계정에는 여러 큐가 포함될 수 있으며 각 큐에는 여러 개의 메시지가 포함될 수 있습니다. 유일한 제한 사항은 스토리지 계정에서 사용할 수 있는 공간입니다. 개별 메시지의 최대 크기는 64KB입니다. 이보다 큰 메시지가 필요한 경우 대신 Azure Service Bus 큐를 사용하는 것이 좋습니다.

각 스토리지 큐에는 스토리지 계정이 포함된 고유한 이름이 있습니다. Azure는 이름에 따라 큐를 분할합니다. 동일한 큐에 대한 모든 메시지는 단일 서버에서 제어되는 동일한 파티션에 저장됩니다. 부하를 분산하는 데 도움이 되도록 서로 다른 서버에서 서로 다른 큐를 관리할 수 있습니다. 서버에 큐를 할당하는 것은 애플리케이션 및 사용자에게 투명합니다.

대규모 애플리케이션에서는 이 방법으로 인해 큐를 호스팅하는 서버가 핫 스폿이 될 수 있으므로 애플리케이션의 모든 인스턴스에 동일한 스토리지 큐를 사용하지 마세요. 대신 애플리케이션의 다양한 기능 영역에 대해 서로 다른 큐를 사용합니다. Azure Storage 큐는 트랜잭션을 지원하지 않으므로 메시지를 다른 큐로 보내는 것은 메시징 일관성에 거의 영향을 미치지 않습니다.

Azure Storage 큐는 초당 최대 2,000개의 메시지를 처리할 수 있습니다. 이보다 더 높은 속도로 메시지를 처리해야 하는 경우 여러 큐를 만드는 것이 좋습니다. 예를 들어 전역 애플리케이션에서 각 지역에서 실행되는 애플리케이션 인스턴스를 처리하기 위해 별도의 스토리지 계정에 별도의 스토리지 큐를 만듭니다.

Azure Service Bus 분할

Azure Service Bus는 메시지 브로커를 사용하여 Service Bus 큐 또는 토픽으로 전송되는 메시지를 처리합니다. 기본적으로 큐 또는 토픽으로 전송되는 모든 메시지는 동일한 메시지 브로커 프로세스에서 처리됩니다. 이 아키텍처는 메시지 큐의 전체 처리량에 제한을 적용할 수 있습니다. 그러나 큐 또는 토픽을 만들 때 분할할 수도 있습니다. 큐 또는 토픽 설명의 EnablePartitioning 속성을 true 설정하여 이 작업을 수행합니다.

분할된 큐 또는 토픽은 각각 별도의 메시지 저장소 및 메시지 브로커에 의해 지원되는 여러 조각으로 나뉩니다. Service Bus는 이러한 조각을 만들고 관리하는 역할을 담당합니다. 애플리케이션이 분할된 큐 또는 토픽에 메시지를 게시하면 Service Bus는 해당 큐 또는 토픽의 조각에 메시지를 할당합니다. 애플리케이션이 큐 또는 구독에서 메시지를 받으면 Service Bus는 각 조각에서 사용 가능한 다음 메시지를 확인한 다음 처리를 위해 애플리케이션에 전달합니다.

이 구조는 메시지 브로커 및 메시지 저장소에 부하를 분산하여 확장성을 높이고 가용성을 향상시키는 데 도움이 됩니다. 한 조각에 대한 메시지 브로커 또는 메시지 저장소를 일시적으로 사용할 수 없는 경우 Service Bus는 사용 가능한 나머지 조각 중 하나에서 메시지를 검색할 수 있습니다.

Service Bus는 다음과 같이 조각에 메시지를 할당합니다.

• 메시지가 세션에 속하는 경우 SessionId 속성에 대해 동일한 값을 가진 모든 메시지가 동일한 조각으로 전송됩니다.

• 메시지가 세션에 속하지 않지만 발신자가 PartitionKey 속성에 대한 값을 지정한 경우 동일한 PartitionKey 값을 가진 모든 메시지가 동일한 조각으로 전송됩니다.

  메모

  SessionId 및 PartitionKey 속성이 모두 지정된 경우 동일한 값으로 설정해야 합니다. 그렇지 않으면 메시지가 거부됩니다.

• 메시지에 대한 SessionId 및 PartitionKey 속성을 지정하지 않았지만 중복 검색을 사용하도록 설정하면 MessageId 속성이 사용됩니다. 동일한 MessageId 있는 모든 메시지는 동일한 조각으로 전달됩니다.

• 메시지에 SessionId, PartitionKey, 또는 MessageId 속성이 포함되지 않은 경우 Service Bus는 메시지를 순차적으로 조각에 할당합니다. 조각을 사용할 수 없는 경우 Service Bus는 다음으로 이동합니다. 즉, 메시징 인프라의 일시적인 오류로 인해 메시지 보내기 작업이 실패하지 않습니다.

Service Bus 메시지 큐 또는 토픽을 분할할지 또는 어떻게 분할할지 결정할 때 다음 사항을 고려합니다.

• Service Bus 큐 및 토픽은 Service Bus 네임스페이스의 범위 내에서 만들어집니다. Service Bus는 현재 네임스페이스당 최대 100개의 분할된 큐 또는 토픽을 허용합니다.

• 각 Service Bus 네임스페이스는 토픽당 구독 수, 초당 동시 송신 및 수신 요청 수, 설정할 수 있는 최대 동시 연결 수 등 사용 가능한 리소스에 할당량을 적용합니다. 이러한 할당량은 Service Bus 할당량문서화되어 있습니다. 이러한 값을 초과해야 하는 경우 자체 큐 및 토픽을 사용하여 추가 네임스페이스를 만들고 이러한 네임스페이스에 작업을 분산합니다. 예를 들어 전역 애플리케이션에서 각 지역에 별도의 네임스페이스를 만들고 가장 가까운 네임스페이스의 큐와 토픽을 사용하도록 애플리케이션 인스턴스를 구성합니다.

• 트랜잭션의 일부로 전송되는 메시지는 파티션 키를 지정해야 합니다. SessionId , PartitionKey또는 MessageId 속성을수 있습니다. 동일한 트랜잭션의 일부로 전송되는 모든 메시지는 동일한 메시지 브로커 프로세스에서 처리해야 하므로 동일한 파티션 키를 지정해야 합니다. 동일한 트랜잭션 내의 다른 큐 또는 토픽에 메시지를 보낼 수 없습니다.

• 분할된 큐 및 토픽은 유휴 상태가 되면 자동으로 삭제되도록 구성할 수 없습니다.

• 플랫폼 간 또는 하이브리드 솔루션을 빌드하는 경우 분할된 큐 및 토픽은 현재 AMQP(고급 메시지 큐 프로토콜)와 함께 사용할 수 없습니다.

Azure Cosmos DB 분할

Azure Cosmos DB for NoSQL JSON 문서를 저장하기 위한 NoSQL 데이터베이스입니다. Azure Cosmos DB 데이터베이스의 문서는 개체 또는 다른 데이터의 JSON 직렬화된 표현입니다. 모든 문서에 고유한 ID가 포함되어야 한다는 점을 제외하고는 고정된 스키마가 적용되지 않습니다.

문서는 컬렉션으로 구성됩니다. 컬렉션에서 관련 문서를 그룹화할 수 있습니다. 예를 들어 블로그 게시물을 유지 관리하는 시스템에서 각 블로그 게시물의 콘텐츠를 컬렉션에 문서로 저장할 수 있습니다. 각 제목 형식에 대한 컬렉션을 만들 수도 있습니다. 또는 여러 작성자가 자신의 블로그 게시물을 제어하고 관리하는 시스템과 같은 다중 테넌트 애플리케이션에서 작성자별로 블로그를 분할하고 각 작성자에게 별도의 컬렉션을 만들 수 있습니다. 컬렉션에 할당된 스토리지 공간은 탄력적이며 필요에 따라 축소 또는 증가할 수 있습니다.

Azure Cosmos DB는 애플리케이션 정의 파티션 키를 기반으로 데이터의 자동 분할을 지원합니다. 논리 파티션 단일 파티션 키 값에 대한 모든 데이터를 저장하는 파티션입니다. 파티션 키에 대해 동일한 값을 공유하는 모든 문서는 동일한 논리 파티션 내에 배치됩니다. Azure Cosmos DB는 파티션 키의 해시에 따라 값을 분산합니다. 논리 파티션의 최대 크기는 20GB입니다. 따라서 파티션 키를 선택하는 것은 디자인 타임에 중요한 결정입니다. 다양한 값과 액세스 패턴이 있는 속성을 선택합니다. 자세한 내용은 Azure Cosmos DB 파티션 및 크기 조정을 참조하세요.

Azure Cosmos DB에서 제공하는 분할 메커니즘이 충분하지 않은 경우 애플리케이션 수준에서 데이터를 분할해야 할 수 있습니다. 문서 컬렉션은 단일 데이터베이스 내에서 데이터를 분할하기 위한 자연스러운 메커니즘을 제공합니다. 분할을 구현하는 가장 간단한 방법은 각 분할된 데이터베이스에 대한 컬렉션을 만드는 것입니다. 컨테이너는 논리적 리소스이며 하나 이상의 서버에 걸쳐 있습니다. 고정 크기 컨테이너의 최대 제한은 20GB 및 10,000RU/s입니다. 무제한 컨테이너에는 최대 스토리지 크기가 없지만 파티션 키를 지정해야 합니다. 애플리케이션 분할을 사용하는 경우 클라이언트 애플리케이션은 일반적으로 분할된 데이터베이스 키를 정의하는 데이터의 일부 특성에 따라 자체 매핑 메커니즘을 구현하여 요청을 적절한 분할된 데이터베이스로 전달해야 합니다.

모든 데이터베이스는 Azure Cosmos DB 데이터베이스 계정의 컨텍스트에서 만들어집니다. 단일 계정에는 여러 데이터베이스가 포함될 수 있으며 데이터베이스가 생성되는 지역을 지정합니다. 또한 각 계정은 자체 액세스 제어를 적용합니다. Azure Cosmos DB 계정을 사용하여 액세스해야 하는 사용자와 가까운 분할된 데이터베이스(데이터베이스 내 컬렉션)를 지리적으로 찾고 해당 사용자만 연결할 수 있도록 제한을 적용할 수 있습니다.

NoSQL용 Azure Cosmos DB를 사용하여 데이터를 분할하는 방법을 결정할 때 다음 사항을 고려합니다.

• Azure Cosmos DB 데이터베이스에 사용할 수 있는 리소스에는 계정할당량 제한이 적용됩니다. 각 데이터베이스는 여러 컬렉션을 보유할 수 있으며 각 컬렉션은 해당 컬렉션에 대한 RU 속도 제한(예약된 처리량)을 제어하는 성능 수준과 연결됩니다. 자세한 내용은 azure 구독 및 서비스 제한, 할당량 및 제약 조건 참조하세요.

• 각 문서에는보관된 컬렉션 내에서 해당 문서를 고유하게 식별하는 데 사용할 수 있는 특성이 있어야 합니다. 이 특성은 문서를 보유하는 컬렉션을 정의하는 분할 키와 다릅니다. 컬렉션에는 많은 수의 문서가 포함될 수 있습니다. 이론적으로 문서 ID의 최대 길이로만 제한됩니다. 문서 ID는 최대 255자까지 가능합니다.

• 문서에 대한 모든 작업은 트랜잭션의 컨텍스트 내에서 수행됩니다. 트랜잭션의 범위는 문서가 포함된 컬렉션으로 지정됩니다. 작업이 실패하면 수행된 작업이 롤백됩니다. 문서에는 작업이 적용되지만 변경된 내용은 스냅샷 수준 격리의 적용을 받습니다. 이 메커니즘은 예를 들어 새 문서 만들기 요청이 실패하는 경우 데이터베이스를 동시에 쿼리하는 다른 사용자에게 제거된 부분 문서가 표시되지 않도록 보장합니다.

• 데이터베이스 쿼리는 컬렉션 수준범위가 지정됩니다. 단일 쿼리는 하나의 컬렉션에서만 데이터를 검색할 수 있습니다. 여러 컬렉션에서 데이터를 검색해야 하는 경우 각 컬렉션을 개별적으로 쿼리하고 결과를 애플리케이션 코드에 병합해야 합니다.

• Azure Cosmos DB는 문서함께 컬렉션에 모두 저장할 수 있는 프로그래밍 가능한 항목을 지원합니다. 여기에는 저장 프로시저, 사용자 정의 함수 및 트리거(JavaScript로 작성됨)가 포함됩니다. 이러한 항목은 동일한 컬렉션 내의 모든 문서에 액세스할 수 있습니다. 또한 이러한 항목은 앰비언트 트랜잭션의 범위 내에서(문서에 대해 수행된 만들기, 삭제 또는 바꾸기 작업의 결과로 발생하는 트리거의 경우) 또는 새 트랜잭션을 시작하여 실행됩니다(명시적 클라이언트 요청의 결과로 실행되는 저장 프로시저의 경우). 프로그래밍 가능한 항목의 코드가 예외를 throw하면 트랜잭션이 롤백됩니다. 저장 프로시저 및 트리거를 사용하여 문서 간의 무결성과 일관성을 유지할 수 있지만 이러한 문서는 모두 동일한 컬렉션의 일부여야 합니다.

• 데이터베이스에 보유하려는 컬렉션은컬렉션의 성능 수준에서 정의된 처리량 제한을 초과할 가능성이 낮습니다. 자세한 내용은 Azure Cosmos DB요청 단위를 참조하세요. 이러한 제한에 도달할 것으로 예상되는 경우 컬렉션당 부하를 줄이기 위해 여러 계정의 데이터베이스 간에 컬렉션을 분할하는 것이 좋습니다.

Azure AI Search 분할

데이터를 검색하는 기능은 종종 많은 웹 애플리케이션에서 제공하는 탐색 및 탐색의 기본 방법입니다. 사용자가 검색 조건의 조합에 따라 리소스를 빠르게 찾을 수 있습니다(예: 전자 상거래 애플리케이션의 제품). AI Search 서비스는 웹 콘텐츠에 대한 전체 텍스트 검색 기능을 제공하며, 미리 입력, 근거리 일치를 기반으로 하는 제안된 쿼리 및 패싯 탐색과 같은 기능을 포함합니다. 자세한 내용은 AI Search란?.

AI Search는 검색 가능한 콘텐츠를 데이터베이스에 JSON 문서로 저장합니다. 이러한 문서에서 검색 가능한 필드를 지정하고 AI Search에 이러한 정의를 제공하는 인덱스를 정의합니다. 사용자가 검색 요청을 제출하면 AI Search는 적절한 인덱스를 사용하여 일치하는 항목을 찾습니다.

경합을 줄이기 위해 AI Search에서 사용하는 스토리지를 1, 2, 3, 4, 6 또는 12 파티션으로 나눌 수 있으며 각 파티션을 최대 6번 복제할 수 있습니다. 복제본 수를 곱한 파티션 수의 곱을 SU(검색 단위). AI Search의 단일 인스턴스에는 최대 36개의 SU가 포함될 수 있습니다(파티션이 12개인 데이터베이스는 최대 3개의 복제본만 지원).

서비스에 할당된 각 SU에 대해 요금이 청구됩니다. 검색 가능한 콘텐츠의 양이 증가하거나 검색 요청 속도가 증가함에 따라 기존 AI Search 인스턴스에 SUS를 추가하여 추가 부하를 처리할 수 있습니다. AI Search 자체는 문서를 파티션 전체에 균등하게 배포합니다. 수동 분할 전략은 현재 지원되지 않습니다.

각 파티션은 최대 1,500만 개의 문서를 포함하거나 300GB의 스토리지 공간을 차지할 수 있습니다(중 더 작은 문서). 최대 50개의 인덱스를 만들 수 있습니다. 서비스의 성능은 문서의 복잡성, 사용 가능한 인덱스 및 네트워크 대기 시간의 영향에 따라 달라집니다. 평균적으로 단일 복제본(1 SU)은 QPS(초당 15개 쿼리)를 처리할 수 있어야 하지만, 보다 정확한 처리량을 얻기 위해 사용자 고유의 데이터로 벤치마킹을 수행하는 것이 좋습니다. 자세한 내용은 AI Search Service 제한을 참조하세요.

AI Search가 서비스의 각 인스턴스에 대한 데이터를 분할하는 방법을 제한했습니다. 그러나 글로벌 환경에서는 다음 전략 중 하나를 사용하여 서비스 자체를 분할하여 성능을 개선하고 대기 시간 및 경합을 더 줄일 수 있습니다.

• 각 지역에서 AI Search 인스턴스를 만들고 클라이언트 애플리케이션이 사용 가능한 가장 가까운 인스턴스로 전달되는지 확인합니다. 이 전략을 사용하려면 검색 가능한 콘텐츠에 대한 모든 업데이트가 서비스의 모든 인스턴스에서 적시에 복제되어야 합니다.

• AI Search의 두 계층을 만듭니다.

  • 해당 지역의 사용자가 가장 자주 액세스하는 데이터를 포함하는 각 지역의 로컬 서비스입니다. 사용자는 빠르고 제한된 결과를 위해 여기에 요청을 보낼 수 있습니다.
  • 모든 데이터를 포괄하는 전역 서비스입니다. 사용자는 느리지만 더 완전한 결과를 위해 여기에 요청을 보낼 수 있습니다.

이 방법은 검색 중인 데이터에 상당한 지역적 변형이 있는 경우에 가장 적합합니다.

Azure Cache for Redis 분할

Azure Cache for Redis는 Redis 키-값 데이터 저장소를 기반으로 하는 클라우드에서 공유 캐싱 서비스를 제공합니다. 이름에서 알 수 있듯이 Azure Cache for Redis는 캐싱 솔루션으로 사용됩니다. 영구 데이터 저장소가 아닌 일시적 데이터를 보유하는 경우에만 사용합니다. Azure Cache for Redis를 사용하는 애플리케이션은 캐시를 사용할 수 없는 경우 계속 작동할 수 있어야 합니다. Azure Cache for Redis는 고가용성을 제공하기 위해 기본/보조 복제를 지원하지만 현재 최대 캐시 크기를 53GB로 제한합니다. 이보다 더 많은 공간이 필요한 경우 추가 캐시를 만들어야 합니다. 자세한 내용은 Azure Cache for Redis를 참조하세요.

Redis 데이터 저장소를 분할하려면 Redis 서비스의 인스턴스 간에 데이터를 분할해야 합니다. 각 인스턴스는 단일 파티션을 구성합니다. Azure Cache for Redis는 외관 뒤에 Redis 서비스를 추상화하고 직접 노출하지 않습니다. 분할을 구현하는 가장 간단한 방법은 여러 Azure Cache for Redis 인스턴스를 만들고 데이터를 분산하는 것입니다.

각 데이터 항목을 데이터 항목을 저장하는 캐시를 지정하는 식별자(파티션 키)와 연결할 수 있습니다. 그런 다음 클라이언트 애플리케이션 논리는 이 식별자를 사용하여 요청을 적절한 파티션으로 라우팅할 수 있습니다. 이 체계는 매우 간단하지만 분할 체계가 변경되는 경우(예: 추가 Azure Cache for Redis 인스턴스가 만들어지는 경우) 클라이언트 애플리케이션을 다시 구성해야 할 수 있습니다.

Native Redis(Azure Cache for Redis 아님)는 Redis 클러스터링을 기반으로 서버 쪽 분할을 지원합니다. 이 방법에서는 해시 메커니즘을 사용하여 데이터를 서버 간에 균등하게 나눌 수 있습니다. 각 Redis 서버는 파티션이 보유하는 해시 키의 범위를 설명하는 메타데이터를 저장하고 다른 서버의 파티션에 있는 해시 키에 대한 정보도 포함합니다.

클라이언트 애플리케이션은 단순히 참여하는 Redis 서버(아마도 가장 가까운 서버)에 요청을 보냅니다. Redis 서버는 클라이언트 요청을 검사합니다. 로컬로 확인할 수 있는 경우 요청된 작업을 수행합니다. 그렇지 않으면 요청을 적절한 서버로 전달합니다.

이 모델은 Redis 클러스터링을 사용하여 구현되며 Redis 웹 사이트의 Redis 클러스터 자습서 페이지에 자세히 설명되어 있습니다. Redis 클러스터링이 클라이언트 애플리케이션에 투명합니다. 클라이언트를 다시 구성하지 않고도 클러스터에 추가 Redis 서버를 추가할 수 있으며 데이터를 다시 분할할 수 있습니다.

분할 페이지: Redis 웹 사이트의 여러 Redis 인스턴스 간에 데이터를 분할하는 방법은 Redis를 사용하여 분할을 구현하는 방법에 대한 자세한 정보를 제공합니다. 이 섹션의 나머지 부분에서는 클라이언트 쪽 또는 프록시 지원 분할을 구현한다고 가정합니다.

Azure Cache for Redis를 사용하여 데이터를 분할하는 방법을 결정할 때 다음 사항을 고려합니다.

• Azure Cache for Redis는 영구 데이터 저장소로 사용할 수 없으므로 구현하는 분할 체계가 무엇이든 애플리케이션 코드는 캐시가 아닌 위치에서 데이터를 검색할 수 있어야 합니다.

• 자주 함께 액세스하는 데이터는 동일한 파티션에 보관해야 합니다. Redis는 데이터를 구조화하기 위한 몇 가지 고도로 최적화된 메커니즘을 제공하는 강력한 키-값 저장소입니다. 이러한 메커니즘은 다음 중 하나일 수 있습니다.

  • 단순 문자열(길이가 512MB인 이진 데이터)
  • 목록과 같은 집계 형식(큐 및 스택으로 작동할 수 있는)
  • 집합(순서가 지정되고 순서가 지정되지 않음)
  • 해시(개체의 필드를 나타내는 항목과 같이 관련 필드를 함께 그룹화할 수 있음)

• 집계 형식을 사용하면 많은 관련 값을 동일한 키와 연결할 수 있습니다. Redis 키는 포함된 데이터 항목이 아닌 목록, 집합 또는 해시를 식별합니다. 이러한 형식은 모두 Azure Cache for Redis에서 사용할 수 있으며 Redis 웹 사이트의 데이터 형식 페이지에 설명되어 있습니다. 예를 들어 고객이 주문한 주문을 추적하는 전자 상거래 시스템의 일부에서 각 고객의 세부 정보는 고객 ID를 사용하여 키가 지정된 Redis 해시에 저장할 수 있습니다. 각 해시는 고객에 대한 주문 ID 컬렉션을 보유할 수 있습니다. 별도의 Redis 집합은 다시 해시로 구조화되고 주문 ID를 사용하여 키를 지정하여 주문을 보유할 수 있습니다. 그림 8은 이 구조를 보여줍니다. Redis는 어떤 형태의 참조 무결성도 구현하지 않으므로 고객과 주문 간의 관계를 유지하는 것은 개발자의 책임입니다.

고객 주문 및 세부 정보Suggested structure in Redis storage for recording customer orders and their details기록하기 위한 Redis Storage의제안된 구조

그림 8. 고객 주문 및 세부 정보를 기록하기 위한 Redis Storage의 제안된 구조입니다.

• 동일한 데이터베이스의 여러 집계에 관련 정보를 저장하여 수직 분할을 구현할 수 있습니다. 예를 들어 전자 상거래 애플리케이션에서 일반적으로 액세스하는 제품에 대한 정보를 한 Redis 해시에 저장하고 자주 사용되지 않은 자세한 정보를 다른 Redis 해시에 저장할 수 있습니다. 두 해시 모두 키의 일부로 동일한 제품 ID를 사용할 수 있습니다. 예를 들어 제품 정보에는 "product: nn" (여기서 nn 제품 ID)를 사용하고 자세한 데이터에는 "product_details: nn"를 사용할 수 있습니다. 이 전략은 대부분의 쿼리가 검색할 가능성이 있는 데이터의 양을 줄이는 데 도움이 될 수 있습니다.

• Redis 데이터 저장소를 다시 분할할 수 있지만 복잡하고 시간이 많이 걸리는 작업이라는 점에 유의하세요. Redis 클러스터링에서는 데이터를 자동으로 다시 분할할 수 있지만 Azure Cache for Redis에서는 이 기능을 사용할 수 없습니다. 따라서 분할 체계를 디자인할 때 시간이 지남에 따라 예상되는 데이터 증가를 허용하기 위해 각 파티션에 충분한 여유 공간을 남겨 둡니다. 그러나 Azure Cache for Redis는 데이터를 일시적으로 캐시하기 위한 것이며 캐시에 보관된 데이터는 TTL(Time-to-Live) 값으로 지정된 제한된 수명을 가질 수 있습니다. 상대적으로 휘발성 데이터의 경우 TTL은 짧을 수 있지만 정적 데이터의 경우 TTL이 훨씬 더 길어질 수 있습니다. 이 데이터의 볼륨이 캐시를 채울 가능성이 있는 경우 캐시에 많은 양의 수명이 긴 데이터를 저장하지 마세요. 공간이 프리미엄인 경우 Azure Cache for Redis에서 데이터를 제거하도록 하는 제거 정책을 지정할 수 있습니다.

  메모

  Azure Cache for Redis를 사용하는 경우 적절한 가격 책정 계층을 선택하여 캐시의 최대 크기(250MB에서 53GB)를 지정합니다. 그러나 Azure Cache for Redis를 만든 후에는 해당 크기를 늘리거나 줄일 수 없습니다.

• Redis 일괄 처리 및 트랜잭션은 여러 연결에 걸쳐 있을 수 없으므로 일괄 처리 또는 트랜잭션의 영향을 받는 모든 데이터는 동일한 데이터베이스(분할된 데이터베이스)에 보관해야 합니다.

  메모

  Redis 트랜잭션의 작업 시퀀스가 반드시 원자성인 것은 아닙니다. 트랜잭션을 구성하는 명령은 실행하기 전에 확인되고 큐에 대기됩니다. 이 단계에서 오류가 발생하면 전체 큐가 삭제됩니다. 그러나 트랜잭션이 성공적으로 제출된 후에는 큐에 대기 중인 명령이 순서대로 실행됩니다. 명령이 실패하면 해당 명령만 실행을 중지합니다. 큐의 모든 이전 및 후속 명령이 수행됩니다. 자세한 내용은 Redis 웹 사이트의 트랜잭션 페이지로 이동합니다.

• Redis는 제한된 수의 원자성 작업을 지원합니다. 여러 키와 값을 지원하는 이 형식의 유일한 작업은 MGET 및 MSET 작업입니다. MGET 작업은 지정된 키 목록에 대한 값 컬렉션을 반환하고 MSET 작업은 지정된 키 목록에 대한 값 컬렉션을 저장합니다. 이러한 작업을 사용해야 하는 경우 MSET 및 MGET 명령에서 참조하는 키-값 쌍을 동일한 데이터베이스 내에 저장해야 합니다.

Azure Service Fabric 분할

Azure Service Fabric은 클라우드의 분산 애플리케이션에 대한 런타임을 제공하는 마이크로 서비스 플랫폼입니다. Service Fabric은 .NET 게스트 실행 파일, 상태 저장 및 상태 비국적 서비스 및 컨테이너를 지원합니다. 상태 저장 서비스는 Service Fabric 클러스터 내의 키-값 컬렉션에 데이터를 영구적으로 저장하는 신뢰할 수 있는 컬렉션 제공합니다. 신뢰할 수 있는 컬렉션에서 키를 분할하는 전략에 대한 자세한 내용은 지침 및 Azure Service Fabric신뢰할 수 있는 컬렉션에 대한 권장 사항을 참조하세요.

다음 단계

• Azure Service Fabric 개요는 Azure Service Fabric에 대한 소개입니다.

• Partition Service Fabric 신뢰할 수 있는 서비스 Azure Service Fabric의 신뢰할 수 있는 서비스에 대한 자세한 정보를 제공합니다.

Azure Event Hubs 분할

Azure Event Hubs 대규모로 데이터 스트리밍을 위해 설계되었으며 수평적 크기 조정을 사용하도록 분할이 서비스에 기본 제공되었습니다. 각 소비자는 메시지 스트림의 특정 파티션만 읽습니다.

이벤트 게시자는 이벤트를 게시하는 파티션이 아니라 파티션 키만 인식합니다. 이렇게 키와 파티션을 분리하면 발신자가 다운스트림 처리에 대해 너무 많이 알 필요가 없습니다. (지정된 파티션에 직접 이벤트를 보낼 수도 있지만 일반적으로 권장되지는 않습니다.)

파티션 수를 선택할 때 장기 규모를 고려합니다. 이벤트 허브를 만든 후에는 파티션 수를 변경할 수 없습니다.

다음 단계

Event Hubs에서 파티션을 사용하는 방법에 대한 자세한 내용은 Event Hubs란?을 참조하세요..

가용성과 일관성 간의 장차에 대한 고려 사항은 Event Hubs 가용성 및 일관성을 참조하세요.