cache는 읽기를 빠르게 하지만 원본과 캐시가 달라지는 순간이 생깁니다. cache invalidation은 TTL로 시간이 지나면 버리거나, 데이터 변경 시 명시적으로 삭제하거나, write-through/write-behind 같은 정책으로 갱신 타이밍을 정하는 문제입니다. 핵심은 빠른 응답과 최신성 사이의 trade-off를 요구사항에 맞게 고르는 것입니다.
꼬리질문
조금 더 깊게 물어본다면
답변 뒤에 이어질 수 있는 질문들을 하나씩 열어볼 수 있어요.
TTL만 두면 충분한가요?
변경 빈도가 낮고 stale 허용 시간이 명확하면 충분할 수 있습니다. 하지만 즉시 반영이 필요한 데이터라면 변경 시 삭제나 갱신이 필요합니다.
cache stampede는 무엇인가요?
캐시가 동시에 만료되어 많은 요청이 한꺼번에 원본 저장소로 몰리는 현상입니다. lock, jitter, stale-while-revalidate 등으로 줄일 수 있습니다.
데이터가 바뀔 때 캐시를 지울지 갱신할지는 어떻게 정하나요?
값을 다시 계산하는 비용이 낮고 다음 요청에서 자연스럽게 채워도 된다면 삭제가 단순합니다. 반대로 최신 값을 바로 보여줘야 하거나 cache miss 비용이 크다면 갱신을 고려할 수 있습니다.
중요한 것은 캐시를 “어떻게 저장할지”보다, 원본 데이터 변경 시점과 캐시 변경 시점을 어떻게 맞출지입니다.
stale data를 허용해도 되는 예시는 무엇인가요?
추천 목록, 조회수, 덜 민감한 통계처럼 약간 늦게 반영되어도 사용자 피해가 작은 데이터입니다.
캐시 무효화 정책은 어디서 정해야 하나요?
기술 선택 전에 비즈니스 요구사항에서 정해야 합니다. 결제 상태와 인기 게시글 목록은 최신성 요구가 다릅니다.
부가 설명
캐시는 넣는 것보다 빼는 것이 어렵다는 말이 있습니다. 상품 가격이 바뀌었는데 캐시에 예전 가격이 남아 있으면 성능은 좋아도 서비스는 틀린 답을 보여줍니다. 그래서 어떤 데이터가 얼마나 오래 stale해도 되는지 먼저 정해야 합니다.
Cache invalidation은 TTL, explicit invalidation, cache stampede, write-through/write-back과 함께 봐야 합니다. 모든 데이터를 항상 최신으로 만들려고 하면 캐시의 장점이 줄어들고, 너무 오래 두면 정합성 문제가 커집니다.
한 줄 정리
cache invalidation은 캐시의 빠름과 데이터 최신성 사이의 기준을 정하는 문제입니다.