객체 수명 주기 관리

객체의 TTL(수명) 설정, 이전 버전의 객체 보관, 비용 억제를 위한 객체 저장소 등급 "다운그레이드"와 같은 일반 사용 사례를 지원하기 위해 Cloud Storage는 객체 수명 주기 관리 기능을 제공합니다. 이 페이지에서는 이 기능에 대해 그리고 이 기능을 사용할 때 가능한 옵션에 대해 설명합니다. 객체 수명 주기 관리를 활성화하는 방법과 수명 주기 정책의 예를 보려면 수명 주기 관리를 참조하세요.

소개

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

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

수명 주기 구성

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

단일 객체에 여러 작업이 적용되는 경우 Cloud Storage는 한 작업만 수행하고, 객체를 재평가한 후에 추가적인 작업을 수행합니다. Delete 작업이 SetStorageClass 작업보다 우선입니다. 여러 개의 SetStorageClass 작업이 지정된 경우에는 저장소 등급을 가장 낮은 미사용 저장소 가격으로 전환하는 작업이 선택됩니다.

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

수명 주기 작업

수명 주기 규칙에 다음의 작업이 지원됩니다.

  • Delete: 실시간 객체나 보관처리된 객체를 삭제합니다. 실시간 객체는 보관처리된 세대가 아닌 객체입니다. 자세한 내용은 객체 버전 관리를 참조하세요. 이 작업은 버전이 관리되는 객체와 버전이 관리되지 않는 객체 모두에 적용될 수 있습니다. 버전 관리가 사용 설정된 버킷에서 실시간 객체를 삭제하면 객체가 보관처리되지만, 보관처리된 객체를 삭제하면 객체가 영구적으로 삭제됩니다.

  • SetStorageClass: 실시간 객체나 보관처리된 객체의 스토리지 클래스를 변경합니다. 이 작업은 버전이 관리되는 객체와 버전이 관리되지 않는 객체 모두에 적용될 수 있습니다. 이 작업은 다음과 같은 저장소 등급 전환을 지원합니다.

    원래 저장소 등급 새 저장소 등급
    Multi-Regional Storage Nearline Storage
    Coldline Storage
    Regional Storage Nearline Storage
    Coldline Storage
    Nearline Storage Coldline Storage

수명 주기 조건

수명 주기 규칙에 대해 다음의 조건이 지원됩니다.

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

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

  • IsLive: 이 수명 주기 조건의 경우 값이 true이면 실시간 객체만 조건을 충족하고, 값이 false이면 보관처리된 객체만 조건을 충족합니다. 이 조건에서 버전이 관리되지 않는 버킷에 있는 객체는 실시간 객체로 간주됩니다.

  • MatchesStorageClass: 이 조건은 버킷의 객체가 지정된 저장소 등급으로 저장된 경우에 충족됩니다. 일반적으로 Multi-Regional Storage 또는 Regional Storage 객체에 이 조건을 사용하려면 비슷한 스토리지 클래스의 모든 객체가 포함되도록 조건에 STANDARDDURABLE_REDUCED_AVAILABILITY도 포함시켜야 합니다.

  • NumberOfNewerVersions: 버전이 관리되는 객체에만 해당됩니다. 이 조건의 값이 N으로 설정되어 있으면 해당 객체보다 더 최신인 버전이 N개 이상일 때(실시간 버전 포함) 조건이 충족됩니다. 실시간 객체의 경우에는 최신 버전의 수가 0으로 간주됩니다. 가장 최근에 보관처리된 버전의 경우에는 최신 버전의 수가 1이 되는 식입니다(실시간 객체가 없는 경우에는 0).

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

수명 주기 구성의 사용 예는 객체 수명 주기 관리를 참조하세요. 수명 주기 구성 파일의 일반 형식은 JSON 버킷 리소스 표현 또는 XML 수명 주기 구성 형식을 참조하세요.

객체 수명 주기 동작

  • Cloud Storage는 객체 수명 주기 관리가 구성된 버킷에 있는 모든 객체를 정기적으로 검사하며, 버킷의 규칙에 따라 적용 가능한 모든 작업을 수행합니다.

    예를 들어 객체가 삭제 조건을 충족하더라도 곧바로 삭제되지는 않을 수 있습니다. 객체에 수명 주기 작업이 실행되기 전까지는 해당 객체가 계속 보입니다. 이 경우 객체 저장 요금이 청구되지 않지만, 객체에 액세스할 경우에는 가격 책정에 설명된 대로 관련 작업 및 대역폭에 대한 요금이 부과됩니다.

  • 수명 주기 구성의 업데이트가 반영되기까지 최대 24시간이 걸릴 수 있습니다. 즉, 수명 주기 구성을 변경할 때 객체 수명 주기 관리가 최대 24시간 동안 여전히 이전 구성을 기준으로 작업을 수행할 수 있다는 의미입니다.

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

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

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

