Azure Files 청구 이해

Azure Files는 프로비저닝과 종량제라는 두 가지 고유한 청구 모델을 제공합니다. 프로비저닝 모델은 FileStorage 스토리지 계정 종류에 배포된 파일 공유인 프리미엄 파일 공유에만 사용할 수 있습니다. 종량제 모델은 범용 버전 2(GPv2) 스토리지 계정 종류에 배포된 파일 공유인 표준 파일 공유에만 사용할 수 있습니다. 이 문서에서는 월간 Azure Files 청구를 이해하는 데 도움이 되도록 두 모델의 작동 방식을 설명합니다.

Azure Files 가격 책정 정보는 Azure Files 가격 책정 페이지를 참조하세요.

스토리지 단위

Azure Files은 2가지 측정 단위를 사용하여 스토리지 용량(KiB, MiB, GiB 및 TiB)을 나타냅니다. 운영 체제는 동일한 측정 단위 또는 계산 시스템을 사용하거나 사용하지 않을 수 있습니다.

Windows

Windows 운영 체제와 Azure Files는 base-2 계산 시스템을 사용하여 스토리지 용량을 측정하지만 단위에 레이블을 지정할 때 차이가 있습니다. Azure Files는 스토리지 용량을 base-2 측정 단위로 레이블링하고 Windows는 스토리지 용량을 base-10 측정 단위로 레이블링합니다. 스토리지 용량을 보고할 때 Windows는 스토리지 용량을 base-2에서 base-10으로 변환하지 않습니다.

머리글자어 정의 단위 Windows는 다음과 같이 표시합니다.
KiB 1,024바이트 키비바이트 KB(킬로바이트)
MiB 1,024KiB(1,048,576바이트) 메비바이트 MB(메가바이트)
GiB 1024MiB(1,073,741,824바이트) 기비바이트 GB(기가바이트)
TiB 1024GiB(1,099,511,627,776바이트) 테비바이트 TB(테라바이트)

macOS

어떤 계산 시스템이 사용되는지 확인하려면 Apple 웹 사이트의 iOS 및 macOS가 스토리지 용량을 보고하는 방법을 참조하세요.

Linux

각 운영 체제 또는 개별 소프트웨어에서 다른 계산 시스템을 사용할 수 있습니다. 스토리지 용량을 보고하는 방법을 확인하려면 해당 설명서를 참조하세요.

프로비저닝된 모델

Azure Files는 프리미엄 파일 공유에 프로비저닝된 모델을 사용합니다. 프로비저닝 비즈니스 모델에서 사용하는 내용에 따라 비용이 청구되는 것이 아니라 Azure Files 서비스에 스토리지 요구 사항을 사전에 지정합니다. 이는 특정 양의 스토리지로 Azure 파일 공유를 프로비저닝할 때, 공간을 사용할 때 온-프레미스의 물리적 미디어의 비용 결제를 시작하지 않는 것처럼 사용 여부에 관계없이 해당 스토리지에 대한 비용을 결제한다는 점에서 온-프레미스 하드웨어 구매와 유사합니다. 온-프레미스에서 물리적 미디어를 구매하는 것과 달리 프로비저닝된 파일 공유는 스토리지 및 IO 성능 특성에 따라 동적으로 확장 또는 축소할 수 있습니다.

프리미엄 파일 공유를 프로비저닝할 때 워크로드에 필요한 GiB 수를 지정합니다. 프로비저닝하는 각 GiB는 고정 비율로 추가 IOPS 및 처리량을 제공합니다. 보장되는 기준 IOPS 외에도 각 프리미엄 파일 공유는 최상의 수준으로 버스팅을 지원합니다. IOPS 및 처리량에 대한 수식은 다음과 같습니다.

  • 기준 IOPS = 400 + 1 * 프로비저닝된 GiB. (최대 100,000 IOPS).
  • 버스트 제한 = 최대(4000, 3 * 기준 IOPS).
  • 송신율 = 60MiB/s + 0.06 * 프로비저닝된 GiB.
  • 수신율 = 40MiB/s + 0.04 * 프로비저닝된 GiB.

