스토리지: Azure VM의 SQL Server에 대한 성능 모범 사례

적용 대상: Azure VM 기반 SQL Server

이 문서에서는 Azure VM(가상 머신) 기반 SQL Server의 성능을 최적화하기 위한 스토리지 모범 사례와 지침을 제공합니다.

일반적으로 비용에 대한 최적화와 성능에 대한 최적화 간의 절충이 있습니다. 이 성능 모범 사례 시리즈는 Azure VM 기반 SQL Server에 대한 최상의 성능을 얻는 데 중점을 두었습니다. 워크로드가 적은 경우 모든 권장 최적화 사항이 필요하지 않을 수 있습니다. 이러한 권장 사항을 평가할 때 성능 요구 사항, 비용 및 작업 패턴을 고려하세요.

자세한 내용은 이 시리즈의 다른 문서(검사 목록, VM 크기, 보안, HADR 구성 및 기준 수집)를 참조하세요.

검사 목록

이 문서의 나머지 부분에서 자세히 설명하는 스토리지 모범 사례에 대한 간략한 개요를 보려면 다음 검사 목록을 검토하세요.

• 디스크 유형을 선택하기 전에 애플리케이션을 모니터링하고 SQL Server 데이터, 로그, tempdb 파일에 대한 스토리지 대역폭 및 대기 시간 요구 사항을 결정합니다.
• 가능한 경우 tempdb D: 로컬 SSD 볼륨에 tempdb 데이터 및 로그 파일을 구성합니다. SQL IaaS 에이전트 익스텐션은 다시 프로비전할 때 필요한 폴더와 권한을 처리합니다.
• 스토리지 성능을 최적화하기 위해 사용 가능한 캐시되지 않은 최고 IOPS를 계획하고, 가상 머신 및 디스크 상한 설정을 방지하면서 데이터 읽기에 대한 성능 기능으로 데이터 캐싱을 사용합니다.
• Ebdsv5 또는 Ebsv5 시리즈 SQL Server VM을 사용하는 경우 최고의 가격 대비 성능을 위해 프리미엄 SSD v2를 사용합니다. Azure Portal(현재 프리뷰 상태)을 사용하여 프리미엄 SSD v2가 포함된 SQL Server VM을 배포할 수 있습니다.
• 데이터, 로그 및 tempdb 파일을 별개의 드라이브에 배치합니다.
  • 데이터 드라이브의 경우 프리미엄 P30 및 P40 디스크 이하를 사용하여 캐시 지원의 가용성을 보장합니다. Ebdsv5 VM 시리즈를 사용하는 경우 높은 IOPS 및 I/O 처리량이 필요한 워크로드에 더 나은 가격 대비 성능을 제공하는 프리미엄 SSD v2를 사용합니다.
  • 로그 드라이브의 경우 프리미엄 SSD v2 또는 프리미엄 SSD P30~P80 디스크를 평가하는 동안 용량 및 테스트 성능과 비용에 대해 계획합니다.
    • 밀리초보다 적은 단위의 스토리지 대기 시간이 필요한 경우 트랜잭션 로그에 프리미엄 SSD v2 또는 Azure Ultra Disks를 사용합니다.
    • M 시리즈 가상 머신 배포의 경우 Azure Ultra Disks를 사용하는 것보다 쓰기 가속기를 사용하는 것이 좋습니다.
  • 최적의 VM 크기를 선택한 후 FCI(장애 조치(failover) 클러스터 인스턴스)의 일부가 아닌 대부분의 SQL Server 워크로드에 대해 임시 디스크(임시 디스크는 임시이며 기본값은 D:\임)에 tempdb를 배치합니다.
    • tempdb를 배치하기에 로컬 드라이브의 용량이 부족한 경우 VM의 크기를 조정하는 것이 좋습니다. 자세한 내용은 데이터 파일 캐싱 정책을 참조하세요.
  • FCI(장애 조치(failover) 클러스터 인스턴스)의 경우 공유 스토리지에 tempdb를 배치합니다.
    • FCI 워크로드가 tempdb 디스크 성능에 크게 의존하는 경우 FCI 스토리지에 있지 않은 로컬 임시 SSD(기본값 D:\) 드라이브에 고급 구성 위치로 tempdb를 배치합니다. 이 구성은 이 드라이브의 오류로 FCI에서 작업을 트리거하지 못하기 때문에 로컬 임시 SSD(기본값 D:\) 드라이브를 항상 사용할 수 있도록 사용자 지정 모니터링 및 작업이 필요합니다.
• 대상 가상 머신의 최대 IOPS 및 처리량 한계까지 I/O 대역폭을 늘리려면 스토리지 공간을 사용하여 여러 Azure 데이터 디스크를 스트라이프합니다.
• 데이터 파일 디스크에 대해 호스트 캐싱을 읽기 전용으로 설정합니다.
• 로그 파일 디스크에 대해 호스트 캐싱을 없음으로 설정합니다.
  • SQL Server 데이터 또는 로그 파일이 포함된 디스크에서 읽기/쓰기 캐싱을 사용하도록 설정하지 마세요.
  • 디스크의 캐시 설정을 변경하기 전에 항상 SQL Server 서비스를 중지합니다.
