서버에 의존하지 않는 Serverless AWS 아키텍쳐 [Curator]
프로젝트 개요
- 목표
사진기자가 촬영한 사진을 사내 이미지 허브에 업로드하는 과정이 느리고 번거로움.
이러한 작업을 자동화하여 마치 박물관의 큐레이터가 이미지를 정리하고 관리해주는 듯한
경험을 사용자에게 제공하는 것이 목표.
이를 반영하여 프로젝트 명을 Curator로 명명함.
기존의 업로드 과정
- 사진 기자가 촬영한 이미지를 SD카드에서 컴퓨터로 이동
- 사내 허브 사이트에 로그인
- 이미지 업로드
개선된 업로드 과정
- 사진기자가 촬영한 이미지를 FTP(File Transfer Protocol)로 업로드
기술 아키텍쳐
- Amazon S3 : FTP로 전송된 이미지를 저장
- Lambda : 이미지 처리 (썸네일 생성, 원본 복사, 메타정보 추출)
- SNS & SQS : 이미지 처리 요청 및 메시지 관리
- DynamoDB : 오류 로그 기록 및 알림 관리
구현 및 서비스 흐름
- 사용자가 FTP를 통해 이미지를 업로드하면 이미지가 AWS S3버킷에 저장됨.
- S3의 Create이벤트를 트리거로 SNS로 이미지 정보 전송
- SNS에서 구독중인 SQS 이벤트 메시지 전송
- SQS의 트리거로 대상 람다함수들에게 이미지 정보 전송
- 사진 모음 페이지에서 이미지 로딩 시간을 빨리하기 위한 프리뷰 썸네일 이미지 생성 람다
- 원본 이미지를 복사하여 보관용 S3 로 이동시키는 람다
- 이벤트 객체로 넘어온 이미지의 메타 정보를 추출한 뒤 허브 API를 호출, Library DB에 메타정보 저장
- 람다함수를 통해 생성된 썸네일과 복사된 이미지는
허브 라이브러리가 바라보고있는 S3 버켓으로 옮겨지며 허브에 등록 완료
위 아키텍쳐를 통해 사진 기자는 컴퓨터 조작 또는 별도의 서버를 사용하지 않고
다이렉트로 허브에 이미지를 업로드 가능.
시연 연상
Error 처리
사용자가 직접 처리하던 일을 자동화하는 AWS 아키텍쳐 구조상 에러를 처리하는 부분 은 굉장히 중요함.
SQS에서 세트로 따라다니는 DLQ를 통해 Lambda의 동작이 실패할 경우 자동으로 ReDrive하는 기능을
추가하긴 했지만 개발자의 입장에서 오류가 왜 발생했는가를 파악하기 위해 SES를 이용.
Lambda 함수가 실행되었을 때 오류가 발생한다면 그 오류 사항을 Dynamo DB에 저장,
FTP를 전송한 사용자의 이메일에 실패한 이미지명과 실패한 이유를 전송.
BackEnd & Serverless & AI Engineer