CloudFront 비용을 절감하는 방법에는 사용 유형, 지리적 리전, 기능을 조정하는 등의 다양한 방법이 있지만, 오늘은 요청 수와 Data Transfer Out(DTO)를 줄이는 방법에 대해 이야기하려고 합니다.
먼저, 어떤 요청이 많이 들어오고 DTO를 많이 사용하는지 어떻게 알 수 있을까요? AWS에서는 이를 파악할 수 있는 관련 데이터를 제공합니다. CloudFront 콘솔에서 "보고서 및 분석"을 통해 확인할 수 있습니다
요청 수 줄이기
요청 수는 어떻게 줄일 수 있으며, 과도한 요청인지 어떻게 파악할 수 있을까요?
저는 DAU에 비해 CloudFront의 "보고서 및 분석 > 인기 객체 > 특정 CF의 요청 수"가 과도하게 큰 것을 발견했습니다. 상위 항목을 살펴 본 결과 대부분 정적 이미지나 HTML, JS 파일이었습니다.
이는 한 번 불러오면 캐시에 저장해 두고 다시 요청할 필요가 없는 파일들이기 때문에 사용자 지정 헤더를 지정하여 요청 수를 줄였습니다.
DTO 줄이기
먼저, 어떤 CloudFront가 가장 많은 비용을 차지하는지 파악한 뒤, 인기 객체 보고서에서 해당 CloudFront를 선택하고 바이트 합계로 정렬하여 어떤 요청이 DTO를 많이 차지하는지 살펴보았습니다. 주요 항목은 다음과 같았습니다.
- 폰트
- 이미지 파일
- 크기 조정 (resize)
- 이미지 확장자 변경 (png => webp)
- lazy loading
- js
- html
- API 응답 크기
각 항목을 최적화한 방법을 설명하겠습니다.
폰트
기존에 폰트를 저장소에 저장해두고 사용했었지만, 이를 외부 CDN을 통해 가져오는 방식으로 변경했습니다.
이미지 파일
크기 조정 (resize)
DTO를 많이 차지하는 이미지들을 확인해보니, 모바일에서 사용하는 크기보다 많이 큰 이미지 사이즈를 가져오는 문제가 있었습니다. ex) 모바일에서 width: 144, height: 163으로 보여주는 이미지가 1440x1630 크기로 제공됨.
이를 해결하기 위해 serverless-image-handler를 사용하여 이미지 크기를 조정했습니다.
이미지 확장자 변경 (png => webp)
기존에 PNG 형식이었던 이미지를 webp 형식으로 변경하여 이미지 파일 크기를 최적화했습니다. 참고로 webp는 PNG보다 26% 더 작습니다.
lazy loading
기존에는 무한 스크롤 영역의 보이지 않는 이미지도 로드했지만, 해당 영역이 보일 때만 이미지를 로드하는 방식으로 변경했습니다. 개발자 도구 > 네트워크 > img를 통해 어떻게 로드되고 있는지 확인할 수 있습니다.
js
번들 분석기를 통해 어떤 패키지가 용량을 많이 차지하는지 파악한 후, 처음에 불러올 필요가 없는 부분은 dynamic import를 사용하여 필요할 때만 불러오도록 하고, 무거운 라이브러리는 가벼운 라이브러리로 변경하여 최적화했습니다.
html
HTML이 상위에 있어서 놀랐지만, 백그라운드 이미지가 base64로 인코딩되어 있음을 발견했습니다. 이를 저장소에 있는 이미지로 대체하여 최적화했습니다.
API 응답 크기
API에서 CF를 사용하는 부분이 있었는데, 요청 한 번에 393KB를 차지하고 있었습니다. 프론트와 백엔드 로직을 살펴본 결과 데이터 양이 그렇게 클 필요가 없었기 때문에, 해당 부분을 리팩토링하여 0.04KB로 줄였습니다.
마무리
중간중간 배포하면서 모니터링을 하고 싶다면 CloudFront > 원격 측정 > 모니터링에서 요청과 데이터 전송량을 확인할 수 있습니다.
아래 그래프는 DTO와 요청 횟수의 변화이며, 이를 통해 4월 30일 이후의 CF 총 비용을 2/3로 줄였습니다.
