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

데이터 집합에는 고유한 수명 주기가 있습니다. 수명 주기 초기에는 사람들이 일부 데이터에 자주 액세스합니다 하지만 액세스 필요성은 데이터가 오래될 수록 크게 줄어듭니다. 어떤 데이터는 클라우드에서 유휴 상태로 유지되고 저장된 후에는 어쩌다 한 번씩 액세스됩니다. 어떤 데이터 세트는 생성된 후 며칠 또는 몇 달 만에 만료되고 또 어떤 데이터 세트는 수명 주기 내내 적극적으로 읽히고 수정됩니다. Azure Storage 수명 주기 관리는 Blob 데이터를 적절한 액세스 계층으로 전환하거나 수명 주기가 끝나면 데이터를 만료하는 데 사용할 수 있는 규칙 기반 정책을 제공하는 경우가 많습니다.

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

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

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

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

중요

데이터 세트를 읽을 수 있어야 하는 경우에는 Blob을 보관 계층으로 이동하는 정책을 설정하지 마십시오. 보관 계층의 Blob이 처음에 리하이드레이션되지 않는 한 이 Blob을 읽을 수 없으며 이 프로세스는 시간과 비용이 많이 소모될 수 있습니다. 자세한 내용은 보관 계층의 Blob 리하이드레이션 개요를 참조하세요.

수명 주기 관리 정책 정의

수명 주기 관리 정책은 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
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

참고

수명 주기 관리 정책의 baseBlob 요소는 Blob의 현재 버전을 나타냅니다. version 요소는 이전 버전을 나타냅니다.

규칙 필터

필터는 규칙 작업을 스토리지 계정 내의 BLOB 작업 하위 집합으로 제한합니다. 둘 이상의 필터를 정의하는 경우 논리적 AND가 모든 필터에서 실행됩니다.

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

필터 이름 필터 형식 참고 필수 여부
blobTypes 미리 정의된 열거형 값의 배열입니다. 현재 릴리스에서는 blockBlobappendBlob을 지원합니다. appendBlob에는 삭제만 지원되며 계층 설정은 지원되지 않습니다.
prefixMatch 일치시킬 접두사에 대한 문자열 배열입니다. 각 규칙은 대/소문자를 구분하는 접두사를 최대 10개까지 정의할 수 있습니다. 접두사 문자열은 컨테이너 이름으로 시작해야 합니다. 예를 들어 규칙에 대해 https://myaccount.blob.core.windows.net/sample-container/blob1/... 아래의 모든 Blob을 일치시키려는 경우 prefixMatch는 sample-container/blob1입니다. 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 스냅샷의 계층화 및 삭제를 지원합니다. 각 규칙에 대해 하나 이상의 작업을 정의합니다.

작업 현재 버전 스냅샷 이전 버전
tierToCool blockBlob에 지원됨 지원됨 지원됨
enableAutoTierToHotFromCool blockBlob에 지원됨 지원되지 않음 지원되지 않음
tierToArchive blockBlob에 지원됨 지원됨 지원됨
delete1 blockBlobappendBlob에 대해 지원됨 지원됨 지원됨

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

참고

동일한 Blob에 작업을 두 개 이상 정의하는 경우 수명 주기 관리는 가장 저렴한 작업을 Blob에 적용합니다. 예를 들어 delete 작업은 tierToArchive 작업보다 저렴합니다. tierToArchive 작업은 tierToCool 작업보다 저렴합니다.

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

작업 실행 조건 조건 값 Description
daysAfterModificationGreaterThan 일 단위로 보존 기간을 나타내는 정수 값 Blob의 현재 버전에 대한 작업 조건
daysAfterCreationGreaterThan 일 단위로 보존 기간을 나타내는 정수 값 Blob 또는 Blob 스냅샷의 이전 버전에 대한 작업 조건
daysAfterLastAccessTimeGreaterThan 일 단위로 보존 기간을 나타내는 정수 값 액세스 추적이 사용하도록 설정된 경우 현재 버전의 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 태그 가져오기는 액세스 작업이 아니므로 마지막 액세스 시간을 업데이트하지 않습니다.

읽기 액세스 대기 시간에 대한 영향을 최소화하기 위해 최근 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 }
          }
        }
      }
    }
  ]
}

참고

효율성을 높이기 위해 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"
          ]
        }
      }
    }
  ]
}

기능 지원

이 기능에 대한 지원은 Data Lake Storage Gen2, NFS(네트워크 파일 시스템) 3.0 프로토콜 또는 SSH SFTP(파일 전송 프로토콜)를 사용하도록 설정하면 영향을 받을 수 있습니다.

이러한 기능을 사용하도록 설정한 경우 Azure Storage 계정의 Blob Storage 기능 지원을 참조하여 이 기능에 대한 지원을 평가합니다.

지역별 가용성 및 가격 책정

수명 주기 관리 기능은 모든 Azure 지역에서 사용할 수 있습니다.

수명 주기 관리 정책은 무료입니다. Blob 계층 설정 API 호출에 대한 표준 작업 비용이 고객에게 청구됩니다. 삭제 작업은 무료입니다. 그러나 Microsoft Defender for Storage와 같은 기타 Azure 서비스 및 유틸리티는 수명 주기 정책을 통해 관리되는 작업에 대해 요금을 부과할 수 있습니다.

