vCore 구매 모델 - Azure SQL Database

적용 대상:Azure SQL Database

이 문서에서는 Azure SQL DatabasevCore 구매 모델을 검토합니다.

개요

vCore(가상 코어)는 논리적 CPU를 나타내며, 하드웨어의 물리적 특성(예: 코어 수, 메모리 및 스토리지 크기)을 선택할 수 있는 옵션을 제공합니다. vCore 기반 구매 모델은 개별 리소스 사용에 대한 유연성, 제어, 투명성 및 온-프레미스 워크로드 요구 사항을 클라우드로 전환하는 직관적인 방법을 제공합니다. 이 모델은 비용을 최적화하고 워크로드 필요에 따라 컴퓨팅, 메모리, 스토리지 리소스를 선택할 수 있습니다.

vCore 기반 구매 모델에서 비용은 다음의 선택 및 사용량에 따라 달라집니다.

  • 서비스 계층
  • 하드웨어 구성
  • 컴퓨팅 리소스(vCore 수 및 메모리 양)
  • 예약된 데이터베이스 스토리지
  • 실제 백업 스토리지

중요

컴퓨팅 리소스, I/O, 데이터 및 로그 스토리지는 데이터베이스 또는 탄력적 풀당 요금이 부과됩니다. 백업 스토리지는 각 데이터베이스당 요금이 부과됩니다. 가격 책정에 대한 자세한 내용은 Azure SQL Database 가격 책정 페이지를 참조하세요.

vCore 및 DTU 구매 모델 비교

Azure SQL 데이터베이스에서 사용하는 vCore 구매 모델은 DTU 기반 구매 모델에 비해 다음과 같은 몇 가지 이점을 제공합니다.

  • 더 높은 컴퓨팅, 메모리, I/O 및 스토리지 제한.
  • 워크로드의 컴퓨팅 및 메모리 요구 사항에 더 잘 맞는 하드웨어 구성 옵션.
  • AHB(Azure 하이브리드 혜택)의 가격 할인
  • 컴퓨팅을 지원하는 하드웨어 세부 정보의 투명도를 향상시킴으로써 온-프레미스 배포에서의 마이그레이션 계획을 용이하게 함.
  • 예약 인스턴스 가격은 vCore 구매 모델에만 사용할 수 있습니다.
  • 크기 조정 세분성이 향상되어 여러 컴퓨팅 크기를 사용할 수 있습니다.

vCore와 DTU 구매 모델 중에서 선택하는 데 도움이 필요하면 vCore와 DTU 기반 구매 모델 간의 차이점을 참조하세요.

컴퓨팅

vCore 기반 구매 모델에는 프로비전된 컴퓨팅 계층 및 서버리스 컴퓨팅 계층이 있습니다. 프로비저닝된 컴퓨팅 계층의 경우, 컴퓨팅 비용은 워크로드 작업과 무관하게 애플리케이션에 대해 지속적으로 프로비저닝된 총 컴퓨팅 용량을 반영합니다. vCore 및 메모리 요구 사항에 따른 비즈니스 요구 사항에 가장 적합한 리소스 할당을 선택한 다음 워크로드에 필요한 경우 리소스를 확장 및 축소합니다. Azure SQL 데이터베이스의 서버리스 컴퓨팅 계층에서 컴퓨팅 리소스는 워크로드 용량에 따라 자동 크기 조정되어 사용되는 컴퓨팅 양에 대해 초당 청구됩니다.

요약:

  • 프로비전된 컴퓨팅 계층은 워크로드 활동과 무관하게 지속적으로 프로비전되는 특정 양의 컴퓨팅 리소스를 제공하지만, 서버리스 컴퓨팅 계층은 워크로드 활동을 기반으로 컴퓨팅 리소스를 자동으로 스케일링합니다.
  • 프로비전된 컴퓨팅 계층은 시간당 고정 가격으로 프로비전된 컴퓨팅 양에 대해 청구되는 반면, 서버리스 컴퓨팅 계층은 초당 사용된 컴퓨팅 양에 대해 청구됩니다.

컴퓨팅 계층에 관계없이 3개의 추가 고가용성 보조 복제본은 중요 비즈니스용 서비스 계층에 자동으로 할당되어 오류 및 빠른 장애 조치(failover)에 대한 높은 복원력을 제공합니다. 이러한 추가 복제본(replica)을 사용하면 범용 서비스 계층보다 약 2.7배 높은 비용이 듭니다. 마찬가지로 중요 비즈니스용 서비스 계층에서 GB당 스토리지 가격이 높을수록 로컬 SSD 스토리지의 IO 한도가 높고 대기 시간이 짧습니다.

하이퍼스케일에서 고객은 비용을 제어하면서 애플리케이션에 필요한 복원력 수준을 얻기 위해 추가 고가용성 복제본 수를 0에서 4로 제어합니다.

Azure SQL 데이터베이스의 컴퓨팅에 대한 자세한 내용은 컴퓨팅 리소스(CPU 및 메모리)를 참조하세요.

