Azure Files 청구 모델 이해

Azure Files는 시나리오의 성능 및 가격 요구 사항에 맞게 파일 공유를 조정할 수 있는 두 개의 서로 다른 스토리지 계층인 SSD 및 HDD를 지원합니다.

• SSD(프리미엄): SSD(반도체 드라이브)에서 호스트되는 파일 공유는 대부분의 IO 작업에 대해 한 자리 밀리초 내에 일관된 고성능 및 짧은 대기 시간을 제공합니다.
• HDD(표준): HDD(하드 디스크 드라이브)의 파일 공유 호스트는 범용으로 비용 효율적인 스토리지를 제공합니다.

Azure Files에는 프로비전 및 종량제 옵션을 비롯한 여러 가격 책정 모델이 있습니다.

• 프로비전된 청구 모델: 프로비전된 청구 모델에서 파일 공유의 기본 비용은 사용량에 관계없이 파일 공유를 만들거나 업데이트할 때 프로비전하는 스토리지 양, IOPS(초당 입력 및 출력 작업) 및 처리량을 기반으로 합니다. Azure Files에는 프로비전된 v2 및 프로비전된 v1의 두 가지 프로비전된 모델이 있습니다.

  • 프로비저닝된 v2: 프로비전된 v2 모델에서는 스토리지, IOPS 및 처리량을 별도로 프로비전할 수 있지만 처음 프로비저닝하는 데 도움이 되는 권장 사항을 제공합니다.
  • 프로비저닝된 v1: 프로비전된 v1 모델에서는 공유에 필요한 스토리지 양을 프로비전하고 IOPS 및 처리량은 프로비전한 스토리지 양에 따라 결정됩니다. Azure Files에 대해 프로비전된 v1 모델은 SSD 파일 공유에만 사용할 수 있습니다.

• 종량제 청구 모델: 종량제 모델에서 파일 공유 비용은 사용된 스토리지, 트랜잭션 및 데이터 전송 비용의 형태로 공유를 사용하는 양을 기반으로 합니다. Azure Files의 종량제 모델은 HDD 파일 공유에만 사용할 수 있습니다. 새 HDD 파일 공유 배포에 프로비전된 v2 모델을 사용하는 것이 좋습니다.

이 문서에서는 월간 Azure Files 청구서를 이해하는 데 도움이 되는 Azure Files 작업에 대한 청구 모델을 설명합니다. Azure Files 가격 책정 정보는 Azure Files 가격 책정 페이지를 참조하세요.

적용 대상

관리 모델	청구 모델	미디어 계층	중복	SMB	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	1024MiB(1,073,741,824바이트)	기비바이트
TiB	1024GiB(1,099,511,627,776바이트)	테비바이트

base-2 측정 단위는 스토리지 수량을 측정하기 위해 대부분의 운영 체제 및 도구에서 일반적으로 사용되지만 KB, MB, GB 및 TB와 같이 더 친숙할 수 있는 base-10 단위로 잘못 레이블이 지정되는 경우가 많습니다. 레이블이 잘못된 이유는 다양하지만 Windows와 같은 운영 체제가 스토리지 단위의 레이블을 잘못 지정하는 일반적인 이유는 많은 운영 체제가 IEC(국제 전기 기술 위원회), BIPM(국제 가중치 및 측정국) 및 NIST(미국 국립 표준 기술 연구소)에 의해 표준화되기 전에 이러한 약어를 사용하기 시작했기 때문입니다.

다음 표에서는 일반적인 운영 체제가 스토리지를 측정하고 레이블을 지정하는 방법을 보여줍니다.

운영 체제	측정 시스템	레이블 지정
Windows	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 수와 지정한 프로비전된 스토리지의 양에 따라 필요한 처리량에 대한 권장 사항을 제공합니다. 이러한 권장 사항은 Azure Files의 해당 미디어 계층에 대해 프로비전된 스토리지의 해당 양에 대한 일반적인 고객 사용량을 기반으로 하지만 워크로드에 "일반적인 파일 공유"보다 더 많거나 적은 IOPS 및 처리량이 필요하며, 필요에 따라 개별 파일 공유 요구 사항에 따라 더 많거나 적은 IOPS 및 처리량을 프로비전할 수 있습니다.

프로비전된 v2 가용성

