캐시 전략: 계층, 읽기·쓰기 패턴, 교체 정책, 장애 패턴

캐시란

캐시(cache)는 느린 원본 대신 빠른 저장소에 결과 사본을 두고 다시 쓰는 장치다. 원본은 DB, 다른 서비스, 디스크, 멀리 있는 서버 등이다. 사본은 메모리나 사용자 가까운 곳에 둔다.

캐시가 빠른 이유는 참조 지역성(locality of reference)이다. 방금 요청된 데이터는 곧 다시 요청되기 쉽다. 캐시는 용량을 내주고 속도를 얻는다. 원본(DB)이 완전하고 영속적인 데 비해 캐시는 데이터의 일부만 잠시 담는다. 대개 휘발성 메모리에 두므로 캐시를 영구 저장소로 쓰지 않는다.

• 적중(hit): 찾는 값이 캐시에 있어 캐시가 답한다.
• 미스(miss): 캐시에 없어 원본에서 읽고, 보통 그 값을 캐시에 채운다.
• 차가운 캐시(cold cache): 재시작·배포 직후처럼 캐시가 비어 거의 모든 요청이 미스인 상태다. 요청이 쌓이며 채워지면 따뜻한(warm), 자주 쓰는 데이터가 다 들어 있어 적중률이 높으면 뜨거운(hot) 캐시라 부른다.

캐시는 공짜가 아니다. 사본을 두는 순간 원본과 사본이 어긋날 수 있다는 문제가 생긴다. 그래서 캐시 설계는 세 질문으로 정리된다.

언제 효과가 큰가

• 읽기가 쓰기보다 훨씬 많다. 같은 결과를 여러 번 재사용할수록 이득이다.
• 데이터가 자주 바뀌지 않는다. 자주 바뀌면 무효화 비용이 이득을 먹는다.
• 원본 접근이 비싸다. 무거운 쿼리, 먼 네트워크, 외부 API.
• 약간 오래된 값을 허용한다. 강한 일관성이 필요한 값(잔액, 재고 차감)은 캐시를 판단 근거로 쓰지 않는다.

반대로 캐시가 도움이 안 되는 경우도 분명하다.

• 캐시 조회가 원본 조회만큼 오래 걸린다(원본이 이미 메모리 DB이거나 바로 옆에 있다).
• 요청이 거의 반복되지 않는다. 무작위성이 크면 적중률이 나오지 않는다.
• 데이터가 너무 자주 바뀌어 사본이 금방 낡고, 결국 매번 원본을 봐야 한다.

캐시는 어디에나 있다

요청이 지나가는 거의 모든 층에 캐시가 있다.

flowchart LR
  b["브라우저<br/>HTTP 캐시"] --> cdn["CDN<br/>엣지 캐시"] --> lb["로드 밸런서<br/>응답 캐시"] --> svc["서비스<br/>로컬 메모리 (+ 디스크)"] --> dc["분산 캐시<br/>Redis 등"] --> db["DB<br/>버퍼 풀, 머티리얼라이즈드 뷰"]
  subgraph side["옆길"]
    mb["메시지 브로커 (디스크에 보존)"]
    se["검색엔진 (색인 = 질의용 사본)"]
  end

여러 서버가 캐시를 함께 쓰는 방식은 둘로 나뉜다.

HTTP 캐시는 읽기 관통(read-through) 방식이다. 클라이언트는 캐시에 묻고, 캐시가 답하지 못할 때만 캐시가 서비스에 묻는다. 웹 아키텍처 전체에서 캐시가 놓이는 자리는 웹 확장성의 구성 요소에 있다.

읽기·쓰기 패턴

캐시와 DB를 어떻게 맞추느냐에 따라 다섯 패턴이 있다. 읽기 둘, 쓰기 셋이다.

읽기

쓰기

flowchart LR
  subgraph wt["Write-through (둘 다 끝나야 응답)"]
    a1["앱"] --> c1["캐시"] --> d1["DB"]
  end
  subgraph wa["Write-around (캐시는 다음 읽기 때 채움)"]
    a2["앱"] --> d2["DB"]
  end
  subgraph wb["Write-back (비동기·일괄 반영)"]
    a3["앱"] --> c3["캐시"] -.-> d3["DB"]
  end

패턴은 섞어 쓴다. 가장 흔한 조합은 cache-aside + write-around다. 쓸 때 DB를 갱신하고 캐시 키를 지우면(invalidate), 다음 읽기가 최신 값을 다시 채운다. 키를 「갱신」하지 않고 「삭제」하는 이유는 동시에 들어온 두 쓰기가 캐시에 순서를 뒤바꿔 남기는 경쟁을 줄이기 위해서다.

Write-back은 조회수·좋아요처럼 잃어도 치명적이지 않고 쓰기가 폭주하는 값에 어울린다. 하드웨어의 CPU 캐시도 같은 쓰기 정책 구분을 쓴다(캐시 메모리와 가상 메모리).

