웹 캐시

본 내용은 "HTTP 완벽 가이드" 와 모든 개발자를 위한 HTTP 웹 기본 지식 내용을 참고하여 기록한 정리본입니다.

• 정말 중요한 챕터이다.
  • 반드시 이해하고 넘어가야 한다.

캐시의 장점

• 불필요한 데이터 전송을 제거
  • 같은 데이터가 반복해서 요청될 경우, 네트워크 대역폭이 낭비되는 공간이 생길 수 있다.
  • 데이터 저장을 계층화하여, 중복된 트래픽을 제거할 수 있다.
• 네트워크 병목을 제거
  • 클라이언트가 서버에 접근할 때의 속도 = 그 경로에 있는 가장 느린 네트워크의 속도이다.
  • 일반적으로 원격 서버보다 로컬 네트워크가 더 넓은 대역폭을 제공하기 때문에,
  • 빠른 LAN에 있는 캐시로부터 사본을 가져오면, 성능 개선이 가능하다.
• 오프로딩(Offloading)
  • 원서버에 대한 요청 수를 완화할 수 있다.
  • 갑작스런 요청 쇄도에 의한 원 서버의 부하를 완화한다.
• 거리로 인한 지연 완화
  • 사용자의 위치에 가까운 캐시 서버에서 데이터를 제공하여 응답 지연을 줄인다.

캐시 히트/캐시 미스

캐시 히트

• 캐시 내에 요청받은 데이터가 존재할 경우를 말한다.

캐시 미스

• 캐시 내에 요청받은 데이터가 존재하지 않을 경우를 의미한다.

캐시 revalidate 히트

• 캐시 내에 요청받은 데이터가 신선하지 않을 가능성이 있어
• Revalidate를 진행하였을 때, 해당 사본이 여전히 유효한 경우를 의미한다.

캐시 revalidate 미스

• 캐시 내에 요청받은 데이터가 신선하지 않을 가능성이 있어
• 재검사를 진행하였을 때, 원본이 갱신된 경우를 의미한다.

잠깐 - 캐시 재검사(Revalidation)

• Revalidation이란?
  • 원서버를 통해 캐시의 신선도 검사를 수행하는 것.
• 캐시의 신선도 검사란?
  • 캐시 데이터가 원서버가 갖고있는 것과 동일한 최신 데이터인지 검증하는 것.
• 캐시는 스스로 원한다면 언제든지 사본을 revalidate 할 수 있다.
  • 효율적으로 재검사하기 위해, 그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 수행한다.

Revalidate hit

• 재검사를 진행했을 때, 데이터가 여전히 신선한 경우

• 위와 같이, 304 응답과 함께 Body 없는 응답을 보낸다.

Revalidate miss

• 재검사를 진행했을 때, 데이터가 갱신된 경우
  • 평범한 200 OK 응답을 제공받는다.
  • 캐시에 해당 데이터를 저장한다.

적중률

• 문서 적중률
  • 요청 당 캐시의 적중 여부를 측정한 뒤 백분율로 환산한 것
• 바이트 적중률
  • 바이트 단위 당 캐시의 적중 여부를 측정한 뒤 백분율로 환산한 것
• 어느정도가 적당할까?
  • 정적 콘텐츠 기준으로는, 95% 이상을 권장한다.
    (출처: Cloudflare - 캐시 적중률)

cf. 프록시 캐시의 경우 클라이언트는 응답이 캐시 히트였는지 원 서버 접근이었는지 알 방법이 없다.

• 응답 코드가 두 경우 모두 200 OK 일 것이기 때문이다.
• Date 헤더를 이용해 추정은 가능하다.
  • 현재 시각과 Date 헤더를 비교
  • Date 헤더가 훨씬 예전이라면, 캐시된 데이터라는 것
• 혹은 Age 헤더를 이용하여서 추정할 수도 있다.
  • 응답이 얼마나 오래되었는가 확인

캐시 토폴로지(형태)

개인 전용 캐시와 공용 캐시의 구분

