Azure 파일 공유 성능 이해 및 최적화
Azure Files는 대부분의 애플리케이션과 사용 사례에서 요구하는 성능을 충족할 수 있습니다. 이 문서에서는 파일 공유 성능에 영향을 줄 수 있는 다양한 요인과 워크로드의 Azure 파일 공유 성능을 최적화하는 방법을 설명합니다.
적용 대상
| 파일 공유 유형 | SMB | NFS |
|---|---|---|
| 표준 파일 공유(GPv2), LRS/ZRS |  |
 |
| 표준 파일 공유(GPv2), GRS/GZRS | |
|
| 프리미엄 파일 공유(FileStorage), LRS/ZRS | |
|
용어 설명
이 문서를 읽기 전에 다음과 같은 스토리지 성능과 관련된 주요 용어를 이해하면 도움이 됩니다.
IOPS(초당 IO 작업 수)
IOPS 또는 초당 입력/출력 작업은 초당 파일 시스템 작업 수를 측정합니다. “IO”라는 용어는 Azure Files 설명서의 “작업” 및 “트랜잭션”이라는 용어와 상호 연결됩니다.
I/O 크기
블록 크기라고도 하는 I/O 크기는 애플리케이션이 스토리지에서 단일 I/O(입출력) 작업을 수행하는 데 사용하는 요청의 크기입니다. 애플리케이션에 따라 I/O 크기는 4KiB와 같은 매우 작은 크기에서 훨씬 더 큰 크기까지 다양할 수 있습니다. I/O 크기는 달성 가능한 처리량에서 중요한 역할을 합니다.
처리량
처리량은 스토리지에서 읽거나 스토리지에 쓰는 초당 비트 수를 측정하며, 초당 메비바이트(MiB/s) 단위로 측정합니다. 처리량을 계산하려면 IOPS에 I/O 크기를 곱합니다. 예를 들어 10,000 IOPS * 1MiB I/O 크기 = 10GiB/s이고, 10,000 IOPS * 4KiB I/O 크기 = 38MiB/s입니다.
대기 시간
대기 시간은 지연과 동의어이며 일반적으로 밀리초(ms) 단위로 측정합니다. 엔드투엔드 대기 시간과 서비스 대기 시간의 두 가지 유형이 있습니다. 자세한 내용은 대기 시간을 참조하세요.
큐 깊이
큐 깊이는 스토리지 리소스가 한꺼번에 처리할 수 있는 보류 중인 I/O 요청 수입니다. 자세한 내용은 큐 깊이를 참조하세요.
사용 패턴에 따라 성능 계층 선택
Azure Files는 적절한 수준의 성능과 가격으로 데이터를 저장하여 비용을 절감할 수 있는 다양한 스토리지 계층을 제공합니다. 최상위 수준에서 Azure Files는 표준 및 프리미엄의 두 가지 성능 계층을 제공합니다. 표준 파일 공유는 HDD(하드 디스크 드라이브)를 사용하는 스토리지 시스템에서 호스트되는 반면, 프리미엄 파일 공유는 고성능을 위해 SSD(반도체 드라이브)를 사용합니다. 표준 파일 공유에는 여러 스토리지 계층(트랜잭션 최적화, 핫 및 쿨)이 있으며 이러한 계층 간에 원활하게 이동하여 데이터 미사용 스토리지 및 트랜잭션 가격을 최대화할 수 있습니다. 그러나 다른 스토리지 계정 간에 데이터를 물리적으로 마이그레이션하지 않으면 표준 계층과 프리미엄 계층 간에 이동할 수 없습니다.
표준 파일 공유와 프리미엄 파일 공유 중에 선택할 때, Azure Files에서 실행하려는 예상 사용 패턴의 요구 사항을 파악하는 것이 중요합니다. 대량의 IOPS, 매우 빠른 데이터 전송 속도 또는 매우 짧은 대기 시간이 필요한 경우 프리미엄 Azure 파일 공유를 선택해야 합니다.
다음 표에는 표준과 프리미엄의 예상 성능 목표가 요약되어 있습니다. 자세한 내용은 Azure Files 확장성 및 성능 목표를 참조하세요.
| 사용 패턴 요구 사항 | Standard | Premium |
|---|---|---|
| 쓰기 대기 시간(10밀리초 미만) | 예 | 예 |
| 읽기 대기 시간(10밀리초 미만) | 예 | 예 |
프리미엄 파일 공유는 공유 크기에 따라 다음과 같은 성능 프로필을 보장하는 프로비저닝 모델을 제공합니다. 자세한 내용은 프로비저닝된 모델을 참조하세요. 버스트 크레딧은 파일 공유에 대한 트래픽이 기준 IOPS 이하가 될 때마다 버스트 버킷에 누적됩니다. 획득한 크레딧은 나중에 작업이 기준 IOPS를 초과할 때 버스팅을 사용하도록 설정하는 데 사용됩니다.
| 용량(GiB) | 기준 IOPS | 버스트 IOPS | 버스트 크레딧 | 처리량(수신 + 송신) |
|---|---|---|---|---|
| 100 | 3,100 | 최대 10,000 | 24,840,000 | 110MiB/s |
| 500 | 3,500 | 최대 10,000 | 23,400,000 | 150MiB/초 |
| 1,024 | 4,024 | 최대 10,000 | 21,513,600 | 203MiB/s |
| 5,120 | 8,120 | 최대 15,360 | 26,064,000 | 613MiB/s |
| 10,240 | 13,240 | 최대 30,720 | 62,928,000 | 1,125MiB/s |
| 33,792 | 36,792 | 최대 100,000 | 227,548,800 | 3,480MiB/s |
| 51,200 | 54,200 | 최대 100,000 | 164,880,000 | 5,220MiB/s |
| 102,400 | 100,000 | 최대 100,000 | 0 | 10,340MiB/s |
성능 검사 목록
새 워크로드 또는 기존 워크로드의 성능 요구 사항을 평가할 때 사용 패턴을 파악하면 예측 가능한 성능을 달성하는 데 도움이 됩니다. 스토리지 관리자 또는 애플리케이션 개발자에게 문의하여 다음 사용 패턴을 확인하세요.
대기 시간 민감도: 사용자가 파일을 열거나 Azure Files에서 실행되는 가상 데스크톱과 상호 작용하나요? 읽기 대기 시간에 민감하고 최종 사용자에게 잘 보이는 워크로드의 예입니다. 이러한 유형의 워크로드는 10밀리초 미만(I/O 크기가 작은 경우 < 2ms)의 읽기 및 쓰기 작업 대기 시간을 제공할 수 있는 프리미엄 Azure 파일 공유에 더 적합합니다.
IOPS 및 처리량 요구 사항: 프리미엄 파일 공유는 표준 파일 공유보다 더 큰 IOPS 및 처리량 제한을 지원합니다. 자세한 내용은 파일 공유 스케일링 대상을 참조하세요.
워크로드 기간 및 빈도: 가끔(1시간마다) 짧게(몇 분) 발생하는 워크로드는 오래 실행되고 자주 발생하는 워크로드에 비해 표준 파일 공유의 상단 성능 제한을 달성할 가능성이 적습니다. 프리미엄 파일 공유에서 워크로드 기간은 프로비저닝 크기에 따라 사용할 올바른 성능 프로필을 결정할 때 유용합니다. 워크로드가 버스트해야 하는 기간과 기준 IOPS보다 적게 사용하는 시간에 따라 피크 시간대에 워크로드를 일관적으로 충족할 수 있는 충분한 버스팅 크레딧을 누적하고 있는지 확인할 수 있습니다. 적절한 균형을 찾으면 파일 공유를 과도하게 프로비저닝하지 않고 비용을 절감할 수 있습니다. 성능 테스트를 짧게 몇 분 동안 실행하는 실수가 자주 벌어지는데, 이 경우 올바르게 파악할 수 없습니다. 성능을 현실적으로 확인하려면 충분히 높은 빈도와 기간으로 테스트해야 합니다.
워크로드 병렬 처리: 동일한 클라이언트에서 여러 스레드, 프로세스, 애플리케이션 인스턴스를 통해 병렬로 작업을 수행하는 워크로드의 경우 프리미엄 파일 공유는 표준 파일 공유인 SMB 다중 채널보다 명확한 이점을 제공합니다. 자세한 내용은 SMB Azure 파일 공유 성능 향상을 참조하세요.
API 작업 배포: 파일 열기/닫기 작업 때문에 워크로드 메타데이터가 무거운가요? 대량의 파일에 대해 읽기 작업을 수행하는 워크로드에서 자주 있는 일입니다. 메타데이터 또는 네임스페이스에 워크로드가 과도함을 참조하세요.
대기 시간
대기 시간을 고려할 때에는 Azure Files에서 대기 시간이 결정되는 방식부터 이해해야 합니다. 가장 일반적인 측정값은 엔드투엔드 대기 시간 및 서비스 대기 시간 메트릭과 연결된 대기 시간입니다. 이러한 트랜잭션 메트릭을 사용하면 애플리케이션 트래픽이 클라이언트를 오가는 데 소요되는 시간을 확인하여 클라이언트 쪽 대기 시간 및/또는 네트워킹 문제를 식별하는 데 도움이 될 수 있습니다.
엔드투엔드 대기 시간(SuccessE2ELatency)은 트랜잭션이 클라이언트에서 네트워크를 지나 Azure Files 서비스로, 그리고 다시 클라이언트로 돌아오는 전체 왕복을 수행하는 데 걸리는 총 시간입니다.
서비스 대기 시간(SuccessServerLatency)은 트랜잭션이 Azure Files 서비스 내에서만 왕복하는 데 걸리는 시간입니다. 클라이언트 또는 네트워크 대기 시간은 여기에 포함되지 않습니다.
SuccessE2ELatency와 SuccessServerLatency 값의 차이는 네트워크와 클라이언트에 의해 발생하는 대기 시간입니다.
클라이언트 대기 시간을 서비스 대기 시간(여기서는 Azure Files 성능)과 혼동하는 경우가 많습니다. 예를 들어 서비스 대기 시간은 짧은 대기 시간을 보고하고 엔드투엔드는 요청에 대한 매우 높은 대기 시간을 보고하는 경우 모든 시간이 Azure Files 서비스가 아닌 클라이언트와 오가는 데 소요된다는 뜻입니다.
또한 다이어그램에서 알 수 있듯이, 서비스에서 멀어질수록 대기 시간 환경이 느려지고, 클라우드 서비스의 성능 확장 제한을 달성하기가 더 어려워집니다. 온-프레미스에서 Azure Files에 액세스할 때 특히 그렇습니다. ExpressRoute와 같은 옵션은 온-프레미스에 적합하지만, 동일한 Azure 지역에서만 실행되는 애플리케이션(컴퓨팅 + 스토리지)의 성능에는 미치지 못합니다.
팁
Azure에서 VM을 사용하여 온-프레미스와 Azure 간의 성능을 테스트하는 것은 Azure에 대한 연결의 네트워킹 기능을 기준으로 하는 효과적이고 실용적인 방법입니다. 크기 미달이거나 잘못 라우팅된 ExpressRoute 회로 또는 VPN 게이트웨이 때문에 워크로드가 느려지는 경우가 많습니다.
큐 깊이
큐 깊이는 스토리지 리소스가 처리할 수 있는 보류 중인 I/O 요청 수입니다. 스토리지 시스템에서 사용하는 디스크는 HDD 스핀들(IDE, SATA, SAS)에서 반도체 디바이스(SSD, NVMe)로 발전함에 따라 더 높은 큐 깊이를 지원하도록 진화했습니다. 큰 데이터 세트 내의 단일 파일과 직렬로 상호 작용하는 단일 클라이언트로 구성된 워크로드는 낮은 큐 깊이의 사례입니다. 반면 여러 스레드 및 여러 파일의 병렬 처리를 지원하는 워크로드는 높은 큐 깊이를 쉽게 달성할 수 있습니다. Azure Files는 수천 개의 Azure 클러스터 노드에 걸쳐 있고 워크로드를 대규모로 실행하도록 설계된 분산 파일 서비스이므로, 높은 큐 깊이로 워크로드를 빌드하고 테스트하는 것이 좋습니다.
클라이언트, 파일 및 스레드와 함께 여러 가지 방법으로 높은 큐 깊이를 달성할 수 있습니다. 워크로드의 큐 깊이를 결정하려면 클라이언트 수와 파일 수와 스레드 수를 곱합니다(클라이언트 수 * 파일 수 * 스레드 수 = 큐 깊이).
아래 표는 높은 큐 깊이를 달성하는 데 사용할 수 있는 다양한 조합을 보여줍니다. 최적의 큐 깊이인 64를 초과해도 되지만 권장하지는 않습니다. 초과해도 성능이 향상되지 않으며, TCP 포화로 인해 대기 시간이 증가할 위험이 있습니다.
| 클라이언트 | 파일 | 스레드 | 큐 깊이 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 6 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 64 |
팁
상단 성능 제한을 달성하려면 여러 파일이 있는 다중 스레드로 워크로드 또는 벤치마킹 테스트를 수행해야 합니다.
단일 스레드 애플리케이션과 다중 스레드 애플리케이션의 차이
Azure Files는 다중 스레드 애플리케이션에 가장 적합합니다. 다중 스레딩이 워크로드에 미치는 성능 영향을 파악하는 가장 쉬운 방법은 I/O 기준 시나리오를 살펴보는 것입니다. 다음은 작은 파일 10,000개를 Azure 파일 공유에 또는 반대로 Azure 파일 공유의 작은 파일 10,000개를 최대한 빨리 복사해야 하는 워크로드 예제입니다.
이 표에는 4KiB 블록 크기로 쓰는 단일 스레드 애플리케이션을 기반으로 Azure 파일 공유에 단일 16KiB 파일을 만드는 데 필요한 시간(밀리초)이 정리되어 있습니다.
| I/O 작업 | 만들기 | 4KiB 쓰기 | 4KiB 쓰기 | 4KiB 쓰기 | 4KiB 쓰기 | 닫기 | 합계 |
|---|---|---|---|---|---|---|---|
| 스레드 1 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
이 예제에서는 6개 작업에서 단일 16KiB 파일을 만드는 데 약 14밀리초가 걸립니다. 단일 스레드 애플리케이션이 10,000개 파일을 Azure 파일 공유로 이동하려는 경우 각 파일이 한 번에 하나씩 순차적으로 이동되기 때문에 14밀리초 * 10,000초 = 140,000밀리초(140초)가 걸립니다. 각 요청을 처리하는 시간은 이전 섹션에서 설명한 것처럼 컴퓨팅과 스토리지 사이의 거리에 크게 좌우됩니다.
1개 대신 8개의 스레드를 사용하면 위의 워크로드를 140,000밀리초(140초)에서 17,500밀리초(17.5초)로 줄일 수 있습니다. 아래 표와 같이 파일 8개를 한 번에 하나씩이 아니라 병렬로 이동하면 동일한 양의 데이터를 이동하는 시간이 87.5% 감소합니다.
| I/O 작업 | 만들기 | 4KiB 쓰기 | 4KiB 쓰기 | 4KiB 쓰기 | 4KiB 쓰기 | 닫기 | 합계 |
|---|---|---|---|---|---|---|---|
| 스레드 1 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
| 스레드 2 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
| 스레드 3 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
| 스레드 4 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
| Thread 5 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
| 스레드 6 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
| 스레드 7 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |
| 스레드 8 | 3ms | 2ms | 2ms | 2ms | 2ms | 3ms | 14밀리초 |