• 여러 다른 워크로드를 클라우드 로 마이그레이션할 때 Azure Elastic SAN은 비용 효율적인 통합 스토리지 솔루션이 될 수 있습니다. 그러나 Azure Elastic SAN을 사용하는 경우 SQL Server 워크로드에 대해 원하는 IOPS/처리량을 달성하려면 용량을 과도하게 프로비전해야 하는 경우가 많습니다. 일반적으로 단일 SQL Server 워크로드에는 적합하지 않지만 성능이 낮은 워크로드를 SQL Server와 결합할 때 비용 효율적인 솔루션을 얻을 수 있습니다.
• 개발 및 테스트 워크로드와 장기 백업 보관에는 표준 스토리지를 사용하는 것이 좋습니다. 프로덕션 워크로드에는 표준 HDD/SSD를 사용하지 않는 것이 좋습니다.
• 크레딧 기반 디스크 버스팅(P1-P20)은 소규모 개발/테스트 워크로드 및 부서 시스템인 경우에만 고려해야 합니다.
• 스토리지 성능을 최적화하려면 사용 가능한 캐시되지 않은 최고 IOPS를 계획하고, 가상 머신 및 디스크 최대 가용량 사용/제한을 방지하면서 데이터 읽기에 대한 성능 기능으로 데이터 캐싱을 사용합니다.
• 임시 D:\ 드라이브(기본값은 4KB)가 아닌 드라이브에 배치된 모든 데이터 파일에 대해 64KB 할당 단위 크기를 사용하도록 데이터 디스크의 형식을 지정합니다. Azure Marketplace를 통해 배포된 SQL Server VMs는 할당 단위 크기로 형식이 지정된 데이터 디스크와 함께 제공되고 64KB로 설정된 스토리지 풀에 인터리빙됩니다.
• SQL Server VM과 동일한 하위 지역에 스토리지 계정을 구성합니다.
• Azure 지역 중복 스토리지(지역에서 복제)를 사용하지 않도록 설정하고 스토리지 계정에서 LRS(로컬 중복 스토리지)를 사용합니다.
• SQL 모범 사례 평가를 사용하도록 설정하여 발생 가능한 성능 문제를 식별하고 SQL Server VM이 모범 사례를 따르도록 구성되어 있는지 평가합니다.
• 스토리지 IO 사용률 메트릭을 사용하여 디스크 및 VM 한도를 검토하고 모니터링합니다.
• 바이러스 백신 소프트웨어 검사에서 데이터 파일, 로그 파일, 백업 파일을 포함한 SQL Server 파일을 제외합니다.

스토리지 체크리스트를 다른 모범 사례와 비교하려면 포괄적인 성능 모범 사례 체크리스트를 참조하세요.

개요

Azure VM에서 SQL Server 워크로드에 대한 가장 효율적인 구성을 찾으려면 먼저 비즈니스 애플리케이션의 스토리지 성능을 측정하여 시작합니다. 스토리지 요구 사항을 파악한 후에는 적절한 메모리 대 vCore 비율을 사용하여 필요한 IOPS 및 처리량을 지원하는 가상 머신을 선택합니다.

워크로드에 대한 스토리지 확장성이 충분하고 비즈니스의 용량 및 성능 요구 사항을 충족하는 디스크를 혼합(일반적으로 스토리지 풀)하여 VM 크기를 선택합니다.

디스크 유형은 디스크에서 호스트 되는 파일 유형과 최고 성능 요구 사항에 따라 달라집니다.

팁

Azure Portal을 통해 SQL Server VM을 프로비저닝하면 스토리지 구성 프로세스를 안내하고, 데이터 및 로그 파일에 대 한 별도의 스토리지 풀 만들기, D:\ 드라이브에 tempdb 대상 지정, 최적의 캐싱 정책 사용과 같은 대부분의 스토리지 모범 사례를 구현할 수 있습니다. 스토리지를 프로비전하고 구성하는 방법에 대한 자세한 내용은 SQL VM 스토리지 구성을 참조하세요.

VM 디스크 유형

디스크의 성능 수준에서 선택할 수 있습니다. 기본 스토리지로 사용할 수 있는 관리 디스크 유형(성능 향상 기능으로 표시됨)은 표준 HDD(하드 디스크 드라이브), 표준 SSD(반도체 드라이브), 프리미엄 SSD, 프리미엄 SSD v2 및 Ultra Disks입니다.

표준 HDD, 표준 SSD 및 프리미언 SSD의 경우 디스크의 성능은 디스크 크기가 4GiB 인 P1 및 120 IOPS와 같은 프리미엄 디스크 레이블을 사용하여 그룹화되며 스토리지가 32TiB인 P80 및 2만 IOPS로 디스크를 늘립니다. 프리미엄 스토리지는 일부 워크로드에 대한 읽기 및 쓰기 성능을 개선하는 데 도움이 되는 스토리지 캐시를 지원합니다. 자세한 내용은 관리 디스크 개요를 참조하세요.

프리미엄 SSD v2 및 Ultra Disks의 성능은 디스크 크기와 별개로 변경할 수 있습니다. 자세한 내용은 Ultra Disk 성능 및 프리미엄 SSD v2 성능을 참조하세요.

Azure VM 기반 SQL Server(OS 디스크, 임시 디스크 및 데이터 디스크)에 대해 고려해야 할 세 가지 주요 디스크 역할도 있습니다. 운영 체제 드라이브 (C:\) 및 임시 드라이브 (D:\)에 저장된 항목을 신중하게 선택합니다.

운영 체제 디스크

운영 체제 디스크는 운영 체제의 실행 버전으로 부팅하고 탑재할 수 있는 VHD이며 C:\ 드라이브로 레이블이 지정됩니다. Azure Virtual Machine을 만들 때 플랫폼에서는 운영 체제 디스크용 VM에 하나 이상의 디스크를 연결합니다. C:\ 드라이브는 애플리케이션 설치 및 파일 구성에 대한 기본 위치입니다.

