예전 프로젝트 중 사진 공감 SNS 플랫폼에서 리사이징 작업을 했던적이 있다.
사진을 기반으로하는 앱이기 때문에 개발단계에서 이미지와 관련된 몇가지 필요한 사항들이 있었다.
- 사진 원본 화질을 최대한 유지할것.
- S3 저장용량을 효율적으로 관리할것.
- 클라이언트의 Image render 개선을 위해 이미지 캐시 및 사진 용량을 줄일것.
이 사항들을 위해서는 이미지 리사이즈 작업이 필요하다고 생각이 들었다.
이전에 이미지와 관련된 작업을 거의 해본적이 없었기 때문에, 구글링에 많은 힘을 썼다.
구글링을 하면서, “온디맨드 이미지 리사이즈”라는 키워드가 많이 보였다.
그렇다면 온디맨드 이미지 리사이즈란 무엇일까?
Ondemand image resize 말 그대로, 클라이언트의 요청이 있을때마다 클라이언트가 필요로하는 Demension으로 이미지 리사이즈를 해주는 것이다.
그중에서 AWS CloudFront + Lambda@edge 를 같이 쓰는 사례들을 많이 찾을 수 있었다. CloudFront는 AWS에서 운영하는 CDN이라고 생각하면된다.
하지만 Lambda@edge에 대해 생소한 사람도 많을것이다. 본인도 분명히 그랬다.
우리가 알고있는 Lambda는 쉽게 말해 지정해놓은 event 발생시 serverless로 trigger 되어 작동되는 코드라고 볼 수 있다.
lambda@edge는 지정해놓은 event가 CloudFront에서 일어난다고 생각하면된다.
이것을 이미지 리사이즈에 적용시켜보면, Process logic 은 아래와 같을것이다.
- 클라이언트가 CloudFront endpoint에 도달
- 클라이언트가 원하는 이미지 사이즈를 params 혹은 querystring으로 담아옴.
- CloudFront에 cache된 리사이즈 이미지가 있는지 확인, 있으면 바로 보내줌.
- 없으면 Lambda@edge trigger.
- Lambda@edge에 구현된 코드를 통해 이미지를 리사이즈하고, S3에 저장 (원본이 없다면 원본도 함께 저장)
- Lambda@edge를 통해 리사이즈된 이미지는 CloudFront endpoint로 redirect
일단 나도 핫한 온디맨드 이미지 리사이즈를 구현해보자! 하는 생각에…
AWS 공홈 문서를 끄적이면서, 어렵게 어렵게 결국 코드를 구현하긴 했지만, 여러 문제가 있었다.
- Lambda와는 달리 Lambda@edge는 많은 제한요인들을 갖고있다.
2. 클라이언트마다 제각각인 온디맨드 이미지 사이즈들은 오히려 많은 요청을 유발할 수 있고, 저장소 공간을 비효율적으로 잡아먹을 수 있다.
OneToMany 프로젝트를 고려했을 때에 다양한 사이즈들은 그리 많이 필요하지않았다. 오히려 최적의 공통된 Dimension으로 리사이즈를 하고, 이를 cache해두는 CDN을 함께 이용하는 것이 최적이라는 판단이 들었다.
하지만 Lambda@edge를 사용해보면서, 충분히 서비스 도중에 이용해볼만한 요소들이 많은점을 느꼈다. 또한 Lean한 프로젝트를 테스트해볼때에 CDN과 Lambda@edge 조합은 간편하게 파워풀한 기능들을 다양하게 사용해볼 수 있다는 생각이 들었다.
일단 프로젝트는 Lambda + CloudFront + S3 조합을 통해 이미지 리사이즈 작업을 완료하였다. 이 조합만으로도 이미지 용량이 확연히 줄어드는 효과를 볼 수 있었고, 당연히 클라이언트에서도 이미지 렌더가 빨라지는것을 체감할 수 있었다.
AWS의 최대 장점은 프로젝트의 Client side, Server side에 대한 수정없이도, 프로젝트의 방향을 바꿔볼 수 있다는 점이라고 생각한다.
Image Resize 후기 끝.
