다음을 통해 공유


DTU 기반 구매 모델 개요

적용 대상: Azure SQL Database

이 문서에서는 Azure SQL 데이터베이스의 DTU 기반 구매 모델에 대한 개요를 제공합니다. DTU 기반 구매 모델은 컴퓨팅, 스토리지, I/O 리소스의 간단한 번들 측정 방식입니다. 일반적인 워크로드를 사용하는 대부분의 고객에게 가장 적합합니다. DTU 기반 구매 모델은 기본, 표준 및 프리미엄 서비스 계층에서 사용할 수 있습니다. DTU 기반 구매 모델은 탄력적 풀에도 사용할 수 있습니다.

DTU 기반 구매 모델은 vCore 기반 구매 모델과 다르므로 구매 모델을 비교할 수 있습니다.

DTU(데이터베이스 트랜잭션 단위)

DTU(데이터베이스 트랜잭션 단위)는 CPU, 메모리, 읽기 및 쓰기의 혼합 측정값을 나타냅니다. DTU 기반 구매 모델에서 서비스 계층은 포함된 스토리지의 고정된 양, 고정된 백업 보존 기간 및 고정 가격을 갖춘 다양한 컴퓨팅 크기로 구분됩니다. DTU 기반 구매 모델의 모든 서비스 계층은 가동 중지 시간을 최소화하면서 컴퓨팅 크기를 유연하게 변경할 수 있습니다. 그러나 짧은 시간 동안 데이터베이스에 대한 연결이 끊어지는 전환 기간이 있는데, 이는 다시 시도 논리를 사용하여 완화할 수 있습니다. 단일 데이터베이스 및 Elastic Pool은 서비스 계층 및 컴퓨팅 크기에 따라 매시간 청구됩니다.

서비스 계층 내 특정 컴퓨팅 크기의 단일 데이터베이스에 대해 Azure SQL 데이터베이스는 해당 데이터베이스(다른 데이터베이스와는 무관)에 대해 특정 수준의 리소스를 보장합니다. 이 보장은 예측 가능한 수준의 성능을 제공합니다. 데이터베이스에 할당된 리소스 양은 DTU 수로 계산되며 컴퓨팅, 스토리지, I/O 리소스를 번들로 묶은 측정값입니다.

원래 이 리소스 간의 비율은 일반적인 실제 OLTP 워크로드로 설계된 OLTP(온라인 트랜잭션 처리) 벤치마크 워크로드에 의해 결정되었습니다. 워크로드가 이러한 리소스의 양을 초과하면 처리량이 제한되어 성능이 느려지고 시간이 초과됩니다.

단일 데이터베이스의 경우, 워크로드에서 사용하는 리소스는 Azure 클라우드의 다른 데이터베이스에 사용할 수 있는 리소스에 영향을 미치지 않습니다. 마찬가지로 다른 워크로드에서 사용하는 리소스는 데이터베이스에 사용할 수 있는 리소스에 영향을 주지 않습니다.

DTU 구매 모델에 대한 다이어그램입니다. 상자의 네 가지 측면은 쓰기, CPU, 읽기 및 메모리이며, DTU 워크로드가 CPU, 메모리 및 읽기-쓰기 속도의 혼합된 방식을 설명합니다.

DTU는 다양한 컴퓨팅 크기 및 서비스 계층의 데이터베이스에 할당된 상대 리소스를 이해하는 데 가장 유용합니다. 예시:

  • 데이터베이스의 컴퓨팅 크기를 증가시켜 DTU를 두 배로 높일 경우 해당 데이터베이스에 사용할 수 있는 리소스 집합이 동일하게 두 배로 높아집니다.
  • 1750 DTU를 사용하는 프리미엄 서비스 계층 P11 데이터베이스는 5개의 DTU를 사용하는 기본 서비스 계층 데이터베이스보다 350배 더 많은 DTU 컴퓨팅 성능을 제공합니다.

워크로드의 리소스(DTU) 사용량에 대한 심층적인 인사이트를 얻으려면 쿼리 성능 인사이트를 사용하여 다음을 수행합니다.

  • 향상된 성능을 위해 잠재적으로 조정될 수 있는 CPU/기간/실행 횟수별 최상위 쿼리를 식별합니다. 예를 들어 I/O 집약적 쿼리는 특정 서비스 계층 및 컴퓨팅 크기에서 사용 가능한 메모리를 더 잘 사용하기 위해 메모리 내 최적화 기술을 활용할 수 있습니다.
  • 쿼리에 대한 세부 정보로 드릴다운하여 리소스 사용률에 대한 텍스트 및 기록을 표시합니다.
  • Database Advisor가 수행한 작업을 보여 주는 성능 튜닝 권장 사항을 봅니다.

