REST API Response(JSON)를 CDN을 활용하여 캐싱하기

목차

- 웹서비스에서 캐싱 대상과 방법

  - 캐시 대상

  - 캐시 방법

- REST API Resonse(JSON)를 CDN을 활용하여 캐싱하기

  - CDN을 활용한 캐싱의 장단점

  - 캐싱하기 예제 (조건, 구현, Cache-Control)

- 마치며

---

웹 서비스에서 캐싱 대상과 방법

웹 서비스에서 캐싱은 중요합니다. 사실 필수적이라고도 볼 수 있죠.

캐싱 덕분에 서버의 응답 시간과 부하를 크게 줄일 수 있습니다.

캐싱 대상

이미지, 동영상부터 html, js, css, json 등 클라이언트와 서버가 주고받는 데이터들은 모두 캐싱 대상으로 볼 수 있습니다. 컨텐츠가 자주 안 바뀌고(정적), 바뀌는(동적) 기준으로도 구분하기도 합니다.

- 정적 컨텐츠(*.html, *. js, *. css, image, video...)

- 동적 컨텐츠(*. json, *. html,...)

캐싱 방법

캐싱 방법도 다양합니다.

- 브라우저 캐싱: 브라우저를 활용하여(로컬 스토리지, 쿠키 등) 캐싱

- 서버 메모리 캐싱: 서버의 메모리를 활용한 로컬 캐싱

- 서버 디스크 캐싱: 서버의 디스크를 활용한 캐싱

- 외부 서버 캐싱: 외부 캐싱 서버(NoSQL, e.g. redis)를 활용한 글로벌 캐싱

- 프록시 캐싱: 클라이언트와 서버 사이에 위치한 프록시 서버가 캐싱

- CDN 캐싱: 전 세계에 분산된 캐시 서버를 활용한 캐싱

-...

캐싱 대상과 방법

---

REST API Response(JSON)을 CDN를 활용하여 캐싱하기

CDN 활용한 캐싱의 장단점

장점

- 응답 시간 단축: CDN은 전 세계에 분산되어 있는 캐시 서버를 통해 컨텐츠를 전송합니다. 클라이언트에게 보다 가까운 캐시 서버에서 데이터를 보내 응답 시간을 단축시킬 수 있습니다

- 트래픽 분산: CDN은 요청을 처리하기 위해 다양한 캐시 서버를 활용하기 때문에 서버의 부하가 분산되어 서버 과부하를 줄일 수 있습니다.

 

단점

- 실시간 데이터의 제공 어려움: CDN은 정적인 데이터를 캐싱하는 데에 적합하므로, 실시간으로 변경되는 데이터에 대한 캐싱은 적합하지 않습니다.

- 캐시 무효화 제어의 어려움: CDN에서 캐싱된 데이터가 만료되면 업데이트된 데이터를 제공해야 합니다. 이때, 캐시 무효화를 어떻게 처리할 것인지에 대한 전략을 세우고, 관리해야 합니다.

 

CDN를 활용한 정적 컨텐츠 캐싱은 매우 효과적입니다. 이미 많은 기업들에서 사용하고 있죠.

동적 컨텐츠인 REST API Response(JSON)도 유효할까요? 실시간으로 변경되는 데이터에 대해 CDN 캐싱은 적합하지 않습니다. 하지만 요청마다 결과가 달라지는 API가 아니라 10분, 30분, 1시간마다의 값이 고정되어 있다면 어떨까요?

REST API Response(JSON)을 CDN를 활용하여 캐싱하기

AWS의 스토리지 서비스(S3)와 CDN(CloudFront)를 활용하여 캐싱을 구현합니다. 

 

예제

- 특정 API에 대해서만 캐싱합니다.

- 캐싱할 API는 30분마다 바뀔 가능성이 있습니다. 매번 바뀌는 것은 아닙니다.(하루 동안 안 바뀌는 경우도 존재합니다.)

- 약간의 데이터 딜레이가 발생해도 괜찮습니다.

- 해당 API만 유독 RPS가 높은 상황입니다. 

- API size는 100kB 이하입니다.

 

구현 

1. 배치코드를 30분 마다 실행합니다.

