객체 수명 주기 관리

설정 구성 샘플

객체의 TTL(수명) 설정, 객체의 이전 버전 유지, 비용 억제를 위한 객체 스토리지 클래스 '다운그레이드'와 같은 일반 사용 사례를 지원하기 위해 Cloud Storage는 객체 수명 주기 관리 기능을 제공합니다.

이 페이지에서는 이 기능과 관련 옵션에 대해 설명합니다. 수명 주기 구성 파일의 일반 형식은 JSON 버킷 리소스 표현 또는 XML 수명 주기 구성 형식을 참조하세요.

소개

객체 수명 주기 관리를 사용하려면 버킷에 설정해야 하는 수명 주기 구성을 정의합니다. 버킷에서 현재 및 미래의 객체에 적용되는 규칙 집합이 구성에 포함되어 있습니다. 객체가 한 규칙의 조건에 맞으면 Cloud Storage가 객체에서 지정된 작업을 자동으로 수행합니다. 몇 가지 사용 사례는 다음과 같습니다.

  • 365일이 지난 객체의 스토리지 클래스를 Coldline Storage로 다운그레이드합니다.
  • 2019년 1월 1일 이전에 생성된 객체를 삭제합니다.
  • 버전 관리가 사용 설정된 상태에서 버킷 내 각 객체에 대해 가장 최근의 3개 버전만 유지합니다.

수명 주기 구성

각 수명 주기 관리 구성에는 규칙 집합이 포함되어 있습니다. 각 규칙에는 하나의 작업과 하나 이상의 조건이 포함되어 있습니다.

  • 규칙의 작업을 수행하려면 객체가 규칙에 지정된 모든 조건과 일치해야 합니다.

  • 같은 작업이 포함된 여러 규칙을 지정하면 객체가 어떤 규칙의 조건이든 일치하기만 하면 객체에서 작업이 수행됩니다.

  • 여러 규칙의 조건이 단일 객체에 대해 동시에 충족되는 경우 Cloud Storage는 다음 고려사항에 따라 오직 하나의 규칙과 관련된 작업을 수행합니다.

    • Delete 작업이 모든 SetStorageClass 작업에 우선합니다.
    • 객체를 가장 저렴한 저장 데이터 가격이 책정된 스토리지 클래스로 전환하는 SetStorageClass 작업이 우선합니다.

    예를 들어 객체의 클래스를 Nearline Storage로 변경하는 규칙과 객체의 클래스를 Coldline Storage로 변경하는 또 다른 규칙이 있는데, 이 두 규칙 모두가 똑같은 조건을 사용하는 경우에는 조건이 충족될 때 항상 객체의 클래스가 Coldline Storage로 변경됩니다.

  • 규칙에 따라 의도치 않은 조건 집합으로 작업이 수행되지 않도록 프로덕션에 적용하기 전 개발 데이터에 대해 수명 주기 규칙을 테스트해야 합니다. 이렇게 할 수 없으면 규칙에 matchesPrefix 또는 matchesSuffix 조건을 사용해서 프로덕션 데이터 중 일부 하위 집합으로 테스트해야 합니다.

  • 버킷의 수명 주기 구성 변경사항은 적용되는 데 최대 24시간까지 걸릴 수 있습니다. 객체 수명 주기 관리는 이 시간 동안 이전 구성에 따라 작업을 수행할 수 있습니다.

    예를 들어 age 조건을 10일에서 20일로 변경하면 최대 24시간까지는 이전 구성을 기준으로 인해 11일 된 객체가 객체 수명 주기 관리에 의해 삭제될 수 있습니다.

사용 사례는 객체 수명 주기 관리의 구성 예시를 참조하세요.

수명 주기 작업

수명 주기 규칙은 정확히 다음 작업 중 하나를 지정합니다.

삭제

객체가 수명 주기 규칙에 지정된 모든 조건을 충족하면 Delete 작업이 객체를 삭제합니다. 기본적으로 라이브 객체를 삭제하면 소프트 삭제되고 Cloud Storage에서 7일 동안 보존합니다. 소프트 삭제 보관 기간 내에 소프트 삭제된 객체를 복원할 수 있습니다.