프로비전된 v2 모델은 FileStorage 스토리지 계정 종류가 있는 스토리지 계정의 파일 공유에 대해 제공됩니다. 현재 스토리지 계정 SKU의 다음 하위 집합을 사용할 수 있습니다.

스토리지 계정 종류	스토리지 계정 SKU	사용 가능한 파일 공유 유형
FileStorage	StandardV2_LRS	지정된 LRS(로컬) 중복성을 사용하여 HDD 프로비전된 v2 파일 공유입니다.
FileStorage	StandardV2_ZRS	지정된 ZRS(영역) 중복성을 사용하여 HDD 프로비전된 v2 파일 공유입니다.
FileStorage	StandardV2_GRS	GRS(Geo) 중복성이 지정된 HDD 프로비전된 v2 파일 공유입니다.
FileStorage	StandardV2_GZRS	지정된 GZRS(GeoZone) 중복성을 사용하여 HDD 프로비전된 v2 파일 공유입니다.

현재 이러한 SKU는 일반적으로 제한된 지역 하위 집합에서 사용할 수 있습니다.

• 프랑스 중부
• 프랑스 남부
• 오스트레일리아 동부
• 오스트레일리아 남동부
• 동아시아
• 동남아시아
• 미국 서부 2
• 미국 중서부
• 서유럽
• 북유럽

프로비저닝된 v2 프로비저닝 세부 정보

프로비전된 v2 파일 공유를 만들 때 스토리지, IOPS 및 처리량 측면에서 파일 공유에 대해 프로비전된 용량을 지정합니다. 파일 공유는 다음 특성에 따라 제한됩니다.

Item	HDD 값
스토리지 프로비저닝 단위	1GiB
IOPS 프로비저닝 단위	1 IO/초
처리량 프로비전 단위	1MiB/초
파일 공유당 최소 프로비전된 스토리지	32GiB
파일 공유당 최소 프로비전된 IOPS	500 IOPS
파일 공유당 최소 프로비전된 처리량	60MiB/초
파일 공유당 최대 프로비전된 스토리지	256TiB(262,144GiB)
파일 공유당 최대 프로비전된 IOPS	50,000 IOPS
파일 공유당 최대 프로비전된 처리량	5,120MiB/초
스토리지 계정당 최대 프로비전된 스토리지	4 PiB(4,194,304GiB)
스토리지 계정당 최대 프로비전된 IOPS	50,000 IOPS
스토리지 계정당 최대 프로비전된 처리량	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 제한 및 크레딧 수를 결정하는 데 사용됩니다.

Item	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
10,000	최대 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 청구 모델을 사용하여 프로비전된 파일 공유는 다음 5개의 청구 미터에 대해 청구됩니다.

• 프로비전된 스토리지: GiB에서 프로비전된 스토리지의 양입니다.
• 프로비전된 IOPS: 프로비전된 IOPS(IO/초)의 양입니다.
• 프로비전된 처리량 MiBPS: MiB/초로 프로비전된 처리량입니다.
• 오버플로 스냅샷 사용량: 프로비전된 스토리지 용량에 맞지 않는 GiB의 차등 스냅샷 사용량입니다. 자세한 내용은 프로비전된 v2 스냅샷을 참조하세요.
• 일시 삭제된 사용: 일시 삭제된 파일 공유에 대해 GiB의 스토리지 용량을 사용했습니다. 자세한 내용은 프로비전된 v2 일시 삭제를 참조하세요.

프로비전된 v2 청구 미터에 대한 사용량은 시간 단위 측면에서 매시간 내보내집니다. 예를 들어 1024GiB가 프로비전된 공유의 경우 다음이 표시됩니다.

• 개별 시간 동안 프로비전된 스토리지 미터에 대해 1,024개 단위입니다.
• 하루 동안 집계된 경우 프로비전된 스토리지 미터에 대해 24,576개 단위입니다.
• 월의 일 수에 따라 한 달 동안 집계되는 경우의 가변 단위 수입니다.
  • 28일 월(정상 2월): 프로비저닝된 스토리지 미터에 대한 688,128 단위
  • 29일(윤년 2월): 프로비저닝된 스토리지 미터에 대한 712,704대
  • 30일 월: 프로비전된 스토리지 미터에 대한 737,280 단위
  • 31일 월: 프로비전된 스토리지 미터에 대한 761,856개 단위

프로비전된 v1 모델