2. 배치는 최근 API Response을 읽습니다. 이전에 S3에 업로드된 데이터와 동등성 비교를 합니다.

3. 기존과 데이터가 같다면 배치를 종료합니다. 데이터가 다르다면 S3에 업로드합니다.

4. S3 업로드 시 HTTP Header인 Cache-Control을 사용하여 캐싱 시간을 설정합니다.(max-age, s-maxage)

5. CloudFront에서 업로드한 리소스를 캐시 무효화를 합니다.

 

Cache-Control: max-age=600, s-maxage=86400

HTTP Header인 Cache-Control를 사용하여 브라우저 캐시나 shared cahce(e.g. Proxies, CDNs)의 캐싱 제어를 할 수 있습니다.

S3 업로드할 때 Cache-Control 값을 지정하여 업로드하게 되면 CloudFront TTL과 비교하여 해당 파일 캐싱 수준을 컨트롤합니다. (AWS Docs: 컨텐츠가 캐시에 유지되는 기간(만료) 관리)

 

max-age

Cache-Control 헤더의 값인 max-age 값(seconds)을 지정하여 리소스의 캐시 유효 시간을 지정할 수 있습니다.

해당 값은 보통 브라우더 캐시로 설정됩니다. 해당 시간은 리소스 생성/수정 시간이 아닌 브라우저가 리소스를 받은 시간 기준(상대시간)입니다.

Cache-Control: max-age=600으로 설정하면 리소스를 10분 동안 브라우저 캐시를 사용한다는 뜻입니다.

만약 max-age 값을 12시간 지정하면, 12시간 동안 브라우저 캐싱되기 때문에 해당 시간 동안 서버나 CDN에 리소스를 요청하지 않는 매우 큰 강점을 가지게 됩니다. 하지만, 되돌릴 수 없으니 상황에 맞게 캐시 시간을 상황에 맞게 고려해야 합니다.

 

s-maxage

s-maxage는 shared cahce(e.g. Proxies, CDNs), 중간 서버에서 캐싱하는 시간을 나타냅니다. 

Cache-Control: s-maxage=86400으로 지정하면 1일 동안 CDN에서 캐싱을 하고 있다는 뜻입니다. 

최초 클라이언트가 CloudFront에 리소스 요청합니다. CloudFront에는 아직 해당 리소스가 캐싱되어있지 않습니다. 오리진 리소스인 S3에서 데이터를 가져오게 됩니다 이때 Cache-Control 헤더 값의 s-maxage값을 보고 캐싱 시간을 지정합니다. 

마치며

간단히 CDN을 활용하여 REST API Response(JSON) 캐싱 방법을 알아보았습니다.

하지만 보통 서버에서도 이미 다양한 방법으로 캐싱으로 응답 시간 줄이고 서버 부하를 줄이고 있습니다. 동적 컨텐츠를 CDN으로 옮길 이유는 없습니다. 하지만 특수한 상황이라면 해당 캐싱 방법도 고려해 볼 수 있습니다. CDN을 사용하여 응답 시간을 단축시키고 무엇보다 서버 트래픽 부하를 아예 서버가 아닌 CDN으로 옮길 수 있는 장점이 있습니다.

 

+a) 비용

서버(EC2) vs CDN(S3/CloudFront) 비용은 상황에 따라 다릅니다. 캐싱 단위, 시간, 크기, 트래픽에 따라 달라지게 됩니다. 예제로 단순 비교했을 때 서울 리전 기준 cdn 캐싱이 더 저렴합니다.

- 데이터 전송 비용(서울/100TB 이상, 1GB 당)  EC2(0.117$), CloudFront(0.095$)

- EC2: 인스턴스 운영/관리 비용 추가

- CloudFront: HTTP 요청, 캐시 무효화, S3 비용 추가

---

Reference

- AWS Docs: 컨텐츠가 캐시에 유지되는 기간(만료) 관리

- Amazon S3 now delivers strong read-after-write consistency automatically for all applications

- [Re2020] S3가 더 넓은 범위의 Strong Consistency 모델을 제공합니다 (Feat. S3 업데이트 이모저모)

- 웹 서비스 캐시 똑똑하게 다루기

- AWS S3 비용 

- AWS CloudFront 비용

- AWS EC2 비용