Azure Cosmos DB의 프로비저닝된 처리량 비용 최적화

  • 아티클

적용 대상: NoSQL MongoDB Cassandra Gremlin 테이블

Azure Cosmos DB는 프로비전된 처리량 모델을 제공하여 규모에 관계없이 예측 가능한 성능을 제공합니다. 사전에 처리량을 예약하거나 프로비전하면 성능에 미치는 "노이즈 주변 효과"가 해소됩니다. 필요한 처리량의 정확한 크기를 지정하면 Azure Cosmos DB가 SLA에서 지원하는 구성된 처리량을 보장합니다.

최소 400RU/초의 처리량으로 시작한 후 초당 수천만 개 이상의 요청으로 확장할 수 있습니다. 저장 프로시저는 Azure Cosmos DB 컨테이너 또는 데이터베이스에 대해 실행하는 모든 요청(예: 읽기 요청, 쓰기 요청, 쿼리 요청)에 대해 프로비전된 처리량에서 차감되는 지정된 비용을 적용합니다. 400RU/초를 프로비전하고 비용이 40RU인 쿼리를 실행하는 경우 이러한 쿼리를 초당 10개 실행할 수 있습니다. 이를 초과하는 요청은 속도가 제한되며 요청을 다시 시도해야 합니다. 클라이언트 드라이버를 사용하는 경우 자동 다시 시도 논리를 지원합니다.

데이터베이스 또는 컨테이너에 대한 처리량을 프로비전할 수 있으며, 각 전략은 시나리오에 따라 비용 절감에 도움이 될 수 있습니다.

다양한 수준에서 처리량을 프로비전하여 최적화

  • 데이터베이스에 대한 처리량을 프로비전하는 경우 모든 컨테이너(예: 해당 데이터베이스 내의 컬렉션/테이블/그래프)는 부하에 따라 처리량을 공유할 수 있습니다. 데이터베이스 수준에서 예약된 처리량은 특정 컨테이너 세트에 대한 워크로드에 따라 비균일하게 공유됩니다.

  • 컨테이너에 대한 처리량을 프로비전하는 경우 SLA에서 지원하는 처리량이 해당 컨테이너에 대해 보장됩니다. 컨테이너의 모든 논리 파티션에 균일하게 부하를 분산하려면 논리 파티션 키를 적절히 선택해야 합니다. 자세한 내용은 분할 및 수평적 크기 조정 문서를 참조하세요.

다음은 프로비전된 처리량 전략을 결정하기 위한 몇 가지 지침입니다.

다음과 같은 경우 Azure Cosmos DB 데이터베이스(컨테이너 세트 포함)에 대한 처리량을 프로비전하는 것이 좋습니다.:

  1. Azure Cosmos DB 컨테이너가 몇 십 개 정도 있으며 일부 또는 전체에서 처리량을 공유하려고 합니다.

  2. IaaS 호스팅된 VM 또는 온-프레미스(예를 들어, NoSQL 또는 관계형 데이터베이스)에서 실행되도록 설계된 단일 테넌트 데이터베이스에서 Azure Cosmos DB로 마이그레이션하려고 합니다. 컬렉션/테이블/그래프가 많이 있으며 데이터 모델을 절대 변경하고 싶지 않습니다. 온-프레미스 데이터베이스에서 마이그레이션할 때 데이터 모델을 업데이트하지 않으면 Azure Cosmos DB에서 제공하는 이점 중 일부를 얻지 못할 수 있습니다. 최대의 성능을 얻고 비용 최적화를 이루려면 항상 데이터 모델을 다시 평가하는 것이 좋습니다.

  3. 데이터베이스 수준에서 풀링되는 처리량으로 예기치 않은 워크로드 급증을 완화하려고 합니다.

  4. 개별 컨테이너에서 특정 처리량을 설정하는 대신, 데이터베이스 내의 컨테이너 집합에서 집계된 처리량을 얻는 데 관심이 있습니다.

다음과 같은 경우 개별 컨테이너에서 처리량을 프로비전하는 것이 좋습니다.

  1. Azure Cosmos DB 컨테이너가 몇 개 있습니다. Azure Cosmos DB는 스키마에 독립적이기 때문에 컨테이너는 다른 유형의 스키마를 갖는 항목을 포함할 수 있으며, 고객이 각 엔터티에 대해 하나씩 여러 컨테이너 유형을 만들 필요가 없습니다. 10~20개의 컨테이너를 단일 컨테이너로 그룹화할 수 있는 경우 항상 고려해야 하는 옵션이 있습니다. 컨테이너의 최소 RU 수가 400개인 경우 10~20개 컨테이너를 모두 하나로 풀링하는 것이 비용 측면에서 더 효율적일 수 있습니다.

  2. 특정 컨테이너에 대한 처리량을 제어하고 지정된 컨테이너에 대해 SLA에서 지원하는 처리량을 보장하려고 합니다.