리소스 한계

vCore 리소스 제한의 경우 사용 가능한 하드웨어 구성을 검토한 다음 리소스 제한을 검토합니다.

데이터 및 로그 스토리지

다음 요소는 데이터 및 로그 파일에 사용되는 스토리지의 양에 영향을 주며 범용 및 중요 비즈니스 계층에 적용됩니다.

  • 각각의 컴퓨팅 크기는 구성 가능한 최대 데이터 크기를 지원하며 기본값은 32GB입니다.
  • 최대 데이터 크기를 구성하면 로그 파일에 대해 추가 30%의 청구 가능한 스토리지가 자동으로 추가됩니다.
  • 범용 서비스 계층의 경우 tempdb에서 로컬 SSD를 사용하며, 이 스토리지의 비용이 vCore 가격에 포함됩니다.
  • 중요 비즈니스 서비스 계층의 경우 tempdb에서 데이터 및 로그 파일이 포함된 로컬 및 SSD 스토리지를 사용하고 tempdb 스토리지의 비용이 vCore 가격에 포함됩니다.
  • 범용 및 중요 비즈니스용 계층에서 데이터베이스 또는 인스턴스에 대해 구성된 최대 스토리지 크기에 대해 요금이 청구됩니다.
  • SQL Database의 경우 1GB 및 지원되는 스토리지 크기 최대값 사이의 최대 데이터 크기를 1GB 증분으로 선택할 수 있습니다.

하이퍼스케일에는 다음과 같은 스토리지 고려 사항이 적용됩니다.

  • 최대 데이터 스토리지 크기는 100TB로 설정되며 구성할 수 없습니다.
  • 최대 데이터 스토리지가 아닌 할당된 데이터 스토리지에 대해서만 요금이 청구됩니다.
  • 로그 스토리지에 대한 요금은 청구되지 않습니다.
  • tempdb는 로컬 SSD 스토리지를 사용하며, 해당 비용은 vCore 가격에 포함됩니다. SQL Database에서 현재 할당 및 사용된 데이터 스토리지 크기를 모니터링하려면 각각 allocated_data_storage스토리지 Azure Monitor 메트릭을 사용합니다.

T-SQL을 사용하는 데이터베이스에서 개별 데이터 및 로그 파일의 현재 할당 및 사용 스토리지 크기를 모니터링하려면 sys.database_files 보기 및 FILEPROPERTY(... , 'SpaceUsed') 함수를 사용합니다.

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

백업 스토리지

데이터베이스 백업 스토리지는 SQL Database의 PITR(특정 시점 복원)LTR(장기 보존) 기능을 지원하기 위해 할당됩니다. 이 스토리지는 데이터 및 로그 파일 스토리지와는 별개이며 별도로 청구됩니다.

  • PITR: 범용 및 중요 비즈니스용 계층에서 개별 데이터베이스 백업은 Azure 스토리지에 자동으로 복사됩니다. 스토리지 크기는 새 백업이 생성될 때 동적으로 늘어납니다. 전체, 차등 및 트랜잭션 로그 백업에 스토리지를 사용합니다. 스토리지 사용량은 백업에 대해 구성된 데이터베이스 변동률과 보존 기간에 따라 다릅니다. 각 데이터베이스마다 SQL Database에 대해 1~35일 범위의 개별 보존 기간을 구성할 수 있습니다. 구성된 최대 데이터 크기와 같은 백업 스토리지 용량이 추가 요금 없이 제공됩니다.
  • LTR: 최대 10년 동안 전체 백업의 장기 보존을 구성할 수 있습니다. LTR 정책을 설정하는 경우 이러한 백업은 Azure Blob 스토리지에 자동으로 저장되지만 백업 복사 빈도를 제어할 수 있습니다. 서로 다른 준수 요구 사항을 충족하려면 주별, 월별 또는 연도별 백업에 대해 다른 보존 기간을 선택할 수 있습니다. 선택한 구성에 따라 LTR 백업에 사용되는 스토리지의 양이 결정됩니다. 자세한 내용은 장기 백업 보존을 참조하세요.

하이퍼스케일의 백업 스토리지는 하이퍼스케일 데이터베이스에 대한 자동화된 백업을 참조하세요.

서비스 계층

vCore 구매 모델의 서비스 계층 옵션에는 범용, 중요 비즈니스용 및 하이퍼스케일이 포함됩니다. 서비스 계층은 일반적으로 스토리지 유형 및 성능, 고가용성 및 재해 복구 옵션, 메모리 내 OLTP와 같은 특정 기능의 가용성을 결정합니다.

