객체 수명 주기 관리

예시로 이동

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

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

소개

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

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

수명 주기 구성

각 수명 주기 관리 구성에는 규칙 집합이 포함되어 있습니다. 규칙을 정의할 때 작업에 대한 조건 집합을 지정할 수 있습니다. 규칙에서 여러 조건을 지정하는 경우에는 객체가 모든 조건과 일치해야 작업이 수행됩니다. 같은 작업을 포함한 여러 규칙을 지정하는 경우에는 객체가 어떤 규칙의 조건이든지 일치하기만 하면 작업이 수행됩니다. 각 규칙은 하나의 작업만 포함해야 합니다.

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

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

작업이 수행되면, 객체의 재평가를 거쳐 추가 작업이 수행됩니다.

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

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

수명 주기 작업

수명 주기 규칙은 Delete 작업 또는 SetStorageClass 작업을 지정합니다.

삭제

객체가 수명 주기 규칙에 지정된 모든 조건을 충족하면 Delete 작업이 객체를 삭제합니다.

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

SetStorageClass

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

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

원래 스토리지 클래스 새 스토리지 클래스
Durable Reduced Availability(DRA) 스토리지 Nearline Storage
Coldline Storage
Archive Storage
Multi-Regional Storage/Regional Storage1
표준 스토리지, 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는 스토리지 클래스 전환 정확도를 검증하지 않습니다. 즉, 위 표에 없는 스토리지 클래스 전환을 지정할 수 있지만, 전환은 발생하지 않습니다. 수명 주기 규칙이 나열된 스토리지 클래스 전환 중 하나를 사용하는지 확인해야 합니다.

수명 주기 조건

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

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

Age

Age 조건은 객체가 지정된 경과 기간(일수)에 도달하는 경우에 충족됩니다. 경과 기간은 객체 생성 시부터 측정됩니다. 예를 들어 객체의 생성 시간이 2019/01/10 10:00 UTC이고 Age 조건이 10일인 경우 2019/01/20 10:00 UTC 이후의 객체에 대해 조건에 충족됩니다. 객체가 생성된 후 객체 버전 관리를 통해 객체가 이전 버전으로 되는 경우에도 마찬가지입니다.

CreatedBefore

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

CustomTimeBefore

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

DaysSinceCustomTime

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

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

DaysSinceNoncurrentTime

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

IsLive

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

MatchesStorageClass

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

일반적으로 표준 스토리지 객체에 MatchesStorageClass 조건을 사용하려는 경우 다음도 포함해야 합니다.

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

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

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

NoncurrentTimeBefore

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

NumberOfNewerVersions

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

객체 수명 주기 동작

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

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

    • 객체가 원래 상태를 유지하는 동안 적용 가능한 요금이 적용되지만 한 가지 예외가 있습니다. 객체가 Delete 작업이 포함된 규칙을 따르고 규칙의 유일한 조건이 Age 조건이며 객체에서 Age 조건을 충족하면 저장 데이터 스토리지 비용이 면제됩니다.
  • 수명 주기 구성의 업데이트가 반영되기까지 최대 24시간이 걸릴 수 있습니다. 즉, 수명 주기 구성을 변경할 때 객체 수명 주기 관리가 최대 24시간 동안 여전히 이전 구성을 기준으로 작업을 수행할 수 있다는 의미입니다.

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

  • 객체에 객체 보존 조치가 적용되어 있거나 아직 충족되지 않은 보관 정책이 설정된 경우에는 객체에서 객체 수명 주기 Delete 작업이 적용되지 않습니다. 대신, 객체에 보존 조치 또는 보관 정책 제약조건이 있을 때 발생하는 모든 Delete 작업은 해당 객체에 제약조건이 더 이상 적용되지 않게 된 이후에 수행됩니다.

  • 객체 수명 주기 SetStorageClass 작업은 객체 보존 조치 또는 보관 정책의 유무에 따라 영향을 받지 않습니다.

SetStorageClass 비용 고려사항

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

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

  • 객체가 원래 Nearline Storage 또는 Coldline Storage로 설정되었더라도 스토리지 클래스 변경과 관련된 검색 수수료 또는 조기 삭제 수수료가 없습니다.

  • 원래 스토리지 클래스에 설정된 객체의 소요 시간은 새 스토리지 클래스에 적용되는 최소 저장 기간에 반영됩니다.

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

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

객체 생성 시간

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

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

만료 시간 메타데이터

만약 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 주제로 알림을 보냅니다. 이 기능은 작업을 수행한 사람을 기록하지 않습니다.

다음 단계