프로비저닝된 v1 메서드는 온-프레미스 스토리지 솔루션에서 스토리지를 구매하는 방법과 유사하게 서로에 대한 고정 비율로 스토리지, IOPS 및 처리량을 제공합니다. 프로비전된 새 v1 파일 공유를 만들 때 공유에 필요한 스토리지 양을 지정하고 IOPS 및 처리량이 계산된 값입니다. Azure Files에 대해 프로비전된 v1 모델은 SSD 파일 공유에만 사용할 수 있습니다.

프로비전하는 스토리지의 양에 따라 파일 공유 사용량의 보장된 스토리지, IOPS 및 처리량 제한이 결정됩니다. 예를 들어 2TiB 공유를 프로비전하고 2TiB의 데이터를 공유에 업로드하는 경우 공유가 가득 차서 공유 크기를 늘리거나 일부 데이터를 삭제하지 않으면 더 많은 데이터를 추가할 수 없습니다. 크레딧 기반 IOPS 버스팅은 크레딧이 유지되는 동안 최상의 노력으로 사용량에 대한 유연성을 제공합니다.

온-프레미스 스토리지 구매와 달리 프로비전된 v1 파일 공유는 요구 사항이 변경될 때 동적으로 확장 또는 축소할 수 있지만 마지막 스토리지 증가 이후 24시간이 경과한 후에만 프로비전된 스토리지를 줄일 수 있습니다. 스토리지, IOPS 및 처리량 변경은 프로비저닝 변경 후 몇 분 내에 적용됩니다.

프로비저닝된 공유의 크기를 사용된 GiB 이하로 줄일 수 있습니다. 이렇게 하면 데이터가 손실되지 않지만 사용된 크기에 대해 계속 청구되고 사용된 크기가 아니라 프로비저닝된 공유의 성능을 받습니다.

프로비전된 v1 가용성

프로비전된 v1 모델은 FileStorage 스토리지 계정 종류가 있는 스토리지 계정의 SSD 파일 공유에 대해 제공됩니다.

스토리지 계정 종류	스토리지 계정 SKU	사용 가능한 파일 공유 유형
FileStorage	Premium_LRS	LRS(로컬) 중복성이 지정된 SSD 프로비전된 v1 파일 공유입니다.
FileStorage	Premium_ZRS	ZRS(영역) 중복성이 지정된 SSD 프로비전된 v1 파일 공유입니다.

프로비전된 v1 모델을 사용하는 SSD 파일 공유는 대부분의 Azure 지역에서 일반적으로 사용할 수 있습니다. 자세한 내용은 지역별 Azure 제품을 참조하세요.

프로비전된 v1 프로비전 세부 정보

프로비전된 v1 파일 공유를 만들 때 공유에 필요한 스토리지 양을 지정합니다. 프로비전하는 각 GiB는 고정 비율로 더 많은 IOPS 및 처리량을 부여합니다. 파일 공유는 다음 특성에 따라 제한됩니다.

항목	값
스토리지 프로비저닝 단위	1GiB
파일 공유당 최소 프로비전된 스토리지	100GiB
파일 공유당 최대 프로비전된 스토리지	100TiB(102,400GiB)
스토리지 계정당 최대 프로비전된 스토리지	100TiB(102,400GiB)

공유에 프로비전된 IOPS 및 처리량은 다음 수식에 따라 결정됩니다.

Item	수식
계산 프로비전된(기준) IOPS	MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
계산된 프로비전된 처리량(MiB/초)	100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

개별 파일 공유 요구 사항에 따라 프로비저닝 수식이 제공하는 것보다 더 많은 IOPS 또는 처리량이 필요할 수 있습니다. 이 경우 필요한 IOPS 또는 처리량을 얻으려면 더 많은 스토리지를 프로비전해야 합니다.

프로비전된 v1 버스팅

크레딧 기반 IOPS 버스팅은 IOPS 사용에 대한 유연성을 제공합니다. 이러한 유연성은 예상치 못한 IO 스파이크에 대한 버퍼로 가장 적합합니다. 설정된 IO 패턴의 경우 IO 피크를 프로비전하는 것이 좋습니다.

