수명 주기 관리 정책을 사용하여 Blob을 사용 패턴에 따라 비용 효율적인 액세스 계층으로 전환할 수 있습니다. 이 문서에는 계층 간에 Blob을 전환하는 정책 정의의 예가 포함되어 있습니다.
Azure Storage 수명 주기 관리 정책에 대한 일반적인 내용은 Azure Blob Storage 수명 주기 관리 개요를 참조하세요.
오래된 데이터를 쿨 저장소 계층으로 이동
이 예제는 sample-container/blob1 또는 container2/blob2 접두사가 붙은 블록 Blob을 전환하는 방법을 보여줍니다. 이 정책은 30일 넘게 수정되지 않은 BLOB을 쿨 스토리지 계층으로 전환하고, 90일 동안 수정되지 않은 BLOB을 보관 스토리지 계층으로 전환합니다.
{
"rules": [
{
"name": "agingRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
},
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 }
}
}
}
}
]
}
비고
수명 주기 관리 정책의 baseBlob 요소는 Blob의 현재 버전을 나타냅니다.
마지막으로 액세스한 시간에 따라 데이터 이동
다음 예에서는 30일 동안 액세스하지 않은 Blob이 쿨 스토리지로 이동됩니다.
enableAutoTierToHotFromCool 속성은 Blob이 쿨로 계층화된 후 다시 액세스되는 경우 자동으로 쿨에서 다시 핫으로 계층화되어야 하는지 여부를 나타내는 부울 값입니다.
팁 (조언)
Blob이 쿨 계층으로 이동된 다음, 30일이 경과하기 전에 자동으로 다시 이동되면 조기 삭제 요금이 청구됩니다.
enableAutoTierToHotFromCool 속성을 설정하기 전에 예기치 않은 요금을 줄일 수 있도록 데이터의 액세스 패턴을 분석해야 합니다. Blob 액세스 시 쿨에서 핫으로 자동 계층화는 30일 이내에 한 번으로 제한됩니다. 이 안전 조치는 쿨 계층에서 발생할 수 있는 여러 조기 삭제 벌금을 방지하는 데 도움이 됩니다. 정책으로 인해 개체가 다시 쿨로 계층화되는 경우 Blob의 모든 트랜잭션은 쿨 계층 가격으로 청구됩니다. 30일 동안 두 번 이상 자동으로 계층화해야 하는 경우 Blob을 핫 계층에 유지하는 것이 비용 효율적입니다.
규칙을 enableAutoTierToHotFromCool로 활성화하면 이 규칙을 사용하여 계층화된 개체에만 적용됩니다.
enableAutoTierToHotFromCool 쿨 계층에 이미 있는 Blob에는 속성을 활성화할 수 없습니다. 따라서 해당 Blob의 액세스 계층은 액세스될 때 자동으로 핫으로 변경되지 않습니다.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
데이터 수집 후 보관 처리
일부 데이터는 클라우드에 유휴 상태로 유지되며 드물게 액세스됩니다. 다음 수명 주기 정책은 수집 직후 데이터를 보관하도록 구성되었습니다. 이 예에서는 archivecontainer라는 컨테이너의 블록 Blob을 보관 계층으로 전환합니다. 전환은 마지막으로 수정한 시간으로부터 0일 후 Blob에 대해 수행하여 완료됩니다.
중요합니다
데이터 세트를 읽을 수 있어야 하는 경우에는 Blob을 보관 계층으로 이동하는 정책을 설정하지 마십시오. 보관 계층의 Blob이 처음에 리하이드레이션되지 않는 한 이 Blob을 읽을 수 없으며 이 프로세스는 시간과 비용이 많이 소모될 수 있습니다. 자세한 내용은 보관 계층의 Blob 리하이드레이션 개요를 참조하세요. 데이터 집합을 자주 읽어야 하는 경우 트랜잭션 비용이 더 높을 수 있으므로 Blob을 쿨 또는 콜드 계층으로 이동하는 정책을 설정하지 마세요.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
비고
Microsoft는 효율성을 높이기 위해 Blob을 보관 계층에 직접 업로드하는 것을 권장합니다. Blob 배치나 블록 목록 배치 작업의 x-ms-access-tier 헤더에서 보관 계층을 지정할 수 있습니다. REST 버전 2018-11-09 이상 또는 최신 Blob 스토리지 클라이언트 라이브러리에서 x-ms-access-tier 헤더가 지원됩니다.
이전 버전 관리
수명이 지속되는 동안 정기적으로 수정하고 액세스하는 데이터의 경우 Blob Storage 버전 관리를 사용하도록 설정하여 이전 버전의 개체를 자동으로 유지 관리할 수 있습니다. 이전 버전을 계층화하기 위한 정책을 만들 수 있습니다. 버전 보존 기간은 버전 생성 시간을 평가하여 확인합니다. 이 정책 규칙은 버전을 만든 후 90일 이상인 컨테이너 activedata 내의 이전 버전을 쿨 계층으로 이동합니다.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
비고
수명 주기 관리 정책의 버전 요소는 이전 버전을 참조합니다.