프로덕션 SQL Server 환경의 경우 데이터 파일, 로그 파일, 오류 로그에 운영 체제 디스크를 사용하지 마세요.

임시 디스크

Azure VM은 임시 디스크(D:\ 드라이브로 레이블이 지정됨)라는 다른 디스크를 포함합니다. VM 시리즈 및 크기에 따라 이 디스크의 용량은 달라질 수 있습니다. 임시 디스크는 사용 후 삭제됩니다. 즉, VM을 다시 시작하거나(예: 할당 해제 후 다시 할당) 다른 호스트로 이동할 때(예: 서비스 복구) 디스크 스토리지를 다시 만듭니다.

임시 스토리지 드라이브는 원격 스토리지에 유지되지 않으므로 사용자 데이터베이스 파일, 트랜잭션 로그 파일 또는 보존되어야 하는 항목을 저장해서는 안 됩니다. 예를 들어, 버퍼 풀 익스텐션, 페이지 파일 및 tempdb에 사용할 수 있습니다.

로컬 캐시를 사용하는 데 문제가 있는 경우를 제외하고 SQL Server 워크로드에 대한 로컬 임시 SSD D:\ 드라이브에 tempdb를 넣습니다. 임시 디스크가 없는 VM을 사용하는 경우, 캐싱을 읽기 전용으로 설정하여 자체 격리된 디스크 또는 스토리지 풀에 tempdb를 저장하는 것이 좋습니다. 자세한 내용은 tempdb 데이터 캐싱 정책을 참조하세요.

데이터 디스크

데이터 디스크는 단일 디스크에서 VM에 제공할 수 있는 용량과 성능을 초과하기 위해 스토리지 풀에서 자주 만들어지는 원격 스토리지 디스크입니다.

워크로드의 IOPS, 처리량 및 용량 요구 사항을 충족하는 최소 디스크 수를 연결합니다. 크기를 조정하려는 가장 작은 VM의 최대 데이터 디스크 수를 초과하지 마세요.

성능 요구 사항에 가장 적합하도록 프로비전된 데이터 디스크에 데이터 및 로그 파일을 저장합니다.

임시 D:\ 드라이브(기본값은 4KB)가 아닌 드라이브에 배치된 모든 데이터 파일에 대해 64KB 할당 단위 크기를 사용하도록 데이터 디스크의 형식을 지정합니다. Azure Marketplace를 통해 배포된 SQL Server VMs는 할당 단위 크기로 형식이 지정된 데이터 디스크와 함께 제공되고 64KB로 설정된 스토리지 풀에 인터리빙됩니다.

참고 항목

Azure Blob Storage 또는 Azure 프리미엄 파일 공유와 같은 SMB 스토리지에서 직접 SQL Server 데이터베이스 파일을 호스트할 수도 있지만 최상의 성능, 안정성 및 기능 가용성을 위해 Azure 관리 디스크를 사용하는 것이 좋습니다.

프리미엄 SSD v2

현재 제한 사항이 사용자 환경에 적합한 경우 지원되는 하위 지역에서 SQL Server 워크로드를 실행할 때 프리미엄 SSD v2 디스크를 사용해야 합니다. 구성에 따라 프리미엄 SSD v2가 성능을 향상하면서 프리미엄 SSD보다 저렴할 수도 있습니다. 프리미엄 SSD v2를 사용하면 디스크 크기에 관계없이 처리량 또는 IOPS를 개별적으로 조정할 수 있습니다. 성능 옵션을 개별적으로 조정할 수 있으면 더 큰 비용 절감이 가능하며 예상되거나 알려진 필요 기간 동안 성능 요구 사항을 충족하도록 변경 내용을 스크립트로 작성할 수 있습니다.

이러한 높은 I/O 처리량 컴퓨터에 대한 보다 비용 효율적인 솔루션이므로 Ebdsv5 또는 Ebsv5 가상 머신 시리즈를 사용할 때 프리미엄 SSD v2를 사용하는 것이 좋습니다.

Azure Portal(현재 프리뷰 상태)을 사용하여 프리미엄 SSD v2가 포함된 SQL Server VM을 배포할 수 있습니다.

Azure Portal을 사용하여 SQL Server VM을 배포하고 프리미엄 SSD v2를 사용하려는 경우 현재 Ebdsv5 또는 Ebsv5 시리즈 가상 머신으로 제한됩니다. 그러나 프리미엄 SSD v2 스토리지를 사용하여 VM을 수동으로 만든 다음 VM에 SQL Server를 수동으로 설치하는 경우 프리미엄 SSD v2를 지원하는 모든 VM 시리즈를 사용할 수 있습니다. 익스텐션에서 제공하는 모든 이점을 활용할 수 있도록 SQL IaaS 에이전트 익스텐션에 SQL Server VM을 등록해야 합니다.

Azure Elastic SAN

Azure Elastic SAN은 고객에게 스토리지 통합을 통해 비용을 절감할 수 있는 유연하고 확장 가능한 솔루션을 제공하는 네트워크 연결 스토리지 제품입니다. Azure Elastic SAN은 iSCSI 프로토콜을 통해 다양한 Azure 컴퓨팅 서비스에 연결하는 경제적이고, 고성능이며 안정적인 블록 스토리지 솔루션을 제공합니다. Elastic SAN을 사용하면 고객 애플리케이션 아키텍처를 리팩터링하지 않고도 기존 SAN 스토리지 자산에서 클라우드로 원활하게 전환할 수 있습니다.

