릴리스 노트
제품 공지
라이프사이클 설정
적용 시나리오
라이프사이클 설정을 통해 규칙에 부합한 객체가 지정된 조건 하에 일부 조작을 자동 수행할 수 있습니다. 예시:
스토리지 유형 전환: 생성된 객체를 지정된 시간 후에 STANDARD_IA, INTELLIGENT_TIERING, ARCHIVE 및 DEEP_ARCHIVE로 변환합니다.
만료 삭제: 객체의 만료시간을 설정하면 객체가 만료된 후 자동으로 삭제됩니다.
사용 방법
COS 콘솔 사용
1. COS 콘솔에 로그인합니다.
2. 왼쪽 네비게이션 바에서 버킷 목록을 클릭하여 버킷 목록 페이지로 이동합니다.
3. 라이프사이클 기능을 활성화할 버킷을 찾아 버킷 이름을 클릭하여 버킷 상세 페이지로 이동합니다.
4.
왼쪽의 기본 설정 > 라이프사이클 설정 항목을 선택하며, 설정 항목 설명은 다음과 같습니다.
접근 추적: '마지막 접근 시간' 정책 유형을 기반으로 한 라이프사이클 규칙을 설정하려면 이 옵션을 활성화하십시오. 활성화하면 접근 추적 시작 시간이 버킷 내 모든 객체의 마지막 접근 시간으로 설정됩니다. 5단계에서 정책 유형을 마지막 접근 시간으로 구성할 수 있습니다.
주의:
접근 추적 기능은 화이트리스트 기능으로, 화이트리스트에 추가된 후 사용할 수 있습니다. 해당 비즈니스 담당자에게 문의하거나 문의하기를 통해 화이트리스트에 추가하면 당일부터 적용됩니다.
접근 추적 기능의 사용 제한 사항은 다음과 같습니다.
현재 베이징, 상하이, 광저우, 베이징 1존, 충칭, 싱가포르, 난징의 버킷만 접근 추적을 지원합니다.
OFS 통합 버킷은 접근 추적을 지원하지 않습니다.
5. 규칙 추가를 클릭하면 설정 항목에 대한 설명은 다음과 같습니다.
기본 정보
규칙 이름: 라이프사이클 규칙 이름을 입력하세요.
정책 유형: 마지막 수정 시간, 마지막 접근 시간으로 구분됩니다. 이 설정 항목은 접근 추적 기능 화이트리스트에 추가된 사용자에게만 표시됩니다.
마지막 수정 시간: 객체의 마지막 수정 시간에 따라 규칙을 설정합니다.
마지막 접근 시간: 객체의 마지막 접근 시간에 따라 규칙을 설정합니다. 이 설정 항목은 화이트리스트에 추가되고 접근 추적 기능이 활성화되어야만 구성할 수 있습니다(4단계에서 활성화 가능). 현재는 데이터가 STANDARD_IA로 전환되는 것만 지원됩니다.
주의:
접근 추적을 활성화한 후에야 COS는 버킷 내 객체의 접근 시간을 기록하기 시작합니다. 접근 추적을 활성화하기 전의 모든 접근 행위는 접근 시간 분석에 포함되지 않습니다. 예를 들어, 4월 1일에 객체 a(STANDARD)가 10일 동안 접근되지 않은 것을 확인하고, 당일에 접근 추적을 활성화하고 "객체 a를 마지막 접근 시간 5일 후 STANDARD_IA로 전환"이라는 라이프사이클 규칙을 설정하면, 객체 a는 4월 2일이 아닌 4월 6일에 STANDARD_IA로 전환됩니다.
적용 범위: 본 라이프사이클 규칙은 전체 버킷에 적용될 수도 있고 지정된 범위의 객체에만 적용될 수도 있습니다.
지정 범위를 선택할 때 다음 중 최소 한 가지를 구성하십시오.
객체 접두사: 동일한 객체 키 접두사를 가진 객체에 대해 라이프사이클 규칙을 실행하도록 지정할 수 있습니다. 정규 표현식은 지원되지 않습니다.
객체 태그: 동일한 태그가 있는 객체에 대해 라이프사이클 규칙을 실행하도록 지정할 수 있으며, 여러 태그를 지정할 수 있습니다. 영문 대소문자를 구분하십시오. 정책 유형을 마지막 접근 시간으로 선택한 경우 이 항목을 구성할 수 없습니다.
주의:
객체 접두사와 객체 태그를 동시에 지정할 수 있습니다. 객체 접두사와 객체 태그, 객체 태그 간은 모두 'AND' 관계로, 모든 조건이 동시에 충족되어야 합니다. 예를 들어, 라이프사이클 규칙에서 객체 접두사를 doc으로 지정하고 객체 태그 키 값 쌍을
group = IT로 지정하면, 현재 버킷 내에서 객체 키 접두사가 doc이고 객체 태그가 group = IT인 모든 객체가 지정됩니다.전체 버킷을 선택할 때 제외 범위를 구성할지 여부를 선택할 수 있으며, 기본적으로 비활성화되어 있습니다. 다음 구성 항목에 따라 설정할 수 있습니다.
객체 접두사: 동일한 파일 접두사를 가진 객체를 제외하여 라이프사이클 규칙을 실행하도록 지정할 수 있으며, 현재 단일 제외 접두사만 구성할 수 있습니다. 현재 구성된 제외 범위는 통합 버킷을 지원하지 않습니다.
규칙 구성
선택한 정책 유형에 따라 다음과 같은 정보를 구성하세요.
현재 버전 파일 관리: 현재 버전 파일 관리 옵션을 활성화하여 현재 버전 객체 스토리지 유형을 전환시키거나 객체를 삭제할 수 있습니다. 버킷의 객체가 STANDARD와 같은 핫 데이터에서 STANDARD_IA와 같은 콜드 데이터로 전환되도록 지원하며, 객체가 만료된 후 삭제되도록 지원합니다.
여기서 스토리지 유형은 핫에서 콜드로 각각 STANDARD > STANDARD_IA > INTELLIGENT TIERING > ARCHIVE > DEEP ARCHIVE이며, 스토리지 유형 전환은 핫에서 콜드로만 가능하며 역방향으로는 진행할 수 없습니다. 스토리지 유형에 대한 소개 및 적용 리전 설명은 설명은 스토리지 유형 개요 를 참고하십시오. 시간은 파일이 COS에서의 수정 시간을 기준으로 계산되며, 객체 수정 행위는 객체를 다시 업로드하는 것과 동일합니다.
설명:
다중 AZ 구성이 활성화된 스토리지 버킷의 경우, 라이프사이클 전환 순서는 MAZ_STANDARD > MAZ_STANDARD_IA > MAZ_INTELLIGENT TIERING/MAZ_ARCHIVE만 지원됩니다.
이전 버전 파일 관리: 이전 버전 객체 관리 옵션을 활성화하여 이전 버전 객체를 전환시키거나 삭제할 수 있습니다. 해당 옵션을 활성화하지 않은 경우, 최신 버전의 객체만 기본적으로 처리됩니다.
주의:
이전 버전 객체의 전환 및 삭제는 객체가 이전 버전이 된 시간을 기준으로 계산되며, 이전 버전의 업로드 시간을 기준으로 하지 않습니다.
이전 버전이 없는 삭제 마커 정리: 이전 버전이 없는 삭제 마커를 정리하려면 다음 두 가지 구성을 모두 활성화해야 합니다.
1. '이전 버전 파일 관리' 옵션을 활성화하고 이전 버전 파일의 만료 삭제를 설정합니다.
2. '이전 버전이 없는 삭제 마커 정리' 옵션을 활성화합니다.
주의:
이 옵션의 적용은 이전 버전 정리 규칙에 따라 달라집니다. 이 옵션을 선택하면 객체의 최신 버전이 삭제 마커(Delete Marker)이고 라이프사이클에 따라 마지막 이전 버전 객체가 삭제될 때, 다음 날 나머지 여러 삭제 마커가 자동으로 정리됩니다. 예: 1월 1일에 이전 버전 정리가 완료되면 1월 2일에 삭제 마커가 자동으로 정리됩니다. 자세한 내용은 ExpiredObjectDeleteMarker를 참고하십시오.
이 옵션은 현재 버전 파일 관리의 만료 삭제와 동시에 활성화할 수 없습니다.
조각 삭제: 파일 업로드 시 여러 이유로 인해 업로드가 실패하고 일부만 전송된 경우, 이러한 손상된 파일에 대해 정기 삭제를 설정할 수 있습니다.
버전 파일 관리: 버전 파일 관리 옵션을 활성화하여 파일이 연속 접근 일수 내에서 접근 횟수가 몇 번 미만인 경우 버전 객체를 전환시킬지 여부를 판단할 수 있습니다. 버킷 내 객체가 표준 유형(예: STANDARD)에서 저빈도 유형(예: STANDARD_IA)으로 전환하는 것을 지원합니다. 활성화하면 현재 버전과 이전 버전 모두 전환됩니다.
6. 정보 확인이 완료되면 확인을 클릭하면 라이프사이클 규칙을 확인할 수 있습니다.
주의:
7. 라이프사이클 규칙을 중지해야 할 경우 편집을 클릭하여 해당 규칙의 상태를 비활성화로 수정하거나 라이프사이클 규칙을 직접 삭제하면 됩니다.
8. 현재 버킷의 모든 라이프사이클 규칙을 지우려면 모든 규칙 지우기를 클릭하십시오.
규칙 실행 우선 순위
각 저장소는 최대 1000개의 수명 주기 규칙을 추가할 수 있습니다. 동일한 그룹의 객체에 대해 여러 규칙이 구성되어 있고 충돌이 있는 경우, 다양한 충돌 분류에 대해, 객체 저장소는 다음 우선 순위에 따라 수명 주기 규칙을 실행합니다. 자세한 내용은 수명 주기 개요 - 구성 요소 - 작업을 참조하십시오.
주의:
텐센트 클라우드 COS는 동일한 그룹의 객체에 대해 여러 충돌 조건이 포함된 수명 주기 규칙을 구성하지 않도록 강력히 권장합니다. 충돌 실행은 다른 비용 표현을 초래할 수 있습니다.
동일한 수명 주기 규칙의 다른 작업
만약 당신이 수명 주기 규칙을 구성하였고, 규칙 안에서 동일한 그룹의 객체에 대해 다른 작업(예: 침전, 삭제 작업)을 구성하였다면, 이러한 작업 간의 실행 규칙과 예시는 다음과 같습니다:
실행 규칙 | 예시 |
삭제 및 침전 작업이 동시에 충족되는 경우, 삭제 작업이 우선 실행됩니다. | 규칙 R1 : 1. 파일 test.txt는 수정 후 90일 뒤 저주파 저장소로 침전됩니다. 2. 파일 test.txt는 수정 후 90일 뒤 삭제됩니다. 예상 결과 : 우선 2를 실행하며, 파일 test.txt는 90일 후에 삭제됩니다; 1 실행 실패합니다. |
여러 삭제 작업이 동시에 충족되는 경우, 시간이 더 짧은 삭제 작업이 우선 일치됩니다. | 규칙 R1 : 1. 전치사 a가 지정된 파일은 180일 후에 삭제됩니다. 2. 전치사 aa가 지정된 파일은 90일 후에 삭제됩니다. 예상 결과 : 버킷에 aaa.png 파일이 있다고 가정하고 전치사 a와 전치사 aa가 모두 동일한 aaa.png 파일을 명시하는 경우, 2가 우선 실행되어 aaa.png 파일이 90일 후에 삭제되고, 1은 실행 실패합니다. |
여러 가지 침전 조작이 동시에 충족되는 경우, 대상 저장 유형이 더 차가운 침전 조작이 우선 일치합니다. | 규칙 R1 : 1. 파일 test.txt는 수정 후 90일 뒤 저주파 저장소로 침전됩니다. 2. 파일 test.txt는 수정 후 90일 뒤 아카이브 저장소로 침전됩니다. 예상 결과 : 우선 2를 실행하며, 파일 test.txt는 수정 후 90일 뒤 아카이브 저장소로 침전됩니다; 1 실행 실패합니다. |
다른 수명 주기 규칙의 다른 작업
만약 당신이 여러 개의 수명 주기 규칙을 구성하였고, 다른 규칙 안에서 동일한 그룹의 객체에 대해 다른 작업(예: 침전, 삭제 작업)을 구성하였다면, 이러한 작업 간의 실행 규칙과 예시는 다음과 같습니다:
실행 규칙 | 예시 |
여러 규칙 간에 다른 삭제 및 침전 작업이 동시에 충족되는 경우, 삭제 시간이 가장 짧은 작업이 우선 일치됩니다. | 규칙 R1 : 1. 파일 test.txt는 수정 후 50일 뒤 저주파 저장소로 침전됩니다. 2. 파일 test.txt는 수정 후 10일 뒤 삭제됩니다. 규칙 R2 : 1. 파일 test.txt는 수정 후 10일 뒤 저주파 저장소로 침전됩니다. 2. 파일 test.txt는 수정 후 30일 뒤 삭제됩니다. 예상 결과 : 매칭 규칙 R1은 우선 순위 2를 실행하며, 파일 test.txt는 수정 후 10일 뒤에 삭제됩니다; 규칙 R2 실행 실패, R1의 1 실행 실패. |
여러 규칙 간에 다른 삭제 작업이 동시에 충족되는 경우, 시간이 더 짧은 삭제 작업이 우선 일치됩니다. | 규칙 R1:파일 test.txt는 수정 후 10일 뒤 삭제됩니다. 규칙 R2:파일 test.txt는 수정 후 30일 뒤 삭제됩니다. 예상 결과 : 규칙 R1이 일치하며, 파일 test.txt는 수정 후 10일 뒤에 삭제됩니다; 규칙 R2 실행 실패. 규칙 R3:파일 example.txt는 수정 후 10일 뒤 삭제됩니다. 규칙 R4:파일 example.txt는 수정 후 10일 뒤 삭제됩니다. 규칙 R5:파일 example.txt는 수정 후 50일 뒤 삭제됩니다. 예상 결과: 규칙 R3 또는 R4가 일치하며, 파일 example.txt는 수정 후 10일 뒤에 삭제됩니다; 규칙 R5 실행 실패. |
여러 가지 규칙 간에 다른 침전 조작이 동시에 충족되는 경우, 대상 저장 유형이 더 차가운 침전 조작이 우선 일치합니다. | 규칙 R1:파일 test.txt는 수정 후 10일 뒤 저주파 저장소로 침전됩니다. 규칙 R2:파일 test.txt는 수정 후 10일 뒤 아카이브 저장소로 침전됩니다. 예상 결과: 규칙 R2가 일치하며, 파일 test.txt는 수정 후 10일 뒤에 아카이브 저장소로 침전됩니다; 규칙 R1 실행 실패. 규칙 R3:파일 example.txt는 수정 후 10일 뒤 저주파 저장소로 침전됩니다. 규칙 R4:파일 example.txt는 수정 후 10일 뒤 아카이브 저장소로 침전됩니다. 규칙 R5:파일 example.txt는 수정 후 10일 뒤 아카이브 저장소로 침전됩니다. 예상 결과: 규칙 R4 또는 R5가 일치하며, 파일 example.txt는 수정 후 10일 뒤에 아카이브 저장소로 침전됩니다; 규칙 R3 실행 실패. |
REST API 사용
REST API를 직접 사용해 버킷 중 객체의 라이프사이클을 설정 및 관리할 수 있습니다. 자세한 내용은 다음 API 문서를 참조해 주십시오.
SDK 사용
SDK의 라이프사이클을 직접 호출할 수 있습니다. 자세한 내용은 아래 각 언어로 된 SDK 문서를 참조해 주십시오.
C SDK
피드백