데이터 분할에 대한 권장 사항

아티클
11/15/2023

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:06	애플리케이션, 데이터 및 인프라 수준에서 시기 적절하게 안정적인 크기 조정 전략을 구현합니다.

관련 가이드:크기 조정

이 가이드에서는 배포하는 데이터베이스 및 데이터 스토리지 기술에 대한 데이터 분할 전략을 설계하기 위한 권장 사항을 설명합니다. 이 전략은 데이터 자산의 안정성을 개선하는 데 도움이 됩니다.

주요 디자인 전략

많은 대규모 솔루션에서 파티션 은 데이터를 별도로 관리하고 액세스할 수 있도록 데이터를 나누는 데 사용됩니다. 데이터를 분할하면 확장성이 향상되고 경합이 감소하며 성능이 최적화됩니다. 데이터 분할을 구현하여 사용 패턴으로 데이터를 나눕니다. 예를 들어 저렴한 데이터 스토리지에 이전 데이터를 보관할 수 있습니다. 분할 전략을 신중하게 선택하여 이점을 최대화하고 부작용을 최소화합니다.

참고

이 문서에서 용어 분할은 데이터를 별도의 데이터 저장소에 물리적으로 나누는 프로세스를 의미합니다. SQL Server 테이블 분할과 다릅니다.

데이터를 분할하는 이유

확장성 향상. 단일 데이터베이스 시스템을 스케일 업하면 데이터베이스가 결국 물리적 하드웨어 제한에 도달합니다. 별도의 서버에서 호스트되는 각 파티션을 사용하여 여러 파티션 간에 데이터를 나누는 경우 시스템을 거의 무기한으로 확장할 수 있습니다.
성능 향상 각 파티션에서 데이터 액세스 작업은 분할되지 않은 데이터에 비해 적은 양의 데이터에 대해 수행됩니다. 데이터를 분할하여 시스템을 보다 효율적으로 만듭니다. 둘 이상의 파티션에 영향을 주는 작업은 병렬로 실행할 수 있습니다.
보안 기능 향상. 경우에 따라 민감하고 민감하지 않은 데이터를 다른 파티션으로 분리하고 중요한 데이터에 다른 보안 제어를 적용할 수 있습니다.
유연한 운영. 데이터를 분할하여 작업을 미세 조정하고, 관리 효율성을 최대화하고, 비용을 최소화할 수 있습니다. 예를 들어 각 파티션의 데이터 중요도에 따라 관리, 모니터링, 백업 및 복원 및 기타 관리 작업에 대한 전략을 정의할 수 있습니다.
사용 패턴에 맞게 데이터 저장소 조정. 데이터 저장소에서 제공하는 비용 및 기본 제공 기능에 따라 각 파티션을 다른 유형의 데이터 저장소에 배포할 수 있습니다. 예를 들어 Blob Storage에 큰 이진 데이터를 저장하고 구조적 데이터를 문서 데이터베이스에 저장할 수 있습니다. 자세한 내용은 데이터 저장소 모델 이해를 참조하세요.
가용성 향상. 단일 실패 지점을 방지하기 위해 여러 서버에서 데이터를 분리할 수 있습니다. 한 인스턴스가 실패하면 해당 파티션의 데이터만 사용할 수 없게 됩니다. 작업은 다른 파티션에서 계속됩니다. 이 고려 사항은 기본 제공 중복성이 있으므로 PaaS(관리형 PaaS) 데이터 저장소와 관련이 적습니다.

파티션 디자인

데이터를 분할하는 세 가지 일반 전략이 있습니다.

행 분할(일반적으로 분할이라고 함). 이 전략에서는 각 파티션이 별도의 데이터 저장소이지만, 모든 파티션의 스키마가 동일합니다. 각 파티션을 분할 된 데이터베이스라고 하며 고객 주문 집합과 같은 데이터의 하위 집합을 보유합니다.
수직 분할 이 전략에서는 각 파티션에 데이터 저장소의 항목 필드 하위 집합이 보관됩니다. 필드는 해당 사용 패턴에 따라 구분됩니다. 예를 들어 자주 액세스되는 필드가 하나의 수직 분할에 배치되고 덜 자주 액세스되는 필드가 또 다른 수직 분할에 배치됩니다.
기능 분할. 이 전략에서 데이터는 시스템의 각 바인딩된 컨텍스트에서 데이터를 사용하는 방법에 따라 집계됩니다. 예를 들어 전자상거래 시스템에서 청구서 데이터와 제품 재고 데이터를 서로 다른 파티션에 저장할 수 있습니다.