이 솔루션은 최대 수백만 개의 IOPS, 두 자릿수 GB/s의 처리량, 10밀리초 미만의 낮은 대기 시간(기본 제공 복원력)으로 스케일 업하여 가동 중지 시간을 최소화할 수 있습니다. 스토리지를 통합하거나, 여러 컴퓨팅 서비스를 사용하거나, 네트워크 대역폭을 통해 스토리지를 구동할 때 높은 처리량 수준이 필요한 워크로드가 있는 경우 Azure Elastic SAN을 사용합니다. 그러나 SQL Server 워크로드에 대해 원하는 IOPS/처리량을 달성하려면 용량을 과도하게 프로비전 해야 하는 경우가 많으므로 일반적으로 단일 SQL Server 워크로드에는 적합하지 않습니다. 가장 비용 효율적인 솔루션을 달성하려면 다른 저성능 워크로드를 SQL Server와 결합해야 할 수 있습니다.

Azure Elastic SAN에 대한 VM 크기 조정 및 성능을 고려할 때는 네트워크를 통해 스토리지 통신이 수행된다는 점을 이해하는 것이 중요합니다. 예를 들어 VM 크기 E4d_v5 Azure Premium Storage를 지원하지 않지만 최대 12,500Mbps 네트워크 처리량을 지원하므로 Azure Elastic SAN에서 잘 작동합니다. 이 VM 크기로 Azure Elastic SAN을 사용하는 경우 워크로드에 대한 네트워크 및 스토리지 처리량 요구 사항이 12,500Mbps 네트워크 처리량 제한에 속하는지 확인해야 합니다.

Azure Elastic SAN을 사용하여 SQL Server VM을 배포하기 전에 네트워크 및 스토리지 요구 사항을 확인한 다음 네트워크 및 스토리지 사용률을 주의 깊게 모니터링하여 선택한 VM이 워크로드를 수용할 수 있는지 확인합니다. 자세한 내용은 Elastic SAN 볼륨 및 Elastic SAN 메트릭을 사용한 VM 성능을 검토합니다.

주의

• Elastic SAN을 사용한 VM 크기 조정은 스토리지 처리량 외에도 프로덕션(VM에서 VM으로) 네트워크 처리량 요구 사항을 수용해야 합니다. Elastic SAN을 사용하는 경우 IO 처리량에 최적화된 VM 크기는 네트워크 대역폭에 최적화된 VM 크기만큼 비용 효율적이지 않을 수 있습니다.

다음과 같은 이유로 비용 효율성을 높이기 위해 Elastic SAN에 SQL Server 워크로드를 배치하는 것이 고려해보세요.

• 스토리지 통합 및 동적 성능 공유: 일반적으로 Azure VM 기반 SQL Server 워크로드의 경우 디스크 스토리지는 해당 VM에 대한 사용자의 용량 및 최고 성능 요구 사항에 따라 VM별로 프로비전됩니다. 이 오버프로비전된 성능은 필요할 때 사용할 수 있지만 사용되지 않은 성능은 다른 VM의 워크로드와 공유할 수 없습니다. Elastic SAN은 온-프레미스 SAN과 유사하게 여러 SQL 및 비SQL 워크로드의 스토리지 요구를 통합하여 비용 효율성을 높일 수 있으며, IO 요구 사항에 따라 이러한 다양한 워크로드에 프로비전된 볼륨 간에 동적으로 프로비전된 성능을 공유할 수 있습니다. 예를 들어, 미국 동부 지역에 각각 2TiB 용량과 10K IOPS가 필요한 10개의 워크로드가 있지만 전체적으로는 어느 시점에서든 60,000 IOPS 이상이 필요하지 않은 경우입니다. 12TiB 용량과 필요한 60K IOPS를 제공하는 12개의 기본 장치(기본 장치 1개 = GiB/월당 $0.08)와 나머지 8TiB 용량을 더 낮은 비용으로 제공하는 8개의 용량 전용 장치(용량 전용 장치 1개 = GiB/월당 $0.06)로 Elastic SAN을 구성할 수 있습니다. 이 최적의 스토리지 구성은 이러한 각 워크로드에 필요한 성능(10K IOPS)을 제공하면서 더 나은 비용 효율성을 제공합니다. Elastic SAN 기본 및 용량 전용 프로비전 단위에 대한 자세한 내용은 Azure Elastic SAN 계획을 참조하고 가격 책정은 Azure Elastic SAN - 가격 책정을 방문하세요.
• 스토리지 처리량 향상을 위해: Azure VM 기반 SQL Server 배포 시 해당 VM에 대한 디스크 처리량 한도로 인해 VM을 오버프로비전해야 하는 경우가 있습니다. Elastic SAN을 사용하면 iSCSI 프로토콜을 통해 컴퓨팅 네트워크 대역폭보다 스토리지 처리량이 높아지므로 이를 방지할 수 있습니다. 예를 들어 Standard_E32ds_v5 VM은 디스크/스토리지 처리량이 51,200 IOPS 및 865 MBps로 제한되지만 최대 2,000 MBps의 네트워크 처리량을 달성할 수 있습니다. 워크로드에 대한 스토리지 처리량 요구 사항이 865 MBps보다 큰 경우 이제 Elastic SAN을 사용하여 최대 2,000 MBps를 지원할 수 있으므로 더 높은 SKU로 VM을 업그레이드할 필요가 없습니다.

프리미엄 SSD