위의 두 전략을 혼합하는 것을 고려하세요.

  1. 앞서 언급한 것처럼 Azure Cosmos DB는 위의 두 전략에 대한 믹스 앤 매치를 허용하므로, 이제 Azure Cosmos DB 데이터베이스 내에 데이터베이스에 대해 프로비전된 처리량을 공유할 수 있는 컨테이너와 프로비전 처리량 중에서 전용 처리량을 사용할 수 있는 컨테이너가 함께 존재할 수 있습니다.

  2. 위 전략을 적용하여 데이터베이스 수준에서 두 가지 처리량을 프로비전하고 일부 컨테이너에 전용 처리량을 적용하는 혼합 구성을 구현할 수 있습니다.

다음 표와 같이, 선택하는 API에 따라 다양한 세분성으로 처리량을 프로비전할 수 있습니다.

API 공유 처리량의 경우 구성 항목 전용 처리량의 경우 구성 항목
API for NoSQL 데이터베이스 컨테이너
Azure Cosmos DB의 API for MongoDB 데이터베이스 컬렉션
API for Cassandra Keyspace 테이블
API for Gremlin 데이터베이스 계정 그래프
API for Table 데이터베이스 계정 테이블

다양한 수준에서 처리량을 프로비전하여 워크로드의 특징을 기준으로 비용을 최적화할 수 있습니다. 앞에서 설명한 것처럼 프로비전된 처리량을 개별 컨테이너에 대해 또는 컨테이너 세트에 대해 전체적으로 언제든지 프로그래밍 방식으로 늘리거나 줄일 수 있습니다. 워크로드가 변경되면서 처리량 규모를 탄력적으로 조정할 수 있으므로 구성한 처리량에 대해서만 비용을 지불하면 됩니다. 컨테이너 또는 컨테이너 세트가 여러 지역에 분산될 경우 컨테이너 또는 컨테이너 세트에 대해 구성한 처리량을 모든 지역에서 사용할 수 있도록 보장됩니다.

요청 속도 제한 최적화

대기 시간이 중요하지 않은 워크로드의 경우 더 적은 처리량을 프로비전한 후, 실제 처리량이 프로비전된 처리량을 초과할 때 애플리케이션이 속도 제한을 처리하도록 할 수 있습니다. 서버에서 RequestRateTooLarge(HTTP 상태 코드 429)를 사용하여 선제적으로 요청을 종료하고, 사용자가 요청을 다시 시도할 수 있을 때까지 기다려야 하는 시간을 밀리초 단위로 표시하는 x-ms-retry-after-ms 헤더를 반환합니다.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

SDK의 다시 시도 논리

기본 SDK(.NET/.NET Core, Java, Node.js 및 Python)는 이 응답을 암시적으로 모두 catch하고, server-specified retry-after 헤더를 준수하고 요청을 다시 시도합니다. 동시에 여러 클라이언트가 계정에 액세스하지만 않으면 다음 재시도가 성공할 것입니다.

둘 이상의 클라이언트가 요청 속도 이상으로 누적해서 계속 작동할 경우 현재 9로 설정된 기본 재시도 횟수가 충분하지 않을 수 있습니다. 이러한 경우 클라이언트는 상태 코드 429의 RequestRateTooLargeException을 애플리케이션에 throw합니다. 기본 재시도 횟수는 ConnectionPolicy 인스턴스에서 RetryOptions를 설정하여 변경할 수 있습니다. 기본적으로 요청이 요청 속도를 초과하여 계속 작동하는 경우 상태 코드가 429인 RequestRateTooLargeException은 30초의 누적 대기 시간 후에 반환됩니다. 현재 재시도 횟수가 최대 재시도 횟수보다 작은 경우에도 이러한 현상이 발생하기 때문에 기본값인 9 또는 사용자 정의 값으로 두세요.

MaxRetryAttemptsOnThrottledRequests는 3으로 설정됩니다. 이 경우 요청 작업이 컨테이너에 대한 예약된 처리량을 초과하여 속도가 제한되면 요청 작업은 애플리케이션 예외를 throw하기 전에 3번 다시 시도됩니다. MaxRetryWaitTimeInSeconds가 60으로 설정됩니다. 이 경우 첫 번째 요청 이후의 누적 재시도 대기 시간(초)이 60초를 초과하여 예외가 throw됩니다.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