분할 체계를 디자인할 때 이러한 전략을 결합하는 것이 좋습니다. 예를 들어, 데이터를 분할된 데이터베이스에 나눈 후 각각의 분할된 데이터베이스에서 수직 분할을 사용하여 데이터를 더 세분화할 수 있습니다.

행 분할(분할)

다음 이미지는 가로 분할 또는 분할의 예를 보여줍니다. 이 예제에서는 제품 인벤토리 데이터를 제품 키를 기반으로 하는 분할된 데이터베이스로 나눕니다. 각각의 분할된 데이터베이스에는 연속된 분할 키 범위(A-G 및 H-Z)별로 데이터가 사전순으로 정렬되어 있습니다. 분할을 수행하면 더 많은 컴퓨터에 부하가 분산되어 경합이 줄어들고 성능이 향상됩니다.

가장 중요한 요소는 선택한 분할 키입니다. 시스템이 작동된 후에는 키를 변경하기 어려울 수 있습니다. 키는 분할된 데이터베이스에 워크로드가 최대한 균등하게 분산되도록 데이터를 분할해야 합니다.

분할된 데이터베이스의 크기가 같을 필요는 없습니다. 요청 수의 균형을 맞추는 것이 더 중요합니다. 일부 분할된 데이터베이스는 클 수 있지만 분할된 데이터베이스의 각 항목에는 적은 수의 액세스 작업이 있습니다. 다른 분할된 데이터베이스는 더 작을 수 있지만 분할된 데이터베이스의 각 항목은 더 자주 액세스됩니다. 또한 단일 분할된 데이터베이스가 데이터 저장소의 용량 및 처리 리소스 측면에서 크기 제한을 초과하지 않도록 하는 것이 중요합니다.

성능 및 가용성에 영향을 줄 수 있는 핫 파티션을 만들지 않습니다. 예를 들어 고객 이름의 첫 글자를 사용하는 경우 일부 문자가 다른 문자보다 더 일반적이기 때문에 불균형 배포를 만들 수 있습니다. 대신 고객 식별자 해시를 사용하여 파티션 간에 데이터를 균등하게 분산합니다.

나중에 큰 분할된 데이터베이스를 분할하거나, 작은 분할된 데이터베이스를 더 큰 파티션으로 결합하거나, 스키마를 변경해야 할 필요성을 최소화하는 분할 키를 선택합니다. 이러한 작업은 시간이 오래 걸리며 하나 이상의 분할된 데이터베이스를 오프라인으로 전환해야 할 수 있습니다.

분할된 데이터베이스가 복제된 경우 일부 복제본은 온라인 상태로 유지하고 다른 복제본은 분할, 병합 또는 다시 구성할 수 있습니다. 그러나 시스템은 재구성 중에 수행할 수 있는 작업을 제한할 수 있습니다. 예를 들어 데이터 불일치를 방지하기 위해 복제본의 데이터를 읽기 전용으로 표시할 수 있습니다.

자세한 내용은 분할 패턴을 참조하세요.

수직 분할

수직 분할의 가장 일반적인 용도는 자주 액세스하는 항목 가져오기와 관련된 I/O 및 성능 비용을 줄이는 것입니다. 다음 이미지는 수직 분할의 예를 보여줍니다. 이 예제에서는 한 항목의 여러 속성이 서로 다른 파티션에 저장됩니다. 하나의 파티션은 제품 이름, 설명 및 가격을 포함하여 더 자주 액세스되는 데이터를 보유합니다. 또 다른 파티션은 재고 수 및 마지막 주문 날짜를 포함한 재고 데이터를 보유합니다.

이 예제에서 애플리케이션은 고객에게 제품 세부 정보를 표시할 때 제품 이름, 설명 및 가격을 정기적으로 쿼리합니다. 이러한 두 항목은 일반적으로 함께 사용되므로 주식 수와 마지막 주문 날짜는 별도의 파티션에 있습니다.

수직 분할의 다음과 같은 장점을 참조하세요.