프로비저닝된 파일 공유 크기는 언제든지 늘릴 수 있지만 마지막으로 늘린 후 24시간이 지나야 줄일 수 있습니다. 할당량을 늘리지 않고 24시간을 기다린 후 다시 늘릴 때까지 공유 할당량을 원하는 만큼 줄일 수 있습니다. IOPS/처리량 크기 조정은 프로비저닝된 크기 변경 후 몇 분 이내에 적용됩니다.

프로비저닝된 공유의 크기를 사용된 GiB 이하로 줄일 수 있습니다. 이렇게 하면 데이터가 손실되지 않지만 여전히 사용된 크기에 대해 요금이 청구되고 사용된 크기가 아닌 프로비저닝된 공유의 성능(기준 IOPS, 처리량 및 버스트 IOPS)을 받습니다.

다음 표는 프로비저닝된 공유 크기에 대한 이러한 공식의 몇 가지 예를 보여줍니다.

용량(GiB) 기준 IOPS 버스트 IOPS 송신(MiB/s) 수신(MiB/s)
100 500 최대 4,000 66 44
500 900 최대 4,000 90 60
1,024 1,424 최대 4,000 122 81
5,120 5,520 최대 15,360 368 245
10,240 10,640 최대 30,720 675 450
33,792 34,192 최대 100,000 2,088 1,392
51,200 51,600 최대 100,000 3,132 2,088
102,400 100,000 최대 100,000 6,204 4,136

효과적인 파일 공유 성능은 다른 여러 요인 중에서도 머신 네트워크 제한, 사용 가능한 네트워크 대역폭, IO 크기, 병렬 처리의 영향을 받습니다. 예를 들어, 8KiB 읽기/쓰기 IO 크기의 내부 테스트에서 SMB 다중 채널이 활성화되지 않은 단일 Windows 가상 머신, 표준 F16s_v2 , SMB를 통한 프리미엄 파일 공유에 연결된 경우 20K 읽기 IOPS 및 15K 쓰기 IOPS를 달성할 수 있습니다. 512MiB 읽기/쓰기 IO 크기의 경우, 동일한 VM이 1.1GiB/s 송신 및 370MiB/s 수신 처리량을 달성할 수 있습니다. 프리미엄 공유에서 SMB 다중 채널을 사용하는 경우 동일한 클라이언트에서 최대 ~3배의 성능을 달성할 수 있습니다. 최대 성능 확장을 실현하려면 SMB 다중 채널 사용하고 부하를 여러 VM에 분산합니다. 몇 가지 일반적인 성능 문제 및 해결 방법에 대해서는 SMB 다중 채널 성능문제 해결 가이드를 참조하세요.

버스팅

워크로드에 최대 수요를 충족하기 위해 추가 성능이 필요한 경우 공유는 버스트 크레딧을 사용하여 공유 기준 IOPS 제한을 초과하여 수요를 충족하는 데 필요한 공유 성능을 제공할 수 있습니다. 프리미엄 파일 공유는 IOPS를 최대 4,000 또는 최대 3배 중 더 높은 값으로 버스팅할 수 있습니다. 버스팅은 자동화되며 크레딧 시스템을 기반으로 작동합니다. 버스팅은 최상의 수준으로 작동하며 버스트 제한은 보장되지 않으며, 파일 공유는 최대 제한 시간을 60분 까지 버스팅할 수 있습니다.

크레딧은 파일 공유에 대한 트래픽이 기준 IOPS 이하가 될 때마다 버스트 버킷에 누적됩니다. 예를 들어, 100GiB 공유에는 500 기준 IOPS가 있습니다. 공유의 실제 트래픽이 1초 간격으로 100 IOPS인 경우 사용되지 않은 400 IOPS는 버스트 버킷에 크레딧으로 적립됩니다. 마찬가지로 유휴 1TiB 공유는 1,424 IOPS의 버스트 크레딧을 적립합니다. 이러한 크레딧은 나중에 작업이 기준 IOPS를 초과할 때 사용됩니다.