분할 전략 및 프로비저닝된 처리량 비용

적절한 분할 전략은 Azure Cosmos DB의 비용을 최적화하는 데 중요합니다. 스토리지 메트릭을 통해 노출되는 파티션의 차이가 없는지 확인합니다. 처리량 메트릭을 통해 노출되는 파티션에 대한 처리량 차이가 없는지 확인합니다. 특정 파티션 키에 대한 차이가 없는지 확인합니다. 스토리지의 주요 키는 메트릭을 통해 노출되지만, 애플리케이션 액세스 패턴에 따라 좌우됩니다. 올바른 논리 파티션 키가 어떤 키인지를 생각해보는 것이 좋습니다. 적절한 파티션 키는 다음과 같은 특징을 갖습니다.

  • 시간이 지나도 모든 파티션에 워크로드를 균등하게 분산하는 파티션 키를 선택해야 합니다. 즉, 일부 키에만 데이터 대부분이 지정되고, 다른 키에는 소량의 데이터만 지정되거나 지정된 데이터가 없는 구조는 바람직하지 않습니다.

  • 논리 파티션 간에 액세스 패턴이 균등하게 분산되도록 하는 파티션 키를 선택합니다. 워크로드는 모든 키에서 균일합니다. 즉, 워크로드 대부분이 소수의 특정 키에 집중하지 않아야 합니다.

  • 다양한 값 범위를 갖는 파티션 키를 선택합니다.

핵심 개념은 데이터 스토리지 및 처리량에 대한 리소스가 논리 파티션에 분산되도록 컨테이너의 데이터 및 작업을 논리 파티션 집합으로 분산하는 것입니다. 쿼리에서 필터로 자주 표시되는 속성을 파티션 키로 사용할 수 있습니다. 필터 조건자에 파티션 키를 포함하여 쿼리를 효율적으로 라우팅할 수 있습니다. 이러한 분할 전략을 사용하여 프로비전된 처리량을 최적화하는 것이 훨씬 더 쉽습니다.

더 높은 처리량을 위해 더 작은 항목 디자인

주어진 작업의 요청 비용 또는 요청 처리 비용은 항목 크기와 직접 관련이 있습니다. 큰 항목에 대해 작업할 경우 더 작은 항목에 대해 작업할 때보다 비용이 더 많이 듭니다.

데이터 액세스 패턴

데이터에 액세스하는 빈도에 따라 논리 범주별로 데이터를 논리적으로 분리하는 것이 좋습니다. 핫, 중간 또는 콜드 데이터로 분류하여 사용된 스토리지 및 필요한 처리량을 미세 조정할 수 있습니다. 액세스 빈도에 따라, 데이터를 별도 컨테이너(예: 테이블, 그래프 및 컬렉션)에 배치하고, 프로비전된 처리량을 해당 데이터 세그먼트의 요구에 맞게 미세 조정할 수 있습니다.

또한 Azure Cosmos DB를 사용하고 있으며 특정 데이터 값을 기준으로 검색할 예정이 없거나 거의 액세스하지 않으려는 경우, 해당 특성의 압축된 값을 저장해야 합니다. 이 방법을 사용하면 스토리지 공간, 인덱스 공간 및 프로비전된 처리량을 절약하고 비용을 절감할 수 있습니다.

인덱싱 정책을 변경하여 최적화

기본적으로 Azure Cosmos DB는 모든 레코드의 모든 속성을 자동으로 인덱싱합니다. 이 방식은 개발을 용이하게 하고, 다양한 유형의 임시 쿼리에 대해 뛰어난 성능을 보장하기 위한 것입니다. 수천 개의 속성이 있는 대규모 레코드를 사용하는 경우 모든 속성을 인덱싱하기 위한 처리량 비용을 지불하는 것은 유용하지 않을 수 있습니다. 특히 이러한 속성 중에서 10개 또는 20개만 쿼리하는 경우에는 더욱 비효율적입니다. 특정 워크로드를 보다 적절히 처리할 수 있으면 인덱스 정책을 조정하는 것이 좋습니다. Azure Cosmos DB 인덱싱 정책에 대한 자세한 내용은 여기에서 찾을 수 있습니다.

프로비전 및 사용된 처리량 모니터링

