캐싱객체(원본으로부터 캐싱엔진에 저장된 콘텐츠)는 TTL(Time To Live) 동안 유효하며 서비스된다.
HTTP 규격은 TTL을 설정할 수 있도록 Cache-Control 을 명시하고 있다.
하지만 이는 절대적인 것은 아니다.
다양한 방식의 TTL 정책과 Purge 를 통해 서비스 품질을 높일 수 있다.
기본적으로 TTL은 원본서버의 응답에 따라 결정된다.
TTL이 만료되기 전까지 저장된 콘텐츠로 서비스 된다.
TTL이 만료되면 원본서버로 콘텐츠 변경여부( If-Modified-Since 또는 If-None-Match )를 확인한다.
원본서버가 304NotModified 응답을 준다면 TTL은 연장된다.
원본서버 종료로 인해 응답이 오지 않는 경우에는 장애판단이 명확하지만 간혹 정상적으로 응답하면서 장애상황인 경우가 발생한다.
예를 들어 콘텐츠를 저장하는 스토리지와의 연결을 잃거나, 뭔가 정상처리가 불가능하다고 판단하는 경우가 있을 수 있다.
전자의 경우 4xx응답(주로 404NotFound ), 후자는 5xx응답(주로 500InternalError )을 받게된다.
하지만 이미 관련 콘텐츠가 저장되어 있다면,
원본의 응답을 믿는 것보다 TTL을 연장시켜 서비스 전체장애가 발생하지 않도록 하는편이 효과적이다.
고화질 동영상이나 게임처럼 상대적으로 반응성보다 전송속도가 중요한 서비스에서는 이런 방식이 큰 문제가 되지 않는다.
대용량 데이터의 경우 원본서버가 10초만에 갱신에 대한 응답을 한다고 하더라도 전송에 몇 분씩 소요되기 때문에 상대적으로 원본의 반응성이 크게 중요하지 않다.
오히려 접근 빈도가 높지 않은 콘텐츠이기 때문에 반드시 갱신확인이 이루어져야 한다.
하지만 쇼핑몰과 같은 경우 상황은 다르다.
웹 페이지는 빠르게 로딩되는 것이 무엇보다 중요하다.
1~2초 안에 클라이언트 화면구성이 모두 끝나야 한다.
전송속도보다 반응속도가 더 중요하다는 말이다.
이때 TTL이 만료되어 원본서버에게 갱신확인을 해야 한다면 매우 큰 지연이 발생할 수 있다.
보통의 쇼핑몰이 수백만개의 콘텐츠를 동시에 서비스 하는 것을 감안할 때 항상 원본서버로부터 갱신확인 작업이 발생하고 있다고 생각해야 한다.
자칫 원본서버 장애가 발생하거나 네트워크 장애가 발생한다면 최악이다.
우리가 원하는 것은 어떠한 원본서버의 장애나 지연으로부터 캐싱된 콘텐츠가 안전하게 전송되는 것이다.