프로덕션 SQL Server 워크로드에 대한 데이터 및 로그 파일에 프리미엄 SSD를 사용합니다. 프리미엄 SSD IOPS 및 대역폭은 디스크 크기와 유형에따라 달라집니다.

프로덕션 워크로드의 경우 SQL Server 데이터 파일에 대한 P30 및/또는 P40 디스크를 사용하여 캐싱을 지원하고 SQL Server 트랜잭션 로그 파일에 대해 P80까지 P30을 사용합니다. 최적의 총 소유 비용을 위해, 데이터 및 로그 파일에 대해 P30(5000 IOPS/200MBps)부터 시작하고 VM 디스크 수를 제어해야 할 때 더 높은 용량을 선택합니다. 개발/테스트 또는 소규모 시스템의 경우 캐싱을 지원하지만 예약된 가격을 제공하지 않으므로 P30보다 작은 크기를 사용하도록 선택할 수 있습니다.

OLTP 워크로드의 경우 최대 사용 시간 및 Disk Reads/sec + Disk Writes/sec 성능 카운터를 사용하여 워크로드를 사용하는 성능 요구 사항과 디스크(또는 스토리지 풀)당 대상 IOPS를 일치시킵니다. 데이터 웨어하우스 및 보고 워크로드의 경우, 최대 사용 시간의 워크로드 및 Disk Read Bytes/sec + Disk Write Bytes/sec를 사용하여 대상 처리량을 일치시킵니다.

스토리지 공간을 사용하여 최적의 성능을 획득하고 두 개의 풀(로그 파일에 하나 데이터 파일에 다른 하나)을 구성합니다. 디스크 스트라이프를 사용하지 않는 경우, 별도의 드라이브에 매핑된 프리미엄 SSD 디스크 2개(로그 파일용 1개 및 데이터용 1개)를 사용합니다.

스토리지 풀의 일부로 사용되는 디스크당 프로비전된 IOPS 및 처리량입니다. 디스크의 결합된 IOPS 및 처리량 기능은 VM의 처리량 제한까지 이르는 최대 용량입니다.

가장 좋은 방법은 IOPS(및 처리량) 및 용량에 대한 최소 요구 사항을 충족하면서 최대한 적은 수의 디스크를 사용하는 것입니다. 그러나, 소형 디스크가 많은 것이 대형 디스크가 적은 것보다 가격과 성능의 균형을 유지하는 데 좋습니다.

프리미엄 디스크 크기 조정

프리미엄 SSD의 크기는 디스크의 초기 성능 계층을 결정합니다. 배포 시 성능 계층을 지정하거나 디스크 크기를 변경하지 않고 나중에 변경합니다. 요구가 증가하면 비즈니스 요구에 맞게 성능 수준을 높일 수 있습니다.

성능 계층을 변경하면 관리자가 디스크 버스팅에 의존하지 않고 높은 수요를 준비하고 충족할 수 있습니다.

스토리지 성능 계층에 맞게 요금이 청구되는 경우, 필요에 따라 더 높은 성능을 사용할 수 있습니다. 용량을 늘리지 않고 성능 요구 사항에 맞게 계층을 업그레이드합니다. 추가 성능이 더 이상 필요하지 않은 경우 원래 계층으로 돌아갑니다.

이 비용 효율적이고 일시적인 성능 확장은 쇼핑, 성능 테스트, 학습 이벤트 및 단기간 성능 향상이 필요한 기타 짧은 기간과 같은 대상 이벤트에 강력한 사용 사례입니다.

자세한 내용은 관리 디스크의 성능 계층을 참조하세요.

Azure 울트라 디스크

대기 시간이 줄어든 밀리초 미만의 응답 시간이 필요한 경우, SQL Server 로그 드라이브 또는 I/O 대기 시간에 매우 민감한 애플리케이션의 데이터 드라이브에도 Azure Ultra Disk를 사용하는 것이 좋습니다.

용량 및 IOPS를 독립적으로 확장할 수 있는 울트라 디스크를 구성할 수 있습니다. 울트라 디스크 관리자는 애플리케이션 요구 사항에 따라 용량, IOPS 및 처리량 요구 사항으로 디스크를 프로비전할 수 있습니다.

Ultra Disk는 모든 VM 시리즈에서 지원되지 않으며 하위 지역 가용성, 중복성 및 Azure Backup 지원과 같은 기타 제한 사항이 있습니다. 자세한 내용은, 전체 제한 사항 목록에 대한 Azure 울트라 디스크 사용의 내용을 참조하세요.

표준 HDD 및 SSD

표준 HDD 및 SSD는 대기 시간 및 대역폭이 다양하므로 개발/테스트 워크로드에만 권장됩니다. 프로덕션 워크로드에는 프리미엄 SSD v2 또는 프리미엄 SSD를 사용해야 합니다. 표준 SSD(개발/테스트 시나리오)를 사용하는 경우 VM 크기에서 지원하는 최대 데이터 디스크 수를 추가하고 최상의 성능을 위해 스토리지 공간을 사용하여 디스크 스트라이프를 사용하는 것이 좋습니다.

캐싱

프리미엄 스토리지 캐싱을 지원하는 VM은 Azure BlobCache 또는 호스트 캐싱이라는 추가 기능을 활용하여 VM의 IOPS 및 처리량 기능을 확장할 수 있습니다. 프리미엄 스토리지 및 프리미엄 캐싱에 사용하도록 설정된 VM에는 스토리지 성능을 향상시키기 위해 함께 사용할 수 있는 두 가지 스토리지 대역폭 제한이 있습니다.

