Amazon S3가 Lifecycle 구성의 충돌을 처리하는 방식
Amazon S3가 Lifecycle 구성의 충돌을 처리하는 방식
일반적으로 Amazon S3 Lifecycle은 비용을 최적화해요. 예를 들어 두 만료 정책이 겹치면 데이터가 예상보다 오래 저장되지 않도록 더 짧은 만료 정책이 적용돼요. 마찬가지로 두 전환 정책이 겹치면 S3 Lifecycle은 객체를 더 저렴한 스토리지 클래스로 전환해요.
두 경우 모두 S3 Lifecycle은 사용자에게 가장 비용이 적은 경로를 고르려고 해요. 이 일반 규칙의 예외는 S3 Intelligent-Tiering 스토리지 클래스예요. S3 Lifecycle은 S3 Glacier Flexible Retrieval과 S3 Glacier Deep Archive 스토리지 클래스를 제외한 어떤 스토리지 클래스보다 S3 Intelligent-Tiering을 선호해요.
S3 Lifecycle 구성에 여러 규칙이 있으면 객체가 같은 날 여러 S3 Lifecycle 작업의 대상이 될 수 있어요. 이 경우 Amazon S3는 다음 일반 규칙을 따릅니다.
- 영구 삭제가 전환보다 우선해요.
- 전환이 삭제 마커 생성보다 우선해요.
- 객체가 S3 Glacier Flexible Retrieval과 S3 Standard-IA(또는 S3 One Zone-IA) 전환 모두의 대상이면 Amazon S3는 S3 Glacier Flexible Retrieval 전환을 선택해요.
출처: 문서
본문
겹치는 필터 및 충돌하는 Lifecycle 작업의 예시
겹치는 접두사나 작업을 지정한 S3 Lifecycle 구성을 지정할 수 있어요. 다음 예시는 Amazon S3가 잠재적 충돌을 해결하는 방법을 보여줘요.
예제 1: 접두사 겹침(충돌 없음)
다음 예시 구성에는 다음과 같이 겹치는 접두사를 지정한 두 규칙이 있어요.
- 첫 번째 규칙은 빈 필터를 지정해 버킷의 모든 객체를 나타내요.
- 두 번째 규칙은 키 이름 접두사(
logs/)를 지정해 객체 하위 집합만 나타내요.
규칙 1은 생성 후 1년이 지나면 모든 객체를 삭제하도록 요청해요. 규칙 2는 생성 후 30일이 지나면 객체 하위 집합을 S3 Standard-IA 스토리지 클래스로 전환하도록 요청해요.
<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: 충돌하는 Lifecycle 작업
다음 예시 구성에는 객체 수명의 같은 시점에 같은 객체 집합에 두 가지 서로 다른 작업을 수행하도록 Amazon S3에 지시하는 규칙이 두 개 있어요.
- 두 규칙 모두 같은 키 이름 접두사를 지정하므로 두 규칙 모두 같은 객체 집합에 적용돼요.
- 두 규칙 모두 적용되는 시점을 객체 생성 후 같은 365일로 지정해요.
- 한 규칙은 객체를 S3 Standard-IA 스토리지 클래스로 전환하도록, 다른 규칙은 같은 시점에 객체를 만료시키도록 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: 접두사 겹침으로 인한 충돌하는 Lifecycle 작업
다음 예시에서 구성에는 다음과 같이 겹치는 접두사를 지정한 두 규칙이 있어요.
- 규칙 1은 빈 접두사(모든 객체를 나타냄)를 지정해요.
- 규칙 2는 모든 객체의 하위 집합을 식별하는 키 이름 접두사(
logs/)를 지정해요.
logs/ 키 이름 접두사를 가진 객체 하위 집합에는 두 규칙의 S3 Lifecycle 작업이 모두 적용돼요. 한 규칙은 생성 후 10일이 지나면 객체를 전환하도록, 다른 규칙은 생성 후 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: 태그 기반 필터링과 그로 인한 충돌하는 Lifecycle 작업
각각 태그 필터를 지정하는 두 규칙이 있는 다음 S3 Lifecycle 구성이 있다고 가정해 보세요.
- 규칙 1은 태그 기반 필터(
tag1/value1)를 지정해요. 이 규칙은 생성 후 365일이 지나면 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환하도록 Amazon S3에 지시해요. - 규칙 2는 태그 기반 필터(
tag2/value2)를 지정해요. 이 규칙은 생성 후 14일이 지나면 객체를 만료시키도록 Amazon S3에 지시해요.
S3 Lifecycle 구성은 다음 예시와 같아요.
<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일이 지나면 객체를 만료시켜요. 객체가 제거되므로 전환 작업은 적용되지 않아요.