예외: 객체 버전 관리가 사용 설정된 버킷에서 객체의 라이브 버전을 삭제하면 현재 외 버전이 되고 현재 외 버전을 삭제하면 버킷에서 해당 버전이 삭제됩니다. 객체 버전 관리와 함께 Delete 작업을 사용하는 예시는 객체 삭제 구성을 참조하세요.

객체에 객체 보존 조치가 적용되어 있거나 아직 충족되지 않은 보관 정책이 설정된 경우에는 객체에 Delete 작업이 적용되지 않습니다. 객체에 대해 Delete 작업의 조건이 충족된 상태로 유지되는 한 객체 보관 조치를 삭제하고 보관 정책이 충족된 후 Delete 작업이 수행됩니다.

SetStorageClass

SetStorageClass 작업은 객체가 수명 주기 규칙에 지정된 모든 조건을 충족할 때 객체의 스토리지 클래스를 변경하고 객체의 수정 시간을 업데이트합니다.

SetStorageClass는 다음 스토리지 클래스 전환을 지원합니다.

원래 스토리지 클래스 새 스토리지 클래스
Durable Reduced Availability(DRA) 스토리지 Nearline Storage
Coldline Storage
Archive Storage
Multi-Regional Storage/Regional Storage1
Standard Storage, Multi-Regional Storage 또는 Regional Storage Nearline Storage
Coldline Storage
Archive Storage
Nearline Storage Coldline Storage
Archive Storage
Coldline Storage Archive Storage

1 리전에 있는 버킷의 경우 새 스토리지 클래스는 Multi-Regional Storage가 될 수 없습니다. 멀티 리전 또는 이중 리전의 버킷의 경우 새 스토리지 클래스는 Regional Storage가 될 수 없습니다.

Cloud Storage는 스토리지 클래스 전환 정확도를 검증하지 않습니다. 즉, 위 표에 없는 스토리지 클래스 전환을 지정할 수 있지만, 전환은 발생하지 않습니다. 수명 주기 규칙이 나열된 스토리지 클래스 전환 중 하나를 사용하는지 확인해야 합니다.

미완료 멀티파트 업로드 중단

AbortIncompleteMultipartUpload 작업은 미완료 멀티파트 업로드를 중단하고 멀티파트 업로드가 수명 주기 규칙에 지정된 조건을 충족할 때 연관된 부분을 삭제합니다.

다음 수명 주기 조건만 이 작업에 사용할 수 있습니다.

다른 조건과 함께 AbortIncompleteMultipartUpload 작업을 사용하는 규칙을 만들려고 시도하면 오류가 발생합니다.

수명 주기 조건

수명 주기 규칙에는 규칙에 정의된 작업이 객체에서 발생하기 전에 객체가 충족해야 하는 조건이 포함됩니다. 수명 주기 규칙은 다음 조건을 지원합니다.

모든 조건은 선택사항이지만 적어도 하나의 조건은 필요합니다. 존재하지 않는 작업이나 조건을 사용하는 등 잘못된 수명 주기 구성을 설정하려고 하면 400 Bad request 오류 응답이 나타나고 기존 수명 주기 구성이 그대로 유지됩니다.

age

age 조건은 리소스가 지정된 경과 기간(일수)에 도달하는 경우에 충족됩니다. 경과 기간은 리소스 생성 시부터 측정됩니다.

  • 객체의 경우 생성 시간은 업로드가 완료될 때와 같이 객체가 버킷에 성공적으로 기록된 시간입니다.

    • 객체 사용 기간은 현재 외 버전이 되는 객체의 영향을 받지 않습니다.

  • 멀티파트 업로드의 경우 생성 시간은 업로드가 시작된 시간입니다.

예를 들어 리소스가 2022/01/10 10:00 UTC에 생성되었고 age 조건이 10일이면 2022/01/20 10:00 UTC 이후의 리소스에 대해 조건이 충족됩니다.

createdBefore

createdBefore 조건은 객체가 UTC 기준으로 지정된 날짜의 자정 이전에 생성된 경우에 충족됩니다.

customTimeBefore