캐싱을 사용하지 않는 IOPS 및 MBps 처리량은 VM의 캐시되지 않은 디스크 처리량 제한에 포함됩니다. 캐시된 최대 제한은 사용량 증가 및 예기치 않은 최대 사용량을 해결하는 데 도움이 되는 읽기를 위한 또 다른 버퍼를 제공합니다.

추가 비용 없이 데이터 드라이브에 대한 읽기 성능을 확실히 향상시키기 위해 옵션이 지원될 때마다 프리미엄 캐싱을 사용하도록 설정합니다.

Azure BlobCache(캐시된 IOPS 및 처리량)에 대한 읽기 및 쓰기는 VM의 캐시되지 않은 IOPS 및 처리량 한도에 대해 계산되지 않습니다.

참고 항목

4TiB 이상(P50 이상)의 디스크에서 디스크 캐싱은 지원되지 않습니다. 여러 디스크가 VM에 연결되어 있는 경우 4TiB보다 작은 디스크는 캐싱을 지원합니다. 자세한 내용은 디스크 캐싱을 참조하세요.

캐시되지 않은 처리량

최대 캐시되지 않은 디스크 IOPS 및 처리량은 VM에서 처리할 수 있는 최대 원격 스토리지 한도입니다. 이 제한은 VM에서 정의되며 기본 디스크 스토리지의 제한이 아닙니다. 이 제한은 임시 드라이브( D:\ 드라이브) 또는 OS 드라이브에 대한 로컬 I/O가 아닌 VM에 원격으로 연결된 데이터 드라이브에 대한 I/O에만 적용됩니다.

VM에 사용할 수 있는 캐시되지 않은 IOPS 및 처리량의 양은 VM에 대한 설명서에서 확인할 수 있습니다.

예를 들어, M 시리즈 설명서는 Standard_M8ms VM에 대한 최대 캐시되지 않은 처리량이 5000 IOPS 및 125MBps의 캐시되지 않은 디스크 처리량임을 보여 줍니다.

마찬가지로 Standard_M32ts에서 2만의 캐시되지 않은 디스크 IOPS 및 500MBps의 캐시되지 않은 디스크 처리량을 지원하는지 확인할 수 있습니다. 이 제한은 기본 프리미엄 디스크 스토리지에 관계 없이 VM 수준에서 관리됩니다.

자세한 내용은, 캐시되지 않은 한도 및 캐시된 한도를 참조하세요.

캐시된 스토리지 및 임시 스토리지 처리량

최대 캐시 및 임시 저장소 처리량 제한은 VM에 대한 캐시되지 않은 처리량 제한과는 별개의 제한입니다. Azure BlobCache는 VM 호스트의 임의 액세스 메모리와 로컬로 연결된 SSD의 조합으로 구성됩니다. VM 내에 임시 드라이브(D:\ 드라이브)도 이 로컬 SSD에 호스트됩니다.

캐시된 최대 및 임시 스토리지 처리량 제한은 호스트 캐싱이 사용되는 경우에만 로컬 임시 드라이브(D:\ 드라이브)와 Azure BlobCache에 대한 I/O를 제어합니다.

프리미엄 스토리지에서 캐싱이 설정된 경우, VM은 원격 스토리지의 캐시되지 않은 VM IOPS 및 처리량 제한을 초과하여 확장할 수 있습니다.

특정 VM만 프리미엄 스토리지 및 프리미엄 스토리지 캐싱을 모두 지원합니다(VM 설명서에서 확인해야 함). 예를 들어, M 시리즈 설명서는 프리미엄 스토리지 및 프리미엄 스토리지 캐싱이 모두 지원됨을 나타냅니다.

캐시 제한은 VM 크기에 따라 달라집니다. 예를 들어, Standard_M8ms VM은 10000의 캐시된 디스크 IOPS 및 1000MBps의 캐시된 디스크 처리량을 793GiB의 총 캐시 크기와 함께 지원합니다. 마찬가지로, Standard_M32ts VM은 40000의 캐시된 디스크 IOPS 및 400MBps의 캐시된 디스크 처리량을 3,174GiB의 총 캐시 크기로 지원합니다.

기존 VM에서 호스트 캐싱을 수동으로 사용하도록 설정할 수 있습니다. VM의 캐싱 정책을 변경하기 전에 모든 애플리케이션 워크로드 및 SQL Server 서비스를 중지합니다. VM 캐시 설정을 변경하면 설정이 적용된 후 대상 디스크가 분리되어 다시 첨부됩니다.

데이터 파일 캐싱 정책

스토리지 캐싱 정책은 드라이브에서 호스트되는 SQL Server 데이터 파일의 유형에 따라 달라집니다.

다음 테이블에서는 SQL Server 데이터 유형에 따라 권장되는 캐싱 정책을 요약하여 보여줍니다.

