데이터 수명 주기를 자동으로 관리하여 비용 최적화

Azure Blob Storage 수명 주기 관리는 Blob 데이터를 적절한 액세스 계층으로 전환하거나 수명 주기가 끝나면 데이터를 만료하는 데 사용할 수 있는 규칙 기반 정책을 제공합니다.

수명 주기 관리 정책을 사용하면 다음을 수행할 수 있습니다.

• 비용 최적화를 위해 이러한 개체에 일정 기간 동안 액세스하거나 수정하지 않은 경우 Blob의 현재 버전, Blob의 이전 버전 또는 Blob 스냅샷을 쿨 스토리지 계층으로 전환합니다.
• Blob에 액세스할 때 즉시 쿨에서 핫으로 다시 전환합니다.
• Blob의 현재 버전, Blob의 이전 버전 또는 수명 주기가 끝나면 Blob 스냅샷을 삭제합니다.
• 필터로 이름 접두사 또는Blob 인덱스 태그를 사용하여 전체 스토리지 계정, 컨테이너 선택 또는 Blob 하위 집합에 규칙을 적용합니다.

수명 주기 관리 정책은 범용 v2, 프리미엄 블록 Blob 및 Blob Storage 계정의 블록 Blob 및 추가 Blob에 대해 지원됩니다. 수명 주기 관리는 $logs 및 $web 컨테이너와 같은 시스템 컨테이너에 영향을 주지 않습니다.

데이터 수명 주기 관리를 통한 비용 최적화

데이터 집합에는 고유한 수명 주기가 있습니다. 수명 주기 초기에는 사람들이 일부 데이터에 자주 액세스합니다 하지만 액세스 필요성은 데이터가 오래될 수록 크게 줄어듭니다. 어떤 데이터는 클라우드에서 유휴 상태로 유지되고 저장된 후에는 어쩌다 한 번씩 액세스됩니다. 어떤 데이터 세트는 생성된 후 며칠 또는 몇 달 만에 만료되고 또 어떤 데이터 세트는 수명 주기 내내 적극적으로 읽히고 수정됩니다.

수명 주기 초기 단계에는 데이터에 자주 액세스하지만 2주 후에는 가끔씩만 데이터에 액세스하는 시나리오를 고려해 보겠습니다. 첫 번째 달 이후에는 데이터 세트에 거의 액세스하지 않습니다. 이 시나리오에서 초기 단계 동안에는 핫 스토리지 계층이 가장 적절합니다. 가끔 접근하는 경우에는 쿨 스토리지가 가장 적합합니다. 보관 스토리지는 데이터가 생성된 지 한 달이 넘은 경우 가장 적절한 계층 옵션입니다. 수명 주기 관리 정책 규칙을 사용하여 해당 수명을 기준으로 데이터를 적절한 스토리지 계층으로 이동하면 요구 사항에 맞는 가장 저렴한 솔루션을 설계할 수 있습니다.

수명 주기 관리 정책 정의

수명 주기 관리 정책은 JSON 문서의 규칙 컬렉션입니다. 다음 샘플 JSON에서는 전체 규칙 정의를 보여줍니다.

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

정책은 다음 표의 설명대로 규칙 컬렉션입니다.

정책 내 각 규칙에는 다음 표에서 설명한 몇 가지 매개 변수가 있습니다.

수명 주기 관리 규칙 정의

정책 내 각 규칙 정의에는 필터 집합과 작업 집합이 포함되어 있습니다. 필터 집합은 컨테이너 또는 개체 이름 내에서 개체의 특정 집합으로 규칙 작업을 제한합니다. 작업 집합은 계층을 적용하거나 필터링된 개체 집합에 대한 작업을 삭제합니다.

샘플 규칙

다음 샘플 규칙은 계정을 필터링하여 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"
          ]
        }
      }
    }
  ]
}

규칙 필터

필터는 규칙 작업을 스토리지 계정 내의 BLOB 작업 하위 집합으로 제한합니다. 둘 이상의 필터를 정의하는 경우 논리적 AND가 모든 필터에서 실행됩니다. 필터를 사용하여 포함할 Blob을 지정할 수 있습니다. 필터는 제외할 Blob을 지정할 방법을 제공하지 않습니다.

필터에는 다음이 포함됩니다.

알려진 문제 및 제한 사항과 함께 Blob 인덱스 기능에 대한 자세한 내용은 Blob 인덱스를 사용하여 Azure Blob Storage에서 데이터 관리 및 찾기를 참조하세요.

규칙 작업

실행 조건이 충족되면 필터링된 Blob에 작업이 적용됩니다.

수명 주기 관리는 현재 버전, 이전 버전 및 Blob 스냅샷의 계층화 및 삭제를 지원합니다. 각 규칙에 대해 하나 이상의 작업을 정의합니다.

¹enableAutoTierToHotFromCool 작업은 daysAfterLastAccessTimeGreaterThan 조건과 함께 사용할 때만 사용할 수 있습니다. 해당 조건은 다음 표에 설명되어 있습니다.

