캐시(Cache)

“컴퓨터 과학에서 어려운 것은 딱 두 가지다. 캐시 무효화, 그리고 이름 짓기(Phil Karlton)”

참고

💵 캐시가 동작하는 아주 구체적인 원리

캐시의 개념과 장점

HTTP caching

CPU Caches

CPU 칩에는 여러 개의 캐시가 들어가며, 각각의 캐시는 각자의 목적과 역할을 가지고 있다. 오늘날 CPU 칩의 면적 30~70% 는 캐시가 차지한다.

• L1 Cache : 프로세서와 가장 가까운 캐시. 속도를 위해 I$ 와 D$로 나뉜다.
  → Instruction Cache(I$): 메모리의 TEXT 영역 데이터를 다루는 캐시
  → Data Cache(D$): TEXT 영역을 제외한 모든 데이터를 다루는 캐시
• L2 Cache : 용량이 큰 캐시. 크기를 위해 L1 캐시처럼 나누지 않는다.
• L3 Cache : 멀티 코어 시스템에서 여러 코어가 공유하는 캐시

성능 측정

• 캐시의 성능을 측정할 때, Hit Latency와 Miss Latency가 중요한 요인으로 꼽힌다.
• Hit : CPU에서 요청한 데이터가 캐시에 존재하는 경우
• Miss Latency : Miss 가 발생해 상위 캐시에서 데이터를 가져오거나, 메모리에서 데이터를 가져올 때 소요되는 시간
• Miss Rate = [ CacheMisses / CacheAccesses ]
• Average Access Time = Hit Latency+ MissRate*MissLatency

구성

캐시는 반응 속도가 빠른 SRAM(Static Random Access Memory)으로, 주소가 키(Key)로 주어지면, 해당 공간에 즉시 접근할 수 있다.

• 캐시가 하드웨어로 구현한 해시 테이블과 같다.
• 캐시는 블록(Block)으로 구성되어 있다.
  → 각각의 Block은 데이터를 담고 있으며, 주소 값을 키로써 접근할 수 있다. 블록의 개수와 블록의 크기가 캐시의 크기를 결정한다.

1. Indexing: 주소값 전체를 키로 사용하지 않고, 그 일부만을 사용
   → 전체 주소에서 하위 5 비트를 오프셋으로 쓰고, 이후 10 비트를 인덱스로 사용하여 블록에 접근했다.
   → 서로 다른 데이터의 인덱스가 중복될 위험
2. Tag Matching: 인덱스의 충돌을 줄이기 위해 주소값의 일부를 태그(Tag)로 사용한다.
   → Tag Overhead
3. Associative Cache: 태그 배열과 데이터 배열을 여러 개 만드는 식으로 개선
   1) Direct Mapped: 인덱스가 가리키는 공간이 하나인 경우. 처리가 빠르지만, 충돌 발생이 잦다.
   2) Fully Associative: 인덱스가 모든 공간을 가리키는 경우. 충돌이 적지만, 모든 블록을 탐색해야 해서 속도가 느리다.
   3) Set Associative: 인덱스가 가리키는 공간이 두 개 이상인 경우.

언제 캐시를 쓸 것인가?

• Write Through: 캐시에 데이터가 작성될 때마다 메모리의 데이터를 업데이트 하는 것. 메모리와 캐시의 데이터가 동일하게 유지.
• Write Back: 블록이 교체될 때만 메모리의 데이터를 업데이한다.

HTTP 캐시

• 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치
• 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여줌
• 캐시는 네트워크 병목을 줄여줌. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 된다.
• 캐시는 원서버에 대한 요청을 줄여줌. 서버는 부하를 줄일 수 있으며, 더 빨리 응답할 수 잇게 된다.
• 캐시는 거리로 인한 지연을 줄인다. 페이지를 먼 곳에서 불러올수록 시간이 많이 걸린다.

적중과 부적중

[ 재검사 Revalidation ( 신선도 검사 ) ]

• 사본이 여전히 최신인지 서버를 통해 점검
• 그 사본이 검사를 할 필요가 있을정도로 충분히 오래된 경우에만 재검사
  → 변경되지 않았다면, 서버는 아주 작은 304 Not Modified 응답을 보냄
  → 변경되었다면 평범한 HTTP 200 OK 응답을 보낸다.
  → 404 Not Found : 캐시는 사본을 삭제한다.
• 문서 적중률: 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지
  → 트랜잭션은 고정된 소요시간을 포함하게 되는데, 시간이 길 수도 있기 때문에, 문서 적중률을 개선하면 전체 대기시간이 줄어든다.
• 바이트 단위 적중율: 얼마나 많은 바이트가 인터넷으로 나가지 않았는지
  → 대역폭 절약
• 응답이 캐시에서 왔는지, 서버에서 왔는지 확인하려면,
  응답의 Data 헤더 값과 응답의 생성일 비교
  → 응답이 얼마나 오래되었는지 말해주는 Age 헤더 이용

캐시 토폴로지

캐시는 한명의 사용자에게만 할당 될 수도 있고, 수천명의 사용자들 간에 공유될 수도 있다.

• 개인 전용 캐시
• 공용 프락시 캐시
• 프락시 캐시 계층들 → 더 큰 부모 캐시가 걸러 남겨진 트래픽을 처리하도록 함
• 캐시 계층이 깊다면 프락시 연쇄가 길어짐 → 성능 저하
• 캐시망: 캐시 커뮤니케이션 결정을 동적으로 내림
• 콘텐츠 라우팅: URL 에 근거하여, 특정 부모 캐시, 원서버를 동적으로 선택
• 피어링: HTTP는 형제 캐시를 지원하지 않기 때문에, ICP(인터넷 캐시 프로토콜)이나 하이퍼텍스트 캐시 프로토콜(HTCP)같은 프로토콜을 이용해 HTTP 확장

캐시 처리 단계

1. 요청받기: 네트워크 커넥션에서의 활동을 감지하고, 들어오는 데이터를 읽어들인다.
2. 파싱: 요청 메시지를 여러 부분으로 파싱하여 헤더 부분을 조작하기 쉬운 자료구조에 담는다.
3. 검색: 로컬 사본이 있는지 검사
4. 신선도 검사
5. 응답 생성
6. 전송
7. 로깅

문서 만료

• 문서 만료: HTTP는 Cache-Control (max-age: 문서의 최대 나이 정의) 과 Expires라는 헤더들을 이용하여
  원서버가 각 문서에 유효기간을 붙일 수 있게 해준다.
• 캐시 된 문서가 만료되면,
  캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, (변경이 없으면 304 Not Modified)
• 만약 그렇다면 신선한 사본을 얻어와야 한다. (새 유효기간과 함께)

서버 재검사

• If-Modified-Since: 날짜 재검사
• If-None-Match: 엔터티 태그 재검사

캐시제어

아래는 HTTP는 문서가 얼마나 오랫동안 캐시될 수 있게 할 것인지,
서버가 설정할 수 있는 여러 가지 방법이다.

1. Cache-control: no-cache
2. Cache-control: no-store
3. Cache-control: must-revalidate
4. Cache-Control: max-age=<seconds>
5. Cache-control: s-maxage=<seconds>
6. Expires 날짜 헤더를 응답에 첨부할 수 있다.
7. 아무 만료 정보도 주지 않고,
   캐시가 스스로 체험적인(휴리스틱 heuristic) 방법으로 결정하게 할 수 있다.