파일 공유에 대한 트래픽이 프로비전된(기준) IOPS보다 낮을 때마다 버스트 IOPS 크레딧이 누적됩니다. 파일 공유의 IOPS 사용량이 프로비전된 IOPS를 초과하고 사용 가능한 버스트 IOPS 크레딧이 있을 때마다 파일 공유가 최대 허용 버스트 IOPS 제한까지 버스트될 수 있습니다. 남은 크레딧이 있는 한 파일 공유가 계속 버스트될 수 있지만 이는 발생한 버스트 크레딧 수를 기반으로 합니다. 프로비전된 IOPS 이외의 각 IO는 하나의 크레딧을 사용합니다. 모든 크레딧이 사용되면 공유는 프로비전된 IOPS로 돌아갑니다. 파일 공유에 대한 IOPS는 버스팅을 사용하기 위해 특별한 작업을 수행할 필요가 없습니다. 버스팅은 최상의 노력으로 작동합니다.

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

• 파일 공유가 프로비전된 IOPS보다 적게 사용하는 경우 발생합니다.
• 파일 공유가 프로비전된 IOPS 이상 및 버스트 모드에서 사용하는 경우 거부됩니다.
• 상수입니다. 파일 공유가 프로비전된 IOPS를 정확히 사용하고 누적되거나 사용된 크레딧이 없는 경우

새 파일 공유는 버스트 버킷의 전체 크레딧 수로 시작됩니다. 서버의 제한으로 인해 공유 IOPS가 프로비전된 한도 아래로 떨어지면 버스트 크레딧이 발생하지 않습니다. 다음 수식은 파일 공유에 대해 가능한 버스트 IOPS 제한 및 크레딧 수를 결정하는 데 사용됩니다.

Item	수식
버스트 한도	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	150
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
51,200	54,200	최대 102,400	164,880,000	5,220
102,400	102,400	최대 102,400	0	10,340

효과적인 파일 공유 성능은 다른 여러 요인 중에서도 컴퓨터 네트워크 제한, 사용 가능한 네트워크 대역폭, IO 크기, 병렬 처리의 영향을 받습니다. 병렬 처리의 최대 이점을 얻으려면 SSD 파일 공유에서 SMB 다중 채널을 사용하도록 설정하는 것이 좋습니다. 일반적인 성능 문제와 해결 방법은 SMB 성능 및 성능 문제 해결 가이드를 참조하세요.

프로비전된 v1 스냅샷

Azure Files는 Windows 파일 서버의 VSS(볼륨 섀도 복사본)와 유사한 스냅샷을 지원합니다. 공유 스냅샷에 대한 자세한 내용은 Azure Files의 스냅샷 개요를 참조하세요.

스냅샷은 항상 라이브 공유와 서로 다릅니다. 프로비전된 v1 청구 모델에서 사용되지 않는 프로비전된 스토리지의 양에 관계없이 총 차등 크기는 사용량 측정기에 대해 청구됩니다. 사용된 스냅샷 스토리지 미터는 프로비전된 스토리지 가격보다 가격이 낮습니다.

프로비전된 v1 일시 삭제

일시 삭제를 사용하도록 설정된 스토리지 계정의 삭제된 파일 공유는 일시 삭제 기간 동안 삭제된 공유의 사용된 스토리지 용량에 따라 요금이 청구됩니다. 일시 삭제된 사용량 스토리지 용량은 사용된 스냅샷 스토리지 미터에 대해 내보내집니다. 일시 삭제에 대한 자세한 내용은 Azure 파일 공유에서 일시 삭제를 사용하도록 설정하는 방법을 참조 하세요.

프로비전된 v1 청구 미터

프로비전된 v1 청구 모델을 사용하여 프로비전된 파일 공유는 다음 두 미터에 대해 청구됩니다.

• Premium Provisioned: GiB에서 프로비전된 스토리지의 양입니다.
• 프리미엄 스냅샷: 사용된 스냅샷 및 사용된 일시 삭제된 용량의 양입니다.

프로비전된 v1 청구 미터에 대한 사용량은 매월 단위로 매시간 내보내집니다. 예를 들어 1024GiB가 프로비전된 공유의 경우 다음이 표시됩니다.

• 월의 일 수에 따라 개별 시간의 가변 단위 수입니다.
  • 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 단위.
• 한 달 동안 집계된 경우 프리미엄 프로비전된 미터에 대한 1024 단위입니다.

종량제 모델