상대적으로 느리게 움직이는 데이터(제품 이름, 설명 및 가격)를 보다 동적 데이터(주식 수준 및 마지막 주문 날짜)와 분리할 수 있습니다. 느린 이동 데이터는 애플리케이션이 메모리에 캐시할 수 있는 좋은 후보입니다.
보안 컨트롤이 추가된 별도의 파티션에 중요한 데이터를 저장할 수 있습니다.
수직 분할은 필요한 동시 액세스의 양을 줄일 수 있습니다.

수직 분할은 데이터 저장소에서 엔터티 수준으로 수행되며, 특히 엔터티를 부분적으로 정규화하여 범위가 넓은 항목을 범위가 좁은 항목 집합으로 분할합니다. HBase 및 Cassandra와 같은 열 지향 데이터 저장소에 이상적으로 적합합니다. 열 컬렉션의 데이터가 변경되지 않을 경우 SQL Server 열 저장소를 사용하는 것이 좋습니다.

기능 분할

애플리케이션의 각 고유한 비즈니스 영역에 대해 제한된 컨텍스트를 식별할 수 있는 경우 기능 분할은 격리 및 데이터 액세스 성능을 향상시킬 수 있습니다. 기능 분할의 또 다른 일반적인 용도는 읽기 전용 데이터에서 읽기-쓰기 데이터를 분리하는 것입니다. 다음 이미지는 인벤토리 데이터가 고객 데이터와 분리된 기능 분할에 대한 개요를 보여줍니다.

이러한 분할 전략은 시스템의 여러 부분에서 데이터 액세스 경합을 줄일 수 있습니다.

확장성을 위한 파티션 디자인

각 파티션의 크기와 워크로드를 고려하는 것이 중요합니다. 최대 확장성을 달성하기 위해 데이터가 분산되도록 균형을 조정합니다. 그러나 단일 파티션 저장소의 크기 조정 제한을 초과하지 않도록 데이터를 분할해야 합니다.

확장성을 위해 파티션을 디자인할 때 다음 단계를 수행합니다.

애플리케이션을 분석하여 각 쿼리가 반환하는 결과 집합의 크기, 액세스 빈도, 내재된 대기 시간 및 서버 쪽 컴퓨팅 처리 요구 사항과 같은 데이터 액세스 패턴을 이해합니다. 대부분의 경우 일부 주요 엔터티는 대부분의 처리 리소스를 요구합니다.
이 분석을 사용하여 데이터 크기 및 워크로드와 같은 현재 및 향후 확장성 목표를 결정합니다. 그런 다음 확장성 목표에 맞도록 데이터를 파티션에 분산합니다. 가로 분할의 경우 올바른 분할 키를 선택하여 균등한 분산을 보장합니다. 자세한 내용은 분할 패턴을 참조하세요.
각 파티션에 데이터 크기 및 처리량 측면에서 확장성 요구 사항을 처리할 수 있는 충분한 리소스가 있는지 확인합니다. 데이터 저장소에 따라 스토리지 공간, 처리 능력 또는 네트워크 대역폭의 양에 대해 각 파티션에 대한 제한이 있을 수 있습니다. 요구 사항이 이러한 제한을 초과할 가능성이 있는 경우 분할 전략을 구체화하거나 데이터를 추가로 분할해야 할 수 있습니다. 두 개 이상의 전략을 결합해야 할 수도 있습니다.
시스템을 모니터링하여 데이터가 예상대로 분산되는지, 파티션에서 부하를 처리할 수 있는지 확인합니다. 실제 사용량이 분석에서 예측하는 것과 항상 일치하지는 않습니다. 필요한 균형을 얻으려면 파티션의 균형을 조정하거나 시스템의 일부 부분을 다시 디자인해야 할 수 있습니다.

일부 클라우드 환경에서는 인프라 경계에 따라 리소스를 할당합니다. 선택한 경계의 한도가 데이터 볼륨, 데이터 스토리지, 처리 능력 및 대역폭의 예상 증가에 충분한 공간을 제공하는지 확인합니다.

예를 들어 Azure Table Storage를 사용하는 경우 단일 파티션이 특정 기간에 처리할 수 있는 요청 볼륨에 제한이 있습니다. 자세한 내용은 표준 스토리지 계정의 확장성 및 성능 목표를 참조하세요. 사용 중인 분할된 데이터베이스는 단일 파티션에서 처리할 수 있는 양보다 더 많은 리소스를 요구합니다. 부하를 분산하려면 분할된 데이터베이스를 다시 분할해야 할 수 있습니다. 이러한 테이블의 총 크기 또는 처리량이 스토리지 계정의 용량을 초과하는 경우 더 많은 스토리지 계정을 만들고 이러한 계정에 테이블을 분산해야 할 수 있습니다.

