Azure Files 성능 이해

2025-05-04

Azure Files는 대부분의 애플리케이션과 사용 사례에서 요구하는 성능을 충족할 수 있습니다. 이 문서에서는 파일 공유 성능에 영향을 줄 수 있는 다양한 요인과 워크로드의 Azure 파일 공유 성능을 최적화하는 방법을 설명합니다.

적용 대상

관리 모델	청구 모델	미디어 계층	중복성
Microsoft.Storage (마이크로소프트 저장소)	프로비전된 v2	HDD(표준)	로컬(LRS)
Microsoft.Storage (마이크로소프트 저장소)	프로비전된 v2	HDD(표준)	영역(ZRS)
Microsoft.Storage (마이크로소프트 저장소)	프로비전된 v2	HDD(표준)	지역(GRS)
Microsoft.Storage (마이크로소프트 저장소)	프로비전된 v2	HDD(표준)	GeoZone(GZRS)
Microsoft.Storage (마이크로소프트 저장소)	프로비전된 v1	SSD(프리미엄)	로컬(LRS)
Microsoft.Storage (마이크로소프트 저장소)	프로비전된 v1	SSD(프리미엄)	영역(ZRS)
Microsoft.Storage (마이크로소프트 저장소)	종량제	HDD(표준)	로컬(LRS)
Microsoft.Storage (마이크로소프트 저장소)	종량제	HDD(표준)	영역(ZRS)
Microsoft.Storage (마이크로소프트 저장소)	종량제	HDD(표준)	지역(GRS)
Microsoft.Storage (마이크로소프트 저장소)	종량제	HDD(표준)	GeoZone(GZRS)

용어 설명

이 문서를 읽기 전에 다음과 같은 스토리지 성능과 관련된 주요 용어를 이해하면 도움이 됩니다.

IOPS(초당 IO 작업 수)

IOPS 또는 초당 입력/출력 작업은 초당 파일 시스템 작업 수를 측정합니다. "IO"라는 용어는 Azure Files 설명서의 "operation" 및 "transaction"이라는 용어와 상호 교환할 수 있습니다.
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입니다.
대기 시간

대기 시간은 지연의 동의어이며 밀리초(밀리초)로 측정됩니다. 엔드투엔드 대기 시간과 서비스 대기 시간의 두 가지 유형이 있습니다. 자세한 내용은 대기 시간을 참조하세요.
큐 깊이

큐 깊이는 스토리지 리소스가 한꺼번에 처리할 수 있는 보류 중인 I/O 요청 수입니다. 자세한 내용은 큐 깊이를 참조하세요.

사용 패턴에 따라 미디어 계층 선택

Azure Files는 성능과 가격의 균형을 맞출 수 있는 두 가지 스토리지 미디어 계층인 SSD와 HDD를 제공합니다. 스토리지 계정 수준에서 파일 공유의 미디어 계층을 선택하고 특정 미디어 계층에서 스토리지 계정을 만든 후에는 새 파일 공유로 수동으로 마이그레이션하지 않고는 다른 계층으로 이동할 수 없습니다.

SSD와 HDD 파일 공유 중에서 선택할 때는 Azure Files에서 실행하려는 예상 사용 패턴의 요구 사항을 이해하는 것이 중요합니다. 많은 양의 IOPS, 빠른 데이터 전송 속도 또는 짧은 대기 시간이 필요한 경우 SSD 파일 공유를 선택해야 합니다.

다음 표에는 SSD와 HDD 파일 공유 간의 예상 성능 목표가 요약되어 있습니다. 자세한 내용은 Azure Files 확장성 및 성능 목표를 참조하세요.

사용 패턴 요구 사항	SSD	HDD
쓰기 대기 시간(10밀리초 미만)	예	예
읽기 대기 시간(10밀리초 미만)	예	예

SSD 파일 공유는 공유 크기에 따라 다음 성능 프로필을 보장하는 프로비저닝 모델을 제공합니다. 자세한 내용은 프로비전된 v1 모델을 참조 하세요.

성능 검사 목록

새 워크로드 또는 기존 워크로드에 대한 성능 요구 사항을 평가하는 경우 사용 패턴을 이해하면 예측 가능한 성능을 달성할 수 있습니다.

대기 시간 민감도: 읽기 대기 시간에 민감하고 최종 사용자에게 높은 가시성을 제공하는 워크로드는 읽기 및 쓰기 작업(< 작은 I/O 크기의 경우 2ms)에 1밀리초 대기 시간을 제공할 수 있는 SSD 파일 공유에 더 적합합니다.
IOPS 및 처리량 요구 사항: SSD 파일 공유는 HDD 파일 공유보다 더 큰 IOPS 및 처리량 제한을 지원합니다. 자세한 내용은 파일 공유 스케일링 대상을 참조하세요.
워크로드 기간 및 빈도: 짧은(분) 및 자주 발생하지 않는(매시간) 워크로드는 자주 발생하는 장기 실행 워크로드에 비해 HDD 파일 공유의 상한 성능 제한을 달성할 가능성이 적습니다. SSD 파일 공유에서 워크로드 기간은 프로비전된 스토리지, IOPS 및 처리량에 따라 사용할 올바른 성능 프로필을 결정할 때 유용합니다. 성능 테스트를 짧게 몇 분 동안 실행하는 실수가 자주 벌어지는데, 이 경우 올바르게 파악할 수 없습니다. 성능을 현실적으로 확인하려면 충분히 높은 빈도와 기간으로 테스트해야 합니다.
워크로드 병렬 처리: 동일한 클라이언트에서 여러 스레드, 프로세스 또는 애플리케이션 인스턴스를 통해 병렬로 작업을 수행하는 워크로드의 경우 SSD 파일 공유는 HDD 파일 공유인 SMB 다중 채널보다 명확한 이점을 제공합니다. 자세한 내용은 SMB Azure 파일 공유 성능 향상을 참조하세요.
API 작업 배포: 많은 수의 파일에 대해 읽기 작업을 수행하는 워크로드와 같은 메타데이터가 많은 워크로드는 SSD 파일 공유에 더 적합합니다. 메타데이터 또는 네임스페이스에 워크로드가 과도함을 참조하세요.