종량제 모델에서 지불하는 금액은 프로비전된 금액을 기반으로 하는 것이 아니라 사용하는 양에 따라 결정됩니다. 상위 수준에서는 저장된 논리적 데이터의 양에 대해 요금을 지불하고 해당 데이터의 사용량을 기준으로 트랜잭션에 대해서도 요금을 청구합니다. 종량제 청구 모델은 최종 사용자 소비에 의해 구동되기 때문에 예산 프로세스의 일부로 계획하기 어려울 수 있습니다. 따라서 새 파일 공유 배포에 프로비전된 v2 모델을 사용하는 것이 좋습니다. 종량제 모델은 HDD 파일 공유에만 사용할 수 있습니다.

종량제 가용성

종량제 모델은 StorageV2 또는 Storage 스토리지 계정 종류가 있는 스토리지 계정의 HDD 파일 공유에 대해 제공됩니다.

스토리지 계정 종류	스토리지 계정 SKU	사용 가능한 파일 공유 유형
StorageV2 또는 Storage	Standard_LRS	LRS(로컬) 중복성이 지정된 HDD 종량제 파일 공유입니다.
StorageV2 또는 Storage	Standard_ZRS	지정된 ZRS(영역) 중복성을 사용하는 HDD 종량제 파일 공유입니다.
StorageV2 또는 Storage	Standard_GRS	GRS(Geo) 중복성이 지정된 HDD 종량제 파일 공유입니다.
StorageV2 또는 Storage	Standard_GZRS	GZRS(GeoZone) 중복성이 지정된 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가지 트랜잭션 범주로 그룹화됩니다. 이러한 범주는 쓰기, 나열, 읽기, 기타 및 삭제입니다.

다음 표는 각 트랜잭션의 분류를 보여 줍니다.

트랜잭션 버킷	관리 작업	데이터 작업
쓰기 트랜잭션	CreateShare SetFileServiceProperties SetShareMetadata SetShareProperties SetShareAcl SnapshotShare RestoreShare	CopyFile Create CreateDirectory CreateFile PutRange PutRangeFromURL SetDirectoryMetadata SetFileMetadata SetFileProperties SetInfo Write PutFilePermission Flush SetDirectoryProperties
나열 트랜잭션	ListShares	ListFileRanges ListFiles ListHandles
읽기 트랜잭션	GetFileServiceProperties GetShareAcl GetShareMetadata GetShareProperties GetShareStats	FilePreflightRequest GetDirectoryMetadata GetDirectoryProperties GetFile GetFileCopyInformation GetFileMetadata GetFileProperties QueryDirectory QueryInfo Read GetFilePermission
기타/프로토콜 트랜잭션	AcquireShareLease BreakShareLease ReleaseShareLease RenewShareLease ChangeShareLease	AbortCopyFile Cancel ChangeNotify Close Echo Ioctl Lock Logoff Negotiate OplockBreak SessionSetup TreeConnect TreeDisconnect CloseHandles AcquireFileLease BreakFileLease ChangeFileLease ReleaseFileLease
삭제 트랜잭션	DeleteShare	ClearRange DeleteDirectory DeleteFile

참고 항목

NFS 4.1은 프로비전된 청구 모델을 사용하는 SSD 파일 공유에만 사용할 수 있습니다. 트랜잭션 버킷은 프로비전된 파일 공유에 대한 청구에 영향을 주지 않습니다.

액세스 계층 간 전환

세 가지 액세스 계층 간에 종량제 파일 공유를 변경할 수 있지만 초기 마이그레이션 후 비용을 최적화하는 가장 좋은 방법은 가장 비용 최적 액세스 계층을 선택하고 액세스 패턴이 변경되지 않는 한 유지되는 것입니다. 표준 파일 공유의 액세스 계층을 변경하면 다음과 같은 추가 비용이 발생하기 때문입니다.

• 트랜잭션: 더 핫한 액세스 계층에서 쿨 액세스 계층으로 공유를 이동하면 공유의 각 파일에 대해 쿨러 액세스 계층의 쓰기 트랜잭션 요금이 발생합니다. 파일 공유를 쿨러 액세스 계층에서 핫 액세스 계층으로 이동하면 공유의 각 파일에 대해 쿨러 액세스 계층의 읽기 트랜잭션 요금이 발생합니다.

• 데이터 검색: 쿨 액세스 계층에서 핫 또는 트랜잭션 최적화로 이동하는 경우 이동된 데이터의 크기에 따라 데이터 검색 요금이 발생합니다. 쿨 액세스 계층만 데이터 검색 요금이 부과됩니다.