사용 사례 범용 중요 비즈니스용 하이퍼스케일
적합한 대상 대부분의 비즈니스 워크로드. 예산에 맞게 균형 있고 확장 가능한 컴퓨팅 및 스토리지 옵션을 제공합니다. 여러 개의 고가용성 보조 복제본을 사용하여 비즈니스 애플리케이션에서 오류에 대한 가장 높은 복원력 및 최고의 I/O 성능을 제공합니다. 확장성이 뛰어난 스토리지 및 읽기 확장 요구 사항이 있는 워크로드를 포함하여 다양한 워크로드를 제공합니다. 둘 이상의 고가용성 보조 복제본 구성이 가능하여 오류에 대한 더 높은 복원력을 제공합니다.
컴퓨팅 크기 vCore 2~128개 vCore 2~128개 vCore 2~128개
스토리지 유형 프리미엄 원격 스토리지(인스턴스별) 초고속 로컬 SSD 스토리지(인스턴스별) 로컬 SSD 캐시를 사용하여 스토리지 분리(컴퓨팅 복제본(replica)당)
스토리지 크기 1GB – 4TB 1GB – 4TB 10GB~100TB
IOPS vCore당 320 IOPS(최대 16,000 IOPS) vCore당 4,000 IOPS(최대 327,680 IOPS) 최대 로컬 SSD를 사용하는 327,680 IOPS
하이퍼스케일은 여러 수준에서 캐싱을 사용하는 다중 계층 아키텍처입니다. 유효 IOPS는 워크로드에 따라 달라집니다.
메모리/vCore 5.1GB 5.1GB 5.1GB 또는 10.2GB
Backup 지역 중복, 영역 중복 또는 로컬 중복 백업 스토리지 중에서 선택, 1~35일 보존(기본값 7일)
최대 10년까지 사용할 수 있는 장기 보존
지역 중복, 영역 중복 또는 로컬 중복 백업 스토리지 중에서 선택, 1~35일 보존(기본값 7일)
최대 10년까지 사용할 수 있는 장기 보존
LRS(로컬 중복), ZRS(영역 중복) 또는 GRS(지역 중복) 스토리지의 선택 항목
1~35일(기본적으로 7일) 보존, 최대 10년의 장기 보존 가능
가용성 1개 복제본, 읽기 확장 복제본(replica) 없음,
영역 중복 HA(고가용성)
3개 복제본, 1개 읽기 확장 복제본(replica),
영역 중복 HA(고가용성)
영역 중복 HA(고가용성)
가격 책정 및 청구 vCore, 예약된 스토리지 및 백업 스토리지가 청구됩니다.
IOPS는 청구되지 않습니다.
vCore, 예약된 스토리지 및 백업 스토리지가 청구됩니다.
IOPS는 청구되지 않습니다.
각 복제본 및 사용된 스토리지에 대한 vCore에는 요금이 부과됩니다.
IOPS는 청구되지 않습니다.
할인 모델 예약 인스턴스
Azure 하이브리드 혜택(개발/테스트 구독에서 사용할 수 없음)
Enterprise종량제 개발/테스트 구독
예약 인스턴스
Azure 하이브리드 혜택(개발/테스트 구독에서 사용할 수 없음)
Enterprise종량제 개발/테스트 구독
Azure 하이브리드 혜택(개발/테스트 구독에서는 제공되지 않음)1
Enterprise종량제 개발/테스트 구독

1 SQL Database 하이퍼스케일의 가격 책정이 간소화됩니다. 자세한 내용은 하이퍼스케일 가격 책정 블로그를 검토하세요.

자세한 내용은 논리 서버, 단일 데이터베이스풀링된 데이터베이스에 대한 리소스 한도를 검토하세요.

참고 항목

SLA(서비스 수준 약정)에 대한 자세한 내용은 Azure SQL Database에 대한 SLA를 참조하세요.

범용

범용 서비스 계층의 아키텍처 모델은 컴퓨팅과 스토리지 분리를 기반으로 합니다. 이 아키텍처 모델은 데이터베이스 파일을 확실하게 복제하고 내부 인프라 오류가 발생하는 경우에도 데이터 무손실을 보장하는 Azure Blob Storage의 고가용성 및 안정성을 기반으로 합니다.

다음 그림은 분리된 컴퓨팅 및 스토리지 레이어가 있는 표준 아키텍처 모델의 4개 노드를 보여줍니다.

컴퓨팅과 스토리지의 분리를 보여 주는 다이어그램.

범용 서비스 계층의 아키텍처 모델에는 두 개의 계층이 있습니다.

  • 상태 비저장 컴퓨팅 레이어는 sqlservr.exe 프로세스를 실행하고 일시적인 데이터와 캐시된 데이터(예: 계획 캐시, 버퍼 풀, 열 저장 풀)만 포함합니다. 이 상태 비저장 노드는 프로세스를 초기화하고 노드의 상태를 제어하며 필요한 경우 다른 위치로 장애 조치(failover)를 수행하는 Azure 서비스 패브릭에 의해 운영됩니다.
  • 상태 저장 데이터 계층에는 데이터베이스 파일(.mdf/.ldf)이 있으며 Azure Blob Storage에 저장됩니다. Azure Blob Storage는 데이터베이스 파일에 배치된 모든 레코드의 데이터가 손실되지 않도록 보장합니다. Azure Storage에는 프로세스가 중단되더라도 로그 파일의 모든 레코드나 데이터 파일의 페이지가 보존되도록 하는 데이터 가용성/백업 기능이 기본 제공됩니다.