(eDTU)탄력적 데이터베이스 트랜잭션 단위

항상 필요하지 않을 수 있는 전용 리소스 집합(DTU)을 제공하는 대신 이러한 데이터베이스를 탄력적 풀에 배치할 수 있습니다. 탄력적 풀의 데이터베이스는 데이터베이스 엔진의 단일 인스턴스를 사용하여 동일한 리소스 풀을 공유합니다.

Elastic Pool의 공유 리소스는 eDTU(탄력적 데이터베이스 트랜잭션 단위)로 측정됩니다. Elastic Pool은 매우 다양하고 예측할 수 없는 사용 패턴을 지닌 여러 데이터베이스에 대한 성능 목표를 관리하기 위한 간단하고 비용 효율적인 솔루션을 제공합니다. Elastic Pool은 풀의 한 데이터베이스에서 모든 리소스를 사용할 수 없도록 보장하는 동시에 풀의 각 데이터베이스에 항상 사용 가능한 최소한의 필요한 리소스가 있는지 확인합니다.

풀은 집합 가격에 대한 eDTU 수 집합이 제공됩니다. 탄력적 풀에서 개별 데이터베이스는 구성된 경계 내에서 자동 스케일링할 수 있습니다. 부하가 높은 데이터베이스는 요구를 충족하기 위해 더 많은 eDTU를 사용합니다. 더 가벼운 부하를 받는 데이터베이스는 eDTU를 적게 사용합니다. 부하가 없는 데이터베이스는 eDTU를 사용하지 않습니다. 리소스는 데이터베이스당이 아닌 전체 풀에 대해 프로비전되므로 Elastic Pool은 관리 작업을 간소화하고 풀에 대한 예측 가능한 예산을 제공합니다.

데이터베이스 가동 중지 시간이 최소화된 기존 풀에 다른 eDTU를 추가할 수 있습니다. 마찬가지로 추가 eDTU가 더 이상 필요하지 않은 경우 언제든지 기존 풀에서 제거하면 됩니다. 또한 언제든지 데이터베이스를 풀에 추가하거나 풀에서 제거할 수 있습니다. 다른 데이터베이스를 위한 eDTU를 예약하려면 높은 부하 상태에서 데이터베이스가 사용할 수 있는 eDTU 수를 제한합니다. 데이터베이스가 풀의 다른 데이터베이스에 영향을 미치는 리소스 사용률이 지속적으로 높은 경우 풀에서 이동하여 예측 가능한 양의 필수 리소스가 있는 단일 데이터베이스로 구성합니다.

리소스의 Elastic Pool 이점을 활용하는 워크로드

풀은 리소스 사용률이 낮고 사용률이 상대적으로 적은 데이터베이스에 적합합니다. 자세한 내용은 Azure SQL Database에서의 Elastic Pool을 참조하세요.

워크로드에 필요한 DTU 수 확인

기존 온-프레미스 또는 SQL Server 가상 머신 워크로드를 Azure SQL Database로 마이그레이션하려는 경우 SKU 권장 사항을 참조하여 필요한 DTU의 수를 대략적으로 계산합니다. 기존 SQL Database 워크로드의 경우 쿼리 성능 인사이트를 사용하여 DTU(데이터베이스 리소스 사용량)를 이해하고 워크로드를 최적화하기 위한 심층적인 인사이트를 얻습니다. sys.dm_db_resource_stats DMV(동적 관리 뷰)를 사용하면 지난 1시간의 리소스 소비량을 볼 수 있습니다. sys.resource_stats 카탈로그 뷰는 지난 14일 동안의 리소스 사용량을 표시하지만 5분 평균의 낮은 충실도로 표시됩니다.

DTU 사용률 확인

데이터베이스 또는 탄력적 풀의 DTU/eDTU 제한을 기준으로 DTU/eDTU 사용률의 평균 백분율을 확인하려면 다음 수식을 사용합니다.

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

이 수식의 입력 값은 sys.dm_db_resource_stats, sys.resource_stats, sys.elastic_pool_resource_stats DMV에서 가져올 수 있습니다. 즉, 데이터베이스 또는 Elastic Pool의 DTU/eDTU 제한에 대한 DTU/eDTU 사용률의 백분율을 확인하려면 특정 시점의 다음 avg_cpu_percent, avg_data_io_percent, avg_log_write_percent 에서 가장 큰 백분율 값을 선택합니다.

참고 항목