다음 표에서는 액세스 계층 이동에 대한 비용 분석을 보여 줍니다.

액세스 계층	트랜잭션 최적화(대상)	핫(대상)	쿨(대상)
트랜잭션 최적화(원본)	--	파일당 1개의 핫 쓰기 트랜잭션.	파일당 1개의 쿨 쓰기 트랜잭션.
핫(원본)	파일당 1개의 핫 읽기 트랜잭션.	--	파일당 1개의 쿨 쓰기 트랜잭션.
쿨(원본)	파일당 1개의 쿨 읽기 트랜잭션. 사용된 총 GiB당 데이터 검색.	파일당 1개의 쿨 읽기 트랜잭션. 사용된 총 GiB당 데이터 검색.	--

파일 공유의 액세스 계층을 변경할 수 있는 빈도에 대한 공식적인 제한은 없지만 공유의 데이터 양에 따라 공유를 전환하는 데 시간이 소요됩니다. 파일 공유가 액세스 계층 간에 전환되는 동안에는 공유의 액세스 계층을 변경할 수 없습니다. 파일 공유의 액세스 계층을 변경해도 일반 파일 공유 액세스에는 영향을 주지 않습니다.

액세스 계층 선택

기존 데이터를 Azure Files로 마이그레이션하는 방법에 관계없이 마이그레이션 중에 발생하는 트랜잭션 수가 많기 때문에 처음에는 트랜잭션 최적화 액세스 계층에서 파일 공유를 만드는 것이 좋습니다. 마이그레이션이 완료되고 몇 일 또는 몇 주 동안 정기적으로 사용한 후에는 트랜잭션 수를 가격 계산기에 연결하여 워크로드에 가장 적합한 액세스 계층을 파악할 수 있습니다.

종량제 파일 공유는 스토리지 계정 수준에서만 트랜잭션 정보를 표시하므로 스토리지 메트릭을 사용하여 파일 공유 수준에서 더 저렴한 액세스 계층을 예측하는 것은 불완전한 과학입니다. 가능하면 청구에 대한 완전한 가시성을 보장하기 위해 각 스토리지 계정에 파일 공유를 하나만 배포하는 것이 좋습니다.

이전 트랜잭션을 보려면 다음을 수행합니다.

1. Azure Portal의 스토리지 계정으로 이동합니다.
2. 서비스 메뉴의 모니터링에서 메트릭을 선택합니다.
3. 범위를 스토리지 계정 이름으로 선택하고 메트릭 네임스페이스를 "파일"로, 메트릭을 "트랜잭션"으로, 집계를 "합계"로 선택합니다.
4. 분할 적용을 선택합니다.
5. 값을 "API 이름"으로 선택합니다. 원하는 한도 및 정렬을 선택합니다.
6. 원하는 기간을 선택합니다.

참고 항목

평균 트랜잭션 수를 더 잘 알기 위해 특정 기간의 트랜잭션을 볼 수 있는지 확인합니다. 선택한 기간이 초기 프로비전과 겹치지 않는지 확인합니다. 이 기간의 평균 트랜잭션 수를 곱하여 한 달 동안의 예상 트랜잭션을 얻습니다.

종량제 스냅샷

Azure Files는 Windows 파일 서버의 VSS(볼륨 섀도 복사본)와 유사한 스냅샷을 지원합니다. 공유 스냅샷에 대한 자세한 내용은 Azure Files의 스냅샷 개요를 참조하세요.

스냅샷은 항상 라이브 공유와 서로 다릅니다. 종량제 청구 모델에서 총 차등 크기는 일반적으로 사용되는 스토리지 미터에 대해 청구됩니다. 즉, 종량제 스토리지 계정에 대한 스냅샷을 나타내는 별도의 품목이 청구서에 표시되지 않습니다. 즉, 종량제 파일 공유에 대해 구매한 예약에 대해 차등 스냅샷 사용량이 계산됩니다.

종량제 일시 삭제

일시 삭제를 사용하도록 설정된 스토리지 계정의 삭제된 파일 공유는 일시 삭제 기간 동안 삭제된 파일 공유의 사용된 스토리지 용량에 따라 요금이 청구됩니다. 일시 삭제된 사용된 스토리지 용량은 일반 사용된 스토리지 미터에 대해 내보내집니다. 즉, 종량제 스토리지 계정에 대한 일시 삭제된 파일 공유를 나타내는 별도의 품목이 청구서에 표시되지 않습니다. 즉, 일시 삭제된 파일 공유 사용량은 종량제 파일 공유를 위해 구매한 예약에 대해 계산됩니다.