데이터베이스 엔진이나 운영 체제가 업그레이드되고, 기본 인프라의 일부 부분은 실패하거나 sqlservr.exe 프로세스에서 일부 심각한 문제가 감지될 때마다, Azure Service Fabric은 상태 비저장 프로세스를 다른 상태 비저장 컴퓨팅 노드로 옮깁니다. 장애 조치(failover) 시간을 최소화하기 위해 기본 노드의 장애 조치(failover)가 발생하는 경우 새 컴퓨팅 서비스를 실행하려고 대기하는 예비 노드 세트가 있습니다. Azure Storage 계층의 데이터는 영향을 받지 않으며 데이터/로그 파일은 새로 초기화된 프로세스에 연결됩니다. 이 프로세스는 기본적으로 99.99%의 가용성을 보장하고 영역 중복성을 사용하도록 설정하면 99.995%의 가용성을 보장합니다. 전환 시간과 새 노드가 콜드 캐시로 시작된다는 사실로 인해 실행 중인 많은 워크로드로 어느 정도 성능에 영향을 미칠 수 있습니다.

이 서비스 계층을 선택하는 시기

범용 서비스 계층은 대부분의 일반 워크로드를 위해 설계된 Azure SQL 데이터베이스의 기본 서비스 계층입니다. 기본 SLA와 스토리지 대기 시간이 5~10ms인 완전 관리형 데이터베이스 엔진이 필요한 경우에는 범용 계층이 적합한 옵션입니다.

중요 비즈니스용

중요 비즈니스용 서비스 계층 모델은 데이터베이스 엔진 프로세스의 클러스터를 기반으로 합니다. 이 아키텍처 모델은 데이터베이스 엔진 노드의 쿼럼에 의존하며 유지 보수 작업 중에도 워크로드에 최소한의 성능 영향을 줍니다. 기본 운영 체제, 드라이버 및 데이터베이스 엔진의 업그레이드와 패치는 최종 사용자의 가동 중지 시간을 최소화하면서 투명하게 수행됩니다.

중요 비즈니스용 모델에서 컴퓨팅 및 스토리지는 각 노드에 통합됩니다. 4개 노드 클러스터의 각 노드에 있는 데이터베이스 엔진 프로세스 간에 데이터를 복제하고 각 노드는 로컬로 연결된 SSD를 데이터 스토리지로 사용하여 고가용성을 달성합니다. 다음 다이어그램에서는 중요 비즈니스용 서비스 계층이 가용성 그룹 복제본(replica)의 데이터베이스 엔진 노드 클러스터를 구성하는 방법을 보여 줍니다.

중요 비즈니스용 서비스 계층이 가용성 그룹 복제본(replica) 데이터베이스 엔진 노드 클러스터를 구성하는 방법을 보여 주는 다이어그램

데이터베이스 엔진 프로세스와 기본 .mdf/.ldf 파일은 모두 로컬로 연결된 SSD 스토리지가 있는 동일한 노드에 배치되어 짧은 대기 시간을 워크로드에 제공합니다. SQL Server Always On 가용성 그룹과 유사한 기술을 사용하여 고가용성이 구현됩니다. 모든 데이터베이스는 고객 워크로드에 액세스할 수 있는 기본 복제본(replica) 하나와 데이터 복사본을 포함하는 3개의 보조 복제본이 있는 데이터베이스 노드의 클러스터입니다. 주 복제본은 어떤 이유로든 오류가 발생하는 경우 보조 복제본의 데이터를 사용할 수 있도록 하기 위해 변경 내용을 보조 복제본으로 지속적으로 푸시합니다 장애 조치(failover)는 Service Fabric 및 데이터베이스 엔진을 통해 처리됩니다. 보조 복제본 하나가 주 복제본이 되고 클러스터에 충분한 노드를 보장하기 위해 새로운 보조 복제본(replica) 복제본이 만들어집니다. 워크로드는 새로운 주 복제본에 자동으로 리디렉션됩니다.

또한 중요 비즈니스용 클러스터에는 주 복제본 워크로드의 성능에 영향을 주지 않는 읽기 전용 쿼리(예: 보고서)를 실행하는 데 사용되는 읽기 전용 복제본을 무료로 제공하는 읽기 확장 기능이 제공됩니다.

이 서비스 계층을 선택하는 시기

중요 비즈니스용 서비스 계층은 기본 SSD 스토리지에서 짧은 대기 시간 응답(평균1 ~ 2밀리초) 및 기본 인프라가 실패하는 경우 빠른 복구가 필요하거나, 보고서 분석 및 읽기 전용 쿼리를 무료로 읽을 수 있는 주 데이터베이스의 보조 복제본으로 오프로드할 필요성이 있는 애플리케이션용으로 설계되었습니다.

