TTL (Time To Live)

캐싱객체(원본으로부터 캐싱엔진에 저장된 콘텐츠)는 TTL(Time To Live) 동안 유효하며 서비스된다. HTTP 규격은 TTL을 설정할 수 있도록 Cache-Control 을 명시하고 있다. 하지만 이는 절대적인 것은 아니다. 다양한 방식의 TTL 정책과 Purge 를 통해 서비스 품질을 높일 수 있다.

Note

간단 요약

  • TTL이란 저장된 콘텐츠의 유효시간이다.

  • TTL을 길게 설정하면 원본서버의 부하는 줄어들지만 변경사항이 늦게 반영된다.

  • TTL을 짧게 설정하면 너무 잦은 변경확인 요청으로 원본서버 부하가 높아진다.

  • 운영의 묘미는 TTL을 적절히 설정하여 원본부하를 줄이는 것에 있다.

  • TTL은 한번 설정되면 만료되기 전까지 바뀌지 않는다.

  • 새로운 TTL은 파일이 만료되었을 때 적용된다.

기본

기본적으로 TTL은 원본서버의 응답에 따라 결정된다. TTL이 만료되기 전까지 저장된 콘텐츠로 서비스 된다. TTL이 만료되면 원본서버로 콘텐츠 변경여부( If-Modified-Since 또는 If-None-Match )를 확인한다. 원본서버가 304 Not Modified 응답을 준다면 TTL은 연장된다.

See also

  • ref-functions-network-cahce-ttl-resCode - 응답코드별 TTL 설정

  • ref-functions-network-cahce-ttl-custom - 커스텀 TTL 설정

비정상 TTL 연장

원본서버 종료로 인해 응답이 오지 않는 경우에는 장애판단이 명확하지만 간혹 정상적으로 응답하면서 장애상황인 경우가 발생한다. 예를 들어 콘텐츠를 저장하는 스토리지와의 연결을 잃거나, 뭔가 정상처리가 불가능하다고 판단하는 경우가 있을 수 있다. 전자의 경우 4xx응답(주로 404 Not Found ), 후자는 5xx응답(주로 500 Internal Error )을 받게된다.

하지만 이미 관련 콘텐츠가 저장되어 있다면, 원본의 응답을 믿는 것보다 TTL을 연장시켜 서비스 전체장애가 발생하지 않도록 하는편이 효과적이다.

See also

  • ref-functions-network-cahce-ttl-policies - TTL 고급정책

정상적인 서버라면 5xx 로 응답하지 않는다. 주로 서버의 일시적인 장애로부터 콘텐츠를 무효화하여 원본부하를 가중시키지 않기 위한 용도로 사용된다.

갱신정책

TTL이 만료된 콘텐츠의 경우 원본서버에서 갱신여부를 확인한 뒤 서비스가 이루어진다.

../../../_images/perf_refreshexpired.jpg

변경확인 후 응답

  1. TTL이 유효하다. 즉시 응답한다.

  2. TTL이 만료되어 원본서버로 변경확인(If-Modified-Since)을 요청한다. 변경확인이 될때까지 클라이언트에게 응답하지 않는다.

  3. 원본서버에서 응답이 오면 TTL을 연장하거나 콘텐츠를 변경(Swap)한다. 원본서버에서 확인이 되었으므로 클라이언트에게 응답한다.

  4. 변경확인이 된 콘텐츠이므로 다음 TTL 만료시까지 즉시 응답한다.

See also

  • ref-functions-network-cahce-purge

고화질 동영상이나 게임처럼 상대적으로 반응성보다 전송속도가 중요한 서비스에서는 이런 방식이 큰 문제가 되지 않는다. 대용량 데이터의 경우 원본서버가 10초만에 갱신에 대한 응답을 한다고 하더라도 전송에 몇 분씩 소요되기 때문에 상대적으로 원본의 반응성이 크게 중요하지 않다. 오히려 접근 빈도가 높지 않은 콘텐츠이기 때문에 반드시 갱신확인이 이루어져야 한다.

하지만 쇼핑몰과 같은 경우 상황은 다르다. 웹 페이지는 빠르게 로딩되는 것이 무엇보다 중요하다. 1~2초 안에 클라이언트 화면구성이 모두 끝나야 한다. 전송속도보다 반응속도가 더 중요하다는 말이다.

이때 TTL이 만료되어 원본서버에게 갱신확인을 해야 한다면 매우 큰 지연이 발생할 수 있다. 보통의 쇼핑몰이 수백만개의 콘텐츠를 동시에 서비스 하는 것을 감안할 때 항상 원본서버로부터 갱신확인 작업이 발생하고 있다고 생각해야 한다. 자칫 원본서버 장애가 발생하거나 네트워크 장애가 발생한다면 최악이다.

우리가 원하는 것은 어떠한 원본서버의 장애나 지연으로부터 캐싱된 콘텐츠가 안전하게 전송되는 것이다.

../../../_images/perf_refreshexpired2.jpg

장애가 두렵지 않다!

이런 차이점 때문에 백그라운드 콘텐츠 갱신기능이 제공된다.

# functions.network.cache.purge

"refreshExpired": true

만약 콘텐츠의 변경이 아주 드문 경우라면 이 설정을 false 로 변경하는 것이 효과적이다.

../../../_images/perf_refreshexpired5.jpg

변경에 민감하지 않다면 기다리지 않는다.

위 그림에서 원본서버와의 갱신작업이 모두 백그라운드로 이루어지기 때문에 캐싱된 콘텐츠는 기다림없이 즉시 클라이언트에게 서비스된다. 원본서버가 304 Not Modified 로 응답한다면 TTL만 연장된다.

파일이 갱신되어 원본서버에서 200 OK 를 응답한 경우 해당 파일이 완전히 다운로드된 후에 파일이 부드럽게 교체된다. 콘텐츠가 바뀌어도 이전 콘텐츠(초록색)를 다운로드 받던 사용자들은 정상적으로 다운로드가 진행된다.

파일 교체 이후 접근된 사용자들(겨자색)은 바뀐 파일로 서비스 된다. 콘텐츠 갱신, 네트워크 장애, 원본서버 장애 등 어떠한 변수에도 콘텐츠 갱신은 백그라운드로 진행되기 때문에 실제 서비스에는 전혀 지연이 없다.

갱신불가시 정책

콘텐츠의 TTL은 만료되었지만 원본서버가 모두 배제되어 정상적으로 콘텐츠를 갱신(Revalidate)할 수 없을 때의 정책을 설정한다.

See also

  • ref-functions-network-cahce-ttl-policies - TTL 고급정책

예를 들어 다음과 같이 설정되어 있다면 콘텐츠를 갱신할 수 없을 때, 만료된 콘텐츠를 404 Not Found 로 응답한다.

# functions.network.cache.ttl.policies

"unvalidatableObjectResCode": 404

클라이언트 no-cache 요청시 TTL만료

클라이언트 HTTP요청에 no-cache 설정이 하나 이상 명시된 경우 해당 콘텐츠를 즉시 만료시킬 수 있다.

GET /logo.jpg HTTP/1.1
...
cache-control: no-cache 또는 cache-control:max-age=0
pragma: no-cache
...

만료된 콘텐츠는 갱신정책 에 따른다.

See also

  • ref-functions-network-cahce-purge