객체 수명 주기 관리

예시로 이동

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

소개

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

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

수명 주기 구성

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

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

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

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

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

수명 주기 작업

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

  • 삭제: 객체를 삭제합니다.

    예외: 객체 버전 관리가 사용 설정된 버킷에서 서비스 중인 객체 버전을 삭제하면 이전 버전이 생성되지만, 이전 버전을 삭제하면 해당 버전이 완전히 삭제됩니다.

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

수명 주기 조건

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

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

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

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

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

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

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

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

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

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

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

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

객체 수명 주기 동작

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

    예를 들어 객체가 삭제 조건을 충족하더라도 곧바로 삭제되지는 않을 수 있습니다. 따라서 객체에 수명 주기 작업을 실행할 때까지 해당 객체가 보입니다. 객체가 존재하는 동안 적용 가능한 요금이 적용되지만 한 가지 예외가 있습니다. age 조건만 있는 규칙으로 인해 객체가 Delete 작업의 대상이 되는 경우 저장 데이터 스토리지 비용은 면제됩니다.

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

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

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

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

조기 삭제 동작

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

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

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

만료 시간 메타데이터

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

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

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

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

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

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

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

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

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

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

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

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

  • 버킷에 Cloud Storage용 Cloud Pub/Sub 알림을 사용 설정합니다. 이 기능은 지정된 작업이 발생할 때 선택한 Pub/Sub 주제로 알림을 보냅니다. 이 기능은 작업을 수행한 사람을 기록하지 않습니다.

다음 단계