범용 계층 대신 중요 비즈니스용 서비스 계층을 선택해야 하는 주요 이유는 다음과 같습니다.

  • 낮은 I/O 대기 시간 요구 사항 - 스토리지 레이어에서 지속적으로 빠른 응답(평균 1~2밀리초)이 필요한 워크로드는 중요 비즈니스용 계층을 사용해야 합니다.
  • 단일 무료 보조 읽기 전용 복제본(replica)이 충분한 보고 및 분석 쿼리를 사용하는 워크로드.
  • 더 높은 복원력과 오류로부터의 빠른 복구. 시스템 오류가 발생하면 주 인스턴스의 데이터베이스가 비활성화되고 보조 복제본(replica) 중 하나가 즉시 쿼리를 처리할 준비가 된 새 읽기-쓰기 주 데이터베이스가 됩니다.
  • 고급 데이터 손상 방지 중요 비즈니스용 계층은 백그라운드에서 데이터베이스 복제본을 사용하므로 서비스는 미러 및 가용성 그룹과 함께 사용할 수 있는 자동 페이지 복구를 사용하여 데이터 손상을 완화합니다. 복제본(replica)이 데이터 무결성 문제로 인해 페이지를 읽을 수 없는 경우 다른 복제본(replica)에서 페이지의 새 복사본을 검색하여 데이터 손실 또는 고객의 가동 중지 시간 없이 읽을 수 없는 페이지를 대체합니다. 이 기능은 데이터베이스에 지역 보조 복제본이 있는 경우 범용 계층에서 사용할 수 있습니다.
  • 더 높은 가용성 - 다중 가용성 영역 구성의 중요 비즈니스용 계층은 영역 오류 및 고가용성 SLA에 대한 복원력을 제공합니다.
  • 빠른 지역 복구 - 활성 지역 복제가 구성되면 중요 비즈니스용 계층은 배포된 배포 시간의 100%에 대해 5초의 RPO(복구 지점 목표) 및 30초의 RTO(복구 시간 목표)를 보장합니다.

하이퍼스케일

하이퍼스케일 서비스 계층은 모든 워크로드 유형에 적합합니다. 클라우드 네이티브 아키텍처는 독립적으로 확장 가능한 컴퓨팅 및 스토리지를 제공하여 가장 다양한 기존 및 최신 응용 프로그램을 지원합니다. 하이퍼스케일의 컴퓨팅 및 스토리지 리소스는 범용 및 중요 비즈니스용 계층에서 사용할 수 있는 리소스를 크게 초과합니다.

자세히 알아보려면 Azure SQL 데이터베이스의 하이퍼스케일 서비스 계층을 검토하세요.

이 서비스 계층을 선택하는 시기

하이퍼스케일 서비스 계층은 클라우드 데이터베이스에서 기존에 확인되던 많은 실제 제한을 없애줍니다. 대부분의 다른 데이터베이스가 단일 노드에서 사용할 수 있는 리소스로 제한되지만 하이퍼스케일 서비스 계층의 데이터베이스에는 이러한 제한이 없습니다. 유연한 스토리지 아키텍처를 사용하면 하이퍼스케일 데이터베이스는 필요에 따라 확장되며, 사용하는 스토리지 용량에 대해서만 요금이 청구됩니다.

하이퍼스케일은 고급 크기 조정 기능 외에도 대규모 데이터베이스뿐만 아니라 모든 워크로드에 적합한 옵션입니다. 하이퍼스케일을 사용하면 다음의 이점이 있습니다.

  • 고가용성 복제본 수를 0에서 4로 선택하여 비용을 제어하면서 높은 복원력과 빠른 오류 복구를 달성합니다.
  • 컴퓨팅 및 스토리지에 대한 영역 중복성을 사용하도록 설정하여 고가용성을 개선합니다.
  • 데이터베이스의 자주 액세스하는 부분에 대해 낮은 I/O 대기 시간(평균 1-2밀리초)을 달성합니다. 더 작은 데이터베이스의 경우 전체 데이터베이스에 적용될 수 있습니다.
  • 명명된 복제본(replica)을 사용하여 다양한 읽기 확장 시나리오를 구현합니다.
  • 새 노드의 로컬 스토리지에 데이터가 복사될 때까지 기다리지 않고 빠른 크기 조정을 활용합니다.
  • 영향을 주지 않으며 연속 데이터베이스 백업빠른 복원을 즐길 수 있습니다.
  • 장애 조치(failover) 그룹 및 지역 복제본을 사용하여 무중단 업무 방식 요구 사항을 지원합니다.

하드웨어 구성

vCore 모델의 일반적인 하드웨어 구성에는 표준 시리즈(Gen5), Fsv2 시리즈, DC 시리즈가 포함됩니다. 하이퍼스케일은 프리미엄 시리즈 및 프리미엄 시리즈 메모리 최적화 하드웨어에 대한 옵션도 제공합니다. 하드웨어 구성은 컴퓨팅 및 메모리 제한과 워크로드 성능에 영향을 주는 기타 특성을 정의합니다.

