1. 하는 이유
지금 하고 있는 프로젝트인 중고 거래 플랫폼 앱에서 거래 플랫폼이기 때문에 많은 이미지를 저장하고 효율적으로 처리할 필요가 있다고 생각되었기 때문입니다.
사실 이미지를 처리하고 비용을 줄이는 방법은 여러가지가 있습니다. 그 중에서도 필자가 알고 가장 잘 알려져있는 방법만 해도 2가지가 있습니다.
- S3와 lambda를 이용한 image resizing
- S3와 CloudFront & Lambda@edge로 image resizing과 S3 횟수 최소화
S3와 lambda를 이용한 image resizing
- S3에 정적 데이터가 들어오는 플래그를 lambda에 등록해둔 함수로 image의 용량을 줄여주는 방법입니다.
- 이 방법이 좋아보이지만 원본 파일과 다른 버킷이나 폴더에 용량을 줄인 파일을 넣음으로써 S3의 용량비용과 계속 되는 S3 GET 비용을 생각 안할 수 없습니다.
- 저번에 했을 때 에러율이 20%정도로 꽤나 높았습니다... (물론 제가 설정을 잘못했겠지요)
- 압축 실패 시 다시 시도하는 비용도 듭니다.
S3와 CloudFront & Lambda@edge로 image resizing과 S3 횟수 최소화
- S3에 들어오는 정적 데이터를 Lambda@edge로 사용자가 원하는 옵션으로 CloudFront로 여러 지역에 배포
- CloudFront의 Url로 불러옴으로써 캐시데이터를 사용할 수 있게 됩니다.
- S3는 용량 가격과 데이터를 등록하는 가격만을 부담합니다.
물론 CloudFront와 Lambda@edge의 가격도 있지만 첫 번째 방법보다 두 번째 방법이 효율적이라고 생각되었습니다.
2. CloudFront와 Lambda@edge
이 방법을 사용하기로 했으니 이 친구들의 동작 방식을 알아야합니다.
☁ CloudFront
- AWS에서 설명한 그대로의 설명
CloudFront는 전 세계의 정적/동적 웹 콘텐츠, 비디오 스트림 및 API를 안전하게 대규모로 전송할 수 있는 콘텐츠 전송 네트워크(CDN) 서비스
CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 보내줄 수 있다.
엣지 서버를 사용해 콘텐츠를 캐싱하고 서비스를 제공하면 최종 사용자가 위치한 곳에 더욱 가깝게 콘텐츠를 전송할 수 있기 때문에 성능이 향상된다.
🤔 그럼 어떻게 비용을 줄일 수 있을까?
- 사용자가 cloudfront로 요청을 보내면 일단 캐시 사본이 있는지부터 확인합니다.
- 있다면 그 캐시 사본을 보내줌으로써 사용자 입장에서는 빠른 응답 그리고 개발자 입장에서는 S3 비용 감소가 됩니다.
- 캐시 사본이 없다면 S3에서 파일을 가져옵니다.
⭐ 여기서 중요한 점은 S3에서 Cloudfront로 파일을 가져올 때의 비용은 무려 무료다!!
🏃♂️ Lambda@edge
- Lambda@Edge는 Cloudfront Edge 전후 위치에서 실행되는 Lambda 서비스라고 보면 됩니다.
위의 그림의 플로우는 이렇습니다.
- Viewer request: End user 가 CloudFront 로 보내는 요청입니다.
- CloudFront Cache: 요청 받은 리소스의 캐싱 여부 판단
- Origin request: CloudFront 에서 cache miss가 일어나면 origin(S3)에 리소스 요청합니다.
- Origin response: Origin 으로 부터 리소스를 CloudFront 에 응답합니다.
- Viewer response: origin 의 리소스 or cache hit된 응답합니다.
이 과정에서 사용자는 lambda@edge가 개입하는 곳을 선택하여 컨트롤할 수 있게 됩니다.
참고 자료
backend-developer