SQL Server 디스크	권장
데이터 디스크	SQL Server 데이터 파일을 호스트하는 디스크에 Read-only 캐싱을 사용하도록 설정합니다. 캐시에서 읽기는 데이터 디스크에서 캐시되지 않은 읽기를 수행하는 것보다 빠릅니다. 캐시되지 않은 IOPS 및 처리량 외에도 캐시된 IOPS 및 처리량은 VM 한도 내의 VM에서 사용할 수 있는 총 성능을 제공하지만 실제 성능은 캐시를 사용하는 워크로드의 기능 (캐시 적중률)에 따라 달라집니다.
트랜잭션 로그 디스크	트랜잭션 로그를 호스팅하는 디스크에 대한 캐싱 정책을 None으로 설정합니다. 트랜잭션 로그 디스크에 캐싱을 사용하도록 설정하는 경우, 성능의 이점을 얻을 수 없으며 실제로, 로그 드라이브에서 Read-only 또는 Read/Write 캐싱을 사용하도록 설정하면 드라이브에 대한 쓰기 성능이 저하되고 데이터 드라이브에서 읽기에 사용할 수 있는 캐시의 양이 줄어듭니다.
운영 OS 디스크	기본 캐싱 정책은 OS 드라이브에 대해 Read/write입니다. OS 드라이브의 캐싱 수준을 변경하지 않는 것이 좋습니다.
tempdb	용량이 부족하여 임시 드라이브 D:\에 tempdb를 배치할 수 없는 경우, 더 큰 임시 드라이브를 가져오도록 VM의 크기를 조정하거나 Read-only 캐싱이 구성된 별도의 데이터 드라이브에 tempdb를 배치하세요. VM 캐시와 임시 드라이브 모두 로컬 SSD를 사용하므로 tempdb I/O로 크기를 조정하면 임시 드라이브에 호스팅될 때 캐시된 IOPS 및 처리량 VM 한도에 대해 이를 염두에 두어야 합니다.

Important

Azure 디스크의 캐시 설정이 변경되면 대상 디스크를 분리하고 다시 연결합니다. SQL Server 데이터, 로그 또는 애플리케이션 파일을 호스트하는 디스크에 대한 캐시 설정을 변경하는 경우 데이터 손상 방지를 위해 다른 관련 서비스와 함께 SQL Server 서비스를 중지해야 합니다.

자세히 알아보려면 디스크 캐싱을 참조하세요.

디스크 스트라이프

로그 파일 및 tempdb를 포함하여 SQL 데이터 파일에 필요한 처리량 및 대역폭을 분석합니다. 처리량 및 대역폭 제한은 VM 크기에 따라 달라집니다. 자세한 내용은 VM 크기를 참조하세요.

데이터 디스크를 더 추가하고 추가 처리량에 디스크 스트라이프를 사용할 수 있습니다. 예를 들어, 12,000IOPS 및 180MB/초 처리량을 요구하는 애플리케이션은 3개의 스트라이프 P30 디스크를 사용하여 15,000IOPS 및 600MB/s 처리량을 제공할 수 있습니다.

디스크 스트라이프를 구성하려면 디스크 스트라이프를 참조하세요.

디스크 상한 설정

디스크 및 VM 수준 모두에서 처리량 제한이 있습니다. VM당 및 디스크당 최대 IOPS 제한은 서로 다르고 독립적입니다.

이러한 한도를 초과하는 리소스를 사용하는 애플리케이션은 제한됩니다(더 이상 사용되지 않음). 애플리케이션 요구 사항을 충족하는 디스크 스트라이프에서 VM 및 디스크 크기를 선택하면 상한 설정 제한이 발생하지 않습니다. 상한 설정을 해결하려면 캐싱을 사용하거나 더 적은 처리량이 필요하도록 애플리케이션을 조정합니다.

예를 들어, 12000IOPS 및 180MB/초를 필요로 하는 애플리케이션은 다음을 수행할 수 있습니다.

• 최대 캐시되지 않은 디스크 처리량이 20,000IOPS 및 500MBps인 Standard_M32ms를 사용합니다.
• 3개의 P30 디스크를 스트라이프하여 15000IOPS 및 600mb/s 처리량을 제공합니다.
• Standard_M16ms VM을 사용하고 호스트 캐싱을 사용하여 처리량을 소비하는 동안 로컬 캐시를 활용합니다.

사용률이 높은 시간 동안 확장하도록 구성된 VM은 최대 VM 크기를 지원할 수 있는 충분한 IOPS 및 처리량이 있는 저장소를 프로비전하고, 사용 대상으로 지정된 가장 작은 VM SKU로 지원되는 최대 개수 보다 작거나 같은 전체 디스크 수를 유지해야 합니다.

디스크 상한 설정 제한 사항에 대한 자세한 내용 및 상한 설정 사용을 방지하기 위해 캐싱을 사용하는 것에 대한 자세한 내용은 디스크 IO 상한 설정을 참조하세요.

참고

일부 디스크 상한 설정은 사용자에게 만족할 만한 성능을 제공할 수 있습니다. 대규모 VM으로 크기를 조정하는 대신 워크로드를 조정하고 관리하여 비즈니스에 대한 비용 및 성능 관리를 분산합니다.

쓰기 가속화

쓰기 가속화는 M 시리즈 VM에서만 사용할 수 있는 디스크 기능입니다. 쓰기 가속화의 목적은 대용량 중요 업무용 OLTP 워크로드 또는 데이터 웨어하우스 환경으로 인해 한 자릿수 I/O 대기 시간이 필요할 때 Azure Premium Storage에 대한 쓰기의 I/O 대기 시간을 개선하는 것입니다.

쓰기 가속화를 사용하여 로그 파일을 호스트하는 드라이브에 대한 쓰기 대기 시간을 향상시킵니다. SQL Server 데이터 파일에 쓰기 가속화를 사용하지 마세요.

쓰기 가속기 디스크는 VM과 동일한 IOPS 제한을 공유합니다. 연결된 디스크는 VM에 대한 쓰기 가속화 IOPS 제한을 초과할 수 없습니다.

다음 표에서는 VM당 지원되는 데이터 디스크 및 IOPS의 수를 간략하게 설명합니다.