Nearline Storage 및 Coldline Storage 객체의 조기 삭제

객체 수명 주기 관리는 객체의 저장소 등급을 변경할 때 객체를 다시 작성하지 않습니다. 즉, SetStorageClass 기능을 사용하여 객체를 Nearline Storage 또는 Coldline Storage로 전환되면 후속 조기 삭제 및 관련 요금은 스토리지 클래스 변경 시점과 관계없이 객체가 처음 생성된 시점을 기준으로 합니다.

예를 들어 객체를 Regional Storage로 업로드하고 20일 후에 수명 주기 구성이 객체의 저장소 등급을 Nearline Storage로 변경한다고 가정합니다. 그리고 객체를 즉시 삭제하는 경우에는 객체가 20일 동안 존재했기 때문에 10일 조기 삭제 비용이 발생합니다. 저장소 등급을 Nearline Storage로 변경하고 10일 후에 객체를 삭제하는 경우에는 객체가 30일 동안 존재했기 때문에 조기 삭제 비용이 발생하지 않습니다.

반면에 객체를 Regional Storage로 업로드하고 20일 후에 다시 쓰기를 사용하여 저장소 등급을 변경(Nearline Storage로 다시 변경)한다고 가정합니다. 그리고 곧바로 객체를 삭제하면 다시 쓴 시간이 새로운 생성 시간이 되기 때문에 30일 조기 삭제 비용이 온전히 발생합니다. 마찬가지로, 다시 쓰고 10일 기다린 후에 객체를 삭제하면 20일 조기 삭제 비용이 발생합니다.

만료 시간 메타데이터

Age 조건이 설정되고 NumberOfNewerVersions 조건은 설정되지 않은 버킷에 대해 Delete 작업이 지정된 경우에는 만료 시간 메타데이터를 사용하여 일부 객체를 태그할 수 있습니다. 객체의 만료 시간은 객체 수명 주기 관리를 통해 객체를 삭제할 수 있게 되는(또는 삭제할 수 있게 된) 시점을 나타냅니다. 만료 시간은 버킷의 수명 주기 구성 또는 보관 정책이 변경됨에 따라 변경될 수 있습니다.

만료 시간 메타데이터가 없는 경우 이는 객체가 삭제되지 않는다는 것을 의미하는 것이 아니라, 삭제 여부 또는 삭제 시점을 결정하기 위한 정보가 충분하지 않다는 것을 의미합니다. 예를 들어 객체 생성 시간이 2013/01/10 10:00 UTC이고 Age 조건이 10일로 설정되어 있으면 객체 만료 시간이 2013/01/20 10:00 UTC입니다. 하지만 다음과 같은 경우에는 객체에 대한 만료 시간이 제공되지 않습니다.

  • NumberOfNewerVersions 조건도 지정된 경우. 이 경우 새 버전이 추가되는 경우에도 오래된 버전의 객체가 삭제될 수 있습니다.

  • CreatedBefore 조건도 지정되어 있고 조건 값이 '2013-01-01'로 설정된 경우. 이는 객체가 이 조건을 충족하지 않기 때문입니다.

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

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

만료 시간이 제공되는 경우 메타데이터에서 객체의 만료 시간에 액세스할 수 있습니다. REST API는 x-goog-expiration 응답 헤더에서 객체의 만료 시간을 반환합니다.

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

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

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

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

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

  • Cloud Storage 액세스 로그를 사용합니다. 이 기능은 작업과 작업을 수행한 사람을 기록합니다. 로그 항목의 cs_user_agent 필드에 GCS Lifecycle Management 값이 있으면 수명 주기 구성에 따라 Cloud Storage가 작업을 수행했음을 나타냅니다.

  • 버킷에 Cloud Storage용 Cloud Pub/Sub 알림을 사용 설정합니다. 이 기능은 지정된 작업이 수행될 경우에 선택된 Cloud Pub/Sub 항목으로 알림을 보냅니다. 이 기능은 작업을 수행한 사람을 기록하지 않습니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.