[Lambda] Lambda와 S3를 사용한 이미지 리사이징 (1)- 도입배경,설계,실패경험

1. 도입배경

• 현재 프로젝트에서는 Amazon S3를 이미지 스토리지로 사용중
• 랭킹 페이지와 같은 페이지에서는 썸네일을 위한 많은 이미지가 필요하며, 원본 이미지 전송시 과도한 트래픽 발생
• 고해상도 이미지 대신 리사이징된 이미지를 제공 함으로써 리소스 전송 비용 감소 및 사용자에게 최적화된 경험을 제공
• 이를 통해 이미지 전송 네트워크 비용을 절감 하고, 사용자 접속 시 빠른 로딩 속도 를 기대할 수 있다.

왜 Lambda로 이미지 리사이징을 하는가?

• 자동화된 트리거: S3와 결합하여 버킷에 이미지가 업로드될 때 Lambda를 통해 자동으로 리사이징을 처리할 수 있어 편리하다.
• 서버리스 비용 절감 : Lambda는 서버리스 서비스로 사용한 만큼만 비용이 발생하므로, 리사이징에 따른 추가 비용을 효율적으로 관리할 수 있다.
• 비즈니스 로직과 리사이징 분리: 이미지 리사이징 작업은 프론트엔드나 백엔드 서버가 아닌, Lambda에서 독립적으로 처리되므로, 리사이징을 위해 서버 리소스를 사용하지 않아도 된다.

---

2. 타 서비스 분석

• 현재 서비스중인 카카오페이지, 노벨피아와 같은 웹노벨 사이트의 이미지 처리 방식을 분석하였다.
• 해당 사이트들은 랭킹 페이지와 같은 많은 이미지를 랜더링해야하는 페이지에서, 리사이징된 이미지를 사용중이였으며, 이를 참고하여 이미지 리사이징을 통한 감소율을 설정하였다.

---

3. 설계

현황

• 작가가 소설의 썸네일 이미지를 등록하면 해당 이미지는 Amazon S3의 Original Image Bucket에 원본으로 저장된다.
• 클라이언트는 WAS를 통해 전달받은 이미지 URL을 통해 CloudFront에서 이미지를 요청하여 전달받는 구조이다.

개선된 방식

• AWS Lambda를 사용하여 S3 버킷에 파일이 업로드될 때 트리거가 발생하도록 설정하고, 업로드된 이미지를 리사이징하여 다른 버킷에 저장하도록 설계하였다.
• 리사이징된 이미지에는 mini- 접두사 를 붙여 리사이징 이미지임을 표시했으며, URL 생성 시에도 이를 포함 하도록 변경하였다.
  (예: mini-cover.jpg)
• 클라이언트는 WAS에서 제공한 URL을 통해 CloudFront에서 이미지를 요청하게 되며, 리사이징된 이미지 요청 시에는 mini- 접두사가 포함된 URL을 사용하여 전된다.
• 예를 들어, (https://cdnurl.cloudfront.net/thumbnail/mini-cover.jpg) 같은 URL을 통해 리사이징된 이미지를 받게 된다.

리사이징 이미지 버킷을 따로두는 이유(실패 경험)

재귀호출 문제

• AWS에서 권장하는 S3 버킷의 트리거 방식은 입력과 출력 버킷을 분리하여 재귀 호출을 방지하는 것이다.
• 처음에는 권장사항과 다르게 Lambda의 트리거를 단일 버킷에 설정했으나, 이미지 리사이징 작업 후 다시 같은 버킷에 저장되면서 재귀 호출로 인해 다수의 요청(Request)이 발생하였다.
• 이로 인해 시스템 성능 저하와 예상치 못한 비용 증가 문제가 발생하였다.
• 아래 이미지처럼 mini-mini- 접두어가 붙은 파일들이 재귀 호출로 중복 생성된 것을 확인할 수 있었다.

재귀호출로 리사이징된 이미지

• 트리거 생성시 이벤트 유형으로 재귀호출을 제한하는 방법이 있긴 하지만, 안전하게 AWS 권장사항처럼 버킷을 여러개 두는 방식으로 재설계하였다.