교체 정책

캐시가 꽉 차면 무언가를 내보내야(evict) 한다. 무엇을 내보내느냐가 적중률(hit ratio) 을 정한다.

• 2계층 캐시(two-tier caching)는 교체 정책이라기보다 배치 전략이다. 1차는 프로세스 메모리, 2차는 분산 캐시에 둔다. 1차는 빠르지만 서버마다 내용이 다르므로 TTL을 짧게 둔다.
• 실제 제품은 이론적 정책을 근사한다. Redis는 표본을 몇 개 뽑아 그중에서 LRU·LFU를 고르는 근사 알고리즘을 쓰고, 자바 Caffeine 같은 로컬 캐시는 빈도와 최근성을 섞은 W-TinyLFU를 쓴다.

무효화 방식과 Memcached

캐시를 비우는 방법은 세 가지다. 시간 만료(TTL), 무기한 저장 후 이벤트로 삭제(데이터가 바뀌는 코드에서 키를 지운다), 버전 번호를 키에 넣고 바뀔 때 올리기(user:42:v7 → v8. 옛 키는 아무도 읽지 않으니 LRU가 자연히 치운다). 셋째는 삭제 누락이나 경쟁 조건 없이 한 번에 여러 키를 무효화할 수 있다.

Memcached는 이런 단순 캐시의 표준이다. 서버끼리 서로 모르고, 서버 목록 관리와 키 분배는 클라이언트 몫이다. 클라이언트가 hash(key) % 서버 수로 고르면 서버 하나가 빠질 때 거의 모든 키 자리가 바뀌어 캐시 전체가 식으므로, 일관된 해싱 클라이언트를 쓴다(데이터베이스 샤딩). 복제와 장애 조치가 없고 키를 나열할 수 없으며, 값 크기 기본 상한은 1MB다. 접근 제어는 SASL 인증과 1.5.13부터 지원하는 TLS(--enable-tls로 빌드, -Z로 켬)로 하지만 기본은 꺼져 있어, 민감한 데이터를 넣을 때는 네트워크로 막는다.

• 렌더링한 페이지 조각을 담는 출력 캐시는 빠르지만 언어·로그인 상태 같은 의존성이 많고, DB 결과를 담는 데이터 캐시는 의존성 추적이 쉽다.
• 여러 키는 multi-get으로 한 번에 가져와 왕복을 줄인다.
• 캐시로 DB 튜닝을 대신하지 않는다. 낡은 데이터 버그는 재현이 어려우니 캐시 코드에도 단위 테스트를 둔다.

캐시가 DB를 무너뜨리는 네 가지 경우

캐시가 있으면 DB는 캐시가 막아 주는 만큼의 트래픽만 견디도록 작게 설계되기 쉽다. 그래서 캐시가 제 역할을 못 하는 순간 DB가 한꺼번에 무너진다.

평소:

flowchart LR
  A["요청 100"] --> B["캐시(적중 95)"] --> C["DB 5"]

캐시 실패 시:

flowchart LR
  A["요청 100"] --> B["캐시(적중 0)"] --> C["DB 100<br>20배"]

블룸 필터(Bloom filter)는 「확실히 없다」 또는 「아마 있다」만 답하는 작은 확률적 자료구조다. 「없다」는 틀리지 않으므로 없는 키를 DB 앞에서 버리기에 알맞다. 「있다」는 가끔 틀리므로 그 경우에는 캐시와 DB를 확인한다. 데이터가 추가될 때 필터도 함께 갱신해야 한다.

핫 키를 로컬 캐시로 흡수하고 장애 노드를 걸러 내는 운영 기법은 캐시 클러스터 운영과 장애 대응에 있다.

캐시 지표

정리

• 캐시는 요청 경로의 모든 층에 있고, 사본을 두는 순간 원본과의 일관성 문제가 따라온다.
• 읽기는 cache-aside가 기본이고, 쓰기는 DB 갱신 + 캐시 키 삭제(write-around 계열)가 가장 흔하다. Write-back은 빠르지만 잃을 수 있는 값에만 쓴다.
• 교체 정책은 LRU가 기본값이고, 스캔에 약한 점을 SLRU·LFU 계열이 보완한다. TTL은 정책이라기보다 안전망이다.
• 캐시 장애는 DB 장애로 번진다. TTL 지터, null 캐싱과 블룸 필터, single-flight, 이중화와 서킷 브레이커로 막는다.
• 캐시는 나중에 붙일 수 있다. 측정해서 적중률이 나올 곳에만 넣는다.

관련 노트: Redis, 캐시 클러스터 운영과 장애 대응, 웹 확장성의 구성 요소, HTTP 캐시, CDN, 대규모 트래픽에서 서비스를 지키는 설계, 백엔드 지연 시간 줄이기