Azure Files는 스토리지의 두 가지 미디어 계층인 SSD 및 HDD를 지원합니다. 이렇게 하면 시나리오의 성능 및 가격 요구 사항에 맞게 파일 공유를 조정할 수 있습니다.
- SSD(프리미엄): SSD(반도체 드라이브)에서 호스트되는 파일 공유는 대부분의 IO 작업에 대해 한 자리 밀리초 내에 일관된 고성능 및 짧은 대기 시간을 제공합니다.
- HDD(표준): HDD(하드 디스크 드라이브)에서 호스트되는 파일 공유는 범용으로 비용 효율적인 스토리지를 제공합니다.
Azure Files에는 프로비전 및 종량제 옵션을 비롯한 여러 가격 책정 모델이 있습니다.
프로비전된 청구 모델: 프로비전된 청구 모델에서 파일 공유의 기본 비용은 스토리지 양, IOPS(초당 입력 및 출력 작업) 및 파일 공유를 만들거나 업데이트할 때 프로비전하는 처리량을 기반으로 합니다. 실제로 사용하는 양에 관계없이 프로비전한 금액을 기준으로 요금을 지불합니다. Azure Files에는 두 가지 서로 다른 프로비저닝 모델인 프로비전된 v2와 프로비전된 v1이 있습니다.
- 프로비전된 v2: Azure Files용 프로비저닝된 v2 모델에서는 스토리지, IOPS 및 처리량을 별도로 프로비전할 수 있지만 처음 프로비저닝하는 데 도움이 되는 권장 사항을 제공합니다.
- 프로비전된 v1: Azure Files용 프로비전된 v1 모델에서 공유에 필요한 스토리지 양을 프로비전하는 반면, IOPS 및 처리량은 프로비전한 스토리지 양에 따라 결정됩니다. Azure Files에 대해 프로비전된 v1 모델은 SSD 파일 공유에만 사용할 수 있습니다.
종량제 청구 모델: 종량제 모델에서 파일 공유 비용은 사용된 스토리지, 트랜잭션 및 데이터 전송 비용의 형태로 공유를 사용하는 양을 기반으로 합니다. 종량제 모델은 HDD 파일 공유에만 사용할 수 있습니다. 새 HDD 파일 공유 배포에 프로비전된 v2 모델을 사용하는 것이 좋습니다.
이 문서에서는 Azure Files의 청구 모델이 작동하는 방식을 설명하므로 월별 Azure Files 청구서를 더 잘 이해할 수 있습니다. Azure Files 가격 책정 정보는 Azure Files 가격 책정 페이지를 참조하세요.
이 비디오에서는 종량제, 프로비전된 v1 및 프로비전된 v2를 포함하여 다양한 Azure Files 청구 모델 간의 차이점에 대한 포괄적인 개요를 제공합니다.
이 비디오에서는 Azure Files 프로비전된 v2 청구 모델을 자세히 알아보고 총 소유 비용을 줄이기 위한 설정 지침 및 권장 사항을 제공합니다.
적용 대상
관리 모델 | 청구 모델 | 미디어 계층 | 중복 | 중소기업 | NFS (네트워크 파일 시스템) |
---|---|---|---|---|---|
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) |
![]() |
![]() |
스토리지 단위
Azure Files는 KiB, MiB, GiB 및 TiB와 같은 base-2 측정 단위를 사용하여 스토리지 용량을 나타냅니다.
약어 | 정의 | 단위 |
---|---|---|
KiB (키비바이트) | 1,024바이트 | 키비바이트 |
MiB | 1,024KiB(1,048,576바이트) | 메비바이트 |
기가바이트 (GiB) | 1,024MiB(1,073,741,824바이트) | 기비바이트 |
티비 | 1,024GiB(1,099,511,627,776바이트) | 테비바이트 |
기본 2 단위는 일반적으로 대부분의 운영 체제 및 도구에서 스토리지 수량을 측정하는 데 사용됩니다. 그러나 이들은 자주 10진수 단위인 KB, MB, GB, TB로 잘못 표기되는데, 여러분이 더 익숙할 수 있는 단위입니다. Windows와 같은 운영 체제에서 스토리지 단위의 레이블을 잘못 지정하는 일반적인 이유는 많은 운영 체제가 IEC(국제 전기 기술 위원회), BIPM(국제 가중치 측정국) 및 미국 국립 표준 기술 연구소(NIST)에 의해 표준화되기 전에 이러한 약어를 사용하기 시작했기 때문입니다.
다음 표에서는 일반적인 운영 체제가 스토리지를 측정하고 레이블을 지정하는 방법을 보여줍니다.
운영 체제 | 측정 시스템 | 레이블 지정 |
---|---|---|
윈도우즈 | Base-2 | 일관되게 base-10으로 잘못된 레이블을 지정합니다. |
Linux 배포 | 일반적으로 base-2, 일부 소프트웨어는 base-10을 사용함 | 일관되지 않은 레이블 지정, 측정과 레이블 지정 간의 맞춤은 소프트웨어 패키지에 따라 달라집니다. |
macOS, iOS 및 iPad OS | Base-10 | 일관되게 base-10으로 레이블을 지정합니다. |
운영 체제가 목록에 없으면 운영 체제 공급업체에 문의하세요.
파일 공유 총 소유 비용 체크리스트
온프레미스에서 Azure Files로 마이그레이션하거나 Azure Files를 다른 클라우드 스토리지 솔루션과 비교하는 경우 공정하고 균등한 비교를 보장하기 위해 다음 요인을 고려하세요.
스토리지, IOPS 및 대역폭에 대한 요금을 어떻게 지불하나요? 대부분의 클라우드 솔루션에는 가격 결정성 및 단순성과 같은 프로비저닝된 스토리지의 원칙에 부합하는 모델 또는 종 량제 스토리지가 있으며 실제로 사용하는 항목에 대해서만 요금을 청구하여 비용을 최적화할 수 있습니다. 프로비전된 청구 모델은 프로비전된 최소 공유 크기, 프로비전 단위 및 프로비저닝을 늘리거나 줄이는 기능에 따라 다를 수 있습니다.
스토리지 비용을 최적화하는 방법이 있나요? Azure Files 예약을 사용하여 스토리지에서 최대 36% 할인을 받을 수 있습니다. 다른 솔루션은 스토리지 효율성을 선택적으로 최적화하기 위해 중복 제거 또는 압축과 같은 전략을 사용할 수 있습니다. 그러나 이러한 스토리지 최적화 전략에는 성능 저하와 같은 비금전적 비용이 발생하는 경우가 많습니다. Azure Files 예약은 성능에 부작용이 없습니다.
스토리지 복원력과 중복성을 어떻게 실현하나요? Azure Files를 사용하면 스토리지 복원력과 중복성이 제품 제공 사항에 포함됩니다. 모든 계층 및 중복성 수준은 데이터의 고가용성을 보장하며 세 개 이상의 데이터 복사본에 대한 액세스를 제공합니다. 다른 파일 스토리지 옵션을 고려할 때 스토리지 복원력 및 중복성이 기본 제공되는지 또는 직접 어셈블해야 하는지를 고려합니다.
무엇을 관리해야 하나요? Azure Files는 완전히 관리되는 솔루션입니다. 다른 솔루션에는 운영 체제 업데이트 또는 VM, 디스크 및 네트워크 IP 주소와 같은 가상 리소스를 관리해야 할 수 있습니다.
부가 가치 제품의 비용은 얼마인가요? Azure Files는 여러 자사 및 타사 부가가치 서비스와의 통합을 지원합니다. Azure Backup, Azure Files 동기화, 스토리지용 Microsoft Defender와 같은 부가 가치 서비스는 Azure Files에 대한 백업, 복제, 캐싱, 보안 기능을 제공합니다. 온-프레미스든 클라우드든 부가가치 솔루션에는 자체 라이선스 및 제품 비용이 있지만 파일 스토리지에 대한 총 소유 비용의 일부로 간주되는 경우가 많습니다.
설정된 v2 모델
Azure Files용 프로비전된 v2 모델은 총 소유 비용의 예측 가능성을유연성과 쌍으로 연결하여 정확한 스토리지 및 성능 요구 사항을 충족하는 파일 공유를 만들 수 있습니다. 프로비전된 새 v2 파일 공유를 만들 때 파일 공유에 필요한 스토리지, IOPS 및 처리량을 지정합니다. 프로비전하는 각 수량의 양에 따라 총 청구 금액이 결정됩니다.
프로비전하는 스토리지, IOPS 및 처리량은 파일 공유 사용량의 보장된 제한입니다. 예를 들어 2TiB 공유를 프로비전하고 2TiB의 데이터를 공유에 업로드하면 공유가 가득 찼습니다. 공유 크기를 늘리거나 일부 데이터를 삭제하지 않으면 더 많은 데이터를 추가할 수 없습니다. 크레딧 기반 IOPS 버스팅은 크레딧이 유지되는 동안 최상의 노력으로 사용량에 대한 유연성을 제공합니다.
프로비전하는 스토리지, IOPS 및 처리량은 요구 사항이 변경되면 동적으로 확장하거나 축소할 수 있습니다. 그러나 마지막 수량 증가 이후 24시간이 경과한 후에만 프로비전된 수량을 줄일 수 있습니다. 스토리지, IOPS 및 처리량 변경은 프로비저닝 변경 후 몇 분 내에 적용됩니다.
기본적으로 프로비전된 v2 모델을 사용하여 새 파일 공유를 만들 때 IOPS 수와 필요한 처리량에 대한 권장 사항을 제공합니다. 이 값은 지정한 프로비전된 스토리지의 양을 기준으로 계산됩니다. 이러한 권장 사항은 선택한 미디어 계층에 대해 프로비전된 스토리지 양에 대한 일반적인 고객 사용을 기반으로 합니다. 그러나 워크로드에 "일반적인 파일 공유"보다 더 많거나 적은 IOPS 및 처리량이 필요할 수 있습니다. 이 경우 개별 파일 공유 요구 사항에 따라 필요에 따라 더 많거나 적은 IOPS 및 처리량을 프로비전할 수 있습니다.
프로비전된 v2 가용성
프로비전된 v2 모델은 FileStorage 스토리지 계정 종류가 있는 스토리지 계정의 파일 공유에 대해 제공됩니다. 현재 다음 스토리지 계정 SKU를 사용할 수 있습니다.
Storage 계정 종류 | 스토리지 계정 SKU | 사용 가능한 파일 공유 유형 |
---|---|---|
파일 저장소 | StandardV2_LRS | 로컬(LRS) 중복성이 지정된 HDD 프로비전된 v2 파일 공유입니다. |
파일 저장소 | StandardV2_ZRS | 영역(ZRS) 중복성이 지정된 HDD 프로비전된 v2 파일 공유입니다. |
파일 저장소 | StandardV2_GRS | 지역(GRS) 중복성이 지정된 HDD 프로비전된 v2 파일 공유입니다. |
파일 저장소 | StandardV2_GZRS | GeoZone(GZRS) 중복성이 지정된 HDD 프로비전된 v2 파일 공유입니다. |
현재 이러한 SKU는 일반적으로 제한된 지역 하위 집합에서 사용할 수 있습니다.
- 모든 Azure 퍼블릭 클라우드 지역.
- 모든 Azure 미국 정부 클라우드 지역.
프로비전된 v2 프로비전 세부 정보
프로비전된 v2 파일 공유를 만들 때 스토리지, IOPS 및 처리량 측면에서 파일 공유에 대해 프로비전된 용량을 지정합니다. 파일 공유는 다음 특성에 따라 제한됩니다.
항목 | HDD 값 |
---|---|
스토리지 프로비저닝 단위 | 1GiB |
IOPS 프로비저닝 단위 | 1 IO/초 |
처리량 프로비전 단위 | 1MiB/초 |
파일 공유당 최소 프로비전된 스토리지 | 32GiB |
파일 공유당 최소 프로비전된 IOPS | 500 IOPS |
파일 공유당 최소 프로비전된 처리량 | 60MiB/초 |
파일 공유당 최대 프로비전된 스토리지 | 256TiB(262,144GiB) |
파일 공유당 최대 프로비전된 IOPS | 50,000IOPS |
파일 공유당 최대 프로비전된 처리량 | 5,120MiB/초 |
스토리지 계정당 최대 프로비전된 스토리지 | 4PiB(4,194,304GiB) |
스토리지 계정당 최대 프로비전된 IOPS | 50,000IOPS |
스토리지 계정당 최대 프로비전된 처리량 | 5,120MiB/초 |
스토리지 계정당 최대 파일 공유 수 | 파일 공유 50개 |
기본적으로 지정한 프로비저닝된 스토리지에 따라 IOPS 및 처리량 프로비저닝을 권장합니다. 이러한 권장 사항 수식은 Azure Files에서 해당 미디어 계층에 대해 프로비전된 스토리지 양에 대한 일반적인 고객 사용량을 기반으로 합니다.
수식 이름 | HDD 수식 |
---|---|
IOPS 권장 사항 | MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000) |
처리량 권장 사항 | MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120) |
개별 파일 공유 요구 사항에 따라 권장 사항보다 더 많거나 적은 IOPS 또는 처리량이 필요할 수 있습니다. 필요에 따라 원하는 대로 사용자 고유의 값으로 이러한 권장 사항을 재정의할 수 있습니다.
프로비전된 v2 버스팅
크레딧 기반 IOPS 버스팅은 IOPS 사용에 대한 유연성을 제공합니다. 이러한 유연성은 예상치 못한 IO 스파이크에 대한 버퍼로 가장 적합합니다. 설정된 IO 패턴의 경우 IO 피크를 프로비전하는 것이 좋습니다.
파일 공유에 대한 트래픽이 프로비전된(기준) IOPS보다 작을 때마다 버스트 IOPS 크레딧이 누적됩니다. 파일 공유의 IOPS 사용량이 프로비전된 IOPS를 초과하고 사용 가능한 버스트 IOPS 크레딧이 있을 때마다 파일 공유가 최대 허용 버스트 IOPS 제한까지 버스트될 수 있습니다. 누적된 버스트 크레딧 수에 따라 남은 크레딧이 있는 한 파일 공유가 계속 버스트될 수 있습니다. 프로비전된 IOPS 이외의 각 IO는 하나의 크레딧을 사용합니다. 모든 크레딧이 사용되면 공유는 프로비전된 IOPS로 돌아갑니다. 파일 공유에 대한 IOPS는 버스팅을 사용하기 위해 특별한 작업을 수행할 필요가 없습니다. 버스팅은 최선의 활동 기준으로 작동합니다.
공유 크레딧에는 세 가지 상태가 있습니다.
- 파일 공유가 프로비전된 IOPS보다 적게 사용하는 경우 발생합니다.
- 파일 공유가 프로비전된 IOPS 이상 및 버스트 모드에서 사용하는 경우 거부됩니다.
- 상수입니다. 파일 공유가 프로비전된 IOPS를 정확히 사용하고 누적되거나 사용된 크레딧이 없는 경우
새 파일 공유는 버스트 버킷의 전체 크레딧 수로 시작됩니다. 서버의 제한으로 인해 공유 IOPS가 프로비전된 한도 아래로 떨어지면 버스트 크레딧이 발생하지 않습니다. 다음 수식은 파일 공유에 대해 가능한 버스트 IOPS 제한 및 크레딧 수를 결정하는 데 사용됩니다.
항목 | HDD 수식 |
---|---|
버스트 IOPS 제한 | MIN(MAX(3 * ProvisionedIOPS, 5000), 50000) |
버스트 IOPS 크레딧 | (BurstLimit - ProvisionedIOPS) * 3600 |
다음 표에서는 프로비전된 다양한 IOPS 양에 대한 이러한 수식의 몇 가지 예를 보여 줍니다.
프로비전된 IOPS | HDD 버스트 IOPS 제한 | HDD 버스트 크레딧 |
---|---|---|
500 | 최대 5,000개 | 16,200,000 |
1,000 | 최대 5,000개 | 14,400,000 |
3,000 | 최대 9,000 | 21,600,000 |
5,000 | 최대 15,000개 | 36,000,000 |
10000 | 최대 30,000 | 72,000,000 |
25,000 | 최대 50,000개 | 90,000,000 |
50,000 | 최대 50,000개 | 0 |
프로비전된 v2 스냅샷
Azure Files는 Windows 파일 서버의 VSS(볼륨 섀도 복사본)와 유사한 스냅샷을 지원합니다. 공유 스냅샷에 대한 자세한 내용은 Azure Files의 스냅샷 개요를 참조하세요.
스냅샷은 항상 라이브 공유와 서로 다릅니다. 프로비전된 v2 청구 모델에서 모든 스냅샷의 총 차등 크기가 파일 공유의 과도한 프로비전된 스토리지 공간에 맞는 경우 스냅샷 스토리지에 대한 추가 비용은 없습니다. 라이브 공유 데이터의 크기와 차등 스냅샷 데이터의 크기가 공유의 프로비전된 스토리지보다 크면 스냅샷의 초과 사용 용량이 오버플로 스냅샷 사용량 측정기에 대해 청구됩니다. 오버플로 양을 결정하는 수식은 다음과 같습니다. MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)
Azure Files의 일부 부가 가치 서비스는 가치 제안의 일부로 스냅샷을 사용합니다. 자세한 내용은 Azure Files에 대한 부가 가치 서비스를 참조하세요.
프로비전된 v2 일시 삭제
일시 삭제를 사용하도록 설정된 스토리지 계정의 삭제된 파일 공유는 정의된 보존 기간 동안 삭제된 공유의 사용된 스토리지 용량에 따라 청구됩니다. 삭제된 파일 공유가 언제나 복원될 수 있도록 하기 위해, 해당 파일 공유의 프로비전된 스토리지, IOPS 및 처리량은 파일 공유가 완전히 제거될 때까지 스토리지 계정의 한도에 포함됩니다. 그러나 요금이 청구되지 않습니다. 일시 삭제에 대한 자세한 내용은 Azure 파일 공유에서 일시 삭제를 사용하도록 설정하는 방법을 참조 하세요.
설정된 v2 청구 미터
프로비전된 v2 청구 모델을 사용하여 프로비전된 파일 공유는 다음 청구 미터에 대해 청구됩니다.
- 프로비전된 스토리지: GiB에서 프로비전된 스토리지의 양입니다.
- 프로비전된 IOPS: 프로비전된 IOPS(IO/초)의 양입니다.
- 프로비전된 처리량 MiBPS: MiB/초로 프로비전된 처리량입니다.
- 오버플로 스냅샷 사용량: 프로비전된 스토리지 용량에 맞지 않는 GiB의 차등 스냅샷 사용량입니다. 자세한 내용은 프로비전된 v2 스냅샷을 참조하세요.
- 일시 삭제된 사용량: 일시 삭제된 파일 공유에 사용된 GiB의 스토리지 용량. 자세한 내용은 제공된 v2 소프트 삭제를 참조하세요.
프로비저닝된 v2 청구 미터에 대한 소비 단위는 매시간 기록됩니다. 예를 들어 1,024GiB가 프로비전된 공유의 경우 다음이 표시됩니다.
- 개별 시간 동안 프로비전된 스토리지 미터에 대해 1,024단위.
- 하루 동안 집계된 경우 프로비전된 스토리지 미터에 대해 24,576단위.
- 월의 일 수에 따라 한 달 동안 집계되는 경우의 가변 단위 수입니다.
- 28일로 구성된 달(평년 2월): 프로비전된 스토리지 미터에 대한 688,128단위.
- 29일로 구성된 달(윤년 2월): 프로비전된 스토리지 미터에 대한 712,704단위.
- 30일로 구성된 달: 프로비전된 스토리지 미터에 대해 737,280단위.
- 31일로 구성된 달: 프로비전된 스토리지 미터에 대해 761,856단위.
프로비전된 v2 마이그레이션
종량제 모델에서 프로비전된 v2 청구 모델로 SMB Azure 파일 공유를 마이그레이션하는 프로세스는 Azure 파일 동기화를 사용하는지 여부에 따라 다릅니다.
- Azure 파일 동기화 없이 Azure Files를 사용하는 경우 한 SMB Azure 파일 공유에서 다른 SMB Azure 파일 공유로 파일 마이그레이션을 참조하세요.
- Azure 파일 동기화를 사용하는 경우, Azure 파일 동기화를 사용할 때, 한 Azure 파일 공유에서 다른 파일 공유로 파일을 마이그레이션하는 방법을 참조하세요.
프로비전된 v1 모델
프로비저닝된 v1 메서드는 온-프레미스 스토리지 솔루션에서 스토리지를 구매하는 방법과 유사하게 서로 고정된 비율로 스토리지, IOPS 및 처리량을 제공합니다. 프로비전된 새 v1 파일 공유를 만들 때 공유에 필요한 스토리지 양을 지정하고 IOPS 및 처리량이 계산된 값입니다. Azure Files에 대해 프로비전된 v1 모델은 SSD 파일 공유에만 사용할 수 있습니다.
프로비전하는 스토리지의 양에 따라 파일 공유 사용량의 보장된 스토리지, IOPS 및 처리량 제한이 결정됩니다. 예를 들어 2TiB 공유를 프로비전하고 2TiB의 데이터를 공유에 업로드하면 공유가 가득 찼습니다. 공유 크기를 늘리거나 일부 데이터를 삭제하지 않으면 더 많은 데이터를 추가할 수 없습니다. 크레딧 기반 IOPS 버스팅은 크레딧이 유지되는 동안 최상의 노력으로 사용량에 대한 유연성을 제공합니다.
온-프레미스 스토리지 구매와 달리 프로비전된 v1 파일 공유는 요구 사항이 변경되면 동적으로 확장하거나 축소할 수 있습니다. 그러나 마지막 스토리지 증가 이후 24시간이 경과한 후에만 프로비전된 스토리지를 줄일 수 있습니다. 스토리지, IOPS 및 처리량 변경은 프로비저닝 변경 후 몇 분 내에 적용됩니다.
프로비저닝된 공유의 크기를 사용된 GiB 이하로 줄일 수 있습니다. 이렇게 하면 데이터가 손실되지 않지만 사용된 크기에 대한 요금이 계속 청구됩니다. 사용된 크기가 아니라 프로비전된 공유의 성능을 받게 됩니다.
프로비전된 v1 가용성
프로비전된 v1 모델은 FileStorage 스토리지 계정 종류가 있는 스토리지 계정의 SSD 파일 공유에 대해 제공됩니다.
Storage 계정 종류 | 스토리지 계정 SKU | 사용 가능한 파일 공유 유형 |
---|---|---|
파일 저장소 | 프리미엄_LRS | SSD 프로비전된 v1 파일 공유로, 로컬(LRS) 중복성이 지정되어 있습니다. |
파일 저장소 | Premium_ZRS | 영역(ZRS) 중복성이 지정된 SSD 프로비전된 v1 파일 공유입니다. |
프로비전된 v1 모델을 사용하는 SSD 파일 공유는 대부분의 Azure 지역에서 일반적으로 사용할 수 있습니다. 자세한 내용은 지역별 Azure 제품을 참조하세요.
프로비전된 v1 프로비전 세부 정보
프로비전된 v1 파일 공유를 만들 때 공유에 필요한 스토리지 양을 지정합니다. 프로비전하는 각 GiB는 고정 비율로 더 많은 IOPS 및 처리량을 부여합니다. 파일 공유는 다음 특성에 따라 제한됩니다.
항목 | 값 |
---|---|
스토리지 프로비저닝 단위 | 1GiB |
파일 공유당 최소 프로비전된 스토리지 | 100GiB |
파일 공유당 최대 프로비전된 스토리지 | 100TiB(102,400GiB) |
스토리지 계정당 최대 프로비전된 스토리지 | 100TiB(102,400GiB) |
다음 수식은 공유에 프로비전된 IOPS 및 처리량의 양을 결정합니다.
항목 | 수식 |
---|---|
계산 프로비전된(기준) IOPS | MIN(3000 + 1 * ProvisionedStorageGiB, 102400) |
계산된 프로비전된 처리량(MiB/초) | 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
개별 파일 공유 요구 사항에 따라 프로비저닝 수식이 제공하는 것보다 더 많은 IOPS 또는 처리량이 필요할 수 있습니다. 이 경우 필요한 IOPS 또는 처리량을 얻기 위해 더 많은 스토리지를 프로비전해야 합니다.
프로비전된 v1 버스팅
프로비전된 v1 모델은 프로비전의 일부로 무료로 포함된 크레딧 기반 버스팅과 IOPS 및 처리량이 프로비전된 금액을 초과할 때마다 선택적으로 사용량 기반 청구를 지원할 수 있는 고급 기능인 유료 버스팅이라는 두 가지 유형의 버스팅을 지원합니다.
프로비전된 v1 크레딧 기반 버스팅
크레딧 기반 IOPS 버스팅은 IOPS 사용에 대한 유연성을 제공합니다. 이러한 유연성은 예상치 못한 IO 스파이크에 대한 버퍼로 가장 적합합니다. 설정된 IO 패턴의 경우 IO 피크를 프로비전하는 것이 좋습니다.
파일 공유에 대한 트래픽이 프로비전된(기준) IOPS보다 작을 때마다 버스트 IOPS 크레딧이 누적됩니다. 파일 공유의 IOPS 사용량이 프로비전된 IOPS를 초과하고 사용 가능한 버스트 IOPS 크레딧이 있을 때마다 파일 공유가 최대 허용 버스트 IOPS 제한까지 버스트될 수 있습니다. 누적된 버스트 크레딧 수에 따라 남은 크레딧이 있는 한 파일 공유가 계속 버스트될 수 있습니다. 프로비전된 IOPS 이외의 각 IO는 하나의 크레딧을 사용합니다. 모든 크레딧이 사용되면 공유는 프로비전된 IOPS로 돌아갑니다. 파일 공유에 대한 IOPS는 버스팅을 사용하기 위해 특별한 작업을 수행할 필요가 없습니다. 버스팅은 최선의 활동 기준으로 작동합니다.
공유 크레딧에는 세 가지 상태가 있습니다.
- 파일 공유가 프로비전된 IOPS보다 적게 사용하는 경우 발생합니다.
- 파일 공유가 프로비전된 IOPS 이상 및 버스트 모드에서 사용하는 경우 거부됩니다.
- 상수입니다. 파일 공유가 프로비전된 IOPS를 정확히 사용하고 누적되거나 사용된 크레딧이 없는 경우
새 파일 공유는 버스트 버킷의 전체 크레딧 수로 시작됩니다. 서버의 제한으로 인해 공유 IOPS가 프로비전된 한도 아래로 떨어지면 버스트 크레딧이 발생하지 않습니다. 다음 수식은 파일 공유에 대해 가능한 버스트 IOPS 제한 및 크레딧 수를 결정하는 데 사용됩니다.
항목 | 수식 |
---|---|
버스트 한도 | MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400) |
버스트 크레딧 | (BurstLimit - BaselineIOPS) * 3600 |
다음 표에서는 프로비전된 공유 크기에 대한 이러한 수식의 몇 가지 예를 보여 줍니다.
용량(GiB) | 기준 IOPS | 버스트 IOPS | 버스트 크레딧 | 처리량(수신 + 송신)(MiB/초) |
---|---|---|---|---|
100 | 3,100 | 최대 10,000 | 24,840,000 | 110 |
500 | 3,500 | 최대 10,000 | 23,400,000 | 백오십 |
1,024 | 4,024 | 최대 10,000 | 21,513,600 | 203 |
5,120 | 8,120 | 최대 15,360 | 26,064,000 | 613 |
10,240 | 13,240 | 최대 30,720 | 62,928,000 | 1,125 |
33,792 | 36,792 | 최대 102,400 | 227,548,800 | 3,480 |
5만 1천 2백 | 54,200 | 최대 102,400 | 164,880,000 | 5,220 |
102,400 | 102,400 | 최대 102,400 | 0 | 10,340 |
프로비전된 v1 유료 버스트
유료 버스팅은 제한하지 않으려는 고객을 지원하도록 설계된 프로비전된 v1 모델의 고급 기능입니다. 유료 버스팅은 프로비전된 스토리지 위의 모든 IOPS 또는 처리량에 대한 추가 사용량 기반 청구를 추가합니다. 이는 프로비전된 스토리지의 일부로 무료로 포함된 크레딧 기반 버스팅과는 다릅니다. 유료 버스팅은 파일 공유를 프로비전하는 방법에 강력한 유연성을 더할 수 있지만 잘못 사용하면 예기치 않은 청구가 발생할 수도 있습니다.
크레딧 기반 버스팅과 마찬가지로 유료 버스팅은 올바른 양의 IOPS 및 처리량을 프로비전하는 대신 사용할 수 없습니다. 대신, 예기치 않은 수요가 발생할 경우 처리 속도 제한에 대한 추가적인 보호 기능을 제공합니다. 일관된 수준의 IOPS 또는 처리량 사용량이 있는 경우 유료 버스팅에 의존하는 대신 수요를 충당하기 위해 충분한 IOPS 및 처리량(스토리지 프로비저닝을 통해)을 프로비전하는 것이 더 저렴합니다.
유료 버스팅은 기본적으로 사용하지 않도록 설정되지만, 지침에 따라 프로비전된 v1 파일 공유의 비용 및 성능 특성을 변경 하여 사용하도록 설정할 수 있습니다(PowerShell 및 CLI만 해당). 유료 버스팅을 사용하는 경우 Azure Monitor를 통해 사용할 수 있는 다음 메트릭을 사용하여 IOPS 및 처리량 사용량을 신중하게 모니터링하는 것이 좋습니다.
- 파일 공유 프로비저닝되는 IOPS
- 파일 공유 프로비전된 대역폭 MiB/s(처리량)
- 최대 IOPS별 트랜잭션
- 최대 MiB/초(처리량)에 따른 대역폭
- IOPS에 대한 버스트 크레딧(크레딧 기반 버스팅)
- 유료 버스팅 IOS(IO)
- 유료 버스팅 대역폭
프로비전된 v1 스냅샷
Azure Files는 Windows 파일 서버의 VSS(볼륨 섀도 복사본)와 유사한 스냅샷을 지원합니다. 공유 스냅샷에 대한 자세한 내용은 Azure Files의 스냅샷 개요를 참조하세요.
스냅샷은 항상 라이브 공유와 서로 다릅니다. 프로비전된 v1 청구 모델에서 사용되지 않는 프로비전된 스토리지의 양에 관계없이 총 차등 크기는 사용량 측정기에 대해 청구됩니다. 사용된 스냅샷 스토리지 미터는 프로비전된 스토리지 가격보다 가격이 낮습니다.
프로비전된 v1 일시 삭제
일시 삭제를 사용하도록 설정된 스토리지 계정의 삭제된 파일 공유는 정의된 보존 기간 동안 삭제된 공유의 사용된 스토리지 용량에 따라 청구됩니다. 일시 삭제된 사용량 스토리지 용량은 사용된 스냅샷 스토리지 미터에 대해 내보내집니다. 일시 삭제에 대한 자세한 내용은 Azure 파일 공유에서 일시 삭제를 사용하도록 설정하는 방법을 참조 하세요.
프로비전된 v1 청구 미터
v1 청구 모델에 따라 프로비전된 파일 공유는 다음 미터를 기준으로 청구됩니다.
- Premium Provisioned: GiB에서 프로비전된 스토리지의 양입니다.
- 프리미엄 스냅샷: 사용된 스냅샷 및 사용된 일시 삭제된 용량의 양입니다.
프로비전된 v1 청구 미터에 대한 사용량은 매월 단위로 보고됩니다. 예를 들어 1,024GiB가 프로비전된 공유의 경우 다음이 표시됩니다.
- 월의 일 수에 따라 개별 시간의 가변 단위 수입니다.
- 28일로 구성된 달(평년 2월): 프리미엄 프로비전 미터에 대해 1.5238단위.
- 29일로 구성된 달(윤년 2월): 프리미엄 프로비전 미터에 대해 1.4713단위.
- 30일로 구성된 달: 프리미엄 프로비전 미터에 대한 1.4222단위.
- 31일로 구성된 달: 프리미엄 프로비전 미터에 대한 1.3763단위.
- 월의 일 수에 따라 하루 동안 집계되는 경우의 가변 단위 수입니다.
- 28일로 구성된 달(평년 2월): 프리미엄 프로비전 미터에 대해 36.5714단위.
- 29일로 구성된 달(윤년 2월): 프리미엄 프로비전 미터에 대해 35.3103단위.
- 30일로 구성된 달: 프리미엄 프로비전 미터에 대해 34.1333단위.
- 31일로 구성된 달: 프리미엄 프로비전 미터에 대해 33.0323단위.
- 한 달 동안 집계된 경우 프리미엄 프로비전 미터에 대해 계산된 1,024개의 단위입니다.
종량제 모델
종량제 모델에서는 프로비전 금액이 아니라 사용하는 스토리지 양에 대한 요금이 청구됩니다. 상위 수준에서는 저장된 논리적 데이터의 양에 대해 요금을 지불하고 해당 데이터의 사용량을 기준으로 트랜잭션에 대해서도 요금을 청구합니다. 종량제 청구는 최종 사용자 소비에 따라 지불하기 때문에 예산 프로세스의 일부로 계획하기 어려울 수 있습니다. 따라서 새 파일 공유 배포에 프로비전된 v2 모델을 사용하는 것이 좋습니다. 종량제 모델은 HDD 파일 공유에만 사용할 수 있습니다.
종량제 가용성
종량제 모델은 스토리지 계정 종류가 StorageV2 또는 Storage인 스토리지 계정의 HDD 파일 공유에 대해 제공됩니다.
Storage 계정 종류 | 스토리지 계정 SKU | 사용 가능한 파일 공유 유형 |
---|---|---|
StorageV2 또는 Storage | 스탠다드_LRS | 로컬(LRS) 중복성이 지정된 HDD 종량제 파일 공유입니다. |
StorageV2 또는 Storage | Standard_ZRS (표준_ZRS) | 영역(ZRS) 중복성이 지정된 HDD 종량제 파일 공유입니다. |
StorageV2 또는 Storage | 스탠다드_GRS | 지역(GRS) 중복성이 지정된 HDD 종량제 파일 공유입니다. |
StorageV2 또는 Storage | Standard_GZRS | GeoZone(GZRS) 중복성이 지정된 HDD 종량제 파일 공유입니다. |
종량제 모델을 사용하는 HDD 파일 공유는 일반적으로 모든 Azure 지역에서 사용할 수 있습니다.
액세스 계층의 차이점
HDD 파일 공유를 만들 때 트랜잭션 최적화, 핫 및 쿨 액세스 계층 중에서 선택합니다. 세 가지 액세스 계층은 모두 정확히 동일한 스토리지 하드웨어에 저장됩니다. 이러한 세 가지 액세스 계층의 주요 차이점은 쿨 계층에서 낮은 미사용 데이터 스토리지 가격과 쿨 계층에서 더 높은 트랜잭션 가격입니다. 즉,
- 이름에서 알 수 있듯이 트랜잭션 최적화는 높은 IOPS(트랜잭션) 워크로드에 대한 가격을 최적화합니다. 트랜잭션 최적화의 경우 저장 데이터 스토리지 가격이 가장 높지만 트랜잭션 가격은 가장 낮습니다.
- 핫 은 많은 수의 트랜잭션을 포함하지 않는 활성 워크로드용입니다. 미사용 데이터 스토리지 가격은 약간 낮지만 트랜잭션 최적화에 비해 트랜잭션 가격은 약간 높습니다. 이를 트랜잭션 최적화 계층과 쿨 계층의 중간으로 생각하세요.
- 쿨 은 작업량이 높지 않은 워크로드의 가격을 최적화하여 미사용 데이터 저장 가격이 가장 낮지만 트랜잭션 가격이 가장 높습니다.
사용 사례에 적합한 액세스 계층을 선택하면 비용을 상당히 줄일 수 있습니다. 자주 액세스하지 않는 워크로드를 트랜잭션 최적화 전용 접근 계층에 배치하면, 귀하의 리소스에 대한 트랜잭션을 한 달에 몇 번만 수행할 때 거의 비용이 들지 않습니다. 그러나 데이터 스토리지 비용에 대해 높은 금액을 지불합니다. 이 동일한 공유를 쿨 액세스 계층으로 이동한 경우 이 워크로드에 대한 트랜잭션을 자주 수행하지 않으므로 트랜잭션 비용에 대해 거의 아무것도 지불하지 않을 것입니다. 그러나 쿨 액세스 계층은 데이터 스토리지 가격이 저렴합니다.
마찬가지로 액세스가 높은 워크로드를 쿨 액세스 계층에 배치하는 경우 트랜잭션 비용이 훨씬 더 많이 들지만 데이터 스토리지 비용은 더 적게 지불합니다. 이로 인해 트랜잭션 가격 상승으로 인한 비용 증가가 데이터 스토리지 가격 감소로 인한 절감액보다 크고, 트랜잭션 최적화에 대해 지불한 것보다 쿨 비용을 더 많이 지불할 수 있는 상황이 발생할 수 있습니다. 일부 사용량 수준의 경우 핫 액세스 계층이 가장 비용 효율적일 수 있으며 쿨 액세스 계층은 트랜잭션 최적화보다 비용이 더 많이 들 수 있습니다.
워크로드 및 활동 수준은 종량제 파일 공유에 가장 비용 효율적인 액세스 계층을 결정합니다. 실제로 가장 비용 효율적인 액세스 계층을 선택하는 가장 좋은 방법은 공유의 실제 리소스 사용량(저장된 데이터, 쓰기 트랜잭션 등)을 살펴보는 것입니다. 종량제 파일 공유의 경우 Azure Files로 초기 마이그레이션하는 동안 트랜잭션 최적화 계층에서 시작한 다음 마이그레이션이 완료된 후 사용량에 따라 올바른 액세스 계층을 선택하는 것이 좋습니다. 마이그레이션 중 트랜잭션 사용량은 일반적으로 일반적인 트랜잭션 사용량을 나타내지 않습니다.
트랜잭션이란?
SMB를 사용하여 컴퓨터에 Azure 파일 공유를 탑재하면 Azure 파일 공유가 로컬 스토리지인 것처럼 컴퓨터에 노출됩니다. 즉, 컴퓨터에 있는 애플리케이션, 스크립트 및 기타 프로그램이 Azure에 저장되어 있다는 사실을 알 필요 없이 Azure 파일 공유의 파일 및 폴더에 액세스할 수 있습니다.
파일을 읽거나 쓸 때 사용 중인 애플리케이션은 운영 체제에서 제공하는 파일 시스템 API에 대한 일련의 API 호출을 수행합니다. 그러면 운영 체제는 이러한 호출을 SMB 프로토콜 트랜잭션으로 해석하고, 이를 이행하기 위해 Azure Files로 유선으로 전송됩니다. 최종 사용자가 처음부터 끝까지 파일을 읽는 것과 같이 단일 작업으로 인식하는 간단한 작업은 Azure Files에서 제공하는 여러 SMB 트랜잭션으로 변환될 수 있습니다.
원칙적으로 표준 파일에서 사용하는 종량제 청구 모델은 사용량에 따라 청구서를 공유합니다. 애플리케이션 및 스크립트에서 수행한 SMB 및 FileREST 트랜잭션은 파일 공유의 사용을 나타내며 청구서의 일부로 표시됩니다. Azure 파일 동기화 또는 Azure Backup과 같이 공유에 추가할 수 있는 부가 가치 클라우드 서비스에도 동일한 개념이 적용됩니다.
트랜잭션은 Azure 파일 공유에 미치는 영향에 따라 가격이 서로 다른 5가지 트랜잭션 범주로 그룹화됩니다. 이러한 범주는 쓰기, 나열, 읽기, 기타 및 삭제입니다.
다음 표는 각 트랜잭션의 분류를 보여 줍니다.
트랜잭션 버킷 | 관리 작업 | 데이터 작업 |
---|---|---|
트랜잭션 작성 |
|
|
트랜잭션 목록 |
|
|
거래 내역 조회 |
|
|
기타/프로토콜 트랜잭션 |
|
|
삭제 트랜잭션 |
|
|
참고
NFSv4.1은 프로비전된 청구 모델을 사용하는 SSD 파일 공유에만 사용할 수 있습니다. 트랜잭션 버킷은 프로비전된 파일 공유에 대한 청구에 영향을 주지 않습니다.
액세스 계층 간 전환
세 가지 액세스 계층 간에 종량제 파일 공유를 변경할 수 있지만 초기 마이그레이션 후 비용을 최적화하는 가장 좋은 방법은 가장 비용 최적 액세스 계층을 선택하고 액세스 패턴이 변경되지 않는 한 유지되는 것입니다. 표준 파일 공유의 액세스 계층을 변경하면 다음과 같이 추가 비용이 발생하기 때문입니다.
트랜잭션: 더 핫한 액세스 계층에서 쿨 액세스 계층으로 공유를 이동하면 공유의 각 파일에 대해 쿨러 액세스 계층의 쓰기 트랜잭션 요금이 발생합니다. 파일 공유를 쿨러 액세스 계층에서 핫 액세스 계층으로 이동하면 공유의 각 파일에 대해 쿨러 액세스 계층의 읽기 트랜잭션 요금이 발생합니다.
데이터 검색: 쿨 액세스 계층에서 핫 또는 트랜잭션 최적화로 이동하는 경우 이동된 데이터의 크기에 따라 데이터 검색 요금이 발생합니다. 쿨 액세스 계층만 데이터 검색 요금이 부과됩니다.
다음 표에서는 액세스 계층 이동에 대한 비용 분석을 보여 줍니다.
액세스 계층 | 트랜잭션 최적화(대상) | 인기 있는 여행지 | 쿨한 (목적지) |
---|---|---|---|
트랜잭션 최적화(원본) | -- |
|
|
핫(원본) |
|
-- |
|
쿨(원본) |
|
|
-- |
30일 이내에 파일 공유의 액세스 계층을 최대 5회까지 변경할 수 있습니다. 30일 기간의 첫 번째 날은 첫 번째 계층 변경이 발생할 때 시작됩니다. 액세스 계층 간의 변경은 즉시 발생하지만 공유의 액세스 계층을 변경한 후에는 지난 30일 이내에 액세스 계층 속성을 5회 미만으로 변경한 경우에도 24시간 이내에 다시 변경할 수 없습니다.
액세스 계층 선택
기존 데이터를 Azure Files로 마이그레이션하는 방법에 관계없이 처음에는 트랜잭션 최적화 액세스 계층에서 파일 공유를 만드는 것이 좋습니다. 이는 마이그레이션 중에 발생하는 트랜잭션 수가 많기 때문입니다. 마이그레이션이 완료되고 정기적으로 사용하면서 며칠 또는 몇 주 동안 작업한 후에는 트랜잭션 수를 가격 계산기에 연결하여 워크로드에 가장 적합한 액세스 계층을 결정할 수 있습니다.
종량제 파일 공유는 스토리지 계정 수준에서만 트랜잭션 정보를 표시하므로 스토리지 메트릭을 사용하여 파일 공유 수준에서 더 저렴한 액세스 계층을 예측하는 것은 불완전한 과학입니다. 가능하면 청구에 대한 완전한 가시성을 보장하기 위해 각 스토리지 계정에 파일 공유를 하나만 배포하는 것이 좋습니다.
이전 트랜잭션을 보려면 다음을 수행합니다.
- Azure Portal의 스토리지 계정으로 이동합니다.
- 서비스 메뉴의 모니터링에서 메트릭을 선택합니다.
- 범위를 스토리지 계정 이름으로 선택하고 메트릭 네임스페이스를 "파일"로, 메트릭을 "트랜잭션"으로, 집계를 "합계"로 선택합니다.
- 분할 적용을 선택합니다.
- 값을 "API 이름"으로 선택합니다. 원하는 한도 및 정렬을 선택합니다.
- 원하는 기간을 선택합니다.
참고
평균 트랜잭션 수에 대한 현실적인 아이디어를 얻기 위해 충분한 기간 동안 트랜잭션을 볼 수 있는지 확인합니다. 선택한 기간이 초기 프로비전과 겹치지 않는지 확인합니다. 이 기간의 평균 트랜잭션 수를 곱하여 한 달 동안의 예상 트랜잭션을 얻습니다.
종량제 스냅샷
Azure Files는 Windows 파일 서버의 VSS(볼륨 섀도 복사본)와 유사한 스냅샷을 지원합니다. 공유 스냅샷에 대한 자세한 내용은 Azure Files의 스냅샷 개요를 참조하세요.
스냅샷은 항상 라이브 공유와 서로 다릅니다. 종량제 청구 모델에서 총 차등 크기는 일반적으로 사용되는 스토리지 미터에 대해 청구됩니다. 즉, 귀하의 종량제 스토리지 계정과 관련된 스냅샷은 청구서에 별도로 항목으로 표시되지 않습니다. 즉, 종량제 파일 공유에 대해 구매한 예약에 대해 차등 스냅샷 사용량이 계산됩니다.
종량제 일시 삭제
일시 삭제를 사용하도록 설정된 스토리지 계정의 삭제된 파일 공유는 정의된 보존 기간 동안 삭제된 파일 공유의 사용된 스토리지 용량에 따라 청구됩니다. 일시 삭제된 사용된 스토리지 용량은 일반 사용된 스토리지 미터에 대해 내보내집니다. 즉, 종량제 스토리지 계정에 대한 일시 삭제된 파일 공유를 나타내는 별도의 품목이 청구서에 표시되지 않습니다. 즉, 종량제 파일 공유에 대해 구매한 예약에 대해 일시 삭제된 파일 공유 사용량이 계산됩니다.
종량제 청구 미터
종량제 청구 모델을 사용하여 만든 파일 공유는 다음 사용량 계량기에 대해 청구됩니다.
- 데이터 저장소: 라이브 공유, 차등 스냅샷 및 일시 삭제된 파일 공유를 포함한 사용된 스토리지 용량(GiB)입니다.
- 메타데이터: ACL(액세스 제어 목록) 및 GiB의 다른 속성과 같은 파일 및 디렉터리와 연결된 파일 시스템 메타데이터의 크기입니다. 이 청구 미터는 핫 또는 쿨 액세스 계층의 파일 공유에만 사용됩니다.
- 쓰기 작업: 쓰기 트랜잭션 버킷의 수입니다(하나의 버킷 = 10,000개의 트랜잭션).
- 목록 작업: 목록 트랜잭션 버킷의 수입니다(하나의 버킷 = 10,000개의 트랜잭션).
- 읽기 작업: 읽기 트랜잭션 버킷의 수입니다(하나의 버킷 = 10,000개의 트랜잭션).
- 기타 작업 / 프로토콜 작업: 다른 트랜잭션 버킷의 수입니다(하나의 버킷 = 10,000개의 트랜잭션).
- 데이터 검색: GiB의 파일 공유에서 읽은 데이터 양입니다. 이 미터는 쿨 액세스 계층의 파일 공유에만 사용됩니다.
- Geo-복제 데이터 전송: 파일 공유에 Geo 또는 GeoZone 중복성이 있는 경우, 파일 공유에 기록된 데이터의 양이 기가바이트(GiB) 단위로 보조 지역에 복제됩니다.
데이터 저장 및 메타데이터 청구 미터에 대한 소비 단위는 매월 단위로 매시간 내보내집니다. 예를 들어 사용된 GiB가 1,024개인 공유의 경우 다음이 표시됩니다.
- 월의 일 수에 따라 개별 시간의 가변 단위 수입니다.
- 28일로 구성된 달(평년 2월): 저장된 데이터 미터에 대해 1.5238단위.
- 29일로 구성된 달(윤년 2월): 저장된 데이터 미터에 대해 1.4713단위.
- 30일로 구성된 달: 저장된 데이터 미터에 대해 1.4222단위.
- 31일로 구성된 달: 저장된 데이터 미터에 대해 1.3763단위.
- 월의 일 수에 따라 하루 동안 집계되는 경우의 가변 단위 수입니다.
- 28일로 구성된 달(평년 2월): 저장된 데이터 미터에 대해 36.5714단위.
- 29일로 구성된 달(윤년 2월): 저장된 데이터 미터에 대해 35.3103단위.
- 30일로 구성된 달: 저장된 데이터 미터에 대해 34.1333단위.
- 31일로 구성된 달: 저장된 데이터 미터에 대해 33.0323단위.
- 한 달 동안 집계된 경우 데이터 저장 미터에 대한 1,024 단위입니다.
다른 미터에 대한 소비량(예: 쓰기 작업 또는 데이터 검색)은 매시간 내보내지만 시간 범위 측면에서 내보내지 않으므로 알아야 할 특수 단위 변환이 없습니다.
프로비전된/할당량, 논리적 크기 및 물리적 크기
Azure Files는 공유 용량과 관련하여 세 가지 개별 수량을 추적합니다.
프로비저닝된 크기 또는 할당량: 프로비전된 파일 공유와 종량제 파일 공유를 모두 사용하여 파일 공유를 늘릴 수 있는 최대 크기를 지정합니다. 프로비전된 파일 공유에서 이 값을 프로비전된 크기라고 부릅니다. 프로비전하는 금액은 실제로 사용하는 양에 관계없이 지불하는 금액입니다. 종량제 파일 공유에서 이 값을 할당량이라고 하며 청구서에 직접적인 영향을 주지 않습니다. 프로비전된 크기는 프로비전된 파일 공유에 필요한 필드입니다. 종량제 파일 공유의 경우 프로비전된 크기를 직접 지정하지 않으면 공유는 기본적으로 스토리지 계정이 지원하는 최대값(100TiB)으로 설정됩니다.
논리적 크기: 파일 공유 또는 파일의 논리적 크기는 스토리지 최적화 없이 실제로 저장되는 방식을 고려하지 않고 파일 공유 또는 파일의 크기와 관련이 있습니다. 파일의 논리적 크기는 파일을 다른 위치에 복사한 경우 유선을 통해 전송되는 KiB/MiB/GiB 수입니다. 프로비전된 파일 공유와 종량제 파일 공유 모두에서 파일 공유의 총 논리적 크기는 프로비전된 크기/할당량에 대한 적용에 사용됩니다. 종량제 파일 공유에서 논리적 크기는 미사용 데이터 사용량 청구에 사용되는 수량입니다. 논리적 크기는 파일/폴더에 대한 Windows 속성 대화 상자에서 "크기"라고 하며 Azure Files 메트릭에서는 "콘텐츠 길이"라고 합니다.
물리적 크기: 파일의 물리적 크기는 디스크에 인코딩된 파일의 크기와 관련이 있습니다. 물리적 크기는 파일의 논리적 크기에 맞거나 운영 체제에서 파일을 쓴 방법에 따라 더 작을 수 있습니다. 논리적 크기와 물리적 크기가 다른 일반적인 이유는 스파스 파일을 사용하기 때문입니다. 공유에 있는 파일의 실제 크기는 스냅샷 청구에 사용되지만, 할당된 범위는 변경되지 않은 경우 스냅샷 간에 공유됩니다(차등 스토리지).
부가 가치 서비스
많은 온-프레미스 스토리지 솔루션과 마찬가지로 Azure Files는 자사 및 타사 제품이 고객 소유 파일 공유와 통합할 수 있는 통합 지점을 제공합니다. 이러한 솔루션은 Azure Files에 상당한 추가 가치를 제공할 수 있지만 이러한 서비스가 Azure Files 솔루션의 총 비용에 추가하는 부가적인 비용을 고려해야 합니다.
비용은 세 가지 버킷으로 분류됩니다.
부가 가치 서비스에 대한 라이선스 비용. 라이선스 비용은 고객, 최종 사용자("헤드 비용"이라고도 함), Azure 파일 공유 또는 스토리지 계정당 고정 비용 형식으로 제공됩니다. 또한 파일 공유에 있는 데이터의 500GiB 청크마다 고정 비용과 같은 스토리지 사용률 단위를 기반으로 할 수도 있습니다.
부가 가치 서비스에 대한 트랜잭션 비용. 일부 부가 가치 서비스에는 선택한 Azure Files 청구 모델 위에 고유한 트랜잭션 개념이 있습니다. 이러한 트랜잭션은 부가 가치 서비스의 요금에 따라 청구서에 표시됩니다. 그러나 파일 공유와 함께 부가 가치 서비스를 사용하는 방법과 직접 관련이 있습니다.
부가 가치 서비스 사용에 대한 Azure Files 비용. Azure Files는 부가 가치 서비스 추가에 대해 고객에게 직접 비용을 청구하지 않지만, Azure 파일 공유에 가치를 추가하는 과정에서 부가 가치 서비스가 Azure 파일 공유에 표시되는 비용을 증가시킬 수 있습니다. 이러한 비용은 트랜잭션 요금 때문에 종량제 파일 공유로 쉽게 확인할 수 있습니다. 부가 가치 서비스가 사용자 대신 파일 공유에 대해 트랜잭션을 수행하는 경우 직접 트랜잭션을 수행하지 않았더라도 Azure Files 트랜잭션 청구서에 표시됩니다. 이는 눈에 띄지 않을 수 있지만 프로비전된 파일 공유에도 적용됩니다. 부가 가치 서비스의 프로비전된 파일 공유에 대한 트랜잭션은 프로비전된 IOPS 번호에 대해 계산됩니다. 즉, 부가 가치 서비스에서 워크로드에 사용할 수 있는 충분한 IOPS 또는 처리량을 갖도록 더 많은 스토리지를 프로비전해야 할 수 있습니다.
파일 공유에 대한 총 소유 비용을 계산할 때 Azure Files 및 Azure Files와 함께 사용하려는 모든 부가 가치 서비스의 비용을 고려해야 합니다.
부가 가치 서비스에는 여러 가지 자사 및 타사 서비스가 있습니다. 이 문서에서는 고객이 Azure 파일 공유와 함께 사용하는 일반적인 자사 서비스의 하위 집합에 대해 설명합니다. 여기에 나열되지 않은 서비스에 대한 자세한 내용은 해당 서비스의 가격 책정 페이지를 참조하세요.
Azure 파일 동기화
Azure 파일 동기화는 하나 이상의 온-프레미스 Windows 파일 공유를 Azure 파일 공유와 동기화하는 Azure Files용 부가 가치 서비스입니다. 클라우드 Azure 파일 공유에는 온-프레미스에서 사용할 수 있는 동기화된 파일 공유에 있는 데이터의 전체 복사본이 있으므로 온-프레미스 Windows 파일 서버를 Azure 파일 공유의 캐시로 변환하여 온-프레미스 공간을 줄일 수 있습니다. 자세히 알아보려면 Azure 파일 동기화 소개를 읽어보세요.
Azure 파일 동기화를 사용하여 배포된 솔루션의 총 소유 비용을 고려할 때 다음 비용 측면을 고려해야 합니다.
하나 이상의 서버 엔드포인트가 있는 Windows 파일 서버의 자본 및 운영 비용. 복제 솔루션인 Azure 파일 동기화는 Azure Files와 동기화되는 Windows 파일 서버 위치의 제약을 받지 않으며 온-프레미스, Azure VM 또는 다른 클라우드에 호스트할 수 있습니다. Azure VM에 호스트되는 Windows 파일 서버에서 Azure 파일 동기화를 사용하지 않는 한, 자본(즉, 솔루션의 선행 하드웨어 비용) 및 운영(즉, 인건비, 전기 요금 등) 비용은 Azure 청구서에 포함되지 않지만 여전히 총 소유 비용에서 큰 부분을 차지합니다. 온-프레미스에 캐시해야 하는 데이터의 양, Windows 파일 서버에서 Azure 파일 동기화 워크로드를 호스트하는 데 필요한 CPU 수와 메모리 양(자세한 내용은 권장 시스템 리소스 참조) 및 기타 조직별 비용을 고려해야 합니다.
Azure 파일 동기화 등록된 서버의 서버별 라이선스 비용. 특정 Windows 파일 서버에서 Azure 파일 동기화를 사용하려면 먼저 Azure 파일 동기화의 Azure 리소스인 Storage Sync Service에 등록해야 합니다. 첫 번째 서버 이후에 등록하는 각 서버에는 월 단위 정액 요금이 부과됩니다. 이 수수료는 매우 소액이지만 고려할 청구서의 구성 요소 중 하나입니다. 원하는 지역의 현재 서버 등록 요금을 보려면 Azure Files 가격 책정 페이지의 파일 동기화 섹션을 참조하세요.
Azure Files 비용. Azure 파일 동기화는 Azure Files에 사용되는 동기화 솔루션이므로 Azure Files 리소스를 소비하게 됩니다. 스토리지 사용량과 같은 이러한 리소스 중 일부는 비교적 명확하지만, 트랜잭션 및 스냅샷 사용률과 같은 리소스는 그렇지 않을 수 있습니다. 대부분의 고객은 Azure 파일 동기화에서 표준 파일 공유를 사용하는 것이 좋습니다. 원한다면 Azure 파일 동기화가 완전히 지원되는 프리미엄 파일 공유를 사용해도 됩니다.
스토리지 사용률. Azure 파일 동기화는 서버 엔드포인트에 지정된 Windows 파일 서버의 경로 변경 내용을 Azure 파일 공유에 복제하므로 스토리지가 소비됩니다. 표준 파일 공유에서는 변경 내용이 복제되므로 서버 엔드포인트의 기존 파일 크기가 늘어나면 스토리지 비용이 증가합니다. 프리미엄 파일 공유에서는 변경 내용이 프로비저닝된 공간을 사용합니다. 파일 공유 증가를 고려하여 프로비저닝을 주기적으로 확장하는 것은 고객의 몫입니다.
스냅샷 사용률. Azure 파일 동기화는 일반 사용 시 공유 및 파일 수준 스냅샷을 만듭니다. 스냅샷 사용률은 항상 차등적이지만, Azure Files 청구서에서 큰 부분을 차지할 수도 있습니다.
변동의 트랜잭션. 서버 엔드포인트에서 파일이 변경되면 변경 내용이 클라우드 공유에 업로드되고 트랜잭션이 생성됩니다. 클라우드 계층화가 사용하도록 설정되면 송신 비용과 별도로, 계층화된 파일에서 발생하는 I/O를 포함하여 계층화된 파일을 관리하기 위한 추가 트랜잭션이 생성됩니다. 변동률 및 캐시 효율성으로 인해 트랜잭션의 수량과 유형을 예측하기는 어렵지만, 향후 사용량이 현재 사용량과 비슷할 것으로 생각되는 경우 이전 트랜잭션 패턴을 사용하여 향후 비용을 예측할 수 있습니다.
클라우드 열거형의 트랜잭션. Azure 파일 동기화는 서버 엔드포인트에 동기화할 수 있도록 공유에 직접 적용된 변경 내용을 검색하기 위해 하루에 한 번 클라우드의 Azure 파일 공유를 열거합니다. 이 스캔은 디렉터리당 하루 한 개의
ListFiles
트랜잭션으로 저장소 계정에 청구되는 트랜잭션을 생성합니다. 이 숫자를 가격 계산기에 넣어 검색 비용을 예측할 수 있습니다.
팁
보유한 폴더 수를 잘 모르는 경우 JAM Software GmbH의 TreeSize 도구를 검토해 보세요.
Azure 백업
Azure Backup은 파일 공유 및 Azure 파일 동기화와 같은 기타 부가 가치 서비스와 원활하게 통합되는 Azure Files용 서버리스 백업 솔루션을 제공합니다. Azure Files용 Azure Backup은 관리자가 정의한 일정에 따라 자동으로 스냅샷을 생성하기 위한 예약 메커니즘을 제공하는 스냅샷 기반 백업 솔루션입니다. 또한 삭제된 파일/폴더 또는 전체 공유를 특정 시점으로 복원하기 위한 사용자 친화적인 인터페이스도 제공합니다. 자세한 내용은 Azure 파일 공유 백업 정보를 참조하세요.
Azure Backup 사용 비용을 고려할 때 다음 요소를 고려합니다.
Azure 파일 공유 데이터에 대한 보호된 인스턴스 라이선스 비용. Azure Backup은 백업된 Azure 파일 공유를 포함하는 스토리지 계정당 보호된 인스턴스 라이선스 비용을 청구합니다. 보호된 인스턴스는 Azure 파일 공유 스토리지 250GiB로 정의됩니다. 250GiB 미만을 포함하는 스토리지 계정에는 보호된 인스턴스 비용의 일부가 적용됩니다. 자세한 내용은 Microsoft Azure Backup 가격 책정을 참조하세요. Azure Backup이 보호할 수 있는 서비스 목록에서 Azure Files를 선택해야 합니다.
Azure Files 비용. Azure Backup에서는 다음과 같은 방식으로 Azure Files 비용이 증가합니다.
Azure 파일 공유 스냅샷에서 발생하는 차등 비용. Azure Backup은 관리자가 정의한 일정에 따라 Azure 파일 공유 스냅샷 생성을 자동화합니다. 스냅샷은 항상 차등입니다. 그러나 추가된 비용은 스냅샷이 유지되는 기간과 해당 시간 동안 파일 공유의 변동량에 따라 달라집니다. 이러한 요인은 스냅샷이 라이브 파일 공유와 얼마나 다른지, 따라서 Azure Files에서 저장되는 추가 데이터의 양을 결정합니다.
복원 작업으로 인한 트랜잭션 비용. 스냅샷에서 라이브 공유로 작업을 복원하면 트랜잭션 비용이 발생합니다. 표준 파일 공유의 경우 복원에서 스냅샷/쓰기의 읽기는 일반 파일 공유 트랜잭션으로 청구됩니다. 프로비전된 파일 공유의 경우 이러한 작업은 파일 공유에 대해 프로비전된 IOPS에 대해 계산됩니다.
스토리지용 Microsoft Defender
Microsoft Defender는 스토리지용 Microsoft Defender 제품의 일부로 Azure Files를 지원합니다. 스토리지용 Microsoft Defender는 SMB 또는 FileREST를 통해 Azure 파일 공유에 액세스하거나 악용하려는 비정상적이고 잠재적으로 유해한 시도를 감지합니다. 스토리지용 Microsoft Defender는 구독의 스토리지 계정의 모든 파일 공유에 대해 해당 구독 수준에서 사용하도록 설정됩니다.
스토리지용 Microsoft Defender는 Azure 파일 공유에 대한 바이러스 백신 기능을 지원하지 않습니다.
스토리지용 Microsoft Defender의 주요 비용은 제품이 Azure 파일 공유에 대해 수행되는 트랜잭션 위에 부과되는 추가 트랜잭션 비용 집합입니다. 이러한 비용은 Azure Files에서 발생한 트랜잭션을 기반으로 하지만 Azure Files에 대한 청구의 일부가 아니라 Microsoft Defender 가격 책정의 일부입니다. 스토리지용 Microsoft Defender는 Azure Files가 IOPS 프로비저닝의 일부로 트랜잭션을 포함하는 경우에도 프로비전된 파일 공유에서 트랜잭션 요금을 청구합니다. 현재 트랜잭션 속도는 스토리지용 Microsoft Defender 테이블 행 아래의 클라우드용 Microsoft Defender 가격 책정 페이지에서 찾을 수 있습니다.
트랜잭션이 많은 파일 공유는 스토리지용 Microsoft Defender를 사용하여 상당한 비용이 발생합니다. 이러한 비용에 따라 특정 스토리지 계정에 대해 스토리지용 Microsoft Defender를 옵트아웃할 수 있습니다. 자세한 내용은 스토리지용 Microsoft Defender 보호에서 스토리지 계정 제외를 참조하세요.
예약
Azure Files는 프로비전된 v1 및 종량제 모델에 대한 예약(예약 인스턴스라고도 함 )을 지원합니다. 예약을 사용하면 스토리지 사용률을 미리 커밋하여 스토리지에 대한 할인을 달성할 수 있습니다. 프로덕션 워크로드 또는 일관된 공간을 가진 개발/테스트 워크로드에 대한 예약 인스턴스 구매를 고려해야 합니다. 예약을 구매할 때 다음 차원을 지정해야 합니다.
- 용량 크기: 예약은 10TiB 또는 100TiB 중 하나일 수 있으며, 더 높은 용량 예약을 구매하는 경우 더 큰 할인이 제공됩니다. 워크로드 요구 사항에 맞게 다양한 용량 크기의 예약을 포함하여 여러 예약을 구매할 수 있습니다. 예를 들어 프로덕션 배포에 120TiB의 파일 공유가 있는 경우 총 스토리지 용량 요구 사항을 충족하기 위해 100TiB 예약 1개과 10TiB 예약 2개를 구매할 수 있습니다.
- 기간: 1년 또는 3년 기간으로 예약을 구매할 수 있으며, 더 긴 예약 기간을 구매하면 더 큰 할인 혜택을 받을 수 있습니다.
- 계층: 예약에 대한 Azure Files 계층입니다. 예약은 현재 SSD 프로비전된 v1("프리미엄") 및 HDD 종량제(핫 및 쿨 액세스 계층에만 해당) 청구 모델에 사용할 수 있습니다.
- 위치: 예약을 위한 Azure 지역입니다. Azure 지역의 하위 집합에서 예약을 사용할 수 있습니다.
- 중복도: 예약에 대한 스토리지 중복도입니다. 예약은 LRS, ZRS, GRS 및 GZRS를 포함하여 Azure Files가 지원하는 모든 중복에 대해 지원됩니다.
- 대금 청구 주기: 예약에 대한 계정 청구 빈도를 나타냅니다. 옵션에는 월별 또는 선불이 있습니다.
예약을 구매하면 기존 스토리지 사용률이 자동으로 사용됩니다. 예약한 것보다 더 많은 스토리지를 사용하는 경우 예약에서 다루지 않는 잔액에 대해 정가를 지불합니다. 트랜잭션, 대역폭, 데이터 전송, 메타데이터 스토리지 요금은 예약에 포함되지 않습니다.
예약이 종량제 및 프로비전된 v1 파일 공유에 대한 Azure 파일 공유 스냅샷에서 작동하는 방식에는 차이가 있습니다. 종량제 파일 공유의 스냅샷을 생성할 경우 스냅샷 차액은 예약에 대해 계산되며 일반적인 사용된 스토리지 미터의 일부로 청구됩니다. 그러나 프로비전된 v1 파일 공유의 스냅샷을 만드는 경우 스냅샷은 별도의 미터를 사용하여 요금이 청구되며 예약에 계산되지 않습니다.
예약을 구매하는 방법에 대한 자세한 내용은 예약으로 Azure Files에 대한 비용 최적화를 참조하세요.