객체 버전 관리

삭제하거나 덮어쓴 객체를 검색할 수 있도록 Cloud Storage는 객체 버전 관리 기능을 제공합니다. 이 페이지는 이 기능 및 함께 사용할 수 있는 옵션을 설명합니다. 객체 버전 관리 사용 설정 및 사용 방법은 객체 버전 관리 사용을 참조하세요.

Cloud Storage 데이터가 덮어써지거나 실수로 삭제되지 않도록 하려면 객체 버전 관리를 사용하세요. 객체 버전 관리를 사용 설정하면 저장소 비용이 증가할 수 있지만, 오래된 객체 버전을 삭제하도록 객체 수명 주기 관리를 구성하면 비용을 다소 줄일 수 있습니다.

소개

버킷에 대한 객체 버전 관리를 사용 설정합니다. 사용 설정되면 객체의 실시간 버전을 덮어쓰거나 삭제할 때마다 Cloud Storage가 보관처리된 객체 버전을 만듭니다. 보관처리된 버전의 객체 이름은 유지되지만 세대 번호로 고유하게 식별됩니다. 모든 객체에 세대 번호가 연결되어 있지만 보관처리된 객체를 식별할 때만 세대 번호가 필요합니다.

객체 버전 관리를 사용 설정하면 객체의 보관처리된 버전을 나열하거나, 객체의 실시간 버전을 이전 상태로 복원하거나, 필요에 따라 보관처리된 버전을 영구 삭제할 수 있습니다. 언제든지 버킷의 버전 관리를 설정하거나 해제할 수 있습니다. 버전 관리를 해제하면 기존 객체 버전은 남지만 버킷이 보관처리된 새로운 객체 버전을 더 이상 축적하지 않습니다.

중요: 버킷의 버전 관리 구성을 변경하면 변경 내용이 전파되는 데 시간이 걸릴 수 있으며, 버킷 내 객체 삭제나 덮어쓰기가 잠깐 동안 이전 설정에 따라 동작할 수 있습니다. 객체 삭제와 덮어쓰기를 변경 내용에 따라 동작하게 하려면 버전 관리 구성 변경과 객체 삭제 또는 덮어쓰기 사이에 최소 30초 이상의 시간 간격을 두세요.

객체 버전 관리 세부정보

Cloud Storage는 객체 버전을 식별하는 데 2가지 속성을 사용합니다. 한 가지 속성은 객체 데이터의 버전을 식별하고, 또 다른 속성은 객체의 메타데이터 버전을 식별합니다. 이러한 속성은 객체 버전 관리 사용이 설정되지 않았어도 항상 모든 객체 버전에 존재합니다. 이러한 속성은 업데이트 순서의 강제 배열을 위한 조건부 업데이트의 전제 조건으로 사용될 수 있습니다.

Cloud Storage는 다음 속성을 사용하여 모든 객체를 표시합니다.

속성	설명
generation	콘텐츠(데이터) 세대를 식별하고 객체 콘텐츠를 덮어쓸 때 업데이트됩니다. 객체가 같은 버킷에 있더라도 관련 없는 객체의 세대 번호 사이에는 관계가 없습니다.
metageneration	메타데이터 세대를 식별하고 주어진 콘텐츠 세대의 메타데이터가 업데이트될 때마다 증가합니다. 객체의 새 generation마다 metageneration은 1로 재설정됩니다. metageneration 속성은 generation 속성 없이는 의미가 없으며 이와 연결해서만 사용되어야 합니다. 다시 말해서, 데이터 세대가 서로 다른 2가지 버전의 메타데이터 세대를 비교하는 것은 의미가 없습니다.

현재 보관 정책이 설정되어 있는 버킷에는 객체 버전 관리를 사용 설정할 수 없습니다.

주의: 기본적으로 만들 수 있는 객체 버전 수에는 제한이 없습니다. 객체의 각 보관처리된 버전에 객체의 실시간 버전과 동일한 요금이 청구됩니다. 버전 관리를 사용하는 경우, 더 새로운 버전이 보관처리됨에 따라 가장 오래된 객체 버전을 삭제할 수 있는 객체 수명 주기 관리를 사용하는 것이 좋습니다.

보관처리된 객체 메타데이터

보관처리된 객체는 자체 메타데이터를 가지며, 이는 실시간 객체의 메타데이터와 다를 수 있습니다. 가장 중요한 점은 보관처리된 버전은 ACL을 유지하며 실시간 객체 버전과 반드시 권한이 동일할 필요는 없다는 것입니다.

실시간 버전이나 보관처리된 버전에 관계없이 모든 객체에는 하나의 메타데이터 집합이 있으며, 오직 최신 메타 세대 번호만 메타데이터를 참조합니다. 이전 메타 세대 번호는 이후에 변경된 메타데이터 액세스에 사용될 수 없습니다.