데이터베이스의 DTU 제한은 데이터베이스에 사용할 수 있는 CPU, 읽기, 쓰기 및 메모리에 따라 결정됩니다. 그러나 SQL Database 엔진은 일반적으로 데이터 캐시에 사용할 수 있는 모든 메모리를 사용하여 성능을 향상시키므로 현재 데이터베이스 로드와 관계없이 avg_memory_usage_percent 값은 일반적으로 100%에 가깝습니다. 따라서 메모리가 DTU 제한에 간접적으로 영향을 주더라도 DTU 사용률 수식에는 사용되지 않습니다.

하드웨어 구성

DTU 기반 구매 모델에서 고객은 해당 데이터베이스에 사용되는 하드웨어 구성을 선택할 수 없습니다. 지정된 데이터베이스는 일반적으로 오랜 시간 동안(일반적으로 몇 개월) 특정 유형의 하드웨어에서 유지되지만 다른 하드웨어로 데이터베이스를 이전할 수 있는 특정 이벤트가 있습니다.

예를 들어, 다른 서비스 목표로 규모를 스케일 업 또는 다운하는 경우, 데이터 센터의 현재 인프라가 용량 제한에 곧 도달하는 경우 또는 수명 종료로 인해 현재 사용 중인 하드웨어가 곧 해제되는 경우 다른 하드웨어로 데이터베이스를 이전할 수 있습니다.

데이터베이스를 다른 하드웨어로 이동하면 워크로드 성능이 변경될 수 있습니다. DTU 모델은 서비스 목표(DTU 개수)가 동일하게 유지되는 한 데이터베이스가 다른 하드웨어 형식으로 이전할 때 DTU 벤치마크 워크로드의 처리량 및 응답 시간이 동일하게 유지되도록 보장합니다.

그러나 Azure SQL Database에서 실행되는 광범위한 고객 워크로드 전반에서 동일한 서비스 목표에 대해 다른 하드웨어를 사용하는 경우에는 더 많은 영향을 줄 수 있습니다. 다양한 워크로드가 다른 하드웨어 구성 및 기능의 혜택을 받을 수도 있습니다. 따라서 DTU 벤치마크 이외의 워크로드의 경우 데이터베이스가 하드웨어 유형 간에 이전하면 성능 차이를 확인할 수 있습니다.

고객은 vCore 모델을 사용하여 데이터베이스를 만들고 크기 조정하는 동안 선호하는 하드웨어 구성을 선택할 수 있습니다. vCore 모델에서는 각 하드웨어 구성의 각 서비스 목표에 대한 자세한 리소스 제한은 단일 데이터베이스탄력적 풀에 대해 문서화되어 있습니다. 자세한 내용은 하드웨어어 구성을 참조하세요.

서비스 계층 비교

참고 항목

Azure 무료 계정을 사용하여 기본 서비스 계층의 Azure SQL 데이터베이스에서 무료 데이터베이스를 가져올 수 있습니다. 정보는 Azure무료 계정으로 관리되는 클라우드 데이터베이스 만들기를 참조하세요.

서비스 계층을 선택하는 작업은 주로 비즈니스 연속성, 스토리지 및 성능 요구 사항에 따라 다릅니다.

Basic Standard Premium
대상 워크로드 개발 및 프로덕션 개발 및 프로덕션 개발 및 프로덕션
작동 시간 SLA 99.99% 99.99% 99.99%
Backup 지역 중복, 영역 중복 또는 로컬 중복 백업 스토리지 중에서 선택, 1~7일 보존(기본값 7일)
최대 10년까지 사용할 수 있는 장기 보존
지역 중복, 영역 중복 또는 로컬 중복 백업 스토리지 중에서 선택, 1~35일 보존(기본값 7일)
최대 10년까지 사용할 수 있는 장기 보존
LRS(로컬 중복), ZRS(영역 중복) 또는 GRS(지역 중복) 스토리지의 선택 항목
1~35일(기본적으로 7일) 보존, 최대 10년의 장기 보존 가능
CPU 낮음 낮음, 보통, 높음 중간, 높음
IOPS(대략) 1 DTU당 1~4 IOPS DTU당 1~4 IOPS >DTU당 25 IOPS 초과
IO 대기 시간(근사치) 5ms(읽기), 10ms(쓰기) 5ms(읽기), 10ms(쓰기) 2ms(읽기/쓰기)
Columnstore 인덱싱 2 해당 없음 표준 S3 이상 지원 여부
메모리 내 OLTP 해당 없음 해당 없음 지원 여부

