현재 상황
s3 -> s3 deep archive
aws-sdk를 사용해서 aws 중 s3를 제어하는 프로그램을 개발하고 있습니다.
그중에 s3 bucket의 lifecycle를 통해 이전 기간을 설정하여 객체(파일)를
s3 -> s3 deep archive 제어하려고 합니다.
그 중에 다음의 메서드를 이용할 거에요.
putBucketLifecycleConfiguration(params = {}, callback) ⇒ AWS.Request
example를 보고 직접 구현한 코드입니다.
params에는 이런 내용이 들어갑니다. 실제로 aws s3 console ( 웃긴건 이름은 console인데, cli환경이 아닌 gui입니다.) 보시면
public putBucketLifeCycle(days: string, storageClass: string) {
return new Promise((resolve, reject) => {
const params = {
Bucket: config.bucketName,
LifecycleConfiguration: {
Rules: [ /* required */
{
Prefix: "",
Status: "Enabled",
Expiration: {
Days: 1,
},
ID: "S3toGlacier",
NoncurrentVersionExpiration: {
NoncurrentDays: 60,
},
NoncurrentVersionTransitions: [
{
NoncurrentDays: 30,
StorageClass: storageClass,
},
],
Transitions: [
{
Days: days,
StorageClass: storageClass,
},
],
},
/* more items */
],
},
};
s3.putBucketLifecycleConfiguration(params as unknown as AWS.S3.PutBucketLifecycleConfigurationRequest,
(err, data) => {
if (err) {
console.log("s3라이프사이클 에러!!");
reject(err);
return;
}
console.log("s3라이프사이클", data);
resolve(data);
});
});
}
이렇게 규칙이 들어가요.
그런데 스토리지 클래스가 바뀌지 않아요..
위에 코드에서
params 내부에 객체를 타고 타고 들어가면 Rules라는 프로퍼티가 나오는데요.
얘도 객체요. 얘 안에 Transitions이란 프로퍼티가 있습니다.
여기에 days, storageClass 등 변수를 통해 제어하는데요.
각 프로퍼티들의 의미는 aws-sdk 공식문서에 나옵니다.
Days 보시면 제가 날짜를 지정할 수 있어요. 객체가 생성된후 특정 스토리지 클래스로 이전할지 그 날짜를 지정해준거에요.
그런데 현재 상황은 스토리지 클래스가 바뀌지 않습니다. 이어서 삽질을 해야겠습니다.
스토리지 클래스가 이전되었습니다.
정확히 기준이 뭔지를 모르겠지만,
넉넉히 잡아서 하루는 있어야
스토리지 클래스가 이전이 됩니다.
화살표로 가능여부를 알 수 있습니다.
standard 스토리지 클래스는 standard_IA, Intelligent_tiering, Glacier 스토리지 클래스로 객체 이전 할 수 있고,
glacier에서 standard로는 화살표가 없으니, 수명 주기를 사용해서 객체 이전이 지원안된다는거겠죠.
정말 중요한건 사용 하는 스토리지 클래스 마다 요금이 달라집니다.
액세스 패턴, 검색 요금, 데이터를 액세스하는 방법이 다 달라져요.
예를 들어, 데이터 아카이빙용도로 사용하는 스토리지 클래스 중 Glacier를 보면
GLACIER—분 단위로 데이터의 일부를 검색해야 하는 아카이브에 사용합니다.
GLACIER 스토리지 클래스에 저장된 데이터는 최소 스토리지 기간이 90일이며 신속 검색을 사용하여 최소 1~5분 이내에 액세스할 수 있습니다. 90일 최소 기간 이전에 삭제했거나 덮어썼거나 다른 스토리지 클래스로 이전한 경우, 90일 요금이 부과됩니다. 요금 정보는 Amazon S3 요금을 참조하십시오.
이런 얘기가 나와요. 최소 기간 이전에 삭제를 하거나 덮어쓰거나 다른 스토리지 클래스(Deep_archive가 가능하죠.)이전했을때 요금이 부과된대요.
수명 주기 구성의 요소
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/intro-lifecycle-rules.html
대체 Rules 안에 prefix가 뜻하는게 뭐야...
키 접두사를 사용하여 필터 지정 – 이 예제는 키 이름 접두사(logs/)에 기반하여 객체의 하위 집합에 적용되는 수명 주기 규칙을 보여 줍니다. 예를 들어, 이 수명 주기 규칙은 객체 logs/mylog.txt, logs/temp1.txt 및 logs/test.txt에 적용됩니다. 이 규칙은 객체 example.jpg에는 적용되지 않습니다.
즉, 디렉토리(폴더)마다 규칙을 나눌 수도 있겠네요.
위에 수명 주기 구성 요소에서 lifecycle에 관련된 메서드에는 params에 들어가는 필드에 대한 자세한 내용을 이해할 수 있습니다.
수명 주기 구성의 예제
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/lifecycle-configuration-examples.html
https://aws.amazon.com/ko/blogs/aws/new-amazon-s3-storage-class-glacier-deep-archive/
https://docs.aws.amazon.com/ko_kr/amazonglacier/latest/dev/introduction.html
S3 standard에 파일을 저장해요. 수명 주기 구성을 통해 S3 Glacier 스토리지 클래스로 이전할 수 있어요!
객체가 Glacier에 저장은 되어있지만, 사용자는 여전히 Amazon S3에서 관리하는 객체라서~ S3 glacier를 통해서는 직접 액세스할 수 없어요.
모르고 있었던 점은 S3에서 glacier로 객체를 이동시킬때
aws management console에서보면 S3 Glaicer가 있죠? 저기에도 볼트.. 아키이브.. 뭐 어쩌구 개념들이 있는데,
저걸 사용하는게 아니라
S3에서 내부적으로 스토리지 클래스만 Glacier로 바꿔주기만 해도~ S3 standard의 객체가 S3 glacier로 이동한다는 점이에요!
그리고! 위에 말했듯이 s3 glacier로 이동한 객체는 s3 glacier aws console을 통해 액세스 할 수 없다는 점!
출처: 공홈
각 Amazon S3 객체는 데이터와 키, 메타데이터로 구성됩니다.
키
, 메타데이터
키: 파일이름
객체 키(또는 키 이름)는 버킷 내 각 객체를 고유하게 식별합니다. 객체 메타데이터는 이름-값 페어의 집합입니다.
객체를 업로드할 때 객체 메타데이터를 설정할 수 있습니다. 객체를 업로드한 후에는 객체 메타데이터를 변경할 수 없습니다. 객체 메타데이터를 수정할 수 있는 유일한 방법은 객체 복사본을 만든 후 메타데이터를 설정하는 것입니다.
하위 버킷 또는 하위 폴더의 계층 구조는 없습니다. 폴더 개념이 없나요?
폴더 개념 지원합니다.
Amazon S3 콘솔과 같이 키 이름 접두사 및 구분 기호를 사용하여 논리적인 계층 구조를 유추할 수 있습니다. Amazon S3 콘솔은 폴더 개념을 지원합니다. 버킷(admin-created)에 다음과 같은 객체 키를 가진 4개의 객체가 있다고 가정해 보겠습니다.
수명 주기에도 Rules 안에 Prefix라는 프로퍼티가 있는데요.
s3-dg.pdf 키에는 접두사가 없으므로 이 객체는 버킷의 루트 수준에 표시됩니다. Development/ 폴더를 열면 그 안에 Projects.xlsx 객체가 표시됩니다.
나중에 이런 Prefix (접두사)를 통해 필터링해서 S3 객체 수명주기를 조절할 수 있습니다.
객체 메타데이터
시스템 메타데이터 및 사용자 정의 메타데이터라는 두 종류의 메타데이터가 있습니다.
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/UsingMetadata.html