Azure Portal에서 사용한 RU의 수 뿐만 아니라 프로비전된 RU의 총 수, 속도가 제한된 요청 수를 모니터링할 수 있습니다. 다음 이미지는 사용 메트릭 예제를 보여 줍니다.

Monitor request units in the Azure portal

속도가 제한된 요청 수가 특정 임계값을 초과하는지 확인하기 위해 경고를 설정할 수도 있습니다. 자세한 내용은 Azure Cosmos DB를 모니터링하는 방법을 참조하세요. 이러한 경고는 계정 관리자에게 이메일을 보내거나 사용자 지정 HTTP 웹후크 또는 Azure 함수를 호출하여 프로비전된 처리량을 자동으로 늘릴 수 있습니다.

요청이 있을 때 처리량을 탄력적으로 확장

프로비전된 처리량에 대해 요금이 청구되므로, 요구 사항에 맞게 프로비전된 처리량을 조정하면 사용하지 않은 처리량에 대해 요금이 부과되지 않도록 할 수 있습니다. 언제든지 필요에 따라 프로비전된 처리량을 확장 또는 축소할 수 있습니다. 처리량 요구가 매우 예측 가능한 경우 Azure Functions를 사용하고 타이머 트리거를 사용하여 일정에 따라 처리량을 늘리거나 줄일 수 있습니다.

  • RU 소비량 및 속도가 제한되는 요청의 비율을 모니터링하면 일 또는 주 동안 프로비전된 처리량을 일관되게 유지할 필요가 없습니다. 야간 또는 주말 동안에는 더 적은 트래픽 양을 수신할 수 있습니다. Azure Portal 또는 Azure Cosmos DB 기본 SDK 또는 REST API를 사용하여 언제든지 프로비전된 처리량 규모를 조정할 수 있습니다. Azure Cosmos DB의 REST API는 엔드포인트를 제공하여 컨테이너의 성능 수준을 프로그래밍 방식으로 업데이트함으로써 하루 중 시간 또는 주중 요일에 따라 코드에서 처리량을 편리하게 조정할 수 있도록 합니다. 작업은 가동 중지 시간 없이 수행되며, 일반적으로 1분 이내에 적용됩니다.

  • 처리량 규모를 조정해야 하는 영역 중 하나는 Azure Cosmos DB에 데이터를 삽입할 때(예: 데이터 마이그레이션 동안)입니다. 마이그레이션을 완료한 후에는 프로비전된 처리량을 축소하여 솔루션의 안정적인 상태를 유지할 수 있습니다.

  • 요금이 1시간 단위로 청구되므로 프로비전된 처리량을 한 번에 1시간보다 더 자주 변경하면 비용이 절감되지 않습니다.

새 워크로드에 필요한 처리량 확인

새 워크로드에 대해 프로비전된 처리량을 확인하려면 다음 단계를 사용할 수 있습니다.

  1. Capacity Planner를 사용하여 초기에 대략적인 평가를 수행하고 Azure Portal의 Azure Cosmos DB Explorer를 사용하여 예상치를 조정합니다.

  2. 예상보다 더 높은 처리량을 갖는 컨테이너를 만든 후 필요에 따라 축소하는 것이 좋습니다.

  3. 요청 속도가 제한되면 기본 Azure Cosmos DB SDK 중 하나를 사용하여 자동 재시도를 활용하는 것이 좋습니다. 지원되지 않는 플랫폼에서 작업하며 Azure Cosmos DB의 REST API를 사용하는 경우x-ms-retry-after-ms 헤더를 사용하여 사용자 고유의 재시도 정책을 구현합니다.

  4. 애플리케이션 코드가 모든 재시도가 실패하는 경우를 정상적으로 지원하는지 확인합니다.

  5. 속도 제한에 대한 알림을 받으려면 Azure Portal에서 경고를 구성할 수 있습니다. 처음에는 보수적 제한(예: 지난 15분 동안 10개의 속도 제한 요청)으로 시작하고, 실제 사용량을 파악한 후에 좀 더 적극적인 규칙으로 전환할 수 있습니다. 비정기적 속도 제한이 적절하며, 이 경우 설정한 제한이 사용되고 있는지와 사용자가 원하는 방식인지 표시됩니다.

  6. 모니터링을 사용하여 트래픽 패턴을 파악합니다. 이를 통해 일 또는 주 동안의 처리량 프로비전을 동적으로 조정해야 하는지 고려할 수 있습니다.

  7. 프로비전한 처리량 및 사용한 처리량 비율을 정기적으로 모니터링하여 필요한 컨테이너 및 데이터베이스 수보다 많이 프로비전하지 않도록 하세요. 처리량을 약간 과도하게 프로비전하는 것이 안전 유지에 좋습니다.

