S3 객체의 배치 작업을 원큐에 – S3 batch operation 소개
여기서 다루는 내용
· 들어가며
· 기능 개요
· STEP1: Choose Region and manifest
· STEP2: Choose operation
· STEP3: Choose additional options
· 결과 확인
· 마치며
들어가며
안녕하십니까. GS네오텍 최준승입니다.
아침에 머리에 샴푸를 문지르며 문득 이런 생각이 들었습니다.
수많은 AWS 서비스 중에서 다른 AWS 서비스와 연결고리가 가장 많고. 장애가 났을때 파급효과가 큰 서비스가 뭘까?
저는 단연 S3라고 생각합니다.
일단 대부분의 AWS 서비스가 S3와 데이터를 주고받을수 있게 설계되어 있고
실제 수많은 I/O가.. 이 S3라는 객체 스토리지를 중심으로 돌아가고 있습니다.
S3는 분리 단위가 아닌 하나의 거대한 클러스터에 가까운 서비스라 벤더 입장에서도 관리포인트가 적지 않을텐데
그럼에도 불구하고 잘 돌아가고 있습니다. 큰 성능이슈 없이. 수많은 부가 기능을 붙여가며. 사용자에게 높은 자유도를 제공합니다.
오늘은 이 S3 서비스에 새로 출시된 Batch Operation 기능을 살펴볼까 합니다.
18년 리인벤트에서 발표가 됐고. 19년 4월에 공식 GA가 되었는데. 제가 뜯고 씹고 맛을 보니 꽤나 쓸만합니다.
여러분도 분명 S3는 쓰고 계실테니. 알고 계시면 언젠가 분명 쓸모가 있을겁니다.
그럼 시작!
S3 Batch Operation 개요
이름에도 써있듯이 이 기능은 대량의 S3 객체를 대상으로 배치작업을 돌려주는 기능입니다.
AWS Documentation – S3 – Performing Batch Operations
3줄로 요약하면
- 대상 객체 목록을 정하고
- 어떤 배치잡을 돌릴지 할당하면
- 각 객체별로 작업이 쭉 돌고 진행률 및 결과 리포팅을 한다
여기서 제일 중요한건 세번째입니다. “리포팅을 한다.”
그렇다면 두번째에서 얘기하는 Job은 뭘 할당할 수 있을까요? ’19년 6월 기준으로는 다음과 같습니다.
- PUT Object Copy
- Initiate Restore Object
- Invoking a Lambda Function
- Put Object ACL
- Put Object Tagging
객체를 복사하든 Glacier 객체를 복원하든.. Built-In 되어 있는 Operation들은 선택적으로 쓰면 되는것이고
여기서 제일 중요한건 세번째입니다. Lambda를 연계시킨다면 무슨 작업이든지 커스터마이징해서 할수 있으니 자유도 급상승.
이어 아주 간단한 데모를 통해. 이 기능이 어떤 흐름으로 돌아가는지 살펴보도록 하겠습니다.
STEP1: Choose Region and manifest
제일 먼저 배치 작업을 돌릴 객체 목록을 정리해야 합니다. 이 목록을 manifest라고 부르는데요.
이 manifest는 s3 inventory 기능을 이용해서 생성할 수도 있고.
사용자가 별도로 csv 형태로 만들어 쓸수도 있습니다. 물론 형식은 정해져 있습니다.
후자의 경우.
version ID를 포함하지 않고. key값만 나열하게 되면 이렇게.
Examplebucket,objectkey1
Examplebucket,photos/jpgs/objectkey2
Examplebucket,photos/jpgs/newjersey/objectkey3
Examplebucket,object%20key%20with%20spaces
version ID를 포함하게 되면 이렇게 됩니다.
Examplebucket,objectkey1,PZ9ibn9D5lP6p298B7S9_ceqx1n5EJ0p
Examplebucket,photos/jpgs/objectkey2,6EqlikJJxLTsHsnbZbSRffn24_eh5Ny4
Examplebucket,photos/jpgs/newjersey/objectkey3,imHf3FAiRsvBW_EHB8GOu.NHunHO1gVs
Examplebucket,object%20key%20with%20spaces,9HkPvDaZY5MVbMhn6TMn1YTb5ArQAo3w
저는 편의상 dummy 파일을 10개 정도 만들어 S3에 넣고.
manifest.csv 파일을 아래와 같이 작성해서 S3에 참조용으로 업로드하였습니다.
jschoi.test,dummy/01.dum
jschoi.test,dummy/02.dum
jschoi.test,dummy/03.dum
jschoi.test,dummy/04.dum
jschoi.test,dummy/05.dum
jschoi.test,dummy/06.dum
jschoi.test,dummy/07.dum
jschoi.test,dummy/08.dum
jschoi.test,dummy/09.dum
jschoi.test,dummy/10.dum
jschoi.test,dummy/11.dum
(참고로 이 목록중 11.dum 파일은 실제 존재하지 않습니다. 실패시 리포팅 형태를 보기 위해 추가한것임)
자, 준비가 완료되었으니 AWS 콘솔로 가봅시다.
※ manifest 경로를 지정합니다. 포멧에 csv를 선택하고 사전에 올려놓은 manifest.csv 파일의 경로를 입력
1단계 작업이 끝났습니다.
하지만 대상 객체가 10개가 아니라 수십/수백만개라면 어떨까요? 그 중 선택적으로 객체를 골라내고 싶다면?
이 목록을 만드는 일부터 난이도가 높아질 수 있습니다.
객체 태그로 필터링할수도 있고. 객체키값을 정규식으로 발라낼 수도 있고.
스크립트로 객체 리스팅을 해다가 특정 기준으로 필터링해서 목록을 만들어 붙일수도 있고.
만일 Versioning된 버킷이라면. 목록에 Version ID를 가급적 포함해야 하고.. 등등등.
하지만 이 부분은 어디까지나 사용자의 영역이고. 데모가 오늘의 목적이므로 자세히 다루지 않겠습니다.
다음 단계로 넘어갑니다.
STEP2: Choose operation
2단계는 어떤 Job(Operation)을 할지 정해야 합니다.
예시를 Lambda로 하면 좋겠지만. 그럼 데모가 너무 길어지기 때문에.
편의상 새로운 태그를 붙이는 Built-In Job(Replace All Tags)을 사용해 보겠습니다.
※ Replace All Tags를 선택하고, 각 객체에 덧붙일 태그값 덩어리를 입력
참고로 여기서 각 Operation별로. 입력받는 부가정보가 각기 다른데요.
예를 들어 Put Copy의 경우 타겟 버킷은 누구고. 스토리지 클래스는 뭘로 하고. ACL은 어떻게 줄지. 이런것들을 입력받게 되어 있습니다.
한번씩 눌러보시면 나오니까 살펴보시구요.
저는 다음 단계로 넘어갑니다.
STEP3: Choose additional options
마지막 3단계입니다.
이 단계에서는 몇가지 중요한 설정을 정의합니다.
※ Job 우선 순위 / 리포트 생성 여부 / 사용할 IAM Role 등을 지정
여러개의 잡이 동시에 돌아갈때. 우선순위를 조절할 수 있는 부분이 있구요.
처리 결과를 어떤식으로 레포팅할지 (전체/실패한것만) 정해주는 부분이 있습니다.
그리고 캡쳐에는 생략됐지만. 밑에 작업에 필요한 IAM Role 객체를 지정하는 부분이 있는데요.
해당 IAM Role에 붙은 IAM Policy를 보면 느껴지는 바가 있어서 한번 훑어보고 지나가겠습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObjectTagging",
"s3:PutObjectVersionTagging"
],
"Resource": "arn:aws:s3:::jschoi.test/dummy/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::jschoi.test/manifest.csv"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::jschoi.test/result/*"
]
}
]
}
- 첫번째 단락: 대상 목록 객체에 실제 Operation(태그 붙이기)을 하기 위한 권한
- 두번째 단락: manifest 파일을 Read하기 위한 권한
- 세번째 단락: 배치작업 결과를 Write하기 위한 권한
그리고 해당 IAM Role에 Trust Policy엔 Principal 필드에 “batchoperations.s3.amazonaws.com”라는 서비스가 들어갑니다.
(임시권한을 위해 AssumeRole을 수행하는 서비스 주체를 지정하는 부분)
이 IAM Role이 제대로 셋팅되지 않으면. 목록 파일을 못읽등가. 대상 객체를 못읽등가 해서 권한 에러가 발생할 수 있습니다.
설명할게 많다보니. 내용이 너무 길어지고 있는데요.
이제 끝났습니다. Job 셋팅이 끝났으니. 결과를 보고 마무리하겠습니다.
결과 확인
Job을 신규로 등록하면 작업이 바로 시작하는 것은 아닙니다.
사용자가 Confirm을 하고 시작 싸인을 줘야 해당 작업이 시작됩니다.
※ Job을 확인하고, Confirm and Run을 클릭하여 배치작업을 시작하자
자, 이제 배치작업이 돌기 시작하고. 진행률이 표시됩니다.
대상 객체가 수백만개였다면. 진행률을 쳐다보고 있었겠지만.
이 데모는 대상 객체가 10개 뿐이므로 작업이 금방 완료되었습니다.
아래처럼 완료 상태가 표시되고. 전체 객체가 몇개인지. 그리고 이중에 몇개가 실패했는지가 숫자로 표시됩니다.
※ 작업은 완료되었고. 총 11개의 객체중 1개 작업이 실패하였음을 확인할 수 있다
처리 결과는 사전에 지정한 위치에 csv형태로도 리포팅이 됩니다.
※ 2개의 csv 파일 중 위의것이 성공한 목록. 아래것이 실패한 목록
둘중 아래 csv 파일을 한번 열어보겠습니다.
jschoi.test,dummy/11.dum,,failed,404,NoSuchKey,The specified key does not exist.
※ manifest에서 지정한 목록 중 11.dum 객체가 존재하지 않아서 실패한것을 확인
어떤 흐름으로 돌아가는지 이제 좀 이해가 되시나요?
마치며
제가 보기엔 이 기능은 정말 쓸모가 많습니다.
단순 복사를 하거나 Glacier를 복원하거나 Object ACL을 변경하거나 태그를 바꾸는 빌트-인 기능도 쓸모가 많지만
Operation으로 Lambda 함수를 정의한 경우 그 활용도가 급격히 높아지는데요. 예를 들면
- Rekognition API와 연동하여 이미지에서 인식된 사물 목록을 S3 객체 태그로 붙인다거나
- 특정 규칙에 따라 경우의 수를 나눠 각기 다른 meta-data를 객체별로 붙여준다거나
- 객체 이미지의 썸네일을 한번에 쭉 만들어준다거나.. 등등
그리고 이런 작업들이 레포팅이 가능한 환경에서 돌아가기 때문에
실패한 작업들에 대한 사후 처리(재작업) 설계하기에도 관리포인트가 급격히 줄어듭니다.
어떻게 보면 S3라는 스토리지와 Lambda. 그리고 이 기능을 활용하여. Serverless하게 다양한 로직을 구현할 수 있게 되는 셈입니다.
그리고 S3라는 스토리지 특성상. 보통 각종 속성값을 업로드할때 명확하게 정의하는것을 권장하지만.
실제 현실에서는 그렇지 못한 경우가 많기 때문에. 이 부분을 바로 잡아주기에도 아주 적합한 기능이구요.
마지막으로 이벤트 및 로깅 관련하여 AWS 공식 문서의 코멘트를 덧붙이며 마치도록 하겠습니다.
In addition to requesting completion reports, you can also capture, review, and audit batch operations activity using Amazon S3 events. As a job progresses, it emits events that you can capture using AWS CloudTrail, Amazon Simple Notification Service (Amazon SNS), and Amazon Simple Queue Service (Amazon SQS). Because batch operations use existing Amazon S3 APIs to perform tasks, those tasks also emit the same events that they would if you called them directly.
읽느라 수고하셨습니다. 끝!
최신 댓글