캐싱 면접 퀴즈

캐시 기본과 캐시 계층

캐시가 통하는 조건

• 읽기가 쓰기보다 훨씬 많다 (읽기:쓰기 10:1 이상)
• 접근이 일부 데이터에 집중된다 (상위 20% 키가 트래픽 대부분)
• 약간 낡은 데이터를 허용할 수 있다
• 원본 조회가 비싸다 (복잡한 조인, 외부 API 호출)

요청 경로의 캐시 계층

[브라우저 캐시]
      |
   [CDN / 엣지]
      |
[앱 로컬 캐시]
      |
[Redis 등 분산 캐시]
      |
[DB 버퍼 풀] -> [디스크]

실무 포인트

• 히트율 = hits / (hits + misses). Redis는 INFO stats의 keyspace_hits / keyspace_misses로 계산
• 히트율이 낮으면 메모리 증설보다 키 설계와 TTL을 먼저 의심한다
• 쓰기가 잦은 데이터를 캐싱하면 무효화 비용이 이득을 넘는다
• 캐시는 원본을 대신하지 못한다. DB가 죽으면 캐시만으로 오래 버티지 못한다

캐시 읽기와 쓰기 전략

전략 비교

Cache-Aside 읽기 흐름

GET key -> 미스
        -> DB SELECT
        -> SET key value EX ttl
        -> 응답

실무 포인트

• 대부분의 서비스 기본값은 Cache-Aside. 캐시가 죽어도 DB로 서비스가 유지된다
• 갱신 시 캐시를 새 값으로 덮기보다 삭제가 안전하다. 동시 갱신에서 옛 값이 덮어쓰는 경합을 피한다
• Write-Back은 주문과 결제처럼 유실이 치명적인 데이터에는 쓰지 않는다
• 작성 직후 상세 화면처럼 쓰고 바로 읽는 경로가 있으면 쓰기 시점에 캐시를 채우는 방식을 검토

TTL과 캐시 무효화

무효화 방식

• TTL 만료: 가장 단순. 불일치를 허용할 시간을 초 단위로 명시한다
• 키 삭제: 쓰기 트랜잭션 커밋 후 관련 키를 DEL
• 버전 키: 키에 버전을 넣어 user:42:v7처럼 쓰고 구버전은 자연 만료시킨다
• 조건부 재검증: HTTP ETag / If-None-Match로 변경 없으면 304 응답

TTL 선택 기준

실무 포인트

• 키에 정렬, 필터, 페이지 같은 파라미터를 모두 담는다. 조건이 다른 목록이 같은 키를 쓰면 잘못된 응답이 나간다
• 삭제는 반드시 커밋 이후에. 커밋 전에 지우면 롤백 시 캐시가 잘못 채워진다
• 대량 키에 동일 TTL을 주면 만료가 한꺼번에 몰린다. TTL에 지터를 더해 분산한다
• 무효화 누락은 조용히 오래 살아남는다. 캐시 키 생성과 삭제 지점을 코드에서 한곳으로 모은다