캐싱 면접 퀴즈

캐시가 통하는 근거는 지역성입니다. 최근에 쓴 것이 또 쓰이기 때문에 소수를 담아두고도 적중률이 높아집니다.

캐시 기본과 캐시 계층

캐시가 통하는 조건

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

요청 경로의 캐시 계층

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

캐시를 넣기 전에 확인할 것

캐시는 공짜가 아닙니다. 넣으면 낡은 값이 보이는 구간과 무효화할 자리가 생깁니다. 그래서 이득이 그 비용을 넘는지 먼저 봅니다.

세 번째가 결정적입니다. 얼마나 낡아도 되는지가 곧 수명이고, 그 값이 0이면 캐시가 아니라 다른 방법을 찾아야 합니다.

적중률이 낮을 때 무엇을 의심하나

메모리를 늘리는 것은 마지막입니다. 그 앞에 볼 것이 있습니다.

키가 너무 세분화돼 있지 않나: 사용자마다 다른 키면 재사용이 없다
수명이 너무 짧지 않나: 쓰이기 전에 사라진다
캐시할 대상이 아닌 것을 담지 않았나: 조회가 고르게 퍼진 데이터

키 설계가 적중률의 대부분을 정합니다. 같은 답을 여러 사용자가 쓸 수 있게 키를 묶으면 적중률이 크게 오릅니다. 반대로 키에 사용자 정보를 넣으면 재사용이 사라집니다.

실무 포인트

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

갱신 대신 삭제를 쓰는 것이 핵심입니다. 삭제는 멱등해서 여러 번 해도 결과가 같고, 순서가 뒤바뀌어도 안전합니다.

캐시 읽기와 쓰기 전략

전략 비교

Cache-Aside 읽기 흐름

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

왜 지우는 쪽이 안전한가

값을 고칠 때 캐시를 새 값으로 덮는 것과 지우는 것 중에 지우는 쪽이 대개 낫습니다.

덮기는 순서를 보장할 수 없습니다. 두 갱신이 거의 동시에 일어나면 캐시에 어느 것이 남을지 알 수 없습니다. 지우면 그 문제가 사라집니다. 대신 다음 읽기 하나가 느립니다.

쓰기를 미루면 무엇을 잃나

캐시에 먼저 쓰고 원본에 나중에 쓰면 쓰기가 빨라집니다. 대가는 명확합니다.

캐시가 죽으면 아직 원본에 안 간 것이 사라진다
그래서 잃어도 되는 것에만 쓴다
조회수나 마지막 접속 시각 같은 것

돈이나 주문에는 쓰지 않습니다. 반대로 조회수를 매번 원본에 쓰면 그것이 DB 부하의 큰 몫이 되므로, 이쪽은 미루는 것이 맞습니다.

실무 포인트

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

TTL과 캐시 무효화

무효화 방식

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

TTL 선택 기준

수명을 정하는 것은 제품 결정이다

기술로 정할 수 없습니다. 얼마나 낡아도 되는지를 정해야 나오는 값입니다.

마지막 줄이 요점입니다. 즉시 반영이 필요하면 수명이 아니라 지우기입니다. 수명을 아주 짧게 잡아 흉내 내면 적중률만 잃습니다.

수명이 한꺼번에 끝나면

같은 시각에 채운 키들은 같은 시각에 만료됩니다. 배포 직후나 캐시를 비운 뒤에 특히 그렇습니다.

그 순간 모두가 원본으로 몰린다
수명에 약간의 무작위를 섞어 만료를 흩는다

이것은 키가 많을수록 심해집니다. 하나가 만료되는 것은 문제가 아니지만 만 개가 동시에 만료되는 것은 문제입니다.

실무 포인트

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