종량제 청구 미터

종량제 청구 모델을 사용하여 만든 파일 공유는 다음 미터에 대해 청구됩니다.

• 저장된 데이터: 라이브 공유, 차등 스냅샷 및 일시 삭제된 파일 공유를 포함한 사용된 스토리지(GiB)입니다.
• 메타데이터: ACL(액세스 제어 목록) 및 GiB의 다른 속성과 같은 파일 및 디렉터리와 연결된 파일 시스템 메타데이터의 크기입니다. 이 청구 미터는 핫 또는 쿨 액세스 계층의 파일 공유에만 사용됩니다.
• 쓰기 작업: 쓰기 트랜잭션 버킷의 수입니다(버킷 1개 = 트랜잭션 10,000개).
• 목록 작업: 목록 트랜잭션 버킷의 수입니다(버킷 1개 = 트랜잭션 10,000개).
• 읽기 작업: 읽기 트랜잭션 버킷의 수입니다(버킷 1개 = 트랜잭션 10,000개).
• 기타 작업 / 프로토콜 작업: 다른 트랜잭션 버킷의 수입니다(버킷 1개 = 트랜잭션 10,000개).
• 데이터 검색: GiB의 파일 공유에서 읽은 데이터 양입니다. 이 미터는 쿨 액세스 계층의 파일 공유에만 사용됩니다.
• 지역에서 복제 데이터 전송: 파일 공유에 Geo 또는 GeoZone 중복성이 있는 경우 파일 공유에 기록된 데이터의 양이 GiB의 보조 지역에 복제됩니다.

데이터 저장 및 메타데이터 청구 미터에 대한 사용량은 매월 단위로 매시간 내보내집니다. 예를 들어 사용된 GiB가 1024인 공유의 경우 다음이 표시됩니다.

• 월의 일 수에 따라 개별 시간의 가변 단위 수입니다.
  • 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 단위
• 한 달 동안 집계된 경우 데이터 저장 미터에 대한 1024 단위입니다.

다른 미터에 대한 소비량(예: 쓰기 작업 또는 데이터 검색)은 매시간 내보내지만 시간 범위 측면에서 내보내지 않으므로 알아야 할 특수 단위 변환이 없습니다.

프로비전된/할당량, 논리적 크기 및 물리적 크기

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 Backup

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), 핫(HDD) 및 쿨(HDD) 계층에 사용할 수 있습니다.
• 위치: 예약을 위한 Azure 지역입니다. Azure 지역의 하위 집합에서 예약을 사용할 수 있습니다.
• 중복도: 예약에 대한 스토리지 중복도입니다. 예약은 LRS, ZRS, GRS 및 GZRS를 포함하여 Azure Files가 지원하는 모든 중복에 대해 지원됩니다.
• 대금 청구 주기: 예약에 대한 계정 청구 빈도를 나타냅니다. 옵션에는 월별 또는 선불이 있습니다.

예약을 구매하면 기존 스토리지 사용률에 의해 자동으로 소비됩니다. 예약한 것보다 더 많은 스토리지를 사용하는 경우 예약에 포함되지 않는 잔액에 대해서는 정가를 지불하게 됩니다. 트랜잭션, 대역폭, 데이터 전송, 메타데이터 스토리지 요금은 예약에 포함되지 않습니다.

종량제 및 프로비전된 v1 파일 공유에 대해 예약이 Azure 파일 공유 스냅샷과 작동하는 방식에는 차이가 있습니다. 종량제 파일 공유의 스냅샷을 사용하는 경우 스냅샷 차등은 예약에 대해 계산되며 일반적인 사용된 스토리지 미터의 일부로 청구됩니다. 그러나 프로비전된 v1 파일 공유의 스냅샷을 만드는 경우 스냅샷은 별도의 미터를 사용하여 요금이 청구되며 예약에 계산되지 않습니다.

예약을 구매하는 방법에 대한 자세한 내용은 예약으로 Azure Files에 대한 비용 최적화를 참조하세요.

참고 항목

• Azure Files 가격 책정.
• Azure Files 배포 계획 및 Azure 파일 동기화 배포 계획
• 파일 공유 만들기 및 Azure 파일 동기화 배포