표준 시리즈(Gen5)와 같은 특정 하드웨어 구성은 컴퓨팅 리소스(CPU 및 메모리)에 설명된 대로 둘 이상의 프로세서(CPU) 유형을 사용할 수 있습니다. 지정된 데이터베이스 또는 탄력적 풀은 오랜 시간(일반적으로 여러 달 동안) 동일한 CPU 형식의 하드웨어에 유지되는 경향이 있지만 데이터베이스 또는 풀이 다른 CPU 형식을 사용하는 하드웨어로 이동될 수 있는 특정 이벤트가 있습니다. 예를 들어, 데이터베이스 또는 풀을 다른 서비스 목표로 규모를 스케일 업 또는 다운하는 경우, 데이터 센터의 현재 인프라가 용량 제한에 곧 도달하거나 수명 종료로 인해 현재 사용 중인 하드웨어가 곧 해제되는 경우 이동할 수 있습니다.

일부 워크로드의 경우 다른 CPU 유형으로 이동하면 성능이 변경될 수 있습니다. SQL Database CPU 유형이 변경되더라도 예측 가능한 워크로드 성능을 제공하여 좁은 범위 내에서 성능 변경을 유지하도록 하드웨어를 구성합니다. 그러나 SQL Database의 광범위한 고객 워크로드에서 새로운 유형의 CPU를 사용할 수 있게 되면 데이터베이스 또는 풀이 다른 CPU 유형으로 이동하는 경우 성능이 더 눈에 띄게 변할 수 있습니다.

사용되는 CPU 유형에 관계없이 데이터베이스 또는 Elastic Pool의 리소스 제한(예: 코어 수, 메모리, 최대 데이터 IOPS, 최대 로그 속도 및 최대 동시 작업자 수)은 데이터베이스가 동일한 서비스 목표를 유지하는 한 동일하게 유지됩니다.

컴퓨팅 리소스(CPU 및 메모리)

다음 표에서는 여러 다른 하드웨어 구성 및 컴퓨팅 계층의 컴퓨팅 리소스를 비교해서 보여줍니다.

하드웨어 구성 CPU 메모리
표준 시리즈(Gen5) 프로비저닝된 컴퓨팅
- Intel® E5-2673 v4(Broadwell) 2.3 GHz, Intel® SP-8160(Skylake)*, Intel® 8272CL(Cascade Lake) 2.5 GHz*, Intel® Xeon® Platinum 8370C(Ice Lake)*, AMD EPYC 7763v(Milan) 프로세서
- 최대 128개의 vCore 프로비전(하이퍼 스레드)

서버리스 컴퓨팅
- Intel® E5-2673 v4(Broadwell) 2.3 GHz, Intel® SP-8160(Skylake)*, Intel® 8272CL(Cascade Lake) 2.5 GHz*, Intel® Xeon® Platinum 8370C(Ice Lake)*, AMD EPYC 7763v(Milan) 프로세서
- 최대 80개의 vCore 자동크기조정(하이퍼 스레드)
- 메모리 대 vCore 비율은 워크로드 수요에 따라 메모리 및 CPU 사용량에 동적으로 적응하며 vCore당 최대 24GB일 수 있습니다. 예를 들어 지정된 시점에 워크로드가 240GB 메모리와 10개 vCore에 대해서만 사용 및 청구될 수 있습니다.
프로비저닝된 컴퓨팅
- vCore당 5.1GB
- 최대 625GB 프로비전

서버리스 컴퓨팅
- vCore당 최대 24GB까지 자동크기조정
- 최대 240GB까지 자동크기조정
Fsv2 시리즈 - Intel® 8168(Skylake) 프로세서
- 모든 코어 터보 클럭 속도가 3.4GHz이고 최대 싱글 코어 터보 클럭 속도는 3.7GHz입니다.
- 최대 72개의 vCore 프로비전(하이퍼 스레드)
- vCore당 1.9GB
- 최대 136GB 프로비전
DC 시리즈 - Intel® Xeon® E-2288G 프로세서
- Intel SGX(Software Guard Extension) 기능
- 최대 8개의 vCore 프로비전(물리적)
vCore당 4.5GB

* sys.dm_user_db_resource_governance 동적 관리 뷰에서는 Intel® SP-8160(Skylake) 프로세서를 사용하는 데이터베이스에 대한 하드웨어 세대가 Gen6으로 표시되고, Intel® 8272CL(Cascade Lake)을 사용하는 데이터베이스에 대한 하드웨어 세대는 Gen7로 표시되며 Intel® Xeon® Platinum 8370C(Ice Lake) 또는 AMD® EPYC® 7763v(Milan)를 사용하는 데이터베이스에 대한 하드웨어 세대는 Gen8로 표시됩니다. 지정된 컴퓨팅 크기 및 하드웨어 구성에 대해 리소스 한도는 CPU 유형(Intel Broadwell, Skylake, Ice Lake, Cascade Lake 또는 AMD Milan)에 관계없이 동일합니다.