공유가 기준 IOPS를 초과하고 버스트 버킷에 크레딧이 있을 때마다 허용되는 최대 버스트 속도로 버스팅됩니다. 크레딧이 남아있는 한 공유는 최대 60분까지 계속 버스팅할 수 있지만, 이는 적립된 버스트 크레딧 수에 따라 달라집니다. 기준 IOPS를 초과하는 각 IO는 1 크레딧을 사용하고 모든 크레딧을 사용하면 공유는 기준 IOPS로 돌아갑니다.

공유 크레딧에는 세 가지 상태가 있습니다.

  • 파일 공유가 기준 IOPS보다 적게 사용하는 경우 적립됩니다.
  • 파일 공유가 기준 IOPS보다 많이 사용하고 버스트 모드인 경우 감소합니다.
  • 파일 공유가 정확히 기준 IOPS를 사용하는 경우(크레딧이 적립되거나 사용되지 않는 경우) 유지됩니다.

새 파일 공유는 버스트 버킷의 전체 크레딧 수로 시작합니다. 공유 IOPS가 서버의 제한으로 인해 기준 IOPS 이하로 떨어지면 버스트 크레딧이 적립되지 않습니다.

종량제 모델

Azure Files는 표준 파일 공유에 종량제 비즈니스 모델을 사용합니다. 종량제 비즈니스 모델에서 결제 금액은 프로비저닝된 양이 아닌 실제 사용량에 따라 결정됩니다. 사용량이 많은 경우 디스크에 저장된 데이터 양에 대한 비용을 결제한 다음, 해당 데이터의 사용량에 따라 추가 트랜잭션 세트를 결제합니다. 종량제 모델은 향후 성장 또는 성능 요구 사항을 고려하여 과도하게 프로비저닝하거나 데이터 공간 내의 워크로드가 시간에 따라 달라지는 경우 프로비저닝을 해제할 필요가 없기 때문에 비용 효율적일 수 있습니다. 반면, 종량제 모델은 최종 사용자의 사용에 따라 달라지기 때문에 예산 책정 프로세스의 일부로 계획하기가 어려울 수 있습니다.

표준 계층의 차이점

표준 파일 공유를 만들 때 트랜잭션 최적화 계층, 핫 계층 및 쿨 계층 중에서 선택할 수 있습니다. 이 세 계층은 정확히 동일한 표준 스토리지 하드웨어에 저장됩니다. 이러한 세 계층의 주요 차이점은 더 높은 쿨 계층에서 저장 데이터 스토리지 가격이 더 낮고, 트랜잭션 가격이 더 높다는 것입니다. 이는 다음을 의미합니다.

  • 트랜잭션 최적화는 이름에서 암시하듯이 높은 트랜잭션 워크로드에 대한 가격을 최적화합니다. 트랜잭션 최적화의 경우 저장 데이터 스토리지 가격이 가장 높지만 트랜잭션 가격은 가장 낮습니다.
  • 핫은 많은 수의 트랜잭션이 포함되지 않은 활성 워크로드에 적합하며, 저장 데이터 스토리지 가격이 약간 낮지만 트랜잭션 가격은 트랜잭션 최적화에 비해 약간 더 높습니다. 이를 트랜잭션 최적화 계층과 쿨 계층의 중간으로 생각하세요.
  • 쿨은 작업이 많지 않은 워크로드에 대한 가격을 최적화하여 가장 낮은 저장 데이터 스토리지 가격을 제공하지만, 트랜잭션 가격이 가장 높습니다.