a) 개인 전용 캐시, b) 공용 프록시 캐시

개인 전용 캐시

• 웹 브라우저가 사용하는 캐시를 의미한다.
• 브라우저 내에서, "임시 파일"이라고 불린다.

공용 프록시 캐시

• 서로 다른 클라이언트를 위해 사용하는 캐시 서버를 의미한다.
  • 사용자에 입장에서 서버에 접근하기도 하고,
  • 로컬 캐시에서 캐시된 문서를 찾아 클라이언트에게 반환하기도 한다.
• 인터셉트 프록시를 이용해
  • 브라우저의 설정 없이
  • HTTP 요청이 캐시를 통하도록 강제할 수 있다.

캐시 프록시 서버

공용 프록시 캐시 - 캐시 프록시 서버의 설계 방식에 대해 알아보자.

프록시 캐시 계층 방식

• 캐시 계층을 두어
  • 작은 캐시에서 캐시 미스가 발생 시, 더 큰 부모 캐시가 미스된 트래픽을 처리하도록 하는 것을 의미한다.
• 하지만, 캐시 계층이 지나치게 길어지면, 디버깅 및 유지보수가 어려워진다.
  • “이 문제, 어느 프록시에서 발생한 문제지?”
• 또한, 추가 홉에 따른 서버 레이턴시가 길어질 수 있다.
• 일반적으로 프록시를 2~3개 정도만 거치도록 제한한다.

캐시 네트워크 방식

• 좀 더 복잡한 캐시 망 구성 및 동적 라우팅 시에 사용한다.
  • 어떤 부모 캐시와 대화시킬 것인지
  • 아니면 캐시를 완전히 우회해서, 원 서버로 가도록 할 것인지
  • 캐시 간 피어링 지원
• 라우팅 방식
  • URL에 근거하여 부모 캐시와 원 서버 중 하나를 동적으로 선택
  • URL에 근거하여 특정 부모 캐시를 동적으로 선택
  • 부모 캐시에게 가기 전에 캐시된 사본을 로컬에서 찾아봄
  • 다른 캐시들이 특정 캐시 서버의 캐시된 콘텐츠에 부분적으로 접근할 수 있도록 허용
  • 해당 캐시 서버를 통한 인터넷 트랜짓(트래픽이 아예 다른 네트워크로 건너가는 것)은 허용하지 않는다.

cf. Peering vs. Transit

피어링

• 정의
  • 두 개 이상의 네트워크가 서로 직접 연결하여 트래픽을 교환하는 협정
  • 대체로 서로에게 트래픽 전송 비용 없이 (또는 매우 낮은 비용으로) 이루어지는 경우가 많음
• 비용 구조
  • 상호 합의 하에, 무료 또는 낮은 비용 지불
• 연결 방식
  • 대등한 네트워크 간의 직접적 연결
• 트래픽 경로
  • 짧고 직관적인 경로 제공
• 관리 및 운영
  • 피어링 협정 체결과 유지가 필요

트랜짓

• 정의
  • 한 네트워크(고객 네트워크)가 다른 네트워크(대형 ISP 또는 글로벌 통신사업자)의 연결성을 빌려 인터넷 전체(혹은 대다수의 네트워크)에 접근하는 모델
  • 고객 네트워크는 이 서비스를 받기 위해 대가를 지불함
• 비용 구조
  • 사용량 기반 혹은 정기적인 비용 지불 필요
• 연결 방식
  • 고객 네트워크와 대형 ISP 간의 위임된 연결 (하위-상위 관계)
• 트래픽 경로
  • 광범위한 글로벌 경로 제공 (다양한 네트워크에 연결)
• 관리 및 운영
  • 하나의 서비스 계약으로 다수의 네트워크와의 연결이 보장됨

선택 기준

• 트래픽 및 규모
  • 대규모 트래픽을 발생시키거나 비슷한 규모의 네트워크끼리는 피어링이 적합
  • 전 세계적으로 트래픽을 전달할 필요가 있는 소규모 네트워크는 트랜짓 서비스를 주로 활용