VM SKU	쓰기 가속기 디스크 수	VM당 쓰기 가속기 디스크 IOPS
M416ms_v2, M416s_v2	16	20000
M128ms, M128s	16	20000
M208ms_v2, M208s_v2	8	10000
M64ms, M64ls, M64s	8	10000
M32ms, M32ls, M32ts, M32s	4	5,000
M16ms, M16s	2	2500
M8ms, M8s	1	1250

쓰기 가속화 사용에 대한 여러 제한 사항이 있습니다. 자세히 알아보려면 쓰기 가속기 사용 시 제한 사항을 참조하세요.

Azure Ultra Disk와 비교

쓰기 가속화와 Azure Ultra Disks의 가장 큰 차이점은 쓰기 가속화는 M 시리즈에만 사용할 수 있는 VM 기능이지만 Azure Ultra Disks는 저장소 옵션인 것입니다. 쓰기 가속화는 VM 크기에 따라 고유한 제한이 있는 쓰기에 최적화된 캐시입니다. Azure Ultra Disks는 Azure VM에 대한 짧은 대기 시간 디스크 저장소 옵션입니다.

가능하면 트랜잭션 로그 디스크의 울트라 디스크를 통해 쓰기 가속화를 사용합니다. 쓰기 가속화를 지원하지 않지만 트랜잭션 로그에 낮은 대기 시간이 필요한 VM의 경우 Azure Ultra Disks를 사용합니다.

스토리지 성능 모니터

스토리지 요구를 평가하고 스토리지 기능을 얼마나 잘 수행하는지 확인하려면 측정할 내용과 해당 지표의 의미를 이해해야 합니다.

IOPS(초당 입력/출력 수)는 애플리케이션이 초당 스토리지로 만드는 요청 수입니다. 성능 모니터 카운터 Disk Reads/sec 및 Disk Writes/sec을 사용하여 IOPS를 측정합니다. OLTP (온라인 트랜잭션 처리) 애플리케이션은 최적의 성능을 얻기 위해 높은 IOPS를 구동해야 합니다. 결제 처리 시스템, 온라인 쇼핑 및 소매 POS 시스템과 같은 애플리케이션은 모두 OLTP 애플리케이션의 예입니다.

처리량 은 기본 스토리지로 전송되는 데이터의 볼륨이며 종종 초당 메가바이트 단위로 측정됩니다. 성능 모니터 카운터 Disk Read Bytes/sec 및 Disk Write Bytes/sec을 사용하여 처리량을 측정합니다. 데이터 웨어하우징은 IOPS를 통한 처리량을 최대화하는 데 최적화되었습니다. 분석, 보고, ETL 작업 흐름 및 기타 비즈니스 인텔리전스 대상에 대한 데이터 저장소와 같은 애플리케이션은 모두 데이터 웨어하우징 애플리케이션의 예입니다.

I/O 단위 크기는 IOPS 및 처리량 기능에 영향을 주므로 I/O 크기가 작으면 더 높은 IOPS를 생성하고 I/O 크기가 크면 더 높은 처리량을 생성합니다. SQL Server는 최적의 I/O 크기를 자동으로 선택합니다. 자세한 내용은 애플리케이션의 IOPS, 처리량 및 대기 시간 최적화를 참조하세요.

VM 및 디스크 수준에서 상한 설정을 검색하는 데 필요한 중요한 특정 Azure Monitor 메트릭과 AzureBlob 캐시의 사용량과 상태가 있습니다. 모니터링 솔루션 및 Azure Portal 대시보드에 추가할 주요 카운터를 식별하려면 스토리지 사용률 메트릭을 참조하세요.

참고 항목

Azure Monitor는 현재 임시 드라이브 (D:\)에 대한 디스크 수준 메트릭을 제공하지 않습니다. 사용된 VM 캐시된 IOPS 비율 및 사용된 VM 캐시된 대역폭 백분율에는 모두 임시 드라이브 (D:\) 및 호스트 캐싱의 IOPS 및 처리량이 반영됩니다.

트랜잭션 로그 성장 모니터링

전체 트랜잭션 로그는 성능 문제 및 중단으로 이어질 수 있으므로 트랜잭션 로그에서 사용 가능한 공간뿐만 아니라 트랜잭션 로그를 보유하는 드라이브의 사용 가능한 디스크 공간을 모니터링하는 것이 중요합니다. 워크로드에 영향을 주기 전에 트랜잭션 로그 문제를 해결합니다.

로그가 가득 차면 전체 트랜잭션 로그 문제 해결을 검토합니다.

디스크를 확장해야 하는 경우 Azure Marketplace에서 SQL Server 이미지를 배포한 경우 스토리지 창을 SQL 가상 머신 리소스에서 또는 Azure 가상 머신 및 자체 설치된 SQL Server의 디스크 창에서 이 작업을 수행할 수 있습니다.

다음 단계

자세한 내용은 이 모범 사례 시리즈의 다른 문서를 참조하세요.

• 빠른 검사 목록

• VM 크기

• 보안

• HADR 설정

• 기준 수집

• 보안 모범 사례는 Azure Virtual Machines의 SQL Server에 대한 보안 고려 사항을 참조하세요.

• TPC-E 및 TPC_C 벤치마크를 사용하여 Azure VM에서 SQL Server 성능을 자세히 테스트하려면 블로그 OLTP 성능 최적화를 참조하세요.

• Azure Virtual Machines의 SQL Server 개요에서 다른 SQL Server 가상 머신 문서를 검토하세요. SQL Server 가상 머신에 대한 질문이 있으면 질문과 대답을 참조하세요.