쿼리 성능을 위한 파티션 디자인

작은 데이터 세트를 사용하고 병렬 쿼리를 실행하여 쿼리 성능을 높일 수 있습니다. 각 파티션은 전체 데이터 세트의 작은 비율을 포함해야 합니다. 이렇게 볼륨이 감소하면서 쿼리 성능이 개선될 수 있습니다. 그러나 분할은 적절한 데이터베이스 디자인 및 구성의 대안이 아닙니다. 필요한 인덱스를 구현해야 합니다.

쿼리 성능을 위해 파티션을 디자인할 때 다음 단계를 수행합니다.

애플리케이션 요구 사항 및 성능을 검사합니다.
- 비즈니스 요구 사항을 사용하여 항상 신속하게 수행해야 하는 중요 쿼리를 결정합니다.
- 시스템을 모니터링하여 느리게 수행되는 쿼리를 식별합니다.
- 가장 자주 수행하는 쿼리를 결정합니다. 단일 쿼리에 최소한의 비용이 있더라도 누적 리소스 사용량이 클 수 있습니다.
성능 저하를 일으키는 데이터를 분할합니다.
- 쿼리 응답 시간이 목표 범위에 해당하도록 각 파티션 크기를 제한합니다.
- 수평 분할을 사용하는 경우 애플리케이션이 적절한 파티션을 쉽게 선택할 수 있도록 분할 키를 디자인합니다. 이 사양은 쿼리가 모든 파티션을 검사하지 못하도록 합니다.
- 파티션의 위치를 고려합니다. 데이터에 액세스하는 애플리케이션 및 사용자와 지리적으로 가까운 파티션에 데이터를 유지합니다.
엔터티에 처리량 및 쿼리 성능 요구 사항이 있는 경우 해당 엔터티를 기반으로 하는 기능 분할을 사용합니다. 이 할당이 여전히 요구 사항을 충족하지 않는 경우 수평 분할을 추가할 수 있습니다. 단일 분할 전략은 일반적으로 적절하지만 경우에 따라 두 전략을 결합하는 것이 더 효율적입니다.
성능을 향상시키기 위해 파티션 간에 쿼리를 병렬로 실행합니다.

가용성을 위한 파티션 디자인

데이터를 분할하여 애플리케이션의 가용성을 개선합니다. 분할하면 전체 데이터 세트에 단일 실패 지점이 없으며 데이터 세트의 개별 하위 집합을 독립적으로 관리할 수 있습니다.

가용성에 영향을 주는 다음 요인을 고려합니다.

데이터의 중요도를 결정합니다. 트랜잭션과 같은 중요한 비즈니스 데이터와 로그 파일과 같은 덜 중요한 운영 데이터를 식별합니다.

고가용성 파티션에 중요한 데이터를 저장하고 적절한 백업 계획을 만듭니다.
다양한 데이터 세트에 대한 별도의 관리 및 모니터링 절차를 설정합니다.
동일한 수준의 중요도를 포함하는 데이터를 동일한 빈도로 백업할 수 있도록 동일한 파티션에 배치합니다. 예를 들어 로깅 또는 추적 정보를 보유하는 파티션보다 트랜잭션 데이터를 더 자주 보유하는 파티션을 백업해야 할 수 있습니다.

개별 파티션을 관리합니다. 독립적인 관리 및 유지 관리를 지원하도록 파티션을 디자인합니다. 이 방법은 다음과 같은 몇 가지 이점을 제공합니다.

한 파티션이 실패하는 경우 다른 파티션에 있는 데이터에 액세스하는 애플리케이션 없이 파티션을 독립적으로 복구할 수 있습니다.
지리적 영역별로 데이터를 분할하면 예약된 유지 관리 작업이 각 위치에 대해 사용량이 많은 시간에 발생할 수 있습니다. 파티션이 너무 커서 이 기간 동안 계획된 유지 관리가 완료되지 않도록 합니다.