자세한 내용은 단일 데이터베이스탄력적 풀의 리소스 한도를 참조하세요.

하이퍼스케일 데이터베이스 컴퓨팅 리소스 및 사양은 하이퍼스케일 컴퓨팅 리소스를 참조하세요.

표준 시리즈(Gen5)

  • 표준 시리즈(Gen5) 하드웨어는 균형 잡힌 컴퓨팅 및 메모리 리소스를 제공하며 대부분의 데이터베이스 워크로드에 적합합니다.

표준 시리즈(Gen5) 하드웨어는 전 세계의 모든 공개 지역에서 사용할 수 있습니다.

하이퍼스케일 프리미엄 시리즈

  • 프리미엄 시리즈 하드웨어 옵션은 Intel 및 AMD의 최신 CPU와 메모리 기술을 사용합니다. 프리미엄 시리즈는 표준 시리즈 하드웨어에 비해 컴퓨팅 성능을 향상시킵니다.
  • 프리미엄 시리즈 옵션은 표준 시리즈에 비해 더 빠른 CPU 성능과 더 많은 수의 최대 vCore를 제공합니다.
  • 프리미엄 시리즈 메모리 최적화 옵션은 표준 시리즈에 비해 두 배의 메모리 양을 제공합니다.
  • 표준 시리즈, 프리미엄 시리즈 및 프리미엄 시리즈 메모리 최적화는 하이퍼스케일 Elastic Pool(프리뷰)에 사용할 수 있습니다.

자세한 내용은 하이퍼스케일 프리미엄 시리즈 블로그 공지 사항을 참조하세요.

사용 가능한 지역의 경우 하이퍼스케일 프리미엄 시리즈 가용성을 참조하세요.

Fsv2 시리즈

  • Fsv2 시리즈는 CPU 요구량이 가장 많은 워크로드에 대해 낮은 CPU 지연 시간과 높은 클럭 속도를 제공하는 컴퓨팅 최적화 하드웨어 구성입니다. 하이퍼스케일 프리미엄 시리즈 하드웨어 구성과 마찬가지로 Fsv2 시리즈는 Intel 및 AMD의 최신 CPU와 메모리 기술로 구동되므로 고객은 범용 서비스 계층에서 데이터베이스 및 Elastic Pool을 사용하는 동안 최신 하드웨어를 활용할 수 있습니다.
  • 워크로드에 따라 Fsv2 시리즈는 다른 하드웨어 유형보다 많은 vCore당 CPU 성능을 제공할 수 있습니다. 예를 들어 72개의 vCore Fsv2 컴퓨팅 크기는 표준 시리즈(Gen5)의 80개 vCore보다 더 높은 CPU 성능을 저렴한 비용으로 제공할 수 있습니다.
  • Fsv2는 다른 하드웨어보다 vCore당 메모리와 tempdb를 더 적게 제공하므로 이러한 제한에 민감한 워크로드의 경우 표준 시리즈(Gen5)가 더 적합할 수 있습니다.

Fsv2 시리즈는 범용 계층에서만 지원됩니다. Fsv2 시리즈를 사용할 수 있는 지역의 경우 Fsv2 시리즈 가용성을 참조하세요.

DC 시리즈

  • DC 시리즈 하드웨어는 Intel SGX(Software Guard Extensions) 기술을 사용합니다.
  • DC 시리즈는 VBS(가상화 기반 보안) Enclave에 비해 하드웨어 Enclave의 더 강력한 보안 보호가 필요한 보안 Enclave를 사용하는 Always Encrypted 워크로드에 필요합니다.
  • DC 시리즈는 중요한 데이터를 처리하고 보안 Enclave를 사용한 Always Encrypted에서 제공하는 기밀 쿼리 처리 기능이 요구되는 작업을 위해 설계되었습니다.
  • DC 시리즈 하드웨어는 균형 있는 컴퓨팅 및 메모리 리소스를 제공합니다.

DC 시리즈는 프로비저닝된 컴퓨팅에 대해서만 지원되고(서버리스는 지원되지 않음) 영역 중복성을 지원하지 않습니다. DC 시리즈를 사용할 수 있는 지역의 경우 DC 시리즈 가용성을 참조하세요.

DC 시리즈에서 지원되는 Azure 제품 유형

DC 시리즈 하드웨어에서 데이터베이스 또는 탄력적 풀을 만들려면 종량제 또는 EA(기업계약)가 포함된 유료 제품 유형을 구독해야 합니다. DC 시리즈에서 지원되는 Azure 제품 유형의 전체 목록은 지출 한도가 없는 현재 제품을 참조하세요.

하드웨어 구성 선택

SQL Database에서 하드웨어 구성을 만들 때는 데이터베이스 또는 탄력적 풀 중에서 선택할 수 있습니다. 또한 기존 데이터베이스 또는 탄력적 풀의 하드웨어 구성도 변경할 수 있습니다.

SQL Database 또는 풀을 만들 때 하드웨어 구성을 선택하려면