프로비전된 처리량을 최적화하기 위한 모범 사례

Azure Cosmos DB를 사용할 경우 다음 단계를 따르면 가용성이 뛰어나고 비용 효율적인 솔루션을 구현할 수 있습니다.

  1. 컨테이너 및 데이터베이스에서 처리량을 매우 과도하게 프로비전한 경우 프로비전한 RU와 사용한 RU를 검토하고 워크로드를 미세 조정해야 합니다.

  2. 애플리케이션에 필요한 예약된 처리량을 예측하는 한 가지 방법은 애플리케이션에서 사용하는 대표적인 Azure Cosmos DB 컨테이너 또는 데이터베이스에 대해 실행되는 일반 작업과 연결된 요청 단위 RU 요금을 기록한 다음, 예상되는 초당 수행되는 작업 수를 추정하는 것입니다. 일반 쿼리 및 해당 사용량도 측정하여 포함해야 합니다. 프로그래밍 방식으로 또는 포털을 사용하여 쿼리의 RU 비용을 추정하는 방법을 알아보려면 쿼리 비용 최적화를 참조하세요.

  3. 작업을 수행하고 RU 비용을 청구받는 또 다른 방법은 작업/기간 및 요청 요금의 분석 결과를 제공하는 Azure Monitor 로그를 사용하도록 설정하는 것입니다. Azure Cosmos DB는 모든 작업에 대해 요청 요금을 제공하므로, 모든 작업 요금이 응답에서 다시 저장된 후 분석에 사용될 수 있습니다.

  4. 프로비전된 처리량 규모를 워크로드 요구에 맞게 필요한 만큼 탄력적으로 확장 및 축소할 수 있습니다.

  5. 필요에 따라 Azure Cosmos DB 계정과 연결된 지역을 추가 및 제거하고 비용을 제어할 수 있습니다.

  6. 컨테이너의 논리 파티션 간에 데이터 및 워크로드를 균일하게 분산했는지 확인합니다. 파티션을 균일하지 않게 분산한 경우 필요한 것보다 더 높은 처리량이 프로비전될 수 있습니다. 균일하지 않게 분산한 경우 파티션 간에 균일하게 워크로드를 다시 분산하거나 데이터를 다시 분할하는 것이 좋습니다.

  7. 많은 컨테이너가 있고 이러한 컨테이너에 SLA가 필요하지 않은 경우 컨테이너별 처리량 SLA가 적용되지 않는 경우를 위해 데이터베이스 기반 제품을 사용할 수 있습니다. 데이터베이스 수준 처리량 제품으로 마이그레이션한 후 변경 피드 기반 솔루션을 사용하여 마이그레이션하려는 Azure Cosmos DB 컨테이너를 식별해야 합니다.

  8. 개발/테스트 시나리오를 위해 "Azure Cosmos DB 무료 계층"(1년 동안 무료), Azure Cosmos DB(최대 3개 지역) 또는 다운로드 가능한 Azure Cosmos DB 에뮬레이터를 사용해 보세요. 테스트/개발을 위해 이러한 옵션을 사용하면 비용을 크게 절감할 수 있습니다.

  9. 해당되는 경우 워크로드별 비용 최적화(예: 일괄 처리 크기 늘리기, 여러 지역에서 읽기 부하 분산, 데이터 중복 제거)를 추가로 수행할 수 있습니다.

  10. Azure Cosmos DB 예약 용량을 사용하여 3년 동안 최대 65%의 할인을 받을 수 있습니다. Azure Cosmos DB의 예약 용량 모델은 시간이 지나면서 필요하게 되는 요청 단위에 대한 선불 약정입니다. 할인이 계층화되어 있으므로 더 긴 기간 동안 더 많은 요청 단위를 사용할수록 할인 금액이 높아집니다. 이러한 할인은 즉시 적용됩니다. 프로비전된 값을 초과해서 사용한 RU는 예약되지 않은 용량 요금에 따라 청구됩니다. 자세한 내용은 Azure Cosmos DB 예약 용량)을 참조하세요. 예약 용량을 구입하여 프로비전된 처리량 비용을 추가로 절감하는 것이 좋습니다.

다음 단계

이제 다음 문서를 사용하여 Azure Cosmos DB의 비용 최적화에 대해 좀 더 자세히 알아볼 수 있습니다.