파티션 간에 중요한 데이터를 복제합니다. 이 전략은 가용성과 성능을 향상하지만 일관성 문제를 발생시킬 수도 있습니다. 모든 복제본과 변경 내용을 동기화하려면 시간이 걸립니다. 동기화하는 동안 다른 파티션에는 서로 다른 데이터 값이 포함됩니다.

애플리케이션 디자인 고려 사항

분할을 사용하면 시스템 디자인 및 개발이 더 복잡해집니다. 시스템이 처음에 단일 파티션만 포함하는 경우에도 시스템 디자인의 기본 부분으로 데이터를 분할합니다. 분할을 사후 고려로 해결하는 경우 이미 유지 관리할 라이브 시스템이 있기 때문에 어려운 일입니다. 다음을 수행할 수 있습니다.

데이터 액세스 논리를 수정해야 합니다.
파티션에 분산하려면 대량의 기존 데이터를 마이그레이션해야 합니다.
사용자가 마이그레이션 중에 시스템을 계속 사용할 것으로 예상하기 때문에 문제가 발생합니다.

초기 데이터 세트가 작고 단일 서버에서 쉽게 처리할 수 있으므로 분할이 중요하지 않은 경우도 있습니다. 일부 워크로드는 파티션 없이 진행될 수 있지만 사용자 수가 증가함에 따라 많은 상용 시스템을 확장해야 합니다.

일부 소규모 데이터 저장소는 분할의 이점을 누릴 수도 있습니다. 예를 들어 수백 개의 동시 클라이언트가 작은 데이터 저장소에 액세스할 수 있습니다. 이 상황에서 데이터를 분할하면 경합을 줄이고 처리량을 개선하는 데 도움이 될 수 있습니다.

데이터 파티션 구성표를 설계할 때 다음 사항을 고려하세요.

파티션 간 데이터 액세스 작업을 최소화합니다. 파티션 간 데이터 액세스 작업을 최소화하기 위해 가장 일반적인 데이터베이스 작업에 대한 데이터를 파티션에 함께 유지합니다. 단일 파티션 내에서 쿼리하는 것보다 파티션 간에 쿼리하는 데 시간이 더 오래 걸릴 수 있습니다. 그러나 한 쿼리 집합에 대해 파티션을 최적화하면 다른 쿼리 집합에 부정적인 영향을 줄 수 있습니다. 여러 파티션에서 쿼리해야 하는 경우 병렬 쿼리를 실행하고 애플리케이션 내에서 결과를 집계하여 쿼리 시간을 최소화합니다. 예를 들어 한 쿼리의 결과가 다음 쿼리에서 사용되는 경우와 같이 이 방법을 사용할 수 없는 경우도 있습니다.

정적 참조 데이터를 복제합니다. 쿼리에서 우편 번호 테이블 또는 제품 목록과 같이 비교적 정적인 참조 데이터를 사용하는 경우 모든 파티션에서 이 데이터를 복제하여 다른 파티션에서 별도의 조회 작업을 줄이는 것이 좋습니다. 또한 이 방법을 사용하면 참조 데이터가 전체 시스템에서 트래픽이 많은 핫 데이터 세트가 될 가능성을 줄일 수 있습니다. 참조 데이터에 대한 변경 내용 동기화와 관련된 추가 비용이 있습니다.

파티션 간 조인을 최소화합니다. 가능하면 수직 파티션과 기능 파티션 간 참조 무결성 요구 사항을 최소화합니다. 이 구성표에서 애플리케이션은 파티션 간 참조 무결성을 유지하는 책임을 맡습니다. 애플리케이션은 일반적으로 키와 외래 키를 기반으로 하는 연속 쿼리를 수행하므로 여러 파티션에서 데이터를 조인하는 쿼리는 비효율적입니다. 대신, 관련 데이터를 복제하거나 비정규화하는 것이 좋습니다. 파티션 간 조인이 필요한 경우 파티션에 병렬 쿼리를 실행하고 애플리케이션으로 데이터를 조인합니다.

결과적 일관성 보장. 강력한 일관성이 요구 사항인지 평가합니다. 분산 시스템에서는 일반적으로 최종 일관성을 구현합니다. 각 파티션의 데이터는 별도로 업데이트되고 애플리케이션 논리는 업데이트가 성공적으로 완료되도록 합니다. 또한 애플리케이션 논리는 최종적으로 일관된 작업이 실행되는 동안 데이터 쿼리에서 발생하는 불일치를 처리합니다.

