데이터 수명 주기를 자동으로 관리하여 비용 최적화
Azure Blob Storage 수명 주기 관리는 Blob 데이터를 적절한 액세스 계층으로 전환하거나 수명 주기가 끝나면 데이터를 만료하는 데 사용할 수 있는 규칙 기반 정책을 제공합니다.
수명 주기 관리 정책을 사용하면 다음을 수행할 수 있습니다.
- 성능 최적화를 위해 액세스하는 경우 Blob을 쿨에서 핫으로 즉시 전환합니다.
- Blob의 현재 버전, Blob의 이전 버전 또는 Blob 스냅샷을 일정 기간 동안 액세스하거나 수정하지 않은 경우 더 낮은 스토리지 계층으로 전환하여 비용을 최적화합니다.
- Blob의 현재 버전, Blob의 이전 버전 또는 수명 주기가 끝나면 Blob 스냅샷을 삭제합니다.
- 필터로 이름 접두사 또는Blob 인덱스 태그를 사용하여 전체 스토리지 계정, 컨테이너 선택 또는 Blob 하위 집합에 규칙을 적용합니다.
팁
수명 주기 관리는 단일 계정의 계층 간에 데이터를 이동하는 데 도움이 되지만, 스토리지 작업을 사용하면 여러 계정에 걸쳐 대규모로 이 작업을 수행할 수 있습니다. 스토리지 작업은 Azure 스토리지 작업에서 사용할 수 있는 리소스입니다. 여러 스토리지 계정에 걸쳐 수백만 개의 개체에 대해 일반적인 데이터 작업을 수행하는 데 사용할 수 있는 서버리스 프레임워크입니다. 자세히 알아보려면 Azure 스토리지 작업이란?을 참조하세요.
수명 주기 관리 정책은 범용 v2, 프리미엄 블록 Blob 및 Blob Storage 계정의 블록 Blob 및 추가 Blob에 대해 지원됩니다. 수명 주기 관리는 $logs 및 $web 컨테이너와 같은 시스템 컨테이너에 영향을 주지 않습니다.
Important
데이터 세트를 읽을 수 있어야 하는 경우에는 Blob을 보관 계층으로 이동하는 정책을 설정하지 마십시오. 보관 계층의 Blob이 처음에 리하이드레이션되지 않는 한 이 Blob을 읽을 수 없으며 이 프로세스는 시간과 비용이 많이 소모될 수 있습니다. 자세한 내용은 보관 계층의 Blob 리하이드레이션 개요를 참조하세요. 데이터 집합을 자주 읽어야 하는 경우 트랜잭션 비용이 더 높을 수 있으므로 Blob을 쿨 또는 콜드 계층으로 이동하는 정책을 설정하지 마세요.
데이터 수명 주기 관리를 통한 비용 최적화
데이터 집합에는 고유한 수명 주기가 있습니다. 수명 주기 초기에는 사람들이 일부 데이터에 자주 액세스합니다 하지만 액세스 필요성은 데이터가 오래될 수록 크게 줄어듭니다. 어떤 데이터는 클라우드에서 유휴 상태로 유지되고 저장된 후에는 어쩌다 한 번씩 액세스됩니다. 어떤 데이터 세트는 생성된 후 며칠 또는 몇 달 만에 만료되고 또 어떤 데이터 세트는 수명 주기 내내 적극적으로 읽히고 수정됩니다.
수명 주기 초기 단계에는 데이터에 자주 액세스하지만 2주 후에는 가끔씩만 데이터에 액세스하는 시나리오를 고려해 보겠습니다. 첫 번째 달 이후에는 데이터 세트에 거의 액세스하지 않습니다. 이 시나리오에서 초기 단계 동안에는 핫 스토리지 계층이 가장 적절합니다. 가끔 접근하는 경우에는 쿨 스토리지가 가장 적합합니다. 보관 스토리지는 데이터가 생성된 지 한 달이 넘은 경우 가장 적절한 계층 옵션입니다. 수명 주기 관리 정책 규칙을 사용하여 해당 수명을 기준으로 데이터를 적절한 스토리지 계층으로 이동하면 요구 사항에 맞는 가장 저렴한 솔루션을 설계할 수 있습니다.
수명 주기 관리 정책 정의
수명 주기 관리 정책은 JSON 문서의 규칙 컬렉션입니다. 다음 샘플 JSON에서는 전체 규칙 정의를 보여줍니다.
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
정책은 다음 표의 설명대로 규칙 컬렉션입니다.
| 매개 변수 이름 | 매개 변수 형식 | 참고 |
|---|---|---|
rules |
규칙 개체의 배열 | 정책에 하나 이상의 규칙이 필요합니다. 정책에 최대 100개의 규칙을 정의할 수 있습니다. |
정책 내 각 규칙에는 다음 표에서 설명한 몇 가지 매개 변수가 있습니다.
| 매개 변수 이름 | 매개 변수 형식 | 참고 | 필수 |
|---|---|---|---|
name |
문자열 | 규칙 이름은 최대 256자의 영숫자를 포함할 수 있습니다. 규칙 이름은 대/소문자를 구분합니다. 정책 내에서 고유해야 합니다. | True |
enabled |
부울 | 규칙을 일시적으로 사용하지 않을 수 있는 선택적 부울입니다. 설정되지 않은 경우 기본값은 true입니다. | 거짓 |
type |
열거형 값 | 현재 유효한 형식은 Lifecycle입니다. |
True |
definition |
수명 주기 규칙을 정의하는 개체 | 각 정의는 필터 집합과 작업 집합으로 구성됩니다. | True |
수명 주기 관리 규칙 정의
정책 내 각 규칙 정의에는 필터 집합과 작업 집합이 포함되어 있습니다. 필터 집합은 컨테이너 또는 개체 이름 내에서 개체의 특정 집합으로 규칙 작업을 제한합니다. 작업 집합은 계층을 적용하거나 필터링된 개체 집합에 대한 작업을 삭제합니다.
샘플 규칙
다음 샘플 규칙은 계정을 필터링하여 sample-container 내에 존재하고 blob1로 시작하는 개체에 대한 작업을 실행합니다.
- 마지막으로 수정한 시점으로부터 30일 후 Blob을 쿨 계층으로 이동
- 마지막으로 수정한 시점으로부터 90일 후 Blob을 보관 계층으로 이동
- 마지막으로 수정한 시점으로부터 2,555일(7년) 후 BLOB 삭제
- 만들기 후 90일 후에 이전 버전 삭제
{
"rules": [
{
"enabled": true,
"name": "sample-rule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"delete": {
"daysAfterCreationGreaterThan": 90
}
},
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 90,
"daysAfterLastTierChangeGreaterThan": 7
},
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"sample-container/blob1"
]
}
}
}
]
}
참고 항목
수명 주기 관리 정책의 baseBlob 요소는 Blob의 현재 버전을 나타냅니다. version 요소는 이전 버전을 나타냅니다.
규칙 필터
필터는 규칙 작업을 스토리지 계정 내의 BLOB 작업 하위 집합으로 제한합니다. 둘 이상의 필터를 정의하는 경우 논리적 AND가 모든 필터에서 실행됩니다. 필터를 사용하여 포함할 Blob을 지정할 수 있습니다. 필터는 제외할 Blob을 지정할 방법을 제공하지 않습니다.
필터에는 다음이 포함됩니다.
| 필터 이름 | 필터 형식 | 주의 | 필수 여부 |
|---|---|---|---|
| blobTypes | 미리 정의된 열거형 값의 배열입니다. | 현재 릴리스에서는 blockBlob 및 appendBlob을 지원합니다. 삭제 작업만 appendBlob에 대해 지원됩니다; 계층 설정은 지원되지 않습니다. |
예 |
| prefixMatch | 일치시킬 접두사에 대한 문자열 배열입니다. 각 규칙은 대/소문자를 구분하는 접두사를 최대 10개까지 정의할 수 있습니다. 접두사 문자열은 컨테이너 이름으로 시작해야 합니다. 예를 들어 https://myaccount.blob.core.windows.net/sample-container/blob1/... 아래의 모든 Blob을 일치하려면 prefixMatch를 sample-container/blob1(으)로 지정합니다. 이 필터는 이름이 blob1과 함께 시작하는 샘플 컨테이너의 모든 Blob과 일치합니다.. |
prefixMatch를 정의하지 않으면 규칙이 스토리지 계정 내의 모든 Blob에 적용됩니다. 접두사 문자열은 와일드카드 일치를 지원하지 않습니다. * 및 ?와 같은 문자는 문자열 리터럴로 처리됩니다. |
아니요 |
| blobIndexMatch | 일치시킬 Blob 인덱스 태그 키와 값 조건으로 구성된 사전 값의 배열입니다. 각 규칙에서 Blob 인덱스 태그 조건을 최대 10개까지 정의할 수 있습니다. 예를 들어 규칙의 https://myaccount.blob.core.windows.net/에서 모든 Blob을 Project = Contoso와 일치시키려는 경우 blobIndexMatch는 {"name": "Project","op": "==","value": "Contoso"}입니다. |
blobIndexMatch를 정의하지 않으면 규칙은 스토리지 계정 내의 모든 Blob에 적용됩니다. | 아니요 |
알려진 문제 및 제한 사항과 함께 Blob 인덱스 기능에 대한 자세한 내용은 Blob 인덱스를 사용하여 Azure Blob Storage에서 데이터 관리 및 찾기를 참조하세요.
규칙 작업
실행 조건이 충족되면 필터링된 Blob에 작업이 적용됩니다.
수명 주기 관리는 현재 버전, 이전 버전 및 Blob 스냅샷의 계층화 및 삭제를 지원합니다. 각 규칙에 대해 하나 이상의 작업을 정의합니다.
참고 항목
프리미엄 블록 Blob Storage 계정에서 계층화는 아직 지원되지 않습니다. 다른 모든 계정의 경우 계층화는 블록 Blob에서만 허용되며 추가 및 페이지 Blob에는 허용되지 않습니다.
| 작업 | 현재 버전 | 스냅샷 | 이전 버전 |
|---|---|---|---|
| tierToCool | blockBlob에 대해 지원됨 |
지원됨 | 지원됨 |
| tierToCold | blockBlob에 대해 지원됨 |
지원됨 | 지원됨 |
| enableAutoTierToHotFromCool1 | blockBlob에 대해 지원됨 |
지원되지 않음 | 지원되지 않음 |
| tierToArchive4 | blockBlob에 대해 지원됨 |
지원됨 | 지원됨 |
| delete2,3 | blockBlob 및 appendBlob에 대해 지원됨 |
지원됨 | 지원됨 |
1enableAutoTierToHotFromCool 작업은 daysAfterLastAccessTimeGreaterThan 조건과 함께 사용할 때만 사용할 수 있습니다. 해당 조건은 다음 표에 설명되어 있습니다.
2 계층 구조 네임스페이스가 사용하도록 설정된 계정에 적용하면 delete 작업에서 빈 디렉터리를 제거합니다. 디렉터리가 비어 있지 않으면 delete 작업에서 처음 수명 주기 정책 실행 주기 내에 정책 조건을 충족하는 개체를 제거합니다. 해당 작업으로 인해 정책 조건도 충족하는 빈 디렉터리가 생성되면 해당 디렉터리는 다음 실행 주기 내에 제거됩니다.
3 수명 주기 관리 정책은 해당 Blob과 연결된 이전 버전 또는 스냅샷이 삭제될 때까지 Blob의 현재 버전을 삭제하지 않습니다. 스토리지 계정의 Blob에 이전 버전 또는 스냅샷이 있는 경우, 삭제 작업을 정책의 일부로 지정할 때 이전 버전과 스냅샷을 포함해야 합니다.
4 LRS, GRS, RA-GRS용으로 구성된 스토리지 계정만 보관 계층으로 Blob 이동을 지원합니다. 보관 계층은 ZRS, GZRS, RA-GZRS 계정에 대해 지원되지 않습니다. 이 작업은 계정에 대해 구성된 중복성에 따라 나열됩니다.
참고 항목
동일한 Blob에 작업을 두 개 이상 정의하는 경우 수명 주기 관리는 가장 저렴한 작업을 Blob에 적용합니다. 예를 들어 delete 작업은 tierToArchive 작업보다 저렴합니다. tierToArchive 작업은 tierToCool 작업보다 저렴합니다.
실행 조건은 보존 기간을 기준으로 합니다. 현재 버전은 마지막 수정 시간 또는 마지막 액세스 시간을 사용하고, 이전 버전은 버전 생성 시간을 사용하고, Blob 스냅샷은 스냅샷 생성 시간을 사용하여 보존 기간을 추적합니다.
| 작업 실행 조건 | 조건 값 | Description |
|---|---|---|
| daysAfterModificationGreaterThan | 일 단위로 보존 기간을 나타내는 정수 값 | Blob의 현재 버전에 대한 작업 조건 |
| daysAfterCreationGreaterThan | 일 단위로 보존 기간을 나타내는 정수 값 | Blob 또는 Blob 스냅샷의 현재 버전 또는 이전 버전에 대한 작업 조건 |
| daysAfterLastAccessTimeGreaterThan1 | 일 단위로 보존 기간을 나타내는 정수 값 | 액세스 추적이 사용하도록 설정된 경우 현재 버전의 Blob에 대한 조건 |
| daysAfterLastTierChangeGreaterThan | 마지막 Blob 계층 변경 시간 이후의 기간(일)을 나타내는 정수 값 | 보관 계층으로 반환되기 전에 리하이드레이션된 Blob이 핫, 쿨 또는 콜드 계층에 보관되는 최소 기간(일)입니다. 이 조건은 tierToArchive 작업에만 적용됩니다. |
1 만약 마지막 액세스 시간 추적을 사용하도록 설정하지 않으면 daysAfterLastAccessTimeGreaterThan은 Blob의 LastAccessTime 속성 대신 수명 주기 정책이 사용하도록 설정된 날짜를 사용합니다. 이 날짜는 LastAccessTime 속성이 null 값인 경우에도 사용됩니다. 마지막 액세스 시간 추적을 사용하는 방법에 대한 자세한 내용은 마지막 액세스 시간을 기준으로 데이터 이동을 참조하세요.
수명 주기 정책 실행
수명 주기 정책을 구성하거나 편집할 때 변경 내용이 적용되고 첫 번째 실행이 시작되는 데 최대 24시간이 걸릴 수 있습니다. 정책 작업이 완료되는 데 걸리는 시간은 평가되고 작동하는 Blob의 수에 따라 달라집니다.
정책을 사용하지 않도록 설정하면 새 정책 실행이 예약되지 않지만 실행이 이미 진행 중인 경우 실행이 완료될 때까지 계속되며 실행을 완료하는 데 필요한 작업에 대한 요금이 청구됩니다. 지역별 가용성 및 가격 책정을 참조하세요.
수명 주기 정책 완료 이벤트
LifecyclePolicyCompleted 이벤트는 수명 주기 관리 정책에 의해 정의된 작업이 수행될 때 생성됩니다. 정책 정의에 포함된 각 작업에 대한 요약 섹션이 나타납니다. 다음 json은 정책에 대한 예제 LifecyclePolicyCompleted 이벤트를 보여줍니다. 정책 정의에 , tierToCool, tierToCold및 tierToArchive 작업이 포함delete되므로 각 항목에 대한 요약 섹션이 나타납니다.
{
"topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
"subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
"eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
"eventTime": "2022-05-26T00:00:40.1880331",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"data": {
"scheduleTime": "2022/05/24 22:57:29.3260160",
"deleteSummary": {
"totalObjectsCount": 16,
"successCount": 14,
"errorList": ""
},
"tierToCoolSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToColdSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
다음 표에는 LifecyclePolicyCompleted 이벤트의 스키마가 설명되어 있습니다.
| 필드 | 형식 | 설명 |
|---|---|---|
| scheduleTime | string | 수명 주기 정책이 예약된 시간 |
| deleteSummary | 벡터<바이트> | 삭제 작업으로 예약된 Blob의 결과 요약 |
| tierToCoolSummary | 벡터<바이트> | 계층 간 작업을 위해 예약된 Blob의 결과 요약 |
| tierToColdSummary | 벡터<바이트> | 계층-콜드 작업으로 예약된 Blob의 결과 요약 |
| tierToArchiveSummary | 벡터<바이트> | 계층-보관 작업으로 예약된 Blob의 결과 요약 |
수명 주기 정책 예
다음 예는 수명 주기 정책 규칙을 사용하여 일반 시나리오를 해결하는 방법을 보여줍니다.
오래된 데이터를 쿨 저장소 계층으로 이동
이 예제는 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 }
}
}
}
}
]
}
마지막으로 액세스한 시간을 기준으로 데이터 이동
마지막 액세스 시간 추적을 사용하여 Blob을 마지막으로 읽거나 쓴 시점의 레코드를 유지하고 필터로 사용하여 Blob 데이터의 계층화와 보존을 관리할 수 있습니다. 마지막 액세스 시간 추적을 사용하는 방법은 선택적으로 액세스 시간 추적 사용을 참조하세요.
마지막 액세스 시간 추적을 사용하면 Blob을 읽거나 쓸 때 LastAccessTime이라는 Blob 속성이 업데이트됩니다. Blob 가져오기 작업은 액세스 작업으로 간주됩니다. Blob 속성 가져오기, Blob 메타데이터 가져오기 및 Blob 태그 가져오기는 액세스 작업이 아니므로 마지막 액세스 시간을 업데이트하지 않습니다.
마지막 액세스 시간 추적을 사용하도록 설정한 경우 수명 주기 관리는 LastAccessTime를 사용하여 실행 조건 daysAfterLastAccessTimeGreaterThan이 충족되는지 여부를 확인합니다. 수명 주기 관리는 다음 경우 LastAccessTime 대신 수명 주기 정책을 사용하도록 설정한 날짜를 사용합니다.
Blob의
LastAccessTime속성 값은 null 값입니다.참고 항목
마지막 액세스 시간 추적을 사용하도록 설정한 이후 Blob에 액세스하지 않은 경우 Blob의
lastAccessedOn속성은 null입니다.마지막 액세스 시간 추적을 사용할 수 없습니다.
읽기 액세스 대기 시간에 대한 영향을 최소화하기 위해 최근 24시간 동안의 첫 번째 읽기만 마지막 액세스 시간을 업데이트합니다. 동일한 24시간 동안의 이후 읽기는 마지막 액세스 시간을 업데이트하지 않습니다. 읽기 간에 Blob이 수정되는 경우 마지막 액세스 시간은 두 값 중 더 최근입니다.
다음 예에서는 30일 동안 액세스하지 않은 Blob이 쿨 스토리지로 이동됩니다. enableAutoTierToHotFromCool 속성은 Blob이 쿨로 계층화된 후 다시 액세스되는 경우 자동으로 쿨에서 다시 핫으로 계층화되어야 하는지 여부를 나타내는 부울 값입니다.
팁
Blob이 쿨 계층으로 이동된 다음, 30일이 경과하기 전에 자동으로 다시 이동되면 조기 삭제 요금이 청구됩니다. enablAutoTierToHotFromCool 속성을 설정하기 전에 예기치 않은 요금을 줄일 수 있도록 데이터의 액세스 패턴을 분석해야 합니다.
{
"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에 대해 수행하여 완료됩니다.
{
"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 헤더가 지원됩니다.
보존 기간에 따라 데이터 만료
일부 데이터는 생성되고 며칠 또는 몇 달 후에 만료될 것으로 예상됩니다. 데이터 보존 기간에 따라 삭제하여 데이터를 만료하도록 수명 주기 관리 정책을 구성할 수 있습니다. 다음 예는 지난 365일 동안 수정되지 않은 모든 블록 Blob을 삭제하는 정책을 보여 줍니다.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Blob 인덱스 태그를 사용하여 데이터 삭제
일부 데이터는 명시적으로 삭제하도록 표시된 경우에만 만료되어야 합니다. Blob 인덱스 키/값 특성으로 태그가 지정된 데이터를 만료하도록 수명 주기 관리 정책을 구성할 수 있습니다. 다음 예에서는 Project = Contoso 태그가 지정된 모든 블록 Blob을 삭제하는 정책을 보여줍니다. Blob 인덱스에 대해 자세히 알아보려면 Blob 인덱스를 사용하여 Azure Blob Storage에서 데이터 관리 및 찾기를 참조하세요.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
이전 버전 관리
수명이 지속되는 동안 정기적으로 수정하고 액세스하는 데이터의 경우 Blob Storage 버전 관리를 사용하도록 설정하여 이전 버전의 개체를 자동으로 유지 관리할 수 있습니다. 정책을 생성하여 이전 버전을 계층화하거나 삭제할 수 있습니다. 버전 보존 기간은 버전 생성 시간을 평가하여 확인합니다. 이 정책 규칙은 버전 생성 후 90일이 경과한 컨테이너 activedata 내의 이전 버전을 쿨 계층으로 이동하고 365일이 경과한 이전 버전을 삭제합니다.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
지역별 가용성 및 가격 책정
수명 주기 관리 기능은 모든 Azure 지역에서 사용할 수 있습니다.
수명 주기 관리 정책은 무료입니다. Blob 계층 설정 API 호출에 대한 표준 작업 비용이 고객에게 청구됩니다. 삭제 작업은 무료입니다. 그러나 Microsoft Defender for Storage와 같은 기타 Azure 서비스 및 유틸리티는 수명 주기 정책을 통해 관리되는 작업에 대해 요금을 부과할 수 있습니다.
Blob의 마지막 액세스 시간에 대한 각 업데이트 비용은 기타 작업 범주에서 청구됩니다. 마지막 액세스 시간 업데이트는 하루에 수천 번 액세스하더라도 개체당 최대 24시간마다 한 번씩 “다른 트랜잭션”으로 청구됩니다. 이는 읽기 트랜잭션 요금과는 별개입니다.
가격에 대한 자세한 내용은 블록 Blob 가격을 참조하세요.
알려진 문제 및 제한 사항
프리미엄 블록 Blob Storage 계정에서 계층화는 아직 지원되지 않습니다. 다른 모든 계정의 경우 계층화는 블록 Blob에서만 허용되며 추가 및 페이지 Blob에는 허용되지 않습니다.
수명 주기 관리 정책은 전체적으로 읽거나 써야 합니다. 부분 업데이트는 지원되지 않습니다.
각 규칙에는 최대 10개의 대/소문자 구분 접두사 및 최대 10개의 Blob 인덱스 태그 조건이 있을 수 있습니다.
수명 주기 관리 정책은 암호화 범위를 사용하는 Blob의 계층을 변경할 수 없습니다.
수명 주기 관리 정책의 삭제 작업은 변경할 수 없는 컨테이너의 모든 Blob에서 작동하지 않습니다. 변경할 수 없는 정책을 사용하면 개체를 만들고 읽을 수 있지만 수정하거나 삭제할 수는 없습니다. 자세한 내용은 변경이 불가능한 스토리지로 업무상 중요한 Blob 데이터 저장을 참조하세요.
질문과 대답(FAQ)
수명 주기 관리 FAQ를 참조하세요.