Amazon S3가 수명 주기 구성의 충돌을 처리하는 방법
일반적으로 Amazon S3 수명 주기는 비용을 최적화합니다. 예를 들어, 두 만료 정책이 겹치는 경우 데이터가 예상보다 오래 저장되지 않도록 더 짧은 만료 정책이 적용됩니다. 마찬가지로, 두 전환 정책이 겹치는 경우 S3 수명 주기는 객체를 더 저렴한 비용의 스토리지 클래스로 전환합니다.
두 경우 모두 S3 수명 주기는 가장 비용이 적게 드는 경로를 선택하려고 시도합니다. 이 일반 규칙의 예외는 S3 Intelligent-Tiering 스토리지 클래스입니다. S3 Intelligent-Tiering은 S3 Glacier 및 S3 Glacier Deep Archive 스토리지 클래스를 제외한 모든 스토리지 클래스보다 S3 수명 주기에서 우선 적용됩니다.
S3 수명 주기 구성에 규칙이 여러 개인 경우 객체는 같은 날에 여러 가지 S3 수명 주기 작업을 수행할 수 있습니다. 이러한 경우 Amazon S3은 다음과 같은 일반 규칙을 따릅니다.
-
영구 삭제는 전환에 우선합니다.
-
이전은 삭제 마커 생성에 우선합니다.
-
객체에서 S3 Glacier Flexible Retrieval 및 S3 Standard-IA(또는 S3 One Zone-IA) 이전을 모두 사용할 수 있는 경우 Amazon S3가 S3 Glacier Flexible Retrieval 이전을 선택합니다.
중복 필터 및 충돌하는 수명 주기 작업의 예제
S3 수명 주기 구성을 지정하여 중복 접두사 또는 작업을 지정할 수 있습니다. 다음 예에서는 Amazon S3가 어떻게 잠재적인 충돌을 해결하는지 보여줍니다.
예 1: 중복 접두사(충돌 없음)
다음에서 예로 든 구성에는 중복 접두사를 지정하는 규칙이 두 개 있습니다.
-
첫 번째 규칙은 버킷의 모든 객체를 의미하는 빈 필터를 지정합니다.
-
두 번째 규칙은 버킷에서 객체의 하위 집합만을 의미하는 키 이름 접두사(
logs/
)를 지정합니다.
규칙 1은 생성 후 1년이 지난 모든 객체를 삭제하도록 Amazon S3에 요청합니다. 규칙 2는 생성 후 30일이 지난 객체의 하위 집합을 S3 Standard-IA 스토리지 클래스로 전환하도록 Amazon S3에 요청합니다.
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>30</Days> </Transition> </Rule> </LifecycleConfiguration>
이 경우 충돌이 없으므로 Amazon S3는 logs/
접두사가 있는 객체를 생성 후 30일이 지나면 S3 Standard-IA 스토리지 클래스로 전환합니다. 생성 후 1년이 지나면 객체가 삭제됩니다.
예 2: 서로 충돌하는 수명 주기 작업
이 구성 예에는 객체 수명 주기 중 같은 시각에 동일한 객체 집합에 대해 두 가지 작업을 수행하도록 Amazon S3에 지시하는 규칙이 두 개 있습니다.
-
두 규칙은 동일한 키 이름 접두사를 지정하므로, 두 규칙은 동일한 객체 집합에 적용됩니다.
-
두 규칙은, 규칙이 적용될 때 생성 후 365일이 지난 동일한 객체를 지정합니다.
-
한 규칙은 객체를 S3 Standard-IA 스토리지 클래스로 전환하도록 Amazon S3에 지시하고, 이와 동시에 다른 규칙은 객체를 만료 처리하도록 Amazon S3에 지시합니다.
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>
이 경우 객체가 만료(제거)되기를 원하는 것이므로 스토리지 클래스를 변경하는 것은 의미가 없습니다. 따라서 Amazon S3가 이 객체들에 대해 만료 작업을 선택합니다.
예 3: 중복 접두사로 인해 서로 충돌하는 수명 주기 작업
이 예제에서 구성에는 다음과 같이 중복 접두사를 지정하는 두 가지 규칙이 있습니다.
-
규칙 1은 빈 접두사(모든 객체를 의미)를 지정합니다.
-
규칙 2는 모든 객체의 하위 집합을 식별하는 키 이름 접두사(
logs/
)를 지정합니다.
키 이름 접두사가 logs/
인 객체의 하위 집합에는 두 규칙의 S3 수명 주기 작업이 적용됩니다. 한 규칙은 생성 후 10일이 지난 객체를 전환하도록 Amazon S3에 지시하고, 다른 규칙은 생성 후 365일이 지난 객체를 전환하도록 Amazon S3에 지시합니다.
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>10</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>
이 경우, Amazon S3은 생성 후 10일 지난 객체를 전환하는 쪽을 선택합니다.
예 4: 태그 기반 필터링과 그로 인해 서로 충돌하는 수명 주기 작업
다음과 같이 각각 태그 필터를 지정하는 두 가지 규칙이 있는 S3 수명 주기 구성이 있다고 가정해 보겠습니다.
-
규칙 1은 태그 기반 필터(
tag1/value1
)를 지정합니다. 이 규칙은 생성 후 365일이 지난 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환하도록 Amazon S3에 지시합니다. -
규칙 2는 태그 기반 필터(
tag2/value2
)를 지정합니다. 이 규칙은 생성 후 14일이 지난 객체를 만료 처리하도록 Amazon S3에 지시합니다.
S3 수명 주기 구성은 다음 예에 나와 있습니다.
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Tag> <Key>tag1</Key> <Value>value1</Value> </Tag> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>GLACIER<StorageClass> <Days>365</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Tag> <Key>tag2</Key> <Value>value2</Value> </Tag> </Filter> <Status>Enabled</Status> <Expiration> <Days>14</Days> </Expiration> </Rule> </LifecycleConfiguration>
객체에 두 태그가 모두 있는 경우 Amazon S3는 따라야 할 규칙을 결정해야 합니다. 이 경우, Amazon S3은 생성 후 14일 지난 객체를 만료 처리합니다. 객체가 제거되므로 전환 작업이 적용되지 않습니다.