쿼리가 올바른 파티션을 찾는 방법을 고려합니다. 쿼리가 필요한 데이터를 찾기 위해 모든 파티션을 검색해야 하는 경우 여러 병렬 쿼리가 실행되는 경우에도 성능에 큰 영향을 줍니다. 수직 및 기능 분할을 사용하면 쿼리에서 파티션을 지정할 수 있습니다. 반면에 가로 분할은 모든 분할된 데이터베이스에 동일한 스키마가 있기 때문에 항목 찾기를 어렵게 만들 수 있습니다. 일반적인 솔루션은 항목의 분할된 데이터베이스 위치를 조회하는 데 사용되는 맵을 유지하는 것입니다. 애플리케이션의 분할 논리에서 이 맵을 구현합니다. 데이터 저장소가 투명한 분할을 지원하는 경우 데이터 저장소에서 유지 관리할 수도 있습니다.

분할된 데이터베이스의 균형을 주기적으로 조정합니다. 수평 분할을 사용하면 분할된 데이터베이스를 리밸런싱하면 크기 및 워크로드별로 데이터를 균등하게 분산하는 데 도움이 될 수 있습니다. 분할된 데이터베이스의 균형을 조정하여 핫스폿을 최소화하고 쿼리 성능을 최대화하며 물리적 스토리지 제한 사항을 해결합니다. 이 작업은 복잡하며 사용자 지정 도구 또는 프로세스가 필요한 경우가 많습니다.

파티션을 복제합니다. 각 파티션을 복제하여 실패에 대한 추가 보호를 제공합니다. 단일 복제본(replica) 실패하면 쿼리가 작업 복사본으로 전달됩니다.

확장성을 다른 수준으로 확장합니다. 분할 전략의 물리적 한도에 도달하면 확장성을 다른 수준으로 확장해야 합니다. 예를 들어 분할을 데이터베이스 수준에서 수행하는 경우 파티션을 여러 데이터베이스에 배치 또는 복제해야 할 수 있습니다. 분할이 이미 데이터베이스 수준에 있고 물리적 제한 사항이 있는 경우 여러 호스팅 계정에서 파티션을 찾거나 복제해야 할 수 있습니다.

트랜잭션이 여러 파티션에 있는 데이터에 액세스하지 않도록 합니다. 일부 데이터 저장소는 데이터가 단일 파티션에 있는 경우에만 데이터를 수정하는 작업에 대한 트랜잭션 일관성 및 무결성을 구현합니다. 여러 파티션에서 트랜잭션 지원이 필요한 경우 대부분의 분할 시스템이 네이티브 지원을 제공하지 않으므로 애플리케이션 논리의 일부로 구현합니다.

모든 데이터 저장소에는 몇 가지 운영 관리 및 모니터링 활동이 필요합니다. 이러한 작업에는 데이터 로드, 데이터 백업 및 복원, 데이터 재구성, 시스템이 정확하고 효율적으로 수행되도록 하는 작업이 포함됩니다.

운영 관리에 영향을 주는 다음 요인을 고려하도록 합니다.

데이터가 분할될 때 적절한 관리 및 운영 작업을 구현합니다. 이러한 작업에는 백업 및 복원, 데이터 보관, 시스템 모니터링 및 기타 관리 작업이 포함될 수 있습니다. 예를 들어 백업 및 복원 작업 중에 논리적 일관성을 유지하는 것은 어려울 수 있습니다.
여러 파티션에 데이터를 로드하고 다른 원본에서 제공되는 새 데이터를 추가합니다. 일부 도구 및 유틸리티는 데이터를 올바른 파티션에 로드하는 것과 같이 분할된 데이터 작업을 지원하지 않을 수 있습니다.
정기적으로 데이터를 보관하고 삭제합니다. 파티션의 과도한 증가를 방지하려면 매월 데이터를 보관하고 삭제합니다. 다른 보관 스키마와 일치하도록 데이터를 변환해야 할 수 있습니다.
데이터 무결성 문제를 찾습니다. 한 파티션의 데이터와 같이 다른 파티션의 누락된 정보를 참조하는 데이터와 같은 데이터 무결성 문제를 찾기 위해 주기적인 프로세스를 실행하는 것이 좋습니다. 프로세스는 이러한 문제를 자동으로 해결하려고 시도하거나 수동 검토를 위해 보고서를 생성할 수 있습니다.