객체 Custom-Time 메타데이터의 날짜 부분이 이 조건에 지정된 날짜보다 이전이면 customTimeBefore 조건이 충족됩니다. 이 조건은 YYYY-MM-DD 날짜 형식을 사용하여 설정됩니다. customTimeBefore는 Custom-Time 메타데이터가 설정되지 않은 객체에 충족되지 않습니다.

daysSinceCustomTime

객체의 Custom-Time 메타데이터 필드에 날짜 및 시간이 지정된 이후 특정 일수가 경과하면 daysSinceCustomTime 조건이 충족됩니다. 예를 들어 객체의 Custom-Time이 2020-05-16T10:00:00Z이고 daysSinceCustomTime 조건이 10일인 경우 해당 조건은 2020/05/26 10:00 UTC부터 객체에 충족됩니다.

daysSinceCustomTime는 Custom-Time 메타데이터가 설정되지 않은 객체에 충족되지 않습니다.

daysSinceNoncurrentTime

daysSinceNoncurrentTime 조건은 일반적으로 객체 버전 관리와 관련해서만 사용됩니다. 라이브 버전이 삭제되거나 대체되어 객체가 이전 버전 상태가 된 후 지정된 기간(일)이 경과하면 조건이 충족됩니다. 예를 들어 객체가 2020/07/08 15:00 UTC에 이전 버전 상태가 되고 daysSinceNoncurrentTime 조건이 10일인 경우에는 2020/07/18 15:00 UTC부터 객체에 대한 조건이 충족됩니다.

isLive

isLive 조건은 일반적으로 객체 버전 관리와 관련해서만 사용됩니다. false로 설정하면 객체의 모든 이전 버전에서 이 조건이 충족됩니다. true로 설정하면 서비스 중인 객체 버전에서 이 조건이 충족됩니다. 버전 관리를 사용하지 않는 경우 isLive가 true일 때 모든 객체가 서비스 중인 버전으로 간주됩니다.

matchesPrefix 및 matchesSuffix

matchesPrefix 및 matchesSuffix 조건은 객체 이름의 시작 또는 끝이 지정된 프리픽스 또는 서픽스와 정확하게 일치(대소문자 구분)할 때 충족됩니다. 여러 문자열은 목록으로 지정할 수 있습니다(예: "matchesSuffix": [".jpg", ".png"]).

matchesPrefix를 사용할 때는 대부분의 요청 경로에서 객체 이름 앞에 나오는 버킷 이름 또는 /를 포함하지 마세요. 예를 들어 Google Cloud CLI에서 my_bucket이라는 버킷의 객체 경로는 gs://my_bucket/pictures/paris_2022.jpg와 유사한 형식입니다. 객체를 일치시키려면 "matchesPrefix":["pictures/paris_"]와 같은 조건을 사용합니다.

모든 규칙에서 최대 50개의 프리픽스와 50개의 서픽스를 지정할 수 있습니다. 단일 조건에서는 프리픽스나 서픽스를 두 번 사용할 수 없습니다.

matchesStorageClass

matchesStorageClass 조건은 버킷의 객체가 지정된 스토리지 클래스로 저장된 경우에 충족됩니다. matchesStorageClass에 대해 STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL, DURABLE_REDUCED_AVAILABILITY 값을 사용할 수 있습니다.

일반적으로 Standard Storage 객체에 matchesStorageClass 조건을 사용하려는 경우 다음도 포함해야 합니다.

  • 버킷이 리전에 있는 경우 조건에 REGIONAL 및 DURABLE_REDUCED_AVAILABILITY를 포함하세요.

  • 버킷이 멀티 리전 또는 이중 리전에 있는 경우 조건에 MULTI_REGIONAL 및 DURABLE_REDUCED_AVAILABILITY를 포함하세요.

이러한 추가 클래스를 포함하면 기존 스토리지 클래스로 설정될 수 있는 버킷의 이전 객체도 수명 주기 규칙에 포함됩니다.

noncurrentTimeBefore

noncurrentTimeBefore 조건은 일반적으로 객체 버전 관리와 관련해서만 사용됩니다. 조건에 지정된 날짜 이전에 이전 버전 상태가 된 객체에 대한 조건이 충족됩니다. 이 조건은 YYYY-MM-DD 날짜 형식을 사용하여 설정됩니다. noncurrentTimeBefore는 라이브 객체 조건을 만족하지 않습니다.