트랜잭션 최적화 계층에 자주 액세스하지 않는 워크로드를 배치하는 경우, 한 달에 몇 회 정도 수행하는 공유 트랜잭션에 대해서는 결제 금액이 거의 없지만 데이터 스토리지에는 많은 금액을 결제하게 됩니다. 이 동일한 공유를 쿨 계층으로 이동하는 경우, 이 워크로드에 대해 트랜잭션을 매우 드물게 수행하기 때문에 트랜잭션 비용에 대해 거의 결제하지 않지만 쿨 계층의 데이터 스토리지 가격은 훨씬 저렴합니다. 사용 사례에 적합한 계층을 선택하면 비용을 크게 줄일 수 있습니다. 사용 사례에 적합한 계층을 선택하면 비용을 크게 줄일 수 있습니다.

마찬가지로 쿨 계층에 매우 자주 액세스하는 워크로드를 배치하는 경우, 트랜잭션 비용을 훨씬 더 많이 결제하지만 데이터 스토리지 비용을 줄일 수 있습니다. 이로 인해 트랜잭션 가격 상승으로 인한 비용 증가가 데이터 스토리지 가격 하락으로 인한 비용 절감보다 더 큰 상황이 될 수 있으며, 트랜잭션 최적화보다 더 큰 비용을 쿨에 결제하게 됩니다. 일부 사용량 수준은 핫 계층이 가장 비용 효율적인 계층이 될 수 있지만, 쿨 계층은 트랜잭션 최적화 계층보다 비용이 더 많이 듭니다.

워크로드 및 작업 수준에 따라 표준 파일 공유에 가장 비용 효율적인 계층이 결정됩니다. 실제로 가장 비용 효율적인 계층을 선택하는 가장 좋은 방법은 공유의 실제 리소스 사용량(저장된 데이터, 쓰기 트랜잭션 등)을 확인하는 것입니다.

트랜잭션이란?

트랜잭션은 파일 공유의 콘텐츠를 업로드, 다운로드 또는 조작하기 위해 Azure Files에 대한 작업 또는 요청입니다. 파일 공유에 대해 취한 모든 조치는 하나 이상의 트랜잭션으로 변환되고, 종량제 청구 모델을 사용하는 표준 공유에서 트랜잭션 비용으로 변환됩니다.

기본 트랜잭션 범주에는 쓰기, 목록, 읽기, 기타, 삭제 등 5가지가 있습니다. REST API 또는 SMB를 통해 수행되는 모든 작업은 다음 4가지 범주 중 하나로 버킷됩니다.

작업 유형 쓰기 트랜잭션 나열 트랜잭션 읽기 트랜잭션 기타 트랜잭션 삭제 트랜잭션
관리 작업
  • CreateShare
  • SetFileServiceProperties
  • SetShareMetadata
  • SetShareProperties
  • ListShares
  • GetFileServiceProperties
  • GetShareAcl
  • GetShareMetadata
  • GetShareProperties
  • GetShareStats
  • DeleteShare
데이터 작업
  • CopyFile
  • Create
  • CreateDirectory
  • CreateFile
  • PutRange
  • PutRangeFromURL
  • SetDirectoryMetadata
  • SetFileMetadata
  • SetFileProperties
  • SetInfo
  • SetShareACL
  • Write
  • PutFilePermission
  • ListFileRanges
  • ListFiles
  • ListHandles
  • FilePreflightRequest
  • GetDirectoryMetadata
  • GetDirectoryProperties
  • GetFile
  • GetFileCopyInformation
  • GetFileMetadata
  • GetFileProperties
  • QueryDirectory
  • QueryInfo
  • Read
  • GetFilePermission
  • AbortCopyFile
  • Cancel
  • ChangeNotify
  • Close
  • Echo
  • Ioctl
  • Lock
  • Logoff
  • Negotiate
  • OplockBreak
  • SessionSetup
  • TreeConnect
  • TreeDisconnect
  • CloseHandles
  • AcquireFileLease
  • BreakFileLease
  • ChangeFileLease
  • ReleaseFileLease
  • ClearRange
  • DeleteDirectory
  • DeleteFile

참고

NFS 4.1은 프로비저닝된 청구 모델을 사용하는 프리미엄 파일 공유에만 사용할 수 있으며, 트랜잭션은 프리미엄 파일 공유에 대한 청구에 영향을 주지 않습니다.

참고 항목