Azure Files 청구 이해
Azure Files는 프로비저닝과 종량제라는 두 가지 고유한 청구 모델을 제공합니다. 프로비저닝 모델은 FileStorage 스토리지 계정 종류에 배포된 파일 공유인 프리미엄 파일 공유에만 사용할 수 있습니다. 종량제 모델은 범용 버전 2(GPv2) 스토리지 계정 종류에 배포된 파일 공유인 표준 파일 공유에만 사용할 수 있습니다. 이 문서에서는 두 모델이 어떻게 작동하여 월별 Azure Files 청구서를 이해하는 데 도움이 되는지 설명합니다.
이 비디오는 Azure Files 청구 모델의 기본 사항에 대해 설명하는 인터뷰입니다. Azure Files 공유 비용을 최적화하는 방법과 Azure Files를 온-프레미스 및 클라우드의 다른 파일 스토리지 제공 사항과 비교하는 방법을 다룹니다.
Azure Files 가격 책정 정보는 Azure Files 가격 책정 페이지를 참조하세요.
적용 대상
| 파일 공유 유형 | SMB | NFS |
|---|---|---|
| 표준 파일 공유(GPv2), LRS/ZRS |  |
 |
| 표준 파일 공유(GPv2), GRS/GZRS | |
|
| 프리미엄 파일 공유(FileStorage), LRS/ZRS | |
|
스토리지 단위
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에서 사용하는 청구 모델은 프리미엄 또는 표준 파일 공유를 배포하는지에 따라 달라집니다. 대부분의 클라우드 솔루션에는 가격 결정성 및 단순성과 같은 프로비저닝된 스토리지 또는 실제로 사용한 만큼만 비용을 청구하여 비용을 최적화할 수 있는 종량제 스토리지의 원칙과 일치하는 모델이 있습니다. 프로비전된 모델의 경우 최소 프로비전된 공유 크기, 프로비전 단위 및 프로비전을 늘리고 줄이는 기능이 특히 중요합니다.
스토리지 비용을 최적화하는 방법이 있나요? Azure Files 예약을 사용하여 스토리지에서 최대 36% 할인을 받을 수 있습니다. 다른 솔루션은 스토리지 효율성을 선택적으로 최적화하기 위해 중복 제거 또는 압축과 같은 전략을 사용할 수 있습니다. 그러나 이러한 스토리지 최적화 전략에는 성능 저하와 같은 비금전적 비용이 발생하는 경우가 많습니다. Azure Files 예약은 성능에 부작용이 없습니다.
스토리지 복원력과 중복성을 어떻게 실현하나요? Azure Files를 사용하면 스토리지 복원력과 중복성이 제품 제공 사항에 포함됩니다. 모든 계층 및 중복성 수준은 데이터의 고가용성을 보장하며 세 개 이상의 데이터 복사본에 대한 액세스를 제공합니다. 다른 파일 스토리지 옵션을 고려할 때 스토리지 복원력 및 중복성이 기본 제공되는지 아니면 직접 어셈블해야 하는지를 고려합니다.
무엇을 관리해야 하나요? Azure Files에서 기본 관리 단위는 스토리지 계정입니다. 다른 솔루션에는 운영 체제 업데이트 또는 VM, 디스크, 네트워크 IP 주소 등의 가상 리소스 관리와 같은 추가 관리가 필요할 수 있습니다.
부가 가치 제품의 비용은 얼마인가요? Azure Files는 여러 자사 및 타사 부가가치 서비스와의 통합을 지원합니다. Azure Backup, Azure Files 동기화, 스토리지용 Microsoft Defender와 같은 부가 가치 서비스는 Azure Files에 대한 백업, 복제, 캐싱, 보안 기능을 제공합니다. 온-프레미스든 클라우드든 부가가치 솔루션에는 자체 라이선스 및 제품 비용이 있지만 파일 스토리지에 대한 총 소유 비용의 일부로 간주되는 경우가 많습니다.
예약
Azure Files는 예약(예약 인스턴스라고도 함)을 지원하여 스토리지 사용률에 미리 커밋하여 스토리지 할인을 받을 수 있습니다. 프로덕션 워크로드 또는 일관된 공간을 가진 개발/테스트 워크로드에 대한 예약 인스턴스 구매를 고려해야 합니다. 예약을 구매할 때 다음 차원을 지정해야 합니다.
- 용량 크기: 예약은 10TiB 또는 100TiB 중 하나일 수 있으며, 더 높은 용량 예약을 구매하는 경우 더 큰 할인이 제공됩니다. 워크로드 요구 사항에 맞게 다양한 용량 크기의 예약을 포함하여 여러 예약을 구매할 수 있습니다. 예를 들어 프로덕션 배포에 120TiB의 파일 공유가 있는 경우 총 스토리지 용량 요구 사항을 충족하기 위해 100TiB 예약 1개과 10TiB 예약 2개를 구매할 수 있습니다.
- 기간: 1년 또는 3년 기간으로 예약을 구매할 수 있으며, 더 긴 예약 기간을 구매하면 더 큰 할인 혜택을 받을 수 있습니다.
- 계층: 예약에 대한 Azure Files 계층입니다. 예약은 현재 프리미엄, 핫, 쿨 계층에서 사용할 수 있습니다.
- 위치: 예약을 위한 Azure 지역입니다. Azure 지역의 하위 집합에서 예약을 사용할 수 있습니다.
- 중복도: 예약에 대한 스토리지 중복도입니다. 예약은 LRS, ZRS, GRS 및 GZRS를 포함하여 Azure Files가 지원하는 모든 중복에 대해 지원됩니다.
- 대금 청구 주기: 예약에 대한 계정 청구 빈도를 나타냅니다. 옵션에는 월별 또는 선불이 있습니다.
예약을 구매하면 기존 스토리지 사용률에 의해 자동으로 소비됩니다. 예약한 것보다 더 많은 스토리지를 사용하는 경우 예약에 포함되지 않는 잔액에 대해서는 정가를 지불하게 됩니다. 트랜잭션, 대역폭, 데이터 전송, 메타데이터 스토리지 요금은 예약에 포함되지 않습니다.
예약이 표준 및 프리미엄 파일 공유에 대한 Azure 파일 공유 스냅샷에서 작동하는 방식에는 차이가 있습니다. 표준 파일 공유의 스냅샷을 생성할 경우 스냅샷 차액은 예약에 대해 계산되며 일반적인 사용된 스토리지 미터의 일부로 청구됩니다. 그러나 프리미엄 파일 공유의 스냅샷을 만드는 경우 스냅샷은 별도의 미터를 사용하여 요금이 청구되며 예약에 계산되지 않습니다. 자세한 내용은 스냅샷을 참조하세요.
예약을 구매하는 방법에 대한 자세한 내용은 예약으로 Azure Files에 대한 비용 최적화를 참조하세요.
프로비저닝된 모델
Azure Files는 프리미엄 파일 공유에 프로비저닝된 모델을 사용합니다. 프로비전된 청구 모델에서는 사용량에 따라 비용이 청구되는 대신 스토리지 요구 사항을 적극적으로 지정합니다. 스토리지에 대해 프로비저닝된 모델은 특정 양의 스토리지 용량으로 Azure 파일 공유를 프로비저닝할 때 사용 여부에 관계없이 해당 스토리지 용량에 대해 비용을 지불하기 때문에 온-프레미스 스토리지 솔루션을 구입하는 것과 유사합니다. 온-프레미스에서 물리적 미디어를 구매하는 것과 달리 프로비저닝된 파일 공유는 스토리지 및 IO 성능 특성에 따라 동적으로 확장 또는 축소할 수 있습니다.
언제든지 파일 공유의 프로비전된 크기를 늘릴 수 있지만 마지막 증가 이후 24시간이 경과한 경우에만 줄일 수 있습니다. 할당량을 늘리지 않고 24시간을 기다린 후 다시 늘릴 때까지 공유 할당량을 원하는 만큼 줄일 수 있습니다. IOPS/처리량 크기 조정은 프로비저닝된 크기 변경 후 몇 분 이내에 적용됩니다.
프로비저닝된 공유의 크기를 사용된 GiB 이하로 줄일 수 있습니다. 이렇게 하면 데이터가 손실되지 않지만 사용된 크기에 대해 계속 청구되고 사용된 크기가 아니라 프로비저닝된 공유의 성능을 받습니다.
프로비저닝 방법
프리미엄 파일 공유를 프로비저닝할 때 워크로드에 필요한 GiB 수를 지정합니다. 프로비저닝하는 각 GiB는 고정 비율로 추가 IOPS 및 처리량을 제공합니다. 보장되는 기본 IOPS 외에도 각 프리미엄 파일 공유는 최선의 방식으로 버스트를 지원합니다. IOPS 및 처리량에 대한 수식은 다음과 같습니다.
| 항목 | 값 |
|---|---|
| 파일 공유의 최소 크기 | 100GiB |
| 프로비저닝 단위 | 1GiB |
| 기준 IOPS 수식 | MIN(3000 + 1 * ProvisionedStorageGiB, 102400) |
| 버스트 한도 | MIN(MAX(10000, 3 * ProvisionedStorageGiB), 102400) |
| 버스트 크레딧 | (BurstLimit - BaselineIOPS) * 3600 |
| 처리 속도(수신 + 송신)(MiB/sec) | 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
다음 표는 프로비저닝된 공유 크기에 대한 이러한 공식의 몇 가지 예를 보여줍니다.
| 용량(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 크기, 병렬 처리의 영향을 받습니다. 병렬 처리의 이점을 최대한 활용하려면 프리미엄 파일 공유에서 SMB 다중 채널을 사용하도록 설정하는 것이 좋습니다. 일반적인 성능 문제와 해결 방법은 SMB 성능 및 성능 문제 해결 가이드를 참조하세요.
버스팅
워크로드에 최대 수요를 충족하기 위해 추가 성능이 필요한 경우 버스트 크레딧을 사용하여 파일 공유의 기준 IOPS 한도를 초과할 수 있습니다. 버스팅은 자동화되며 크레딧 시스템을 기반으로 작동합니다. 이는 최선의 활동을 바탕으로 작동하며 버스트 제한이 보장되지는 않습니다.
크레딧은 파일 공유에 대한 트래픽이 기준 IOPS 이하가 될 때마다 버스트 버킷에 누적됩니다. 획득한 크레딧은 나중에 작업이 기준 IOPS를 초과할 때 버스팅을 사용하도록 설정하는 데 사용됩니다.
공유가 기준 IOPS를 초과하고 버스트 버킷에 크레딧이 있을 때마다 허용되는 최대 버스트 속도로 버스팅됩니다. 크레딧이 남아 있는 한 공유는 계속 버스팅할 수 있지만, 이는 누적된 버스트 크레딧 수에 따라 달라집니다. 기준 IOPS를 초과하는 각 IO는 1크레딧을 사용합니다. 모든 크레딧이 소비되면 공유는 기준 IOPS로 돌아갑니다.
공유 크레딧에는 세 가지 상태가 있습니다.
- 파일 공유가 기준 IOPS보다 적게 사용하는 경우 적립됩니다.
- 파일 공유가 기준 IOPS보다 많이 사용하고 버스트 모드인 경우 감소합니다.
- 상수, 파일 공유가 정확히 기준 IOPS를 사용하고 있고 크레딧이 누적되거나 사용되지 않은 경우입니다.
새 파일 공유는 버스트 버킷의 전체 크레딧 수로 시작됩니다. 서버의 제한으로 인해 공유 IOPS가 기준 미만으로 떨어지면 버스트 크레딧이 누적되지 않습니다.
종량제 모델
Azure Files는 표준 파일 공유에 종량제 청구 모델을 사용합니다. 이 모델에서 지불하는 금액은 프로비전된 금액이 아닌 실제로 사용한 양에 따라 결정됩니다. 상위 수준에서는 저장된 논리적 데이터의 양에 대해 요금을 지불하고 해당 데이터의 사용량을 기준으로 트랜잭션에 대해서도 요금을 청구합니다. 종량제 모델은 향후 성장 또는 성능 요구 사항을 고려하여 과도하게 프로비저닝할 필요가 없기 때문에 비용 효율적일 수 있습니다. 또한 워크로드와 데이터 공간이 시간에 따라 달라지는 경우 프로비저닝을 해제할 필요가 없습니다. 반면에 종량제 청구 모델은 최종 사용자 사용량에 따라 모델이 구동되므로 예산 책정 프로세스의 일부로 계획하기 어려울 수 있습니다.
표준 계층의 차이점
표준 파일 공유를 만들 때 트랜잭션 최적화 계층, 핫 계층 및 쿨 계층 중에서 선택합니다. 이 세 계층은 정확히 동일한 표준 스토리지 하드웨어에 저장됩니다. 이러한 세 계층의 주요 차이점은 더 높은 쿨 계층에서 저장 데이터 스토리지 가격이 더 낮고, 트랜잭션 가격이 더 높다는 것입니다. 이것은 다음을 의미합니다.
- 트랜잭션 최적화는 이름에서 암시하듯이 높은 트랜잭션 워크로드에 대한 가격을 최적화합니다. 트랜잭션 최적화의 경우 저장 데이터 스토리지 가격이 가장 높지만 트랜잭션 가격은 가장 낮습니다.
- 핫은 많은 수의 트랜잭션을 포함하지 않는 활성 워크로드에 적합합니다. 미사용 데이터 스토리지 가격은 약간 낮지만 트랜잭션 최적화에 비해 트랜잭션 가격은 약간 높습니다. 이를 트랜잭션 최적화 계층과 쿨 계층의 중간으로 생각하세요.
- 쿨은 작업이 많지 않은 워크로드에 대한 가격을 최적화하여 가장 낮은 저장 데이터 스토리지 가격을 제공하지만, 트랜잭션 가격이 가장 높습니다.
트랜잭션 최적화 계층에 자주 액세스하지 않는 워크로드를 배치하는 경우, 한 달에 몇 회 정도 수행하는 공유 트랜잭션에 대해서는 결제 금액이 거의 없습니다. 그러나 데이터 스토리지에는 많은 금액을 결제하게 됩니다. 이 동일한 공유를 쿨 계층으로 이동하는 경우, 이 워크로드에 대해 트랜잭션을 드물게 수행하기 때문에 트랜잭션 비용에 대해 거의 결제하지 않습니다. 그러나 쿨 계층의 데이터 스토리지 가격은 훨씬 저렴합니다. 사용 사례에 적합한 계층을 선택하면 비용을 크게 줄일 수 있습니다.
마찬가지로 쿨 계층에 매우 자주 액세스하는 워크로드를 배치하는 경우, 트랜잭션 비용을 훨씬 더 많이 결제하지만 데이터 스토리지 비용을 줄일 수 있습니다. 이로 인해 트랜잭션 가격 상승으로 인한 비용 증가가 데이터 스토리지 가격 하락으로 인한 비용 절감보다 더 큰 상황이 될 수 있으며, 트랜잭션 최적화보다 더 큰 비용을 쿨에 결제하게 됩니다. 일부 사용량 수준은 핫 계층이 가장 비용 효율적이고, 쿨 계층은 트랜잭션 최적화 계층보다 비용이 더 많이 들 수 있습니다.
워크로드 및 작업 수준에 따라 표준 파일 공유에 가장 비용 효율적인 계층이 결정됩니다. 실제로 가장 비용 효율적인 계층을 선택하는 가장 좋은 방법은 공유의 실제 리소스 사용량(저장된 데이터, 쓰기 트랜잭션 등)을 확인하는 것입니다. 표준 파일 공유의 경우 Azure Files로의 초기 마이그레이션 중에 트랜잭션 최적화 계층에서 시작한 다음, 마이그레이션이 완료된 후 사용량에 따라 올바른 계층을 선택하는 것이 좋습니다. 마이그레이션 중 트랜잭션 사용량은 일반적으로 정상적인 트랜잭션 사용량을 나타내지 않습니다.
트랜잭션이란?
SMB를 사용하여 컴퓨터에 Azure 파일 공유를 탑재하면 Azure 파일 공유가 로컬 스토리지인 것처럼 컴퓨터에 노출됩니다. 즉, 컴퓨터에 있는 애플리케이션, 스크립트 및 기타 프로그램이 Azure에 저장되어 있다는 사실을 알 필요 없이 Azure 파일 공유의 파일 및 폴더에 액세스할 수 있습니다.
파일을 읽거나 쓸 때 사용 중인 애플리케이션은 운영 체제에서 제공하는 파일 시스템 API에 대한 일련의 API 호출을 수행합니다. 그러면 운영 체제는 이러한 호출을 SMB 프로토콜 트랜잭션으로 해석하고, 이를 이행하기 위해 Azure Files로 유선으로 전송됩니다. 파일을 처음부터 끝까지 읽는 것과 같이 최종 사용자가 단일 작업으로 인식하는 작업은 Azure Files에서 제공하는 여러 SMB 트랜잭션으로 변환될 수 있습니다.
원칙적으로 표준 파일에서 사용하는 종량제 청구 모델은 사용량에 따라 청구서를 공유합니다. 애플리케이션과 스크립트에 의해 수행된 SMB 및 FileREST 트랜잭션은 파일 공유 사용량을 나타내며 청구서의 일부로 표시됩니다. Azure 파일 동기화 또는 Azure Backup과 같이 공유에 추가할 수 있는 부가 가치 클라우드 서비스에도 동일한 개념이 적용됩니다. 트랜잭션은 Azure 파일 공유에 미치는 영향에 따라 가격이 서로 다른 5가지 트랜잭션 범주로 그룹화됩니다. 이러한 범주는 쓰기, 나열, 읽기, 기타 및 삭제입니다.
다음 표는 각 트랜잭션의 분류를 보여 줍니다.
| 트랜잭션 버킷 | 관리 작업 | 데이터 작업 |
|---|---|---|
| 쓰기 트랜잭션 |
|
|
| 나열 트랜잭션 |
|
|
| 읽기 트랜잭션 |
|
|
| 기타/프로토콜 트랜잭션 |
|
|
| 삭제 트랜잭션 |
|
|
참고 항목
NFS 4.1은 프로비저닝된 청구 모델을 사용하는 프리미엄 파일 공유에만 사용할 수 있습니다. 트랜잭션은 프리미엄 파일 공유에 대한 청구에 영향을 미치지 않습니다.
표준 계층 간 전환
세 가지 표준 파일 공유 계층 간에 표준 파일 공유를 변경할 수 있지만 초기 마이그레이션 후 비용을 최적화하는 모범 사례는 가장 비용이 효율적인 계층을 선택하고 액세스 패턴이 변경되지 않는 한 그대로 유지하는 것입니다. 표준 파일 공유의 계층을 변경하면 다음과 같은 추가 비용이 발생하기 때문입니다.
트랜잭션: 공유를 더 높은 핫 계층에서 더 높은 쿨 계층으로 이동하면 공유의 각 파일에 대해 더 높은 쿨 계층의 쓰기 트랜잭션 요금이 발생합니다. 파일 공유를 더 높은 쿨 계층에서 더 높은 핫 계층으로 이동하면 공유의 각 파일에 대해 쿨 계층의 읽기 트랜잭션 요금이 발생합니다.
데이터 검색: 쿨 계층에서 핫 계층 또는 트랜잭션 최적화로 이동하는 경우 이동한 데이터의 크기에 따라 데이터 검색 요금이 부과됩니다. 쿨 계층만 데이터 검색 요금이 부과됩니다.
다음 표에서는 계층 이동의 비용 분석을 보여 줍니다.
| 계층 | 트랜잭션 최적화(대상) | 핫(대상) | 쿨(대상) |
|---|---|---|---|
| 트랜잭션 최적화(원본) | -- |
|
|
| 핫(원본) |
|
-- |
|
| 쿨(원본) |
|
|
-- |
파일 공유의 계층을 변경할 수 있는 빈도에 대한 공식적인 제한은 없지만 공유의 데이터 양에 따라 공유를 전환하는 데 시간이 걸립니다. 파일 공유가 계층 간에 전환되는 동안에는 공유 계층을 변경할 수 없습니다. 파일 공유 계층을 변경해도 일반 파일 공유 액세스에는 영향을 미치지 않습니다.
서로 다른 스토리지 계정 유형이 포함되어 있기 때문에 프리미엄 파일 공유와 표준 파일 공유 간에 이동하는 직접적인 메커니즘은 없지만 robocopy와 같은 복사 도구를 사용하여 프리미엄 및 표준 파일 공유 간에 이동할 수 있습니다.
계층 선택
기존 데이터를 Azure Files로 마이그레이션하는 방법에 관계없이 처음에는 트랜잭션 최적화 계층에서 파일 공유를 만드는 것이 좋습니다. 마이그레이션 중에 발생하는 트랜잭션 수가 많기 때문입니다. 마이그레이션이 완료되고 며칠 또는 몇 주 동안 정기적으로 사용하고 나면 트랜잭션 수를 가격 계산기에 연결하여 워크로드에 가장 적합한 계층을 파악할 수 있습니다.
표준 파일 공유는 스토리지 계정 수준의 트랜잭션 정보만 표시하므로 스토리지 메트릭을 사용하여 파일 공유 수준에서 어느 계층이 더 저렴한지 추정하는 것은 불완전한 기법입니다. 가능하면 청구에 대한 완전한 가시성을 보장하기 위해 각 스토리지 계정에 파일 공유를 하나만 배포하는 것이 좋습니다.
이전 트랜잭션을 보려면 다음을 수행합니다.
- 스토리지 계정으로 이동하고 왼쪽 탐색 모음에서 메트릭을 선택합니다.
- 범위를 스토리지 계정 이름으로 선택하고 메트릭 네임스페이스를 "파일"로, 메트릭을 "트랜잭션"으로, 집계를 "합계"로 선택합니다.
- 분할 적용을 선택합니다.
- 값을 "API 이름"으로 선택합니다. 원하는 한도 및 정렬을 선택합니다.
- 원하는 기간을 선택합니다.
참고 항목
평균 트랜잭션 수를 더 잘 알기 위해 특정 기간의 트랜잭션을 볼 수 있는지 확인합니다. 선택한 기간이 초기 프로비전과 겹치지 않는지 확인합니다. 이 기간의 평균 트랜잭션 수를 곱하여 한 달 동안의 예상 트랜잭션을 얻습니다.
프로비전된/할당량, 논리적 크기 및 물리적 크기
Azure Files는 공유 용량과 관련하여 세 가지 개별 수량을 추적합니다.
프로비전된 크기 또는 할당량: 프리미엄 및 표준 파일 공유를 모두 사용하여 파일 공유가 증가할 수 있는 최대 크기를 지정합니다. 프리미엄 파일 공유에서는 이 값을 프로비전된 크기라고 합니다. 프로비전하는 금액은 실제로 사용하는 양에 관계없이 지불하는 금액입니다. 표준 파일 공유에서 이 값을 할당량이라고 하며 청구서에 직접적인 영향을 주지 않습니다. 프로비저닝된 크기는 프리미엄 파일 공유에 필요한 필드입니다. 표준 파일 공유의 경우 프로비저닝된 크기를 직접 지정하지 않으면 공유는 기본적으로 스토리지 계정에서 지원하는 최댓값으로 설정됩니다.
논리적 크기: 파일 공유 또는 파일의 논리적 크기는 크기와 관련이 있으며 추가로 최적화가 적용될 수 있는 실제로 저장되는 방식을 고려하지 않습니다. 파일의 논리적 크기는 파일을 다른 위치에 복사한 경우 유선을 통해 전송되는 KiB/MiB/GiB 수입니다. 프리미엄 및 표준 파일 공유 모두에서 파일 공유의 총 논리적 크기는 프로비전된 크기/할당량에 대한 적용에 사용됩니다. 표준 파일 공유에서 논리적 크기는 미사용 데이터 사용량 청구에 사용되는 수량입니다. 논리적 크기는 파일/폴더에 대한 Windows 속성 대화 상자에서 "크기"라고 하며 Azure Files 메트릭에서는 "콘텐츠 길이"라고 합니다.
물리적 크기: 파일의 물리적 크기는 디스크에 인코딩된 파일의 크기와 관련이 있습니다. 이는 파일의 논리적 크기와 일치할 수도 있고 운영 체제에서 파일을 기록한 방식에 따라 더 작을 수도 있습니다. 논리적 크기와 물리적 크기가 다른 일반적인 이유는 스파스 파일을 사용하기 때문입니다. 공유에 있는 파일의 물리적 크기는 스냅샷 청구에 사용되지만 할당된 범위는 변경되지 않은 경우 스냅샷 간에 공유됩니다(차등 스토리지). Azure Files에서 스냅샷 요금이 청구되는 방식에 대한 자세한 내용은 스냅샷을 참조하세요.
스냅샷
Azure Files는 Windows 파일 서버의 VSS(볼륨 섀도 복사본)와 유사한 스냅샷을 지원합니다. 스냅샷은 항상 라이브 공유와 서로 다르므로 항상 각 스냅샷에서 다른 부분에 대해서만 비용을 지불합니다. 공유 스냅샷에 대한 자세한 내용은 Azure Files의 스냅샷 개요를 참조하세요.
스냅샷은 파일 공유 크기 제한에 포함되지 않지만 특정 수의 스냅샷으로 제한됩니다. 현재 스냅샷 제한을 보려면 Azure 파일 공유 크기 조정 목표를 참조하세요.
스냅샷 요금은 항상 각 스냅샷의 차등 스토리지 사용량을 기준으로 청구됩니다. 그러나 이는 프리미엄 파일 공유와 표준 파일 공유 간에 약간 다르게 보입니다.
프리미엄 파일 공유에서 스냅샷은 자체 스냅샷 측정기에 대해 청구되며 프로비전된 스토리지 가격보다 가격이 저렴합니다. 즉, 청구서에서 각 FileStorage 스토리지 계정의 프리미엄 파일 공유에 대한 스냅샷을 나타내는 별도의 항목이 청구서에 표시됩니다.
표준 파일 공유에서 스냅샷은 일반적으로 사용된 스토리지 측정기의 일부로 청구되지만 스냅샷의 차등 비용에 대해서만 청구됩니다. 즉, Azure 파일 공유를 포함하는 각 표준 스토리지 계정에 대한 스냅샷을 나타내는 별도의 항목이 청구서에 표시되지 않습니다. 즉, 차등 스냅샷 사용량은 표준 파일 공유를 위해 구매한 예약에 포함되어 계산됩니다.
Azure Files의 일부 부가 가치 서비스는 가치 제안의 일부로 스냅샷을 사용합니다. 자세한 내용은 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 Files 비용을 최적화하려면 파일 공유 계층을 고려해야 합니다. 각 파일 공유에 대한 계층을 선택하는 방법에 대한 자세한 내용은 파일 공유 계층 선택을 참조하세요.
StorSimple에서 Azure 파일 동기화로 마이그레이션하는 경우 StorSimple의 비용을 Azure 파일 동기화와 비교를 참조하세요.
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 보호에서 스토리지 계정 제외를 참조하세요.