numNewerVersions

numNewerVersions 조건은 일반적으로 객체 버전 관리와 관련해서만 사용됩니다. 이 조건의 값이 N으로 설정되면, 객체 버전보다 최신인 버전이 N개 이상(서비스 중인 버전 포함) 이상인 경우 해당 객체 버전이 조건을 충족합니다. 서비스 중인 객체 버전의 경우, 최신 버전의 수는 0으로 간주됩니다. 가장 최근인 이전 버전의 경우, 최신 버전의 수는 1(서비스 중인 객체 버전이 없는 경우에는 0) 등으로 간주됩니다.

객체 수명 주기 동작

Cloud Storage는 객체 수명 주기 관리가 구성된 버킷에 있는 모든 객체를 정기적으로 검사하며, 버킷의 규칙에 따라 적용 가능한 모든 작업을 수행합니다. Cloud Storage는 작업을 비동기적으로 수행하기 때문에 조건이 충족되는 시점과 작업이 수행되는 시점 사이에 지연이 발생할 수 있습니다. 따라서 애플리케이션에서 수명 주기 조건이 충족된 후 일정 시간 내에 발생해야 하는 수명 주기 작업을 사용해서는 안 됩니다.

예를 들어 객체가 삭제 조건을 충족하더라도 객체가 즉시 삭제되지 않을 수 있으며 이 객체에서 수명 주기 작업이 실행될 때까지 객체가 표시됩니다. 객체 버전 관리가 사용 설정된 버킷에서는 객체의 현재 외 버전이 삭제 규칙 조건을 충족하더라도 라이브 객체가 일정 시간 동안 현재 외 상태로 존재합니다.

객체가 원래 상태로 유지되는 동안 적용 가능한 요금이 계속 적용되지만 한 가지 예외가 있습니다. 객체가 다음 기준을 모두 충족하면 저장 데이터 스토리지 비용이 면제됩니다.

  • 기준 1: 객체가 소프트 삭제가 중지된 버킷에 있습니다.

  • 기준 2: 객체가 Delete 작업이 있는 규칙을 따릅니다. 여기서 규칙의 유일한 조건은 충족되는 age 조건입니다.

SetStorageClass 비용 고려사항

객체의 스토리지 클래스 수동 변경과 마찬가지로 SetStorageClass 사용은 A 클래스 작업으로 계산되며 대상 스토리지 클래스에 의해 결정되는 요율에 따라 비용이 청구됩니다.

객체의 스토리지 클래스 수동 변경과 달리 SetStorageClass를 사용할 때 객체를 재작성하지 않습니다. 이를 통해 객체 수명 주기 관리는 가격 책정에 있어 다음과 같은 이점을 가집니다.

예를 들어 객체를 Nearline Storage로 업로드하고 20일 후에 수명 주기 구성이 객체의 스토리지 클래스를 Coldline Storage로 변경한다고 가정합니다. 이렇게 변경해도 검색 또는 조기 삭제 수수료가 발생하지 않습니다. Coldline Storage의 최소 저장 기간이 90일이고 객체가 총 80일간 존재했기 때문에 스토리지 클래스를 변경하고 60일 후에 객체를 삭제하면 10일 조기 삭제 요금만 부과됩니다.

반면에 객체를 Nearline Storage로 업로드하고 20일 후에 다시 쓰기를 사용하여 스토리지 클래스를 변경(다시 Coldline Storage로 변경)한다고 가정합니다. 이렇게 변경하면 검색 수수료와 10일 조기 삭제 요금이 발생합니다. 재작성하고 60일 후에 객체를 삭제하면 30일 조기 삭제 요금이 부과됩니다.

두 예시 모두에서 버킷에 소프트 삭제를 사용 설정하면 스토리지 요금이 늘어나지만 조기 삭제 요금은 소프트 삭제 보관 기간에 따라 줄어듭니다.

객체 생성 시간