요청에 generation을 지정하여 보관처리된 객체의 메타데이터를 업데이트할 수 있습니다. 안전한 읽기-수정-쓰기 시맨틱스를 보장하기 위해 메타 세대 일치 전제 조건을 사용할 수 있습니다. 메타데이터를 읽은 시점과 업데이트를 보낸 시점 간에 업데이트하려는 메타데이터가 변경된 경우, 이 전제 조건을 사용하면 업데이트에 실패합니다.

객체 버전 관리 예

이 예는 객체 버전 관리 사용이 설정된 상태에서 파일을 덮어쓰고, 업데이트하고, 삭제할 때 버킷의 cat.jpg 파일에 어떤 일이 발생하는지 보여줍니다.

새 이미지 업로드

우선 cat.jpg를 Cloud Storage에 업로드하면 generation 번호와 metageneration 번호가 수신됩니다. 이 예에서 세대 번호는 1360887697105000입니다. 객체가 새 객체이므로 metageneration 번호는 1입니다.

객체 버전 관리 사용이 설정되지 않았어도 cat.jpg는 generation 및 metageneration 번호를 받습니다. gsutil에서 ls -L 명령어를 사용하여 이 번호를 확인할 수 있습니다. 해당 안내는 객체 메타데이터 보기를 참조하세요.

객체 버전 관리 사용 설정

이 시점에서 버킷에 객체 버전 관리를 사용하기로 결정합니다. 그렇게 해도 cat.jpg의 generation 또는 metageneration 번호는 영향을 받지 않습니다.

이미지의 메타데이터 변경

color:black이라는 커스텀 메타데이터를 추가하여 cat.jpg의 메타데이터를 업데이트합니다. 메타데이터를 업데이트하면 cat.jpg의 metageneration 값이 증가합니다. 이 경우에는 1에서 2로 값이 증가합니다. 하지만 객체 자체는 변경되지 않으므로, Cloud Storage는 계속해서 한 버전의 cat.jpg만 보관하고 버전의 generation 번호도 계속해서 1360887697105000입니다.

새로운 버전의 이미지 업로드

새 버전의 cat.jpg를 Cloud Storage 버킷에 업로드합니다. 이때 객체 버전 관리가 기존 cat.jpg 객체를 보관처리 상태로 옮깁니다. 보관처리된 버전은 이전과 동일한 저장소 등급과 메타데이터를 유지합니다. 보관처리된 버전은 사용자가 버전 관리된 목록 나열을 수행하는 경우에만 나타나며, 일반적인 목록 나열 명령어로는 나타나지 않습니다. 보관처리된 버전은 이제 cat.jpg#1360887697105000으로 참조됩니다.

한편, 새로 업로드된 cat.jpg는 객체의 실시간 버전이 됩니다. 이 새로운 cat.jpg는 고유한 generation 번호를 가지며, 이 예에서는 1360887759327000입니다. 또한 새 버전은 고유 메타데이터를 가지며 metageneration 번호는 1입니다. 즉, 사용자가 지정할 때까지 color:black 메타데이터는 포함되지 않습니다. cat.jpg,에 액세스하거나 수정하는 경우 이 버전이 사용됩니다. 또는 generation 번호를 사용하여 이 cat.jpg 버전을 참조할 수 있습니다. 예를 들어, gsutil 도구를 사용하면 이를 cat.jpg#1360887759327000으로 참조합니다.

이미지의 실시간 버전 삭제

이제 cat.jpg를 삭제합니다. 이때 세대 번호가 1360887759327000이었던 버전이 보관처리됩니다. 이제 버킷에는 cat.jpg의 2가지 보관처리 버전이 있으며 실시간 버전은 없습니다. 계속해서 generation 번호를 사용하여 보관처리된 버전을 참조할 수 있지만 generation 번호 없이 cat.jpg에 액세스를 시도하면 실패합니다.

마찬가지로, 버킷의 일반적인 객체 목록 나열은 버킷의 객체 중 하나로 cat.jpg를 표시하지 않습니다. 객체의 보관처리 버전 나열에 대해서는 보관처리 객체 버전 나열을 참조하세요.

객체 버전 관리 중지

객체 버전 관리를 중지하여 이후의 객체 보관처리를 중지할 수 있습니다. 보관처리된 기존 객체 버전은 Cloud Storage에 남아 있습니다. 객체 버전 관리가 중지되더라도 cat.jpg#1360887697105000과 cat.jpg#1360887759327000은 사용자가 수동으로 또는 객체 수명 주기 관리를 사용하여 삭제할 때까지 버킷에 저장되어 있습니다.

보관처리 버전 중 1개 복원