Blob의 마지막 액세스 시간에 대한 각 업데이트 비용은 기타 작업 범주에서 청구됩니다.

가격 책정에 대한 자세한 내용은 블록 Blob 가격을 참조하세요.

FAQ

새로운 정책을 만들었습니다. 작업이 즉시 실행되지 않는 이유는 무엇인가요?

플랫폼은 하루에 한 번 수명 주기 정책을 실행합니다. 정책을 구성한 후 일부 작업을 처음 실행하는 데 최대 24시간이 걸릴 수 있습니다.

기존 정책을 업데이트하는 경우 작업이 실행되는 데 얼마나 걸리나요?

업데이트된 정책은 적용되는 데 최대 24시간이 걸립니다. 정책이 적용되면 작업이 실행되는 데 최대 24시간이 걸릴 수 있습니다. 따라서 정책 작업을 완료하는 데 최대 48시간이 걸릴 수 있습니다. 업데이트 시 규칙을 사용하지 않거나 삭제하도록 하고 enableAutoTierToHotFromCool을 사용했으면 핫 계층으로 자동 계층화가 계속 발생합니다. 예를 들어 마지막 액세스를 기준으로 enableAutoTierToHotFromCool이 포함된 규칙을 설정합니다. 규칙이 사용되지 않거나 삭제되고 Blob이 현재 쿨 상태에서 액세스되면 수명 주기 관리 외부에 액세스할 때 적용되므로 다시 핫으로 이동합니다. 수명 주기 관리 규칙이 사용되지 않거나 삭제되면 Blob이 핫에서 쿨로 이동하지 않습니다. autoTierToHotFromCool을 방지하는 유일한 방법은 마지막 액세스 시간 추적을 끄는 것입니다.

보관된 Blob을 수동으로 리하이드레이션했습니다. 일시적으로 보관 계층으로 다시 이동하지 않도록 하려면 어떻게 해야 하나요?

Blob을 한 액세스 계층에서 다른 액세스 계층으로 이동하면 마지막 수정 시간이 변경되지 않습니다. 보관된 Blob을 핫 계층으로 수동 리하이드레이션하면 수명 주기 관리 엔진에 의해 보관 계층으로 다시 이동됩니다. 이 Blob에 영향을 주는 규칙을 일시적으로 사용하지 않게 설정하여 다시 보관되지 않도록 합니다 Blob을 다시 보관 계층으로 안전하게 이동할 수 있는 경우 규칙을 다시 사용하도록 설정합니다. 핫 또는 쿨 계층에 영구적으로 유지해야 하는 경우 Blob을 다른 위치에 복사할 수도 있습니다.

Blob 접두사 일치 문자열이 예상되는 Blob에 정책을 적용하지 않았습니다.

정책의 Blob 접두사 일치 필드는 정책 작업을 적용하려는 Blob을 일치시키는 데 사용되는 전체 또는 부분 Blob 경로입니다. 경로는 컨테이너 이름으로 시작해야 합니다. 접두사 일치가 지정되지 않은 경우 정책은 스토리지 계정의 모든 Blob에 적용됩니다. 접두사 일치 문자열의 형식은 [container name]/[blob name]입니다.

접두사 일치 문자열에 대해 다음 사항에 유의합니다.

  • container1/과 같은 접두사 일치 문자열은 container1이라는 컨테이너의 모든 Blob에 적용됩니다. 후행 슬래시 문자(/)가 없는 container1의 접두어 일치 문자열은 컨테이너 이름이 문자열 container1로 시작하는 모든 컨테이너의 모든 Blob에 적용됩니다. 접두사는 이름이 container11, container1234, container1ab 등인 컨테이너와 일치합니다.
  • container1/sub1/의 접두사 일치 문자열은 sub1/ 문자열로 시작하는 container1이라는 컨테이너의 모든 Blob에 적용됩니다. 예를 들어 접두사는 container1/sub1/test.txt 또는 container1/sub1/sub2/test.txt라는 이름의 Blob과 일치합니다.
  • 별표 문자 *는 Blob 이름의 유효한 문자입니다. 별표 문자가 접두사에 사용되는 경우 접두사는 이름에 별표가 있는 Blob과 일치합니다. 별표는 와일드카드 문자로 작동하지 않습니다.
  • 물음표 문자 ?는 Blob 이름의 유효한 문자입니다. 물음표 문자가 접두사에 사용되는 경우 접두사는 이름에 물음표가 있는 Blob과 일치합니다. 물음표는 와일드카드 문자로 작동하지 않습니다.
  • 접두사 일치는 양수(=) 논리 비교만 고려합니다. 음수(!=) 논리 비교는 무시됩니다.

정책이 실행될 시간을 식별하는 방법이 있나요?

불행히도 정책이 실행되는 시간을 추적할 수 있는 방법은 없습니다. 이는 백그라운드 스케줄링 프로세스이기 때문입니다. 그러나 플랫폼은 하루에 한 번 정책을 실행합니다.

다음 단계