파티션 리밸런스

시스템이 성숙함에 따라 파티션 구성표를 조정해야 할 수도 있습니다. 예를 들어 개별 파티션이 불균형한 트래픽 볼륨을 수신하기 시작하고 뜨거워서 과도한 경합이 발생할 수 있습니다. 또는 파티션이 용량 제한에 근접하게 하는 일부 파티션의 데이터 볼륨을 과소 평가했을 수 있습니다.

Azure Cosmos DB 같은 일부 데이터 저장소는 자동으로 파티션을 리밸런싱할 수 있습니다. 다른 경우에는 두 단계로 파티션의 균형을 조정할 수 있습니다.

새로운 분할 전략을 결정합니다.
- 분할 또는 결합해야 하는 파티션은 무엇입니까?
- 새 파티션 키는 무엇인가요?
기존 파티션 구성표의 데이터를 새 파티션 집합으로 마이그레이션합니다.

오프라인 마이그레이션이라고 하는 데이터를 재배치하는 동안 파티션을 사용할 수 없도록 해야 할 수 있습니다. 데이터 저장소에 따라 파티션이 사용 중인 동안 데이터를 마이그레이션할 수 있습니다. 이 기술을 온라인 마이그레이션이라고 합니다.

오프라인 마이그레이션

오프라인 마이그레이션은 경합이 발생할 가능성을 줄입니다. 오프라인 마이그레이션을 수행하려면 다음을 수행합니다.

파티션을 오프라인으로 표시합니다. 파티션을 이동하는 동안 애플리케이션이 데이터를 계속 읽을 수 있도록 파티션을 읽기 전용으로 표시할 수 있습니다.
데이터를 분할-병합한 후 새 파티션으로 이동합니다.
데이터 확인
새 파티션을 온라인으로 전환합니다.
기존 파티션을 제거합니다.

온라인 마이그레이션

온라인 마이그레이션은 오프라인 마이그레이션에 비해 더 복잡하지만 중단이 적습니다. 이 프로세스는 오프라인 마이그레이션과 비슷하지만 원래 파티션을 오프라인으로 표시하지는 않습니다. 마이그레이션 프로세스의 세분성(예: 항목별 항목 및 분할된 데이터베이스별 분할된 데이터베이스)에 따라 클라이언트 애플리케이션의 데이터 액세스 코드는 원래 파티션과 새 파티션의 두 위치에 있는 데이터를 읽고 작성해야 할 수 있습니다.

Azure 촉진

다음 섹션에서는 Azure 서비스에 저장된 데이터를 분할하기 위한 권장 사항을 설명합니다.

Azure SQL Database의 파티션

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

탄력적 풀은 SQL 데이터베이스에 수평 확장을 지원합니다. 탄력적 풀을 사용하여 데이터를 여러 SQL 데이터베이스에 분산된 분할된 데이터베이스로 분할합니다. 데이터 볼륨이 증가하고 축소됨에 따라 분할된 데이터베이스를 추가하거나 제거할 수도 있습니다. 탄력적 풀은 여러 데이터베이스에 부하를 분산하여 경합을 줄일 수도 있습니다.

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

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

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

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

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

Elastic Database는 다음과 같이 shardlet에 데이터를 매핑하고 분할된 데이터베이스에 저장할 수 있는 두 가지 구성표를 제공합니다.

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

이 다이어그램의 Visio 파일을 다운로드합니다.
범위 분할된 데이터베이스 맵은 연속 키 값 집합을 shardlet과 연결합니다. 예를 들어 동일한 shardlet 내에서 각각 고유한 키를 사용하여 테넌트 집합에 대한 데이터를 그룹화할 수 있습니다. 이 체계는 테넌트가 데이터 스토리지를 공유하지만 격리를 덜 제공하기 때문에 목록 분할된 데이터베이스 맵보다 비용이 적게 듭니다.

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

분할된 데이터베이스 하나에 여러 shardlet의 데이터가 포함될 수 있습니다. 예를 들어 목록 shardlet을 사용하여 연속되지 않은 다양한 테넌트 데이터를 동일한 분할된 데이터베이스에 저장할 수 있습니다. 범위 shardlet과 목록 shardlet을 동일한 분할된 데이터베이스에 혼합할 수도 있지만 다른 맵을 통해 처리됩니다. 다음 다이어그램은 이 방법을 보여줍니다.

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

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

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