객체 버전 관리가 중지되더라도 복사본을 만들어 보관처리된 기존 버전 중 하나를 복원할 수 있습니다. 만드는 복사본 이름을 cat.jpg로 지정하면 됩니다. 그러면 버킷에는 보관처리된 버전 2개와 복사본을 만들면서 생긴 실시간 버전 등 3가지 버전의 cat.jpg가 있습니다.

도움말

이 섹션은 객체 버전 관리를 보다 효과적으로 사용하는 데 유용한 팁을 설명합니다.

gsutil 사용

• gsutil 도구는 버전 관리된 객체로 작업 시 객체 버전 관리와 관련된 수많은 작업을 수월하게 해주는 포괄적 지원을 제공합니다. 예를 들어 객체 이름에 #과 generation 번호를 추가하여 객체의 보관처리된 버전으로 작업할 수 있습니다. 객체 버전 관리와 함께 gsutil 사용에 대한 자세한 내용은 객체 버전 관리 및 동시 실행 제어를 참조하세요.

ETag 피하기

• 조건부 업데이트에 ETag 대신 generation과 metageneration 번호를 사용하는 것이 좋습니다. generation과 metageneration 번호는 메타데이터 변경을 포함하여 모든 객체 업데이트를 추적하므로, ETag보다 강력한 보장을 제공합니다.

파일 삭제 및 복원 동작 이해

• 보관처리된 객체 버전을 현재 실시간 버전으로 복사할 수 있습니다. 보관처리된 객체를 복사하기 위한 단계별 안내는 보관처리된 객체 버전 복사를 참조하세요.

  객체 버전 관리 사용을 설정한 상태로 이 작업을 수행하는 경우, 버킷에 객체의 실시간 버전이 이미 있으면 Cloud Storage는 이를 덮어쓰지만 덮어쓴 객체의 새 보관처리 버전도 만듭니다. 이러한 경우, 이후 버킷에는 덮어쓴 객체(지금 보관처리됨)와 이전에 보관처리되었던 객체 복사본 2개(실시간 복사본 1개와 보관처리 중인 복사본 1개)가 포함되며, 이들 모두에 대한 저장 비용이 청구됩니다. 불필요한 비용이 청구되지 않도록 현재 실시간 복사본을 만들기 위해 사용했던 보관처리 버전을 삭제하세요.

• 세대를 지정하지 않고 삭제 요청을 보내면 Cloud Storage는 현재 실시간 객체를 보관처리하고 이후 버전이 인식되지 않는 요청에 이 객체가 누락된 것으로 나타나게 합니다.

• 현재 실시간 객체에 해당하는 generation과 함께 삭제 요청을 보내면 Cloud Storage는 보관처리된 복사본을 만들지 않고 객체를 삭제합니다.

• 보관처리된 객체를 삭제하면 Cloud Storage는 해당 객체 버전을 영구 삭제합니다.

객체의 실시간 버전 변형 시 세대 일치 전제 조건 사용

• 세대 번호를 사용하는 경우, 실시간 혹은 보관처리 여부에 관계없이 해당 이름과 세대 번호를 가진 객체가 있으면 요청이 성공합니다. 이러한 객체가 없으면 Cloud Storage는 404 Not Found를 반환합니다.

• 세대 일치 전제 조건을 사용하면 요청된 객체의 실시간 버전에 지정된 세대 번호가 있는 경우에만 요청이 성공합니다. 이러한 객체가 없거나 보관처리된 경우 Cloud Storage는 412 Precondition Failed를 반환합니다.

• 객체 이름에서 세대 번호와 함께 세대 일치 전제 조건을 사용하지 마세요. 2가지를 모두 사용하는데 번호가 일치하면 전제 조건 사용이 중복됩니다. 번호가 일치하지 않으면 요청이 항상 실패합니다.

• 세대 일치 전제 조건과 함께 동시 실행 변형 요청을 여러 개 제출하면 Cloud Storage의 강력한 일관성으로 인해 해당 요청 중 하나만 성공합니다. 이 기능은 객체가 여러 소스에서 업데이트되고 사용자가 객체를 우발적으로 덮어쓰지 않도록 해야 하는 경우에 유용합니다.

• 객체 업로드 시 세대 일치 전제 조건을 0으로 설정하면 Cloud Storage는 객체의 실시간 버전이 없는 경우에만 지정된 요청을 수행합니다. 예를 들어 헤더 x-goog-if-generation-match:0이 있는 새 객체를 만들기 위해 XML API로 PUT 요청을 수행하는 경우, 객체가 없거나 보관처리된 객체 버전만 있어야 요청이 성공합니다. 실시간 버전의 객체가 있으면 Cloud Storage는 412 Precondition Failed 상태 코드를 사용하여 업데이트를 취소합니다.