대부분의 경우 객체 업로드가 시작 후 바로 완료되지만 재개 가능한 업로드와 같이 여러 요청에 걸쳐 발생하는 업로드의 경우 초기 업로드 요청이 전송된 후 마지막 업로드 요청이 전송될 때까지 며칠이 걸릴 수 있습니다. 이러한 경우 다음 사항에 유의하세요.

  • 객체에는 업로드가 완료될 때까지 수명 주기 규칙이 적용되지 않습니다.
  • 객체의 생성 시간은 업로드가 완료된 시점을 기준으로 합니다. 이는 age 및 createdBefore 수명 주기 조건에 영향을 미칩니다.
  • 객체의 Custom-Time을 설정하면 업로드 시작 부분에서 설정합니다. 요청 시간을 기준으로 Custom-Time을 설정하면 Custom-Time이 객체 생성 시간보다 훨씬 이전일 수 있습니다. 이는 customTimeBefore 및 daysSinceCustomTime 수명 주기 조건에 영향을 미칩니다.

만료 시간 메타데이터

만약 Delete 작업이 버킷에 대해 age 조건으로 지정되어 있으며 matchesStorageClass 외에 다른 조건이 없는 경우 일부 객체에 만료 시간 메타데이터가 태그 지정될 수 있습니다. 객체의 만료 시간은 객체 수명 주기 관리를 통해 객체를 삭제할 수 있게 되는(또는 삭제할 수 있게 된) 시점을 나타냅니다. 만료 시간은 버킷의 수명 주기 구성 또는 보관 정책이 변경됨에 따라 변경될 수 있습니다.

만료 시간 메타데이터가 없는 경우 이는 객체가 삭제되지 않는다는 것을 의미하는 것이 아니라, 삭제 여부 또는 삭제 시점을 결정하기 위한 정보가 충분하지 않다는 것을 의미합니다. 예를 들어 객체 생성 시간이 2020/01/10 10:00 UTC이고 age 조건이 10일로 설정된 경우 객체 만료 시간은 2020/01/20 10:00 UTC입니다. 그러나 다음과 같은 경우 객체의 만료 시간을 확인할 수 없습니다.

  • matchesStorageClass를 제외하고 Delete 규칙에 다른 조건이 지정되어 있습니다.

  • 객체의 스토리지 클래스를 포함하지 않는 matchesStorageClass 조건을 사용합니다.

  • 객체에 보존 조치가 적용된 경우. 이는 Cloud Storage에서 보존 조치가 삭제되는 시점을 알 수 없기 때문입니다.

  • 버킷에 소프트 삭제가 사용 설정되었습니다.

객체가 즉시 삭제되지 않더라도 객체 만료 시간 이후에는 저장 요금이 부과되지 않습니다. 삭제 전까지는 객체에 계속 액세스할 수 있지만 이때 요청 및 네트워크 대역폭 요금과 같은 기타 요금은 부과됩니다. 객체에 대한 만료 시간이 제공되지 않는 경우에는 객체가 삭제될 때까지 저장 비용이 청구됩니다.

만료 시간에 대한 작업을 수행할 때는 다음 사항을 고려하세요.

  • 버킷에 보관 정책이 설정된 경우 만료 시간은 객체 수명 주기 관리의 age 조건과 객체가 보관 정책에 지정된 보관 기간을 충족하는 시점 중 더 늦은 시점입니다.

  • 서로 다른 수명 주기 관리 규칙으로 인해 여러 개의 만료 시간이 객체에 적용되어 충돌할 경우에는 적용 가능한 가장 이른 만료 시간이 사용됩니다.

수명 주기 작업을 추적하기 위한 옵션

Cloud Storage가 수행하는 수명 주기 관리 작업을 추적하려면 다음 옵션 중 하나를 사용하세요.

  • Cloud Storage 사용량 로그를 사용합니다. 이 기능은 작업과 작업을 수행한 사람을 기록합니다. 로그 항목의 cs_user_agent 필드에 GCS Lifecycle Management 값이 있으면 수명 주기 구성에 따라 Cloud Storage가 작업을 수행했음을 나타냅니다.
  • 버킷에 Cloud Storage용 Cloud Pub/Sub 알림을 사용 설정합니다. 이 기능은 지정된 작업이 발생할 때 선택한 Pub/Sub 주제로 알림을 보냅니다. 이 기능은 작업을 수행한 사람을 기록하지 않습니다.

다음 단계