대기 시간

대기 시간을 고려할 때에는 Azure Files에서 대기 시간이 결정되는 방식부터 이해해야 합니다. 가장 일반적인 측정값은 엔드투엔드 대기 시간 및 서비스 대기 시간 메트릭과 연결된 대기 시간입니다. 이러한 트랜잭션 메트릭을 사용하면 애플리케이션 트래픽이 클라이언트를 오가는 데 소요되는 시간을 확인하여 클라이언트 쪽 대기 시간 및/또는 네트워킹 문제를 식별하는 데 도움이 될 수 있습니다.

엔드투엔드 대기 시간(SuccessE2ELatency)은 트랜잭션이 클라이언트에서 네트워크를 지나 Azure Files 서비스로, 그리고 다시 클라이언트로 돌아오는 전체 왕복을 수행하는 데 걸리는 총 시간입니다.
서비스 대기 시간(SuccessServerLatency) 은 트랜잭션이 Azure Files 내에서만 왕복하는 데 걸리는 시간입니다. 클라이언트 또는 네트워크 대기 시간은 여기에 포함되지 않습니다.

SuccessE2ELatency와 SuccessServerLatency 값의 차이는 네트워크와 클라이언트에 의해 발생하는 대기 시간입니다.

클라이언트 대기 시간을 서비스 대기 시간(여기서는 Azure Files 성능)과 혼동하는 경우가 많습니다. 예를 들어 서비스 대기 시간은 짧은 대기 시간을 보고하고 엔드투엔드는 요청에 대한 매우 높은 대기 시간을 보고하는 경우 모든 시간이 Azure Files 서비스가 아닌 클라이언트와 오가는 데 소요된다는 뜻입니다.

또한 다이어그램에서 알 수 있듯이 서비스에서 멀리 떨어져 있을수록 대기 시간 환경이 느려지고 클라우드 서비스에서 성능 확장 제한을 달성하기가 더 어려워집니다. 온-프레미스에서 Azure Files에 액세스할 때 특히 그렇습니다. ExpressRoute와 같은 옵션은 온-프레미스에 적합하지만, 동일한 Azure 지역에서만 실행되는 애플리케이션(컴퓨팅 + 스토리지)의 성능에는 미치지 못합니다.

팁

Azure에서 VM을 사용하여 온-프레미스와 Azure 간의 성능을 테스트하는 것은 Azure에 대한 연결의 네트워킹 기능을 기준으로 하는 효과적이고 실용적인 방법입니다. 크기가 부족하거나 잘못 라우팅된 ExpressRoute 회로 또는 VPN 게이트웨이는 Azure Files에서 실행되는 워크로드의 속도를 크게 저하할 수 있습니다.

큐 깊이

큐 깊이는 스토리지 리소스가 처리할 수 있는 보류 중인 I/O 요청 수입니다. 스토리지 시스템에서 사용하는 디스크는 HDD 스핀들(IDE, SATA, SAS)에서 반도체 디바이스(SSD, NVMe)로 발전함에 따라 더 높은 큐 깊이를 지원하도록 진화했습니다. 큰 데이터 세트 내의 단일 파일과 직렬로 상호 작용하는 단일 클라이언트로 구성된 워크로드는 낮은 큐 깊이의 사례입니다. 반면 여러 스레드 및 여러 파일의 병렬 처리를 지원하는 워크로드는 높은 큐 깊이를 쉽게 달성할 수 있습니다. Azure Files는 수천 개의 Azure 클러스터 노드에 걸쳐 있고 워크로드를 대규모로 실행하도록 설계된 분산 파일 서비스이므로, 높은 큐 깊이로 워크로드를 빌드하고 테스트하는 것이 좋습니다.

클라이언트, 파일 및 스레드와 함께 여러 가지 방법으로 높은 큐 깊이를 달성할 수 있습니다. 워크로드의 큐 깊이를 결정하려면 클라이언트 수와 파일 수와 스레드 수를 곱합니다(클라이언트 수 * 파일 수 * 스레드 수 = 큐 깊이).

아래 표는 높은 큐 깊이를 달성하는 데 사용할 수 있는 다양한 조합을 보여줍니다. 최적의 큐 깊이인 64를 초과해도 되지만 권장하지는 않습니다. 초과해도 성능이 향상되지 않으며, TCP 포화로 인해 대기 시간이 증가할 위험이 있습니다.

클라이언트	파일	스레드	큐 깊이
1	1	1	1
1	1	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밀리초
스레드 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밀리초

다음을 통해 공유

Azure 파일 공유 성능 이해 및 최적화