• 비용 효율성
  • 비용 절감과 네트워크 성능을 최적화하기 위해, 가능하다면 피어링을 선호
  • 피어링 계약을 맺기 어려운 경우 트랜짓을 선택

캐시 처리 단계

• 위 내용으로 갈음하겠다.

캐시 신선도 관리

• 두가지가 결정적인 역할을 한다
  • 문서 만료 기준은 무엇인가?
  • 서버의 Revalidate 방식은 어떤 방식을 따르는가?

문서 만료의 기준은 무엇인가?

유효기간과 나이, 두가지 방식으로 기준을 잡을 수 있다.

유효기간 - Expires 헤더

• 컴퓨터의 시계가 올바르게 맞춰져 있을 것을 요구하기 때문에, 요새는 잘 사용하지 않는다.

나이 - Cache-Control: max-age 속성

• Cache-Control 캐시 지시어 헤더의 max-age 속성을 활용한다.
• 초 단위로 캐시 유효시간을 지정할 수 있다.

서버 Revalidate

날짜 Revalidate

• Last-Modified를 참고하여 Revalidate를 수행한다.
  • 파일의 마지막 변경 시점
  • 서버 개발자가 임의로 변경 불가능하다.
• 클라이언트는 Last-Modified를 통해, If-Modified-Since(IMS) 헤더를 생성하여 요청을 송신한다.
• 서버는 IMS의 일치 여부로 파일의 변경 여부를 검사한다.
  • 변경되었을 경우, 성공 응답, 새로운 Last-Modified와 함께 데이터를 바디에 담아 전송한다.
  • 변경되지 않았을 경우, 304 Not Modified 헤더와 새 만료 날짜만을 반환한다.

ETag Revalidate

• ETag 헤더를 참고하여 Revalidate를 수행한다.
  • 서버 개발자가 자유롭게 만들 수 있는 해시 값
  • 서버 개발자가 임의로 해시 함수를 지정할 수 있다.
• 클라이언트는 ETag 헤더를 통해, If-None-Match 헤더를 생성하여 요청을 송신한다.
• 서버는 ETag의 일치 여부로 파일의 변경 여부를 검사한다.
  • 변경되었을 경우, 성공 응답, 새로운 ETag와 함께 데이터를 바디에 담아 전송한다.
  • 변경되지 않았을 경우, 304 Not Modified 헤더를 반환한다.

둘 다 사용할 수 있다.

• 둘 다 사용할 경우, 두 경우 모두 만족되어야만 304 응답을 반환해야 한다.

캐시 제어

• 캐시 허용 여부를 결정하는 방법과 가능한 문서 만료 정책을 알아보자.

Cache-Control

no-store

• 캐시 기능이 그 응답의 사본을 만드는 것을 금지한다.
• no-store 응답을 받게 되면, 객체를 그 즉시 삭제한다.

no-cache

• 데이터는 캐시해도 되지만, 항상 원 서버에 Revalidate하고 사용해야 한다.
  • 근데, 원 서버에 접근할 수 없는 경우, 캐시 서버 설정에 따라서 캐시 데이터를 반환할 수 있음에 주의하라.
• 캐시되지 않아야 한다는 뜻이 아니다. 이름에 주의하자.

max-age

• 캐시 유효 시간을 초 단위로 지정한다.

must-revalidate

• 캐시 만료후 최초 조회시 원 서버에 검증해야 한다.
  • 원 서버에 접근할 수 없는 경우, 항상 504 오류가 발생해야 한다.
• 원 서버 접근 실패시 반드시 504 오류가 발생해야 한다.
• must-revalidate는 캐시 유효 시간이라면 캐시를 사용한다.

Pragma

• HTTP/1.0 호환용이다.
• 일반적으로 캐시 제어 시 캐싱되는걸 막기 위해서만 사용된다.

Expires

• 지금은 더 유연한 Cache-Control: max-age 사용을 권장한다.
• Cache-Control: max-age와 함께 사용하면 Expires는 무시할 수 있고, 보통 무시된다.