1 백그라운드 IO(검사점 및 지연 기록기)를 포함하여 데이터 파일에 대한 모든 읽기 및 쓰기 IOPS

2 자세한 내용은 columnstore 인덱스를 포함하는 데이터베이스의 서비스 계층 변경을 참조하세요.

Important

기본, S0, S1 및 S2 서비스 개체는 하나 미만의 vCore (CPU)를 제공합니다. CPU를 많이 사용하는 워크로드의 경우에는 S3 이상의 서비스 목표를 권장합니다.

기본, S0 및 S1 서비스 목표에서 데이터베이스 파일은 HDD(하드 디스크 드라이브) 기반 스토리지 미디어를 사용하는 Azure Standard Storage에 저장됩니다. 이러한 서비스는 개발, 테스트 및 성능 변화에 덜 민감하고 자주 발생되지 않는 액세스 워크로드에 가장 적합합니다.

데이터베이스 또는 탄력적 풀에 대한 실제 리소스 거버넌스 제한을 보려면 sys.dm_user_db_resource_governance 보기를 쿼리합니다. 단일 데이터베이스의 경우 한 행이 반환됩니다. Elastic Pool 데이터베이스의 경우 풀의 각 데이터베이스에 대해 행이 반환됩니다.

리소스 한도

단일 데이터베이스와 풀링된 데이터베이스의 리소스 제한은 다릅니다.

단일 데이터베이스 저장 한도

Azure SQL 데이터베이스에서 컴퓨팅 크기는 단일 데이터베이스에 대해서는 DTU(데이터베이스 트랜잭션 단위), Elastic Pool에 대해서는 eDTU(탄력적 데이터베이스 트랜잭션 단위)로 표현됩니다. 자세히 알아보려면 단일 데이터베이스에 대한 리소스 제한을 검토하세요.

Basic Standard Premium
최대 스토리지 크기 2GB 1TB 4 TB
최대 DTU 5 3000 4000

Important

경우에 따라 사용하지 않는 공간을 회수하기 위해 데이터베이스를 축소해야 할 수도 있습니다. 자세한 내용은 Azure SQL 데이터베이스 파일 공간 관리를 참조하세요.

기본 탄력적 풀 제한

자세히 알아보려면, DTU 구매 모델을 사용한 Elastic Pool의 리소스 한도를 검토하세요.

기본 표준 Premium
데이터베이스당 최대 스토리지 크기 2GB 1TB 1TB
풀당 최대 스토리지 크기 156GB 4 TB 4 TB
데이터베이스당 최대 eDTU 5 3000 4000
풀당 최대 eDTU 1600 3000 4000
풀당 최대 데이터베이스 수 500 500 100

Important

현재 일부 예외 지역 이외의 모든 지역에서 프리미엄 계층의 스토리지는 1TB를 초과하여 사용할 수 있습니다(예외 지역: 중국 동부, 중국 북부, 독일 중부, 독일 북동부). 이러한 지역에서 프리미엄 계층 스토리지 최대 크기는 1TB로 제한됩니다. 자세한 내용은 P11-P15 현재 제한 사항을 참조하세요.

Important

경우에 따라 사용하지 않는 공간을 회수하기 위해 데이터베이스를 축소해야 할 수도 있습니다. 자세한 내용은 Azure SQL Database의 파일 공간 관리를 참조하세요.

DTU 벤치마크

각 DTU 측정값과 연결된 물리적 특성(CPU, 메모리, IO)은 실제 데이터베이스 워크로드를 시뮬레이션하는 벤치마크를 사용하여 보정됩니다.

DTU 벤치마크와 연결된 스키마, 사용된 트랜잭션 유형, 워크로드 조합, 사용자 및 속도, 크기 조정 규칙 및 메트릭에 대해 알아봅니다.

DTU 기반 및 vCore 구매 모델 비교

DTU 기반 구매 모델은 컴퓨팅, 스토리지 및 I/O 리소스의 번들 측정값을 기반으로 하지만, Azure SQL Database용 vCore 구매 모델을 사용하면 컴퓨팅 및 스토리지 리소스를 독립적으로 선택하고 크기를 조정할 수 있습니다.

또한 vCore 기반 구매 모델을 사용하면 비용을 절감하기 위해 SQL Server용 Azure 하이브리드 혜택를 사용할 수 있으며, DTU 기반 구매 모델에서는 사용할 수 없는 Azure SQL Database용 서버리스 컴퓨팅 계층Azure SQL Database용 하이퍼스케일 서비스 계층 옵션을 제공합니다.

Azure SQL Database의 vCore 및 DTU 기반 구매 모델 비교에서 자세히 알아봅니다.