자세한 내용은 SQL Database 만들기를 참조하세요.

기본 탭의 컴퓨팅 + 스토리지 섹션에서 데이터베이스 구성 링크를 선택한 다음, 구성 변경 링크를 선택합니다.

구성 페이지의 Azure Portal SQL Database 만들기 배포 스크린샷 구성 변경 단추가 강조 표시됩니다.

원하는 하드웨어 구성을 선택합니다.

Azure SQL 데이터베이스에 대한 SQL 하드웨어 구성 페이지의 Azure Portal 스크린샷

기존 SQL Database 또는 풀의 하드웨어 구성을 변경하려면

데이터베이스의 경우 개요 페이지에서 가격 책정 계층 링크를 선택합니다.

Azure SQL Database 개요 페이지의 Azure Portal 스크린샷 가격 책정 계층 '범용: 표준 시리즈(Gen5), vCore 2개'가 강조 표시되어 있습니다.

풀의 경우 개요 페이지에서 구성을 선택합니다.

단계에 따라 구성을 변경하고 이전 단계에서 설명한 대로 하드웨어 구성을 선택합니다.

고가용성

이전 세대 하드웨어에 대한 정보는 이전 세대 하드웨어 가용성을 참조하세요.

표준 시리즈(Gen5)

표준 시리즈(Gen5) 하드웨어는 전 세계의 모든 공개 지역에서 사용할 수 있습니다.

하이퍼스케일 프리미엄 시리즈

하이퍼스케일 서비스 계층 프리미엄 시리즈 및 프리미엄 시리즈 메모리 최적화 하드웨어는 다음 지역의 단일 데이터베이스 및 Elastic Pool에 사용할 수 있습니다.

  • 오스트레일리아 동부 **
  • 오스트레일리아 남동부
  • 브라질 남부
  • 캐나다 중부 **
  • 캐나다 동부
  • 동아시아
  • 유럽 북부 **
  • 유럽 서부 **
  • 프랑스 중부
  • 독일 중서부
  • 인도 중부
  • 인도 남부
  • 일본 동부
  • 일본 서부
  • 동남아시아
  • 스위스 북부
  • 영국 남부 **
  • 영국 서부 *
  • 미국 중부 **
  • 미국 동부 **
  • 미국 동부 2
  • 미국 중북부
  • 미국 중남부
  • 미국 중서부
  • 미국 서부 1
  • 미국 서부 2 **
  • 미국 서부 3 **

* 프리미엄 시리즈 메모리 최적화 하드웨어는 현재 사용할 수 없습니다.

** 영역 중복에 대한 지원을 포함합니다.

Fsv2 시리즈

Fsv2 시리즈는 다음 지역에서 제공됩니다.

  • 오스트레일리아 중부
  • 오스트레일리아 중부 2
  • 오스트레일리아 동부
  • 오스트레일리아 남동부
  • 브라질 남부
  • 캐나다 중부
  • 동아시아
  • 북유럽
  • 서유럽
  • 프랑스 중부
  • 인도 중부
  • 한국 중부
  • 한국 남부
  • 남아프리카 북부
  • 동남 아시아
  • 영국 남부
  • 영국 서부
  • 미국 동부
  • 미국 서부 2

DC 시리즈

DC 시리즈는 다음 지역에서 제공됩니다.

  • 캐나다 중부
  • 서유럽
  • 북유럽
  • 동남아시아
  • 영국 남부
  • 미국 서부
  • 미국 동부

현재 지원되지 않는 지역에서 DC 시리즈가 필요한 경우 지원 요청을 제출합니다. 기본 사항 페이지에서 다음 값을 제공합니다.

  1. 문제 유형에서 기술을 선택합니다.
  2. 하드웨어에 원하는 구독을 제공합니다. 새로 만들기를 선택합니다.
  3. 서비스 유형에서 SQL Database를 선택합니다.
  4. 리소스에 대해 일반 질문을 선택합니다.
  5. 요약에서 원하는 하드웨어 가용성 및 지역을 제공합니다.
  6. 문제 유형에서 보안, 프라이빗 및 규정 준수를 선택합니다.
  7. 문제 하위 유형에서 Always Encrypted를 선택합니다.

새 지역에서 DC 시리즈를 요청하는 Azure Portal 양식의 스크린샷.

이전 세대 하드웨어

Gen4

Gen4 하드웨어가 사용 중지되었으며 프로비전, 업 스케일링 또는 다운스컬링에는 사용할 수 없습니다. 더 넓은 범위의 vCore 및 스토리지 확장성, 가속화된 네트워킹, 최고의 IO 성능, 최소 지연 시간을 위해 데이터베이스를 지원되는 하드웨어 세대로 마이그레이션합니다. 단일 데이터베이스에 대한 하드웨어 옵션Elastic Pool에 대한 하드웨어 옵션을 검토하세요. 자세한 내용은 Azure SQL 데이터베이스의 Gen4 하드웨어에 대한 지원 종료를 참조하세요.

다음 단계