캐싱 전략 (Caching Strategy)
목차
캐싱 전략이란
캐싱 전략(Caching Strategy) 은 어떤 데이터를, 어디에, 어떤 방식으로 캐시할지 결정하는 설계 작업입니다.
이 문서는 시스템 설계 관점에서 왜 캐시가 필요한지, 언제 어떤 패턴을 도입할지, 그 대가가 무엇인지를 설명합니다.
TTL 설정, eviction policy, stampede 대응 같은 구현·운영 상세는 캐싱 문서를 함께 보면 더 직접적입니다.
캐시를 설계할 때는 보통 다음을 함께 봅니다.
- 무엇이 병목인가: 데이터베이스인지, 외부 API인지, 정적 자산인지
- 어떤 읽기가 반복되는가: 같은 요청이 얼마나 자주 재사용되는가
- 얼마나 오래된 데이터를 허용할 수 있는가: stale data 허용 범위
- 캐시 장애 시 원본이 버틸 수 있는가: miss 폭증과 fallback 경로
즉, 캐싱 전략은 “Redis를 붙이자”가 아니라 지연 시간, 비용, 정합성 사이의 균형점을 찾는 설계 문제입니다.
왜 캐시를 도입하는가
캐시는 보통 다음 목적 중 하나 때문에 도입합니다.
- 응답 시간 단축: 원본 저장소보다 빠른 계층에서 결과를 반환
- 원본 부하 감소: 데이터베이스나 외부 API 호출 수 감소
- 피크 트래픽 흡수: 갑작스러운 조회 폭증을 완충
- 비용 절감: 비싼 원본 계층 증설을 늦춤
하지만 캐시는 만능이 아닙니다.
- 원본이 느린 이유가 락 경합이나 잘못된 쿼리라면 캐시만으로는 해결이 제한적입니다.
- 캐시를 강하게 쓰면 stale data, stampede, invalidation 문제가 따라옵니다.
- 캐시 miss가 늘었을 때 원본이 버티지 못하면 장애가 더 커질 수 있습니다.
면접에서는 “캐시는 빠르다”보다, 캐시가 줄여주는 병목과 새로 만들어내는 복잡성을 같이 설명하는 편이 좋습니다.
캐시 유형
캐시는 보통 배치 위치에 따라 다르게 설계합니다.
| 유형 | 장점 | 주의점 | 적합한 경우 |
|---|---|---|---|
| CDN / Edge Cache | 사용자와 가까운 위치에서 응답 가능 | 무효화와 배포 전략이 중요 | 이미지, 정적 파일, 공개 콘텐츠 |
| 애플리케이션 로컬 캐시 | 네트워크 홉이 없어 가장 빠름 | 인스턴스별 불일치 가능 | 설정값, 짧은 TTL의 소형 데이터 |
| 분산 캐시 | 여러 인스턴스가 같은 캐시를 공유 | 네트워크 비용과 캐시 장애 영향 | 세션, 조회 결과, 공통 참조 데이터 |
| 데이터베이스 캐시 | 원본 바로 앞에서 병목 완화 | 쿼리 패턴과 정합성 설계 필요 | 반복 조회가 많은 핵심 테이블 |
여기서 중요한 점은 캐시 위치가 달라지면 설계 질문도 달라진다는 것입니다.
- CDN은 “어떤 응답을 얼마나 오래 엣지에 둘 것인가”1
- 애플리케이션 캐시는 “인스턴스 간 불일치를 감수할 수 있는가”
- 분산 캐시는 “네트워크 비용과 캐시 장애를 어떻게 다룰 것인가”
- DB 캐시는 “원본 데이터 변경 시 어떻게 무효화할 것인가”
즉, 캐시는 하나가 아니라 문제 유형에 따라 다른 계층에 둘 수 있는 선택지입니다.
대표 캐시 패턴
캐시 전략에서 자주 나오는 패턴은 다음과 같습니다.2
| 패턴 | 핵심 아이디어 | 장점 | 주의점 |
|---|---|---|---|
| Cache-Aside | 읽을 때 미스면 원본 조회 후 캐시 채움 | 범용적이고 메모리 효율이 좋음 | 첫 요청 지연과 invalidation 설계 필요 |
| Read-Through | 애플리케이션 대신 캐시 계층이 원본 조회를 대행 | 애플리케이션 코드가 단순해질 수 있음 | 캐시 계층 책임이 커지고 제품 의존이 생길 수 있음 |
| Write-Through | 원본에 쓸 때 캐시도 함께 갱신 | 읽기 시 최신 데이터가 캐시에 있을 가능성 높음 | 자주 안 읽는 데이터도 캐시에 남을 수 있음 |
| Write-Back | 먼저 캐시에 쓰고 나중에 원본 반영 | 쓰기 burst 완화와 낮은 쓰기 지연 | 장애 시 유실 위험과 운영 복잡도 큼 |
Cache-Aside
가장 많이 쓰는 기본 패턴입니다.
- 캐시 조회
- miss면 원본 조회
- 조회 결과를 캐시에 저장
- 다음 요청부터 캐시 hit
이 패턴은 단순하고 범용적이지만, 쓰기 직후 stale data를 어떻게 막을지가 핵심 설계 포인트입니다.
Read-Through
캐시 계층이 miss를 감지하면 애플리케이션 대신 원본 저장소에서 데이터를 읽어 캐시를 채우는 방식입니다.
- 장점: 애플리케이션이 miss 처리 코드를 덜 가져가도 됩니다.
- 단점: 캐시 제품이나 미들웨어에 더 강하게 의존할 수 있습니다.
그래서 설계 관점에서는 Cache-Aside와 비슷한 목적을 가지지만, 캐시 책임을 애플리케이션이 질지 캐시 계층이 질지가 차이점이라고 설명하면 좋습니다.
Write-Through
원본 저장소에 쓸 때 캐시도 함께 갱신하는 방식입니다.
- 장점: 읽기 시 캐시 hit 확률이 높음
- 단점: 자주 안 읽는 데이터도 캐시에 올라가 오염이 생길 수 있음
즉, 읽기 비중이 높고 최신성이 비교적 중요한 데이터에 더 잘 맞습니다.
Write-Back
먼저 캐시에 반영하고 나중에 비동기로 원본에 저장하는 방식입니다.
- 장점: 쓰기 경로가 빠르고 spike를 흡수하기 좋음
- 단점: 캐시 장애나 flush 실패 시 데이터 유실 위험이 큼
그래서 통계, 로그, 비핵심 집계처럼 약간의 지연이나 손실을 감수할 수 있는 워크로드에서 더 적합합니다.
관련 구현 상세와 추가 패턴은 캐싱 문서에서 더 자세히 다룹니다.
캐시 무효화 전략
캐시 설계에서 가장 어려운 부분은 성능보다 무효화(Invalidation) 입니다.
대표 전략은 다음과 같습니다.
- TTL 기반 만료: 일정 시간이 지나면 자동 만료
- 쓰기 시 삭제: 원본 데이터 갱신 후 캐시를 지움
- 쓰기 시 갱신: 새 값을 즉시 캐시에 반영
- 버전 키 사용: 키에 버전을 붙여 이전 캐시를 자연스럽게 폐기
- 이벤트 기반 무효화: 데이터 변경 이벤트를 받아 관련 캐시를 정리
| 전략 | 장점 | 주의점 |
|---|---|---|
| TTL 기반 | 단순하고 운영이 쉬움 | 정확한 최신성 보장은 약함 |
| 쓰기 시 삭제 | 구현이 단순하고 많이 쓰임 | 짧은 구간의 miss 폭증 가능 |
| 쓰기 시 갱신 | 최신성 확보에 유리 | 여러 계층 캐시가 있으면 복잡도 증가 |
| 이벤트 기반 | 다중 서비스 환경에서 유연함 | 순서, 중복, 재시도 설계 필요 |
면접에서는 “TTL 5분”처럼 숫자만 말하기보다, 왜 stale data를 허용할 수 있는지 또는 왜 즉시 무효화가 필요한지를 업무와 연결해야 답변이 강해집니다.
예를 들면:
- 상품 상세 페이지는 짧은 stale data를 허용할 수 있음
- 결제 가능 금액이나 재고 수량은 훨씬 더 보수적으로 다뤄야 함
언제 캐시를 도입할까
캐시는 초기에 무조건 넣는 기능이 아니라, 병목이 보였을 때 우선순위를 판단해 넣는 경우가 많습니다.
도입을 검토할 시점은 보통 다음과 같습니다.
- 같은 조회가 반복되고 hit ratio가 높을 것으로 예상될 때
- DB나 외부 API가 이미 병목으로 관측될 때
- 읽기 비중이 압도적으로 높을 때
- 피크 트래픽 시 원본 계층 보호가 필요할 때
반대로 아직 캐시를 늦추는 편이 나은 경우도 있습니다.
- 데이터 변경이 매우 잦아 무효화가 더 어려울 때
- 트래픽이 아직 작아 원본이 충분히 버틸 때
- 쿼리 최적화나 인덱스 조정이 먼저인 경우
즉, 좋은 답변은 “캐시는 항상 넣는다”가 아니라 원본 최적화로 버틸 수 있는지 먼저 보고, 반복 조회와 피크 보호가 필요할 때 도입한다는 흐름입니다.
캐싱 전략의 트레이드오프
- 장점: 응답 시간을 줄이고, 원본 부하를 완화하며, 피크 트래픽 대응력을 높일 수 있습니다.
- 단점: 정합성 문제, 무효화 복잡도, 장애 전파 가능성이 커집니다.
- 주의점: 캐시가 있으면 평균 latency는 좋아져도, 캐시 miss 시 원본이 버틸 수 있는지까지 같이 봐야 합니다.
특히 다음 오해를 피해야 합니다.
- 캐시를 넣으면 성능 문제가 자동으로 해결되는 것은 아님
- 히트율이 높다고 설계가 좋은 것은 아님
- stale data를 감수할 수 없는 업무에 같은 전략을 쓰면 안 됨
좋은 캐싱 전략은 성능 향상보다도 어떤 데이터에 얼마나 오래된 값을 허용할지 명확히 정한 전략입니다.
면접 포인트
- 캐싱 전략은 도구 선택보다 병목과 stale data 허용 범위를 먼저 정하는 문제입니다.
- CDN, 애플리케이션 캐시, 분산 캐시는 같은 캐시라도 설계 질문이 다릅니다.
- Cache-Aside는 기본 선택지지만 invalidation 전략까지 함께 말해야 답변이 강합니다.
- 캐시는 원본 최적화를 대체하는 것이 아니라, 반복 조회와 피크 보호를 위한 보조 계층입니다.
- 좋은 답변은 hit ratio뿐 아니라 miss 시 원본이 버틸 수 있는지도 같이 설명합니다.