이번에 클라이언트 개발측에서 호출되는 이미지가 너무 커서 로딩시간이 오래걸린다는 점을 문제로 제기했다.
기존에 GCP storage에 썸네일 이미지와 원본이미지를 같이 저장했는데 원본이미지를 호출하는 페이지가 많아 앱에서는 무리가 되었으리라 생각한다.
그래서 이미지를 원하는 사이즈로 호출하면 바로바로 잘라서 줄 수 있게끔 lambda@edge를 사용해, 이미지 리사이징 서버를 구축하기로 했다.
기존에 Lambda를 지원하는데 lambda@edge를 써야했던 이유는 이미지 리사이징을 온디맨드로 진행하려 했기 때문이다.
바로바로 이미지를 잘라준다는 것은 이미지를 한번 호출할때마다 이미지 리사이징 서버에 호출이 된다는 것을 의미한다.
그래서 중간에 이미 호출한 이미지를 캐싱해주는 역할을 해주는 cloudfront를 놓았다.
이때 cloudfront가 새롭게 들어온 이미지를 판단하여 lambda서버로 trigger하게 되는데, 이 기능을 lambda@edge에서만 지원한다.
처음에 어떻게 서버 아키텍쳐를 구성해야할지 부터 고민이었는데, 원하는 기능이 딱히 복잡한것이 아니어서 범용적으로 쓰는 구성으로 선택했다. 하지만 말이 쉽지, 온전한 결과물까지 가는데는 고려해야 할 사항이 계속 생겨났다.
순서는 이와 같다.
- 이미지 리사이징 서버 아키텍쳐 구성
- 람다 함수 작성 및 디버깅을 위한 로깅 코드 작성
- 적용 및 테스트(앱, 웹)
- 테스트 오류 발생시 두번째와 세번째 과정 반복..
이 과정대로 이미지 리사이징 서버 구축 여정을 서술해볼 생각이다.
'Backend > INFRA' 카테고리의 다른 글
젠킨스 도커플러그인이 인식되지 않을때 (0) | 2022.06.02 |
---|---|
Image resizing with Lambda@edge -2 (0) | 2021.11.30 |
Image resizing with Lambda@edge -1 (0) | 2021.11.30 |