² 계층 구조 네임스페이스가 사용하도록 설정된 계정에 적용하면 delete 작업에서 빈 디렉터리를 제거합니다. 디렉터리가 비어 있지 않으면 delete 작업에서 처음 수명 주기 정책 실행 주기 내에 정책 조건을 충족하는 개체를 제거합니다. 해당 작업으로 인해 정책 조건도 충족하는 빈 디렉터리가 생성되면 해당 디렉터리는 다음 실행 주기 내에 제거됩니다.

³ 수명 주기 관리 정책은 해당 Blob과 연결된 이전 버전 또는 스냅샷이 삭제될 때까지 Blob의 현재 버전을 삭제하지 않습니다. 스토리지 계정의 Blob에 이전 버전 또는 스냅샷이 있는 경우, 삭제 작업을 정책의 일부로 지정할 때 이전 버전과 스냅샷을 포함해야 합니다.

⁴ LRS, GRS, RA-GRS용으로 구성된 스토리지 계정만 보관 계층으로 Blob 이동을 지원합니다. 보관 계층은 ZRS, GZRS, RA-GZRS 계정에 대해 지원되지 않습니다. 이 작업은 계정에 대해 구성된 중복성에 따라 나열됩니다.

실행 조건은 보존 기간을 기준으로 합니다. 현재 버전은 마지막 수정 시간 또는 마지막 액세스 시간을 사용하고, 이전 버전은 버전 생성 시간을 사용하고, Blob 스냅샷은 스냅샷 생성 시간을 사용하여 보존 기간을 추적합니다.

¹ 만약 마지막 액세스 시간 추적을 사용하도록 설정하지 않으면 daysAfterLastAccessTimeGreaterThan은 Blob의 LastAccessTime 속성 대신 수명 주기 정책이 사용하도록 설정된 날짜를 사용합니다. 이 날짜는 LastAccessTime 속성이 null 값인 경우에도 사용됩니다. 마지막 액세스 시간 추적을 사용하는 방법에 대한 자세한 내용은 마지막 액세스 시간을 기준으로 데이터 이동을 참조하세요.

수명 주기 정책 실행

수명 주기 정책의 규칙을 추가하거나 편집할 때 변경 내용이 적용되고 첫 번째 실행이 시작되는 데 최대 24시간이 걸릴 수 있습니다.

활성 정책은 개체를 지속적으로 처리하며 정책이 변경되면 중단됩니다. 규칙을 편집, 삭제 또는 사용하지 않도록 설정하면 해당 정책의 실행이 15분 이내에 종료되고 업데이트된 규칙으로 24시간 이내에 다시 시작됩니다. 정책의 모든 규칙을 사용하지 않도록 설정하거나 삭제하면 정책이 비활성 상태가 되고 새 실행이 예약되지 않습니다.

실행이 완료되는 데 필요한 시간은 평가되고 작동하는 Blob의 수에 따라 달라집니다. 스토리지 계정에 대한 요청 속도가 스토리지 계정 제한에 가까워지면 Blob이 평가되고 작동하는 대기 시간이 더 길어질 수 있습니다. 정책 실행의 요청을 포함하여 스토리지 계정에 대한 모든 요청은 초당 요청에 대해 동일한 한도까지 누적되며, 해당 제한이 접근함에 따라 워크로드에서 수행한 요청에 우선 순위가 지정됩니다. 계정 제한을 늘리려면 Azure 지원에 문의하세요.

기본 확장 제한을 보려면 다음 문서를 참조하세요.

• Blob 스토리지의 확장성 및 성능 목표
• 표준 스토리지 계정의 확장성 및 성능 목표
• 프리미엄 블록 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 이벤트의 스키마가 설명되어 있습니다.

수명 주기 정책 예

다음 예는 수명 주기 정책 규칙을 사용하여 일반 시나리오를 해결하는 방법을 보여줍니다.

오래된 데이터를 쿨 저장소 계층으로 이동

이 예제는 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이 쿨로 계층화된 후 다시 액세스되는 경우 자동으로 쿨에서 다시 핫으로 계층화되어야 하는지 여부를 나타내는 부울 값입니다.

{
  "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
              }
          }
        }
      }
    }
  ]
}

보존 기간에 따라 데이터 만료

일부 데이터는 생성되고 며칠 또는 몇 달 후에 만료될 것으로 예상됩니다. 데이터 보존 기간에 따라 삭제하여 데이터를 만료하도록 수명 주기 관리 정책을 구성할 수 있습니다. 다음 예는 지난 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를 참조하세요.

다음 단계

• 수명 주기 관리 정책 구성
• Blob 데이터에 대한 핫, 쿨 및 보관 액세스 계층
• Blob 인덱스를 사용하여 Azure Blob Storage에서 데이터 관리 및 찾기
• Blob 액세스 계층을 사용하는 모범 사례