파티션 구성표는 시스템 성능에 상당한 영향을 미칠 수 있습니다. 분할된 데이터베이스를 추가하거나 제거해야 하는 속도 또는 데이터를 분할된 데이터베이스에 다시 분할해야 하는 속도에도 영향을 미칠 수 있습니다. 다음 사항을 고려합니다.

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

SQL Database 데이터베이스 간 조인을 지원하지 않지만 Elastic Database 도구를 사용하여 다중 분할된 데이터베이스 쿼리를 수행할 수 있습니다. 다중 분할된 데이터베이스 쿼리는 각 데이터베이스에 개별 쿼리를 보내고 결과를 병합합니다.
분할된 데이터베이스 간에 종속성이 없는 시스템을 디자인합니다. 한 데이터베이스의 참조 무결성 제약 조건, 트리거 및 저장 프로시저는 다른 데이터베이스의 개체를 참조할 수 없습니다.
쿼리에서 자주 사용하는 참조 데이터가 있는 경우 분할된 데이터베이스 간에 데이터를 복제하는 것이 좋습니다. 이 방법을 사용하면 데이터베이스 간에 데이터를 조인할 필요가 없습니다. 복제 작업을 최소화하고 부실해질 가능성을 줄이려면 이러한 데이터가 정적이거나 느리게 이동해야 하는 것이 이상적입니다.
동일한 분할된 데이터베이스 맵에 속하는 shardlet에 대해 동일한 스키마를 사용합니다. 이 지침은 SQL Database 적용되지 않지만 각 shardlet에 다른 스키마가 있는 경우 데이터 관리 및 쿼리가 복잡합니다. 대신, 각 스키마에 대한 별도의 분할된 데이터베이스 맵을 만드세요. 다른 shardlet에 속한 데이터를 동일한 분할된 데이터베이스에 저장할 수 있습니다.
비즈니스 논리가 트랜잭션을 수행해야 하는 경우 동일한 분할된 데이터베이스에 데이터를 저장하거나 최종 일관성을 구현합니다. 트랜잭션 작업은 분할된 데이터베이스가 아닌 분할된 데이터베이스에 있는 데이터에 대해서만 지원됩니다. 트랜잭션은 동일한 분할된 데이터베이스의 일부인 경우 shardlet에 걸쳐 있을 수 있습니다.
분할된 데이터베이스는 해당 분할된 데이터베이스의 데이터에 액세스하는 사용자와 가깝게 배치합니다. 이 전략은 대기 시간을 줄이는 데 도움이 됩니다.
매우 활성 상태이고 상대적으로 비활성 분할된 데이터베이스의 조합은 사용하지 않습니다. 분할된 데이터베이스 간에 부하를 균등하게 분산하려고 합니다. 분할 키를 해시해야 할 수 있습니다. 분할된 데이터베이스를 지리적으로 찾는 경우 해시된 키가 해당 데이터에 액세스하는 사용자 가까이에 저장된 분할된 데이터베이스에 보관된 shardlet에 매핑되는지 확인합니다.

Azure Blob Storage 파티션

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

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

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

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

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

고려 사항

데이터 분할은 고려해야 할 몇 가지 과제와 복잡성을 도입합니다.

파티션 간의 데이터 동기화는 문제가 될 수 있습니다. 한 파티션에 대한 업데이트 또는 변경 내용이 시기적절하고 일관된 방식으로 다른 파티션으로 전파되는지 확인합니다.
장애 조치(failover) 및 재해 복구 프로세스는 여러 파티션의 백업 및 복원을 조정해야 할 때 복잡해집니다. 일부 파티션 또는 해당 백업이 손상되었거나 사용할 수 없는 경우 데이터 무결성 문제가 발생할 수 있습니다.
데이터 분할은 파티션 간에 쿼리해야 하는 경우 및 데이터가 고르지 않게 증가하는 경우 파티션의 균형을 다시 조정하는 경우 성능 및 안정성에 영향을 줄 수 있습니다.

안정성 검사 목록

전체 권장 사항 집합을 참조하세요.

안정성 검사 목록

데이터 분할에 대한 권장 사항