Azure Premium Storage: 고성능을 위한 설계
적용 대상: ✔️ Linux VM ✔️ Windows VM ✔️ 유연한 확장 집합 ✔️ 균일한 확장 집합
이 문서는 Azure Premium Storage를 사용하여 고성능 애플리케이션을 빌드하기 위한 지침을 제공합니다. 애플리케이션에서 사용되는 기술에 적용 가능한 성능 모범 사례가 결합된 이 문서에 제공된 지침을 사용할 수 있습니다. 지침을 설명하기 위해 이 문서 전체에서는 Premium Storage에서 실행되는 SQL Server를 예로 사용합니다.
이 문서에서는 스토리지 계층에 대한 성능 시나리오를 해결하지만 사용자는 애플리케이션 계층을 최적화해야 합니다. 예를 들어 Premium Storage에 SharePoint 팜을 호스팅하는 경우 데이터베이스 서버를 최적화하기 위해 이 문서에서 SQL Server 예제를 사용할 수 있습니다. 또한 SharePoint 팜의 웹 서버와 애플리케이션 서버를 최적화하여 최적의 성능을 얻을 수도 있습니다.
이 문서에서는 Premium Storage에서 애플리케이션 성능을 최적화하는 방법에 대한 다음과 같은 일반적인 질문에 대답합니다.
- 애플리케이션 성능을 어떻게 측정할 수 있나요?
- 예상되는 고성능이 표시되지 않는 이유는 무엇인가요?
- Premium Storage에서 애플리케이션 성능에 영향을 주는 요인은 무엇인가요?
- 이러한 요소가 Premium Storage의 애플리케이션 성능에 주는 영향은 무엇인가요?
- IOPS(초당 입력/출력 작업), 대역폭, 대기 시간에 최적화하려면 어떻게 해야 하나요?
Premium Storage에서 실행되는 워크로드는 성능이 매우 중요하므로 특별히 Premium Storage에 대한 지침을 제공합니다. 적절한 예제를 제공합니다. Standard Storage 디스크가 있는 IaaS(서비스 제공 인프라) VM에서 실행되는 애플리케이션에 이러한 지침 중 일부를 적용할 수도 있습니다.
참고 항목
경우에 따라 디스크 성능 문제로 보이는 것은 실제로 네트워크 병목 현상입니다. 이러한 상황에서 네트워크 성능을 최적화해야 합니다.
디스크를 벤치마킹하려는 경우 다음 문서를 참조하세요.
- Linux: Azure Disk Storage에서 애플리케이션 벤치마크
- Windows의 경우: 디스크 벤치마킹
VM에서 가속화된 네트워킹을 지원하는 경우 VM이 활성화되어 있는지 확인합니다. 활성화되어 있지 않으면 Windows 및 Linux 모두에 이미 배포된 VM에서 활성화할 수 있습니다.
시작하기 전에 Premium Storage를 처음 사용하는 경우 먼저 IaaS VM에 대한 Azure 디스크 유형 선택 및 프리미엄 페이지 Blob 스토리지 계정의 확장성 목표를 읽어보세요.
애플리케이션 성과 지표
다음과 같은 성과 지표를 사용하여 애플리케이션의 성능이 좋은지 여부를 평가합니다.
- 애플리케이션이 사용자 요청을 처리하는 속도입니다.
- 애플리케이션이 요청당 처리하는 데이터의 양입니다.
- 애플리케이션이 특정 기간 동안 처리 중인 요청 수입니다.
- 사용자가 요청을 제출한 후 응답을 받기 위해 기다려야 하는 기간입니다.
이러한 성과 지표에 대한 기술 용어는 IOPS, 처리량 또는 대역폭, 대기 시간입니다.
이 섹션에서는 Premium Storage의 컨텍스트에서 일반적인 성과 지표를 설명합니다. 디스크의 성능 애플리케이션 검사 목록 섹션에서는 애플리케이션에 대한 이러한 성능 지표를 측정하는 방법을 알아봅니다. 애플리케이션 성능 최적화의 뒷부분에서 이러한 성과 지표 및 최적화를 위한 권장 사항에 영향을 주는 요소에 대해 배웁니다.
IOPS
IOPS는 애플리케이션에서 스토리지 디스크에 1초 동안 보내는 요청 수입니다. 입력/출력 작업은 읽기나 쓰기, 순차 또는 임의가 될 수 있습니다. 온라인 소매 웹 사이트와 같은 OLTP(온라인 트랜잭션 처리) 애플리케이션은 많은 동시 사용자 요청을 즉시 처리해야 합니다. 사용자 요청은 애플리케이션에서 신속하게 처리해야 할 삽입 및 업데이트 집약적 데이터베이스 트랜잭션입니다. 이러한 이유로 OLTP 애플리케이션에는 매우 높은 IOPS가 필요합니다.
OLTP 애플리케이션에서는 수백만 개의 작고 임의의 I/O 요청을 처리합니다. 이러한 애플리케이션을 사용하는 경우 IOPS에 대해 최적화하기 위해 애플리케이션 인프라를 설계해야 합니다. 높은 IOPS를 얻기 위해 고려해야 할 모든 요인에 대한 자세한 내용은 애플리케이션 성능 최적화를 참조하세요.
대규모 VM에 Premium Storage 디스크를 연결하는 경우 Azure는 디스크 사양에 따라 보장된 IOPS 수를 프로비전합니다. 예를 들어 P50 디스크는 7,500IOPS를 프로비전합니다. 대규모의 각 VM 크기에는 유지할 수 있는 특정 IOPS 제한이 있습니다. 예를 들어 표준 GS5 VM에는 80,000 IOPS 제한이 있습니다.
처리량
처리량 또는 대역폭은 애플리케이션이 지정된 간격의 스토리지 디스크에 보내는 데이터의 양입니다. 애플리케이션이 대규모 I/O 단위 크기를 사용하여 입/출력 작업을 수행하는 경우 높은 처리량이 필요합니다. 데이터 웨어하우스 애플리케이션은 한 번에 많은 양의 데이터에 액세스하고 일반적으로 대량 작업을 수행하는 스캔 집약적인 작업을 실행하는 경향이 있습니다. 즉, 이러한 애플리케이션에는 더 높은 처리량이 필요합니다. 해당 애플리케이션을 사용하는 경우 처리량에 대해 최적화하기 위해 해당 인프라를 설계해야 합니다. 다음 섹션에서는 이 최적화를 달성하기 위해 조정해야 하는 요인을 설명합니다.
Premium Storage 디스크를 대규모 VM에 연결하는 경우 Azure는 해당 디스크 사양에 따라 처리량을 프로비전합니다. 예를 들어 P50 디스크는 250MB/초의 디스크 처리량을 프로비전합니다. 대규모 VM 크기마다 유지할 수 있는 특정 처리량 한도가 있습니다. 예를 들어 표준 GS5 VM에는 2,000 MB/초의 최대 처리량이 있습니다.
처리량과 IOPS 간에는 다음 수식에 표시된 관계가 있습니다.
애플리케이션에 필요한 최적의 처리량 및 IOPS 값을 결정하는 것이 중요합니다. 하나를 최적화하려고 하면 다른 하나도 영향을 받습니다. IOPS 및 처리량 최적화에 대한 자세한 내용은 애플리케이션 성능 최적화를 참조하세요.
대기 시간
대기 시간은 애플리케이션이 단일 요청을 수신하고 이를 스토리지 디스크에 보내고 클라이언트에 응답을 보내는데 걸리는 시간입니다. 대기 시간은 IOPS 및 처리량 외에도 애플리케이션의 성능에 대한 중요한 측정입니다. Premium Storage 디스크의 대기 시간은 요청에 대한 정보를 검색하고 애플리케이션에게 다시 전달하는데 걸리는 시간입니다. Premium Storage는 일관된 낮은 대기 시간을 제공합니다. 프리미엄 디스크는 대부분의 IO 작업에 대한 한 자릿수 밀리초 대기 시간을 제공하도록 설계되었습니다. Premium Storage 디스크에 읽기 전용 호스트 캐싱을 사용하는 경우 훨씬 더 낮은 읽기 대기 시간을 얻을 수 있습니다. 디스크 캐싱에 대한 자세한 내용은 디스크 캐싱을 참조하세요.
더 높은 IOPS와 처리량을 얻기 위해 애플리케이션을 최적화하면 애플리케이션의 대기 시간에 영향을 미칩니다. 애플리케이션 성능 튜닝 후 애플리케이션의 대기 시간을 평가하여 예기치 않은 높은 대기 시간 동작을 방지합니다.
관리 디스크의 일부 컨트롤 플레인 작업으로 인해 디스크가 한 스토리지 위치에서 다른 스토리지 위치로 이동할 수 있습니다. 스토리지 위치 간 디스크 이동은 데이터의 백그라운드 복사본을 통해 오케스트레이션되며 완료하는 데 몇 시간이 걸릴 수 있습니다. 일반적으로 디스크의 데이터 양에 따라 24시간 미만의 시간이 소요됩니다. 이 기간 동안 일부 읽기가 원래 위치로 리디렉션될 수 있어 완료하는 데 더 오래 걸릴 수 있으므로 애플리케이션의 읽기 대기 시간이 일반적인 읽기 대기 시간보다 길어질 수 있습니다.
백그라운드 복사 중에는 대부분의 디스크 유형에 대한 쓰기 대기 시간에 영향이 없습니다. 프리미엄 SSD v2 및 Ultra Disks의 경우 디스크의 크기가 4K인 경우 읽기 대기 시간이 더 길어집니다. 디스크의 섹터 크기가 512e인 경우 읽기 및 쓰기 대기 시간이 길어집니다.
다음 컨트롤 플레인 작업은 스토리지 위치 간에 디스크를 이동하여 대기 시간을 증가시킬 수 있습니다.
- 스토리지 형식 업데이트
- 한 VM에서 다른 VM으로 디스크 분리 및 연결
- VHD에서 관리 디스크 만들기
- 스냅샷에서 관리 디스크 만들기
- 비관리 디스크에서 관리 디스크로 변환
디스크의 성능 애플리케이션 검사 목록
Premium Storage에서 실행되는 고성능 애플리케이션을 설계하는 첫 번째 단계는 애플리케이션의 성능 요구 사항을 파악하는 것입니다. 성능 요구 사항을 수집한 후에 최적의 성능을 얻을 수 있도록 애플리케이션을 최적화할 수 있습니다.
이전 섹션에서는 일반적인 성과 지표인 IOPS, 처리량, 대기 시간을 설명했습니다. 원하는 사용자 환경을 제공하기 위해 어떤 성과 지표가 애플리케이션에 중요한지 식별해야 합니다. 예를 들어 초당 수백만 개의 트랜잭션을 처리하는 OLTP 애플리케이션에는 높은 IOPS가 가장 중요합니다. 초당 많은 양의 데이터를 처리하는 데이터 웨어하우스 애플리케이션에는 높은 처리량이 중요합니다. 라이브 비디오 스트리밍 웹 사이트와 같은 실시간 애플리케이션에는 매우 짧은 대기 시간이 중요합니다.
다음으로 해당 수명 주기 동안 애플리케이션의 최대 성능 요구 사항을 측정합니다. 다음 샘플 검사 목록을 시작으로 사용합니다. 일반, 최고, 작업 시간 외 워크로드 기간 중의 최대 성능 요구 사항을 기록합니다. 모든 워크로드 수준의 요구 사항을 식별하여 애플리케이션의 전반적인 성능 요구 사항을 확인할 수 있습니다.
예를 들어 전자 상거래 웹 사이트의 일반적인 워크로드는 1년 중 대부분의 날 동안 제공하는 트랜잭션이 됩니다. 웹 사이트의 최대 워크로드는 휴일 시즌 또는 특별 판매 이벤트 동안 제공하는 트랜잭션이 됩니다. 최대 워크로드는 일반적으로 제한된 기간에 대해 숙련되지만 애플리케이션이 두 번 이상 해당 일반 작업을 확장해야 할 수 있습니다. 50 백분위수, 90 백분위수 및 99 백분위수 요구 사항을 알아봅니다. 이 정보는 성능 요구 사항에서 모든 이상값을 필터링하고 올바른 값을 최적화하는 데 노력을 집중할 수 있습니다.
애플리케이션 성능 요구 사항 검사 목록
| 성능 요구 사항 | 50% | 90% | 99% |
|---|---|---|---|
| 초당 최대 트랜잭션 수 | |||
| % 읽기 작업 | |||
| % 쓰기 작업 | |||
| % 임의 작업 | |||
| % 순차적 작업 | |||
| I/O 요청 크기 | |||
| 평균 처리량 | |||
| 최대 처리량 | |||
| 최소 대기 시간 | |||
| 평균 대기 시간 | |||
| 최대 CPU | |||
| 평균 CPU | |||
| 최대 메모리 | |||
| 평균 메모리 | |||
| 큐 깊이 |
참고 항목
애플리케이션의 예상된 향후 성장에 따라 이러한 숫자를 스케일링하는 것을 고려하세요. 나중에 성능 향상을 위한 인프라를 변경하기가 더 어려울 수 있으므로 미리 성장을 계획하는 것이 좋습니다.
기존 애플리케이션이 있고 Premium Storage로 이동하려는 경우 먼저 기존 애플리케이션에 대해 이전 검사 목록을 빌드합니다. 그런 다음 Premium Storage에서 애플리케이션의 프로토타입을 빌드하고 애플리케이션 성능 최적화에 설명된 지침에 따라 애플리케이션을 설계합니다. 다음 문서에서는 성능 측정값을 수집하는데 사용할 수 있는 도구를 설명합니다.
애플리케이션 성능 요구 사항을 측정하기 위한 카운터
애플리케이션의 성능 요구 사항을 측정하는 가장 좋은 방법은 서버의 운영 체제에서 제공하는 PerfMon 모니터링 도구를 사용하는 것입니다. Windows의 경우 PerfMon을 사용하고 Linux의 경우 iostat을 사용할 수 있습니다. 이러한 도구는 이전 섹션에서 설명된 각 측정에 해당하는 카운터를 캡처합니다. 애플리케이션이 일반, 최고, 작업 시간 외 워크로드를 실행하는 경우 이러한 카운터의 값을 캡처해야 합니다.
PerfMon 카운터는 프로세서, 메모리, 각 논리 디스크, 서버의 실제 디스크에 사용할 수 있습니다. VM에서 Premium Storage 디스크를 사용하는 경우 실제 디스크 카운터는 각 Premium Storage 디스크에 대한 것이며 논리 디스크 카운터는 Premium Storage 디스크에 생성된 각 볼륨에 대한 것입니다. 애플리케이션 작업을 호스팅하는 디스크에 대한 값을 캡처해야 합니다. 논리 디스크와 실제 디스크 간에 일대일 매핑이 있는 경우 실제 디스크 카운터를 참조할 수 있습니다. 일대일 매핑이 없는 경우 논리 디스크 카운터를 참조하세요.
Linux에서 iostat 명령은 CPU 및 디스크 사용률 보고서를 생성합니다. 디스크 사용률 보고서는 물리적 디바이스 또는 파티션당 통계를 제공합니다. 별도 디스크에 해당 데이터와 로그가 있는 데이터베이스 서버가 있는 경우 두 디스크에 대한 이 데이터를 수집합니다. 다음 표에서 디스크, 프로세서, 메모리에 대한 카운터를 설명합니다.
| 카운터 | 설명 | PerfMon | iostat |
|---|---|---|---|
| IOPS 또는 트랜잭션 수/초 | 스토리지 디스크에 생성된 초당 I/O 요청 수 | 디스크 읽기/초 디스크 쓰기/초 |
tps r/s w/s |
| Disk reads and writes | 디스크에서 수행되는 읽기 및 쓰기 작업 % | % 디스크 읽기 시간 % 디스크 쓰기 시간 |
r/s w/s |
| 처리량 | 디스크/초에서 읽거나 디스크에 쓴 데이터 양 | 디스크 읽기 바이트/초 디스크 쓰기 바이트/초 |
kB_read/s kB_wrtn/s |
| 대기 시간 | 디스크 I/O 요청을 완료하는 총 시간 | 평균 디스크 초/읽기 평균 디스크 초/쓰기 |
await svctm |
| I/O 크기 | 스토리지 디스크에 생성된 I/O의 요청의 크기 | 평균 디스크 바이트/읽기 평균 디스크 바이트/쓰기 |
avgrq-sz |
| 큐 깊이 | 스토리지 디스크에서 읽거나 스토리지 디스크에 쓰도록 대기 중인 미해결 I/O 요청 수 | 현재 디스크 큐 길이 | avgqu-sz |
| 최대 메모리 | 애플리케이션을 원활하게 실행하는데 필요한 메모리의 양 | 사용 중인 커밋된 바이트 % | vmstat 사용 |
| 최대 CPU | 애플리케이션을 원활하게 실행하는 데 필요한 CPU 양 | 프로세서 시간 비율 | %util |
iostat 및 PerfMon에 대해 자세히 알아봅니다.
애플리케이션 성능 최적화
Premium Storage에서 실행 중인 애플리케이션의 성능에 영향을 주는 주요 요인은 I/O 요청의 특성, VM 크기, 디스크 크기, 디스크 수, 디스크 캐싱, 멀티 스레드, 큐 깊이입니다. 이러한 요소 중 일부는 시스템에서 제공하는 노브를 사용하여 제어할 수 있습니다.
대부분의 애플리케이션은 I/O 크기 및 큐 깊이를 직접 변경할 수 있는 옵션을 제공하지 못할 수도 있습니다. 예를 들어 SQL Server를 사용하는 경우 I/O 크기 및 큐 깊이를 선택할 수 없습니다. SQL Server에서는 최적의 성능을 얻기 위해 최적의 I/O 크기 및 큐 깊이 값을 선택합니다. 성능 요구 사항에 맞게 적절한 리소스를 프로비전할 수 있도록 두 요소 형식이 애플리케이션 성능에 미치는 영향을 이해하는 것이 중요합니다.
이 섹션 전체에서 애플리케이션 성능을 최적화하기 위해 필요한 정도를 식별하도록 만든 애플리케이션 요구 사항 검사 목록을 참조하세요. 검사 목록에 따라 이 섹션에서 조정해야 할 요인을 확인할 수 있습니다.
각 요인이 애플리케이션 성능에 미치는 영향을 감시하려면 애플리케이션 설치에서 벤치마킹 도구를 실행합니다. Windows 및 Linux VM에서 일반적인 벤치마킹 도구를 실행하는 단계는 이 문서의 마지막에 있는 벤치마킹 문서를 참조하세요.
한눈에 IOPS, 처리량 및 대기 시간 최적화
다음 표에서 성능 요소 및 IOPS, 처리량 및 대기 시간을 최적화하는 데 필요한 단계를 요약합니다. 이 요약에 이어지는 섹션에서는 각 요인을 자세히 설명합니다.
VM 크기 및 각 VM의 유형에 사용할 수 있는 IOPS, 처리량 및 대기 시간에 대한 자세한 내용은 Azure에서 가상 머신에 대한 크기를 참조하세요.
| 성능 요인 | IOPS | 처리량 | 대기 시간 |
|---|---|---|---|
| 예제 시나리오 | 초당 비율로 매우 높은 트랜잭션이 필요한 엔터프라이즈 OLTP 애플리케이션입니다. | 다량의 데이터를 처리하는 엔터프라이즈 데이터 웨어하우징 애플리케이션입니다. | 온라인 게임과 같은 사용자 요청에 대한 즉각적인 응답이 필요한 거의 실시간 애플리케이션입니다. |
| 성능 요인 | |||
| I/O 크기 | I/O 크기가 작을수록 IOPS가 높아집니다. | I/O 크기가 클수록 처리량이 높아집니다. | |
| VM 크기 | 애플리케이션 요구 사항보다 큰 IOPS를 제공하는 VM 크기를 사용합니다. | 애플리케이션 요구 사항보다 처리량 제한이 큰 VM 크기를 사용합니다. | 애플리케이션 요구 사항보다 큰 규모 제한을 제공하는 VM 크기를 사용합니다. |
| 디스크 크기 | 애플리케이션 요구 사항보다 큰 IOPS를 제공하는 디스크 크기를 사용합니다. | 애플리케이션 요구 사항보다 처리량 제한이 큰 디스크 크기를 사용합니다. | 애플리케이션 요구 사항보다 큰 규모 제한을 제공하는 디스크 크기를 사용합니다. |
| VM 및 디스크 스케일 제한 | 선택한 VM 크기의 IOPS 제한은 연결된 스토리지 디스크에 의해 생성되는 총 IOPS보다 커야 합니다. | 선택한 VM 크기의 처리량 제한은 연결된 Premium Storage 디스크에 의한 총 처리량보다 커야 합니다. | 선택한 VM 크기의 스케일 제한은 연결된 Premium Storage 디스크의 총 스케일 제한보다 커야 합니다. |
| 디스크 캐싱 | 더 많은 읽기 IOPS를 얻기 위해 많은 읽기 작업과 함께 Premium Storage 디스크의 ReadOnly 캐시를 사용합니다. | 더 짧은 읽기 대기 시간을 얻기 위해 많은 읽기 작업과 함께 Premium Storage 디스크의 ReadOnly 캐시를 사용합니다. | |
| 디스크 스트라이프 | 결합된 높은 IOPS 및 처리량 제한을 얻기 위해 여러 디스크 및 디스크 스트라이프를 사용합니다. VM당 결합된 한계는 연결된 프리미엄 디스크의 결합된 제한보다 높아야 합니다. | ||
| 스트라이프 크기 | OLTP 애플리케이션에 표시된 작은 임의 I/O 패턴의 더 작은 스트라이프 크기입니다. 예를 들어 SQL Server OLTP 애플리케이션에 64KB 스트라이프 크기를 사용합니다. | 데이터 웨어하우스에 애플리케이션에 표시된 순차적 대형 I/O 패턴의 더 큰 스트라이프 크기입니다. 예를 들어 SQL Server 데이터 웨어하우스 애플리케이션에 256KB 스트라이프 크기를 사용합니다. | |
| 멀티스레딩 | 높은 IOPS 및 처리량을 얻도록 하는 Premium Storage에 더 높은 요청 수를 밀어 넣도록 다중 스레딩을 사용합니다. 예를 들어 SQL Server에서 SQL Server에 더 많은 CPU를 할당하는 높은 MAXDOP 값을 설정합니다. | ||
| 큐 깊이 | 큐 깊이가 클수록 IOPS가 높아집니다. | 큐 깊이가 클수록 처리량이 높아집니다. | 큐 깊이가 작을수록 대기 시간이 짧아집니다. |
I/O 요청의 특성
I/O 요청은 애플리케이션에서 수행하는 입력/출력 작업의 단위입니다. I/O 요청, 임의 또는 순차, 읽기 또는 쓰기, 소형 또는 대형의 특성을 식별하면 애플리케이션의 성능 요구 사항을 결정하는데 도움이 됩니다. 애플리케이션 인프라를 설계할 때 올바른 결정을 내릴 수 있도록 I/O 요청의 특성을 이해하는 것이 중요합니다. 최적의 성능을 얻으려면 I/O를 균등하게 배포해야 합니다.
I/O 크기는 더 중요한 요소 중 하나입니다. I/O 크기는 애플리케이션에 의해 생성된 입력/출력 작업 요청의 크기입니다. I/O 크기는 성능, 특히 애플리케이션이 달성할 수 있는 IOPS 및 대역폭에 크게 영향을 줍니다. 다음 수식은 IOPS 간의 관계, I/O 크기, 대역폭/처리량을 보여 줍니다.
일부 애플리케이션에서는 I/O 크기 변경을 허용하지만 일부 애플리케이션에서는 그렇지 않습니다. 예를 들어 SQL Server는 자체적으로 최적의 I/O 크기를 결정하고 변경할 수 있는 노브를 사용자에게 제공하지 않습니다. 반면 Oracle은 데이터베이스의 I/O 요청 크기를 구성하는 데 사용할 수 있는 DB_BLOCK_SIZE라는 매개 변수를 제공합니다.
I/O 크기 변경을 허용하지 않는 애플리케이션을 사용하는 경우 이 문서의 지침을 사용하여 애플리케이션에 가장 관련이 있는 성능 KPI를 최적화합니다. 예시:
- OLTP 애플리케이션에서는 수백만 개의 작고 임의적인 I/O 요청을 생성합니다. 이러한 유형의 I/O 요청을 처리하려면 높은 IOPS를 얻도록 애플리케이션 인프라를 설계해야 합니다.
- 데이터 웨어하우징 애플리케이션은 크고 순차적인 I/O 요청을 생성합니다. 이러한 형식의 I/O 요청을 처리하려면 높은 대역폭 또는 처리량을 얻도록 애플리케이션 인프라를 설계해야 합니다.
I/O 크기를 변경할 수 있는 애플리케이션을 사용하는 경우 다른 성능 지침 외에도 I/O 크기에 대해 이 규칙을 사용합니다.
- 작은 크기의 I/O는 더 높은 IOPS를 얻습니다. 예를 들어 OLTP 애플리케이션의 경우 8KB입니다.
- 더 높은 대역폭/처리량을 얻기 위한 더 큰 크기의 I/O입니다. 예를 들어 데이터 웨어하우스 애플리케이션의 경우 1,024KB입니다.
애플리케이션의 IOPS 및 처리량/대역폭을 계산하는 방법에 대한 예입니다.
P30 디스크를 사용하는 애플리케이션을 고려합니다. P30 디스크가 달성할 수 있는 최대 IOPS 및 처리량/대역폭은 각각 5,000IOPS 및 200MB/초입니다. 애플리케이션에 P30 디스크의 최대 IOPS가 필요하고 8KB와 같은 더 작은 I/O 크기를 사용하는 경우 얻을 수 있는 결과 대역폭은 40MB/초입니다. 애플리케이션에 P30 디스크의 최대 처리량/대역폭이 필요하고 1,024KB와 같은 더 큰 I/O 크기를 사용하는 경우 결과 IOPS는 200IOPS와 같이 더 적습니다.
두 애플리케이션의 IOPS 및 처리량/대역폭 요구 사항이 충족되도록 I/O 크기를 조정합니다. 다음 표에서 P30 디스크에 대한 다양한 I/O 크기 및 해당 IOPS와 처리량을 요약합니다.
| 애플리케이션 요구 사항 | I/O 크기 | IOPS | 처리량/대역폭 |
|---|---|---|---|
| 최대 IOPS | 8KB | 5,000 | 40MB/초 |
| 최대 처리량 | 1,024KB | 200 | 200MB/초 |
| 최대 처리량 + 높은 IOPS | 64KB | 3,200 | 200MB/초 |
| 최대 IOPS + 높은 처리량 | 32KB | 5,000 | 160MB/초 |
단일 Premium Storage 디스크의 최댓값보다 높은 IOPS 및 대역폭을 얻으려면 함께 스트라이프된 여러 프리미엄 디스크를 사용합니다. 예를 들어 두 개의 P30 디스크를 스트라이프하여 10,000IOPS의 결합된 IOPS 또는 400MB/초의 결합된 처리량을 얻습니다. 다음 섹션에서 설명한 대로 결합된 디스크 IOPS 및 처리량을 지원하는 VM 크기를 사용해야 합니다.
참고 항목
IOPS 또는 처리량이 증가하면 다른 하나도 증가합니다. 둘 중 하나가 증가할 때 디스크나 VM의 처리량 또는 IOPS 제한에 도달하지 않도록 합니다.
애플리케이션 성능에 미치는 I/O 크기의 영향을 감시하려면 VM 및 디스크에서 벤치마킹 도구를 실행할 수 있습니다. 여러 테스트 실행을 만들고 각 실행에 다른 I/O 크기를 사용하여 어떤 영향이 있는지 확인합니다. 자세한 내용은 이 문서의 마지막에 있는 벤치마킹 문서를 참조하세요.
대규모 VM 크기
애플리케이션 설계를 시작할 때 실행할 첫 번째 작업 중 하나는 애플리케이션을 호스팅할 VM을 선택하는 것입니다. Premium Storage는 높은 컴퓨팅 능력 및 높은 로컬 디스크 I/O 성능이 필요한 애플리케이션을 실행할 수 있는 대규모의 VM 크기와 함께 제공됩니다. 이러한 VM은 로컬 디스크의 빠른 프로세서, 더 높은 메모리-코어 비율, SSD(반도체 드라이브)를 제공합니다. Premium Storage를 지원하는 대규모 VM의 예로 DS 및 GS 시리즈 VM이 있습니다.
대규모 VM은 다양한 수의 CPU 코어, 메모리, OS, 임시 디스크 크기와 함께 다양한 크기에서 사용할 수 있습니다. 각 VM 크기에는 또한 VM에 연결할 수 있는 데이터 디스크의 최대 수가 있습니다. 선택한 VM 크기는 애플리케이션에 사용할 수 있는 프로세스, 메모리, 스토리지 용량에 영향을 줍니다. 컴퓨팅 및 스토리지 비용에도 영향을 줍니다. 예를 들어 다음 사양은 DS 시리즈 및 GS 시리즈에서 가장 큰 VM 크기의 사양입니다.
| VM 크기 | CPU 코어 | 메모리 | VM 디스크 크기 | 최대 데이터 디스크 수 | 캐시 크기 | IOPS | 대역폭 캐시 I/O 제한 |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112GB | OS = 1023GB 로컬 SSD = 224GB |
32 | 576GB | 50,000 IOPS 512MB/초 |
4,000 IOPS 및 33MB/초 |
| Standard_GS5 | 32 | 448GB | OS = 1023GB 로컬 SSD = 896GB |
64 | 4224GB | 80,000 IOPS 2,000MB/초 |
5,000 IOPS 및 50MB/초 |
사용 가능한 모든 Azure VM 크기의 전체 목록을 보려면 Azure의 가상 머신 크기를 참조하세요. 원하는 애플리케이션 성능 요구 사항에 충족하고 확장할 수 있는 VM 크기를 선택합니다. 또한 VM 크기를 선택할 때 다음과 같은 중요한 고려 사항을 기억합니다.
확장 한도
VM당 및 디스크당 최대 IOPS 제한은 서로 다르고 독립적입니다. 애플리케이션이 VM 및 VM에 연결된 프리미엄 디스크의 한도 내에서 IOPS를 구동하는지 확인하세요. 그렇지 않은 경우 애플리케이션 성능에 제한이 발생합니다.
한 예로 애플리케이션 요구 사항이 최대 4,000 IOPS라 가정합니다. 이 수준을 달성하려면 DS1 VM에서 P30 디스크를 프로비전합니다. P30 디스크는 최대 5,000 IOPS를 제공할 수 있습니다. 그러나 DS1 VM은 3,200 IOPS로 제한됩니다. 따라서 애플리케이션 성능은 3,200 IOPS의 VM 제한으로 인해 제한되며 성능이 저하됩니다. 이러한 상황을 방지하려면 애플리케이션 요구 사항을 충족하는 VM 및 디스크 크기를 선택합니다.
작업 비용
대부분의 경우에서 Premium Storage를 사용하는 작업의 전체 비용은 Standard Storage를 사용하는 비용보다 낮을 수 있습니다.
예를 들어 16,000 IOPS를 필요로 하는 애플리케이션을 가정합니다. 이 성능을 달성하려면 32개의 Standard Storage 1TB 디스크를 사용하여 최대 16,000의 IOPS를 제공할 수 있는 Standard_D14 Azure IaaS VM이 필요합니다. 각 1TB 표준 스토리지 디스크는 최대 500 IOPS를 달성할 수 있습니다.
- 이 VM의 월별 예상 비용은 $1,570입니다.
- 32개의 Standard Storage 디스크의 월별 비용은 $1,638입니다.
- 예상되는 총 월별 비용은 $3,208입니다.
그러나 Premium Storage에 동일한 애플리케이션을 호스트한 경우 더 작은 VM 크기와 적은 Premium Storage 디스크가 필요하므로 전체 비용이 절감됩니다. Standard_DS13 VM은 4개의 P30 디스크를 사용하여 16,000 IOPS 요구 사항을 충족할 수 있습니다. DS13 VM은 25,600의 최대 IOPS를 가지고 각 P30 디스크는 5,000의 최대 IOPS를 가집니다. 전체적으로 이 구성은 5,000 x 4 = 20,000 IOPS를 달성할 수 있습니다.
- 이 VM의 월별 예상 비용은 $1,003입니다.
- 4개의 P30 Premium Storage 디스크의 월간 비용은 $544.34입니다.
- 예상되는 총 월별 비용은 $1,544입니다.
다음 표에서 Standard 및 Premium Storage에 대한 이 시나리오의 비용 분석을 요약합니다.
| 월간 비용 | Standard | Premium |
|---|---|---|
| 월별 VM 비용 | $1,570.58(Standard_D14) | $1,003.66(Standard_DS13) |
| 월별 디스크 비용 | $1,638.40(32 x 1TB 디스크) | $544.34(4 x P30 디스크) |
| 월별 전체 비용 | $3,208.98 | $1,544.34 |
Linux 배포판
Premium Storage를 사용하여 Windows 및 Linux를 실행하는 VM에 대해 동일한 성능 수준을 얻습니다. Microsoft는 다양한 버전의 Linux 배포판을 지원합니다. 자세한 내용은 Azure에서 보증된 Linux 분포를 참조하세요.
다양한 배포판은 다양한 유형의 워크로드에 더 적합합니다. 워크로드가 실행 중인 배포판에 따라 다양한 수준의 성능을 확인할 수 있습니다. 애플리케이션을 사용하여 Linux 배포판을 테스트하고 가장 잘 작동하는 것을 선택합니다.
Premium Storage를 사용하여 Linux를 실행할 때 높은 성능을 보장하기 위해 필수 드라이버의 최신 업데이트를 확인합니다.
Premium Storage 디스크 크기
Premium Storage는 다양한 크기를 제공하므로 요구 사항에 가장 적합한 항목을 선택할 수 있습니다. 각 디스크 크기는 IOPS, 대역폭 및 스토리지에 대한 다른 규모 한도를 가집니다. 애플리케이션 요구 사항 및 대규모 VM 크기에 따라 올바른 Premium Storage 디스크 크기를 선택합니다. 아래 표에서 디스크 크기와 디스크 기능을 보여 줍니다. P4, P6, P15, P60, P70, P80 크기는 현재 관리 디스크에만 지원됩니다.
| 프리미엄 SSD 크기 | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 디스크 크기(GiB) | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
| 디스크당 기본 프로비전된 IOPS | 120 | 120 | 120 | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
| **디스크당 확장 프로비전된 IOPS | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 8,000 | 16,000 | 20,000 | 20,000 | 20,000 | 20,000 |
| 디스크당 기본 프로비전된 처리량 | 25MB/초 | 25MB/초 | 25MB/초 | 25MB/초 | 50MB/초 | 100MB/초 | 125MB/s | 150MB/초 | 200MB/s | 250MB/초 | 250MB/초 | 500MB/s | 750MB/s | 900MB/s |
| **디스크당 확장 프로비전된 처리량 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 300MB/s | 600MB/s | 900MB/s | 900MB/s | 900MB/s | 900MB/s |
| 디스크당 최대 버스트 IOPS | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* |
| 디스크당 최대 버스트 처리량 | 170MB/s | 170MB/s | 170MB/s | 170MB/s | 170MB/s | 170MB/s | 170MB/s | 170MB/s | 1,000MB/s* | 1,000MB/s* | 1,000MB/s* | 1,000MB/s* | 1,000MB/s* | 1,000MB/s* |
| 최대 버스트 기간 | 30분 | 30분 | 30분 | 30분 | 30분 | 30분 | 30분 | 30분 | 무제한* | 무제한* | 무제한* | 무제한* | 무제한* | 무제한* |
| 예약 가능 | 아니요 | 아니요 | 아니요 | 아니요 | 아니요 | 아니요 | 아니요 | 아니요 | 예, 최대 1년 | 예, 최대 1년 | 예, 최대 1년 | 예, 최대 1년 | 예, 최대 1년 | 예, 최대 1년 |
*주문형 버스팅이 설정된 디스크에만 적용됩니다.
** 성능 플러스(미리 보기)가 사용하도록 설정된 디스크에만 적용됩니다.
선택하는 디스크의 수는 선택한 디스크 크기에 따라 달라집니다. 애플리케이션 요구 사항에 맞게 하나의 P50 디스크 또는 여러 P10 디스크를 사용할 수 있습니다. 선택할 때 여기에 나열된 고려 사항을 기억합니다.
스케일 제한(IOPS 및 처리량)
각 프리미엄 디스크 크기의 IOPS 및 처리량 제한은 VM 스케일 제한과 다르며 독립적입니다. 디스크의 총 IOPS 및 처리량이 선택한 VM 크기의 스케일 제한 내에 있는지 확인합니다.
예를 들어 애플리케이션 요구 사항이 최대 250MB/초의 처리량이고 단일 P30 디스크가 있는 DS4 VM을 사용하는 경우 DS4 VM은 최대 256MB/초 처리량을 제공할 수 있습니다. 그러나 단일 P30 디스크는 200MB/초의 처리량 제한이 있습니다. 따라서 디스크 제한으로 인해 애플리케이션은 200MB/초로 제한됩니다. 이 제한을 극복하려면 VM에 둘 이상의 데이터 디스크를 프로비전하거나 디스크의 크기를 P40 또는 P50으로 조정해야 합니다.
참고 항목
캐시에서 제공하는 읽기는 디스크 IOPS 및 처리량에 포함되지 않으므로 디스크 제한이 적용되지 않습니다. 캐시에는 VM당 별도 IOPS 및 처리량 제한이 있습니다.
예를 들어 처음에 읽기 및 쓰기는 각각 60MB/초 및 40MB/초입니다. 시간이 지남에 따라 캐시는 가동 준비하고 캐시에서 더 많은 읽기를 제공합니다. 그런 다음 디스크에서 더 높은 쓰기 처리량을 얻을 수 있습니다.
디스크 수
애플리케이션 요구 사항을 평가하여 필요한 디스크 수를 결정합니다. 각 VM 크기는 VM에 연결할 수 있는 디스크 수의 제한 또한 있습니다. 일반적으로 이 양은 코어 수의 두 배입니다. 선택한 VM 크기가 필요한 디스크 수를 지원할 수 있는지 확인합니다.
Premium Storage 디스크에는 Standard Storage 디스크에 비해 더 높은 성능 기능이 있습니다. Standard Storage를 사용하여 Azure IaaS VM에서 애플리케이션을 Premium Storage로 마이그레이션하는 경우 애플리케이션에 대해 동일하거나 더 높은 성능을 얻을 수 있도록 더 적은 프리미엄 디스크가 필요할 가능성이 있습니다.
디스크 캐싱
Premium Storage를 사용하는 대규모 VM에는 BlobCache라는 다중 계층 캐싱 기술이 있습니다. BlobCache는 캐싱에 대해 호스트 RAM 및 로컬 SSD의 조합을 사용합니다. 이 캐시는 Premium Storage 영구 디스크 및 VM 로컬 디스크에 사용할 수 있습니다. 기본적으로 이 캐시 설정은 OS 디스크에 대해 ReadWrite로 Premium Storage에서 호스팅되는 데이터 디스크에 대해 ReadOnly로 설정됩니다. Premium Storage 디스크에서 디스크 캐싱을 사용하면 대규모 VM은 기본 디스크 성능을 초과하는 매우 높은 수준의 성능을 얻을 수 있습니다.
Warning
디스크 캐싱은 4TiB 이상 디스크에서 지원되지 않습니다. 여러 디스크가 VM에 연결되어 있는 경우 4TiB보다 작은 디스크는 캐싱을 지원합니다.
Azure 디스크의 캐시 설정이 변경되면 대상 디스크를 분리하고 다시 연결합니다. 운영 체제 디스크인 경우 VM이 다시 시작됩니다. 디스크 캐시 설정을 변경하기 전에 이 중단의 영향을 받을 수 있는 모든 애플리케이션/서비스를 중지합니다. 이러한 권장 사항을 따르지 않으면 데이터가 손상될 수 있습니다.
BlobCache를 작동하는 방법에 대한 자세한 내용은 내부 Azure Premium Storage 블로그 게시물을 참조하세요.
올바른 디스크 집합에 캐시를 사용하는 것이 중요합니다. 프리미엄 디스크에서 디스크 캐싱을 사용하도록 설정할지 여부는 디스크가 처리될 워크로드 패턴에 따라 달라집니다. 다음 표에서 OS 및 데이터 디스크에 대한 기본 캐시 설정을 보여 줍니다.
| 디스크 유형 | 기본 캐시 설정 |
|---|---|
| OS 디스크 | ReadWrite |
| 데이터 디스크 | 읽기 전용 |
데이터 디스크에는 다음 디스크 캐시 설정을 사용하는 것이 좋습니다.
| 디스크 캐싱 설정 | 이 설정을 사용하는 시점에 대한 권장 사항 |
|---|---|
| 없음 | 쓰기 전용 및 쓰기가 많은 디스크에 대해 None으로 호스트-캐시를 구성합니다. |
| 읽기 전용 | 읽기 전용 및 읽기-쓰기 디스크에 대해 ReadOnly로 호스트-캐시를 구성합니다. |
| ReadWrite | 애플리케이션이 필요할 때 영구 디스크에 캐시된 데이터 쓰기를 올바르게 처리하는 경우 ReadWrite로 호스트-캐시를 구성합니다. |
읽기 전용
Premium Storage 데이터 디스크에 ReadOnly 캐싱을 구성하면 다음 두 가지 이유로 인해 읽기 대기 시간을 줄이고 애플리케이션에 대한 읽기 IOPS 및 처리량을 매우 높일 수 있습니다.
- VM 메모리 및 로컬 SSD에 있는 캐시에서 수행되는 읽기는 Azure Blob Storage에 있는 데이터 디스크에서 읽는 것보다 빠릅니다.
- Premium Storage는 캐시에서 처리된 읽기를 디스크 IOPS 및 처리량으로 계산하지 않습니다. 이러한 이유로 애플리케이션은 더 높은 총 IOPS 및 처리량을 달성할 수 있습니다.
ReadWrite
기본적으로 OS 디스크에는 ReadWrite 캐싱이 사용되도록 설정되어 있습니다. 최근에 데이터 디스크에 ReadWrite 캐싱에 대한 지원을 추가했습니다. ReadWrite 캐싱을 사용하는 경우 영구 디스크에 캐시의 데이터를 기록하는 적절한 방법이 있어야 합니다. 예를 들어 SQL Server는 자체적으로 영구 스토리지 디스크에 캐시된 데이터 쓰기를 처리합니다. 필요한 데이터를 유지하도록 처리하지 않는 애플리케이션에 ReadWrite 캐시를 사용하면 VM이 충돌할 경우 데이터 손실이 발생할 수 있습니다.
없음
현재 None은 데이터 디스크에서만 지원됩니다. OS 디스크에서는 지원되지 않습니다. OS 디스크에서 None을 설정하면 내부적으로 이 설정을 재정의하고 ReadOnly로 설정합니다.
한 예로 다음 단계에 따라 Premium Storage에서 실행 중인 SQL Server에 이러한 지침을 적용할 수 있습니다.
- 데이터 파일을 호스트하는 Premium Storage 디스크에 ReadOnly 캐시를 구성합니다.
- 데이터 페이지는 데이터 디스크에서 직접 검색하는 것보다 캐시에서 빨리 검색하므로 캐시에서 빠른 읽기는 SQL Server 쿼리 시간을 낮춥니다.
- 캐시에서 읽기 제공은 프리미엄 데이터 디스크에서 사용할 수 있는 더 많은 처리량이 있음을 의미합니다. SQL Server는 이 추가 처리량을 사용하여 더 많은 데이터 페이지와 백업/복원, 배치 처리, 인덱스 다시 빌드와 같은 다른 작업을 검색할 수 있습니다.
- 로그 파일을 호스트하는 Premium Storage 디스크에 None 캐시를 구성합니다.
- 로그 파일은 주로 쓰기 작업이 많으므로 ReadOnly 캐시의 이점을 얻지 못합니다.
Linux VM의 성능 최적화
모든 프리미엄 SSD 또는 Ultra Disk의 경우 데이터 손실이 가능한 캐시가 없다는 것이 확인되면 성능을 향상시키기 위해 디스크의 파일 시스템에 대한 장애물을 사용하지 않도록 설정할 수 있습니다. Azure 디스크 캐싱이 ReadOnly 또는 None으로 설정된 경우 장애물을 사용하지 않도록 설정할 수 있습니다. 그러나 캐싱이 ReadWrite로 설정된 경우 쓰기 내구성을 보장하기 위해 장애물을 사용하도록 설정된 상태로 유지되어야 합니다. 장애물은 일반적으로 기본적으로 활성화되지만 파일 시스템 유형에 따라 다음 방법 중 하나를 사용하여 장애물을 사용하지 않도록 설정할 수 있습니다.
- reiserFS: 장애물을 사용하지 않도록 설정하려면 barrier=none 옵션을 사용합니다. 장애물을 명시적으로 사용하도록 설정하려면 barrier=flush를 사용합니다.
- ext3/ext4: 장애물을 사용하지 않도록 설정하려면 barrier=0 옵션을 사용합니다. 장애물을 명시적으로 사용하도록 설정하려면 barrier=1을 사용합니다.
- XFS: 장애물을 사용하지 않도록 설정하려면 nobarrier 옵션을 사용합니다. 장애물을 명시적으로 사용하도록 설정하려면 barrier를 사용합니다. 주요 Linux 커널 버전 4.10부터 XFS 파일 시스템의 디자인은 항상 내구성을 보장합니다. 장벽을 사용하지 않도록 설정해도 아무런 효과가 없으며 nobarrier 옵션은 더 이상 사용되지 않습니다. 그러나 일부 Linux 배포판에서는 이전 커널 버전을 사용하여 배포 릴리스에 대한 변경 내용을 백포트했을 수 있습니다. 배포 공급업체에 문의하여 실행 중인 배포 및 버전의 상태를 확인합니다.
디스크 스트라이프
대규모 VM이 여러 Premium Storage 영구 디스크와 연결되어 있는 경우 디스크는 해당 IOP, 대역폭, 스토리지 용량을 집계하도록 함께 스트라이프될 수 있습니다.
Windows에서 스토리지 공간을 사용하여 디스크를 함께 스트라이프할 수 있습니다. 풀에서 각 디스크마다 하나의 열을 구성해야 합니다. 그렇지 않은 경우 디스크에서의 고르지 못한 트래픽 분배로 예상보다 스트라이프 볼륨의 전반적인 성능이 저하될 수 있습니다.
서버 관리자 UI를 사용하여 스트라이프 볼륨에 대해 최대 8개까지 열의 총 수를 설정할 수 있습니다. 9개 이상의 디스크를 연결하는 경우에는 PowerShell을 사용하여 볼륨을 만듭니다. PowerShell을 사용하여 디스크 수와 동일한 열 수를 설정할 수 있습니다. 예를 들어 단일 스트라이프 집합에 16개의 디스크가 있는 경우 New-VirtualDisk PowerShell cmdlet의 NumberOfColumns 매개 변수에 16개의 열을 지정합니다.
Linux에서 MDADM 유틸리티를 사용하여 디스크를 함께 스트라이프합니다. Linux에서 디스크를 스트라이프하는 방법의 단계는 Linux에서 소프트웨어 RAID 구성을 참조하세요.
스트라이프 크기
디스크 스트라이프에서 중요한 구성은 스트라이프 크기입니다. 스트라이프 크기 또는 블록 크기는 애플리케이션이 스트라이프 볼륨을 해결할 수 있는 데이터의 가장 작은 청크입니다. 구성한 스트라이프 크기는 애플리케이션 및 해당 요청 패턴의 형식에 따라 달라집니다. 잘못된 스트라이프 크기를 선택하는 경우 애플리케이션의 성능이 저하되는 I/O 정렬 문제가 발생할 수 있습니다.
예를 들어 애플리케이션에 의해 생성된I/O 요청이 디스크 스트라이프 크기보다 큰 경우 스토리지 시스템은 둘 이상의 디스크에 스트라이프 단위 경계를 넘어 작성합니다. 해당 데이터에 액세스할 때 요청을 완료하려면 둘 이상의 스트라이프 단위 간을 검색해야 합니다. 이러한 동작의 누적 된 효과로 성능이 상당히 저하될 수 있습니다. 반면에 I/O 요청 크기가 스트라이프 크기보다 작고 기본적으로 임의일 경우 I/O 요청은 병목 상태가 발생하고 궁극적으로 I/O 성능이 저하되는 동일한 디스크에 추가할 수 있습니다.
애플리케이션이 실행하는 작업의 유형에 따라 적절한 스트라이프 크기를 선택합니다. 작은 임의 I/O 요청의 경우 더 작은 스트라이프 크기를 사용합니다. 반면 순차적인 큰 I/O 요청의 경우 더 큰 스트라이프 크기를 사용합니다. Premium Storage에서 실행되는 애플리케이션의 스트라이프 크기 권장 사항에 대해 알아봅니다. SQL Server의 경우 OLTP 워크로드용은 64KB, 데이터 웨어하우징 워크로드용은 256KB로 스트라이프 크기를 구성합니다. 자세한 내용은 Azure VM의 SQL Server에 대한 성능 모범 사례를 참조하세요.
참고 항목
DS 시리즈 VM에 최대 32개의 Premium Storage 디스크를 GS 시리즈 VM에 64개의 Premium Storage 디스크를 함께 스트라이프할 수 있습니다.
멀티스레딩
Azure는 대규모로 병렬되도록 Premium Storage 플랫폼을 설계합니다. 이러한 이유로 다중 스레드 애플리케이션은 단일 스레드 애플리케이션보다 더 높은 성능을 얻을 수 있습니다. 다중 스레드 애플리케이션은 여러 스레드로 해당 작업을 분할하고 VM 및 디스크 리소스를 최대한으로 활용하여 해당 실행의 효율성을 높입니다.
예를 들어 애플리케이션이 두 개의 스레드를 사용하여 단일 코어 VM에서 실행 중인 경우 CPU는 효율성을 달성하기 위해 두 스레드 사이를 전환할 수 있습니다. 한 스레드가 디스크 I/O 완료를 대기하는 동안 CPU에서 다른 스레드로 전환할 수 있습니다. 이러한 방식으로 두 스레드는 단일 스레드보다 더 많은 작업을 수행할 수 있습니다. VM에 두 개 이상의 코어가 있는 경우 각 코어는 병렬로 작업을 실행할 수 있으므로 실행 시간이 더 줄어듭니다.
기존의 애플리케이션이 단일 스레딩 또는 다중 스레딩을 구현하는 방식을 변경할 수 없을 수도 있습니다. 예를 들어 SQL Server는 다중 CPU 및 다중 코어를 처리할 수 있습니다. 그러나 SQL Server는 하나 이상의 스레드를 사용하여 쿼리를 처리하는 조건을 결정합니다. 다중 스레드를 사용하여 쿼리를 실행하고 인덱스를 작성할 수 있습니다. 사용자에게 반환하기 전에 큰 테이블 결합 및 데이터 정렬을 포함하는 쿼리의 경우 SQL Server는 다중 스레드를 사용할 수 있습니다. 사용자는 SQL Server에서 단일 스레드 또는 다중 스레드를 사용하여 쿼리를 실행할지 여부를 제어할 수 없습니다.
이 다중 스레딩 또는 애플리케이션의 병렬 처리에 영향을 주도록 변경할 수 있는 구성 설정이 있습니다. 예를 들어 SQL Server의 경우 max degree of parallelism 구성입니다. 이 설정은 MAXDOP로 SQL Server에서 병렬 처리 시 사용할 수는 프로세서의 최대 수를 구성할 수 있습니다. 개별 쿼리 또는 인덱스 작업에 대한 MAXDOP를 구성할 수 있습니다. 이 기능은 성능이 중요한 애플리케이션에 대한 시스템의 리소스 균형을 유지하려는 경우에 유용합니다.
예를 들어 SQL Server를 사용하는 애플리케이션이 큰 쿼리와 인덱스 작업을 동시에 실행한다고 가정합니다. 인덱스 작업이 큰 쿼리보다 성능이 높아지길 원한다고 가정해 보겠습니다. 이러한 경우 쿼리에 대한 MAXDOP 값보다 높도록 인덱스 작업의 MAXDOP 값을 설정할 수 있습니다. 이러한 방식으로 SQL Server는 더 큰 쿼리에 사용할 수는 프로세서 수에 비해 인덱스 작업에 사용할 수 있는 것 보다 더 많은 프로세서를 가집니다. SQL Server에서 각 작업에 사용할 스레드 수를 제어하지 않습니다. 다중 스레딩에 사용되는 프로세서의 최대 수를 제어할 수 있습니다.
SQL Server의 병렬 처리 수준에 대해 자세히 알아봅니다. 이러한 설정이 성능을 최적화하기 위해 애플리케이션 및 구성의 다중 스레딩에 어떤 영향을 주는지 확인합니다.
큐 깊이
큐 깊이, 큐 길이 또는 큐 크기는 시스템에서 보류 중인 I/O 요청 횟수입니다. 큐 깊이의 값은 스토리지 디스크가 처리하는 애플리케이션의 정렬 가능한 I/O 작업 수를 결정합니다. 이는 이 문서에서 설명하는 세 가지 애플리케이션 성능 지표인 IOPS, 처리량, 대기 시간 모두에 영향을 줍니다.
큐 깊이와 다중 스레딩은 밀접한 관련이 있습니다. 큐 깊이 값은 얼마나 많은 다중 스레딩을 애플리케이션에서 수행할 수 있는지를 나타냅니다. 큐 깊이가 클 경우 애플리케이션은 동시에 더 많은 작업, 즉 더 많은 다중 스레딩을 동시에 실행할 수 있습니다. 큐 깊이가 작은 경우 애플리케이션이 다중 스레드이더라도 동시 실행을 위해 정렬된 요청이 충분하지 않습니다.
일반적으로 큐 깊이를 잘못 설정한 경우 득보다 실이 더 많기 때문에 기존 애플리케이션에서는 큐 깊이를 변경할 수 없습니다. 애플리케이션은 최적의 성능을 얻기 위해 올바른 값의 큐 깊이를 설정합니다. 애플리케이션의 성능 문제를 해결할 수 있도록 이 개념을 이해하는 것이 중요합니다. 또한 시스템의 벤치마킹 도구를 실행하여 큐 크기의 효과를 확인할 수 있습니다.
일부 애플리케이션은 큐 깊이에 영향을 미칠 수 있는 설정을 제공합니다. 예를 들어 이전 섹션에서 설명한 SQL Server의 MAXDOP 설정입니다. MAXDOP는 SQL Server의 큐 깊이 값을 직접 변경하지는 않지만 큐 깊이 및 다중 스레딩에 영향을 주는 방법입니다.
높은 큐 깊이
높은 큐 크기는 디스크에 더 많은 작업을 정렬합니다. 디스크는 해당 큐에서 미리 다음 요청을 알고 있습니다. 따라서 디스크는 미리 작업을 예약하고 최적의 순서로 처리할 수 있습니다. 애플리케이션이 디스크에 더 많은 요청을 보내므로 디스크는 더 많은 병렬 I/O를 처리할 수 있습니다. 궁극적으로 애플리케이션은 더 높은 IOPS를 달성할 수 있습니다. 애플리케이션이 더 많은 요청을 처리하므로 애플리케이션의 총 처리량도 증가합니다.
일반적으로 애플리케이션에서 연결된 디스크당 8~16 이상의 미해결 I/O를 통해 최대 처리량을 달성할 수 있습니다. 큐 깊이가 1인 경우 애플리케이션은 시스템에 충분한 I/O를 푸시하지 않고 지정된 기간 동안 더 적은 양을 처리합니다. 즉, 처리량이 적습니다.
예를 들어 SQL Server에서 쿼리에 대한 MAXDOP 값을 4로 설정하면 SQL Server에 쿼리를 실행하는데 최대 4개의 코어를 사용할 수 있음을 알립니다. SQL Server는 쿼리 실행에 대한 최적의 큐 깊이 값 및 코어 수를 결정합니다.
최적의 큐 깊이
매우 높은 큐 깊이 값 또한 단점이 있습니다. 큐 깊이 값이 너무 높으면 애플리케이션은 매우 높은 IOPS를 구동하려고 합니다. 애플리케이션에 IOPS가 충분히 프로비전된 영구 디스크가 없는 한, 매우 높은 큐 깊이 값은 애플리케이션 대기 시간에 부정적인 영향을 줄 수 있습니다. 다음 수식은 IOPS, 대기 시간, 큐 깊이 간의 관계를 보여 줍니다.
큐 깊이를 높은 값으로 구성해서는 안되며 대기 시간에 영향을 주지 않고 애플리케이션에 충분한 IOPS를 제공할 수 있는 최적의 값으로 구성해야 합니다. 예를 들어 애플리케이션 대기 시간에 1밀리초가 필요한 경우 5,000개의 IOPS를 달성하기 위해 필요한 큐 깊이는 QD = 5,000 x 0.001 = 5입니다.
스트라이프 볼륨의 큐 깊이
스트라이프 볼륨의 경우 모든 디스크가 개별적으로 최대 큐 깊이를 갖도록 충분히 높은 큐 깊이를 유지합니다. 예를 들어 2의 큐 깊이를 푸시하는 애플리케이션과 스트라이프에 4개의 디스크가 있다고 가정합니다. 두 개의 I/O 요청은 2개의 디스크로 이동하고 나머지 두 디스크는 유휴 상태가 됩니다. 따라서 모든 디스크가 사용 중일 수 있도록 큐 깊이를 구성합니다. 다음 수식에서는 스트라이프 볼륨의 큐 깊이를 결정하는 방법을 보여 줍니다.
제한
Premium Storage는 선택한 VM 크기 및 디스크 크기에 따라 지정된 IOPS 수 및 처리량을 프로비전합니다. 애플리케이션이 VM 또는 디스크가 처리할 수 있는 한도를 초과하여 IOPS 또는 처리량을 구동하려 할 때 Premium Storage는 이를 제한합니다. 결과적으로 애플리케이션의 성능이 저하되어 대기 시간이 길어지거나 처리량이 낮아지거나 IOPS가 낮아질 수 있습니다.
Premium Storage가 제한되지 않는 경우 애플리케이션은 리소스가 달성할 수 있는 한도를 초과하여 완전히 실패할 수 있습니다. 제한으로 인한 성능 문제를 방지하려면 항상 애플리케이션에 충분한 리소스를 프로비전합니다. 이전 VM 크기 및 디스크 크기 섹션에서 설명한 내용을 고려합니다. 벤치마킹은 애플리케이션을 호스트하는데 필요한 리소스를 찾는데 가장 적합합니다.
다음 단계
디스크를 벤치마킹하려는 경우 다음 문서를 참조하세요.
- Linux: Azure Disk Storage에서 애플리케이션 벤치마크
- Windows의 경우: 디스크 벤치마킹
사용 가능한 디스크 유형에 대해 자세히 알아봅니다.
SQL Server 사용자의 경우 SQL Server에 대한 성능 모범 사례의 문서를 참조하세요.