[부하를 견디는 서버의 비밀, Redis] 캐싱(Caching)의 개념 2

이 글은 인프런 딩코딩코의 백엔드 이력서 차별화 전략 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.

---

언제 캐시를 만료시켜야할까? - 캐시 만료 정책

앞서 어떤 데이터를 캐싱하면 좋을지 알아봤다.

🤔 그렇다면 이렇게 캐싱된 데이터는 언제까지 캐시에 남아 있어야 할까?

     한 번 저장된 캐싱 데이터는 계속해서 유효할 수 있을까?

 

현실의 백엔드 서버에서는 다양한 요청을 처리하는 과정에서 데이터가 지속적으로 생성, 수정, 삭제되며 원본 DB의 내용도 계속해서 변하게 된다.

즉, 원본 데이터가 지속적으로 변경되는 상황에서 처음에 캐싱된 데이터가 계속해서 유효하다고 볼 수는 없다.

 

만약 캐시를 적절히 만료시키지 않거나, 원본 데이터의 변경 사항을 캐시에 반영하지 못한다면

캐시 데이터와 원본 DB 간에 불일치가 발생하게 된다.

 

즉, 데이터 일관성이 손상되어 신뢰할 수 없는 상태가 된다.

실제 서비스라면, 사용자에게 오래되거나 잘못된 정보를 제공하게 되는 심각한 문제가 발생할 수 있다.

 

또한 캐시 시스템의 용량은 제한적이다.

캐시 시스템에 불필요한 데이터를 계속 유지하면 캐시 히트율이 떨어지고, 그로 인해 전체 캐싱 효율이 저하된다.

 

따라서 불필요한 캐시 데이터를 적절한 시점에 만료시켜 캐싱 효율성과 데이터 일관성을 함께 관리해야 한다.

 

📝 정리하면, 데이터 일관성을 유지하고 캐시의 효율적 활용을 위해서는

"캐시 데이터를 언제, 어떻게 만료시킬지?"를 결정하는 캐시 만료 방식을 정해야한다.

(캐시 만료 : cache eviction)

 

백엔드에서 일반적으로 사용되는 대표적인 캐시 만료 방식

1. TTL

가장 기본적인 캐시 만료 방식은 TTL(Time To Live)이다.

캐시가 생성된 시점으로부터 일정 시간이 지나면 자동으로 만료되는 방식이다.

설정이 간단하고, 캐시가 유지되는 동안에는 캐시 데이터를 재사용할 수 있다.

 

이러한 특성 때문에, 데이터가 일정 시간동안만 유효해도 되는 경우에 가장 간단하고 효과적인 만료 전략으로 널리 사용된다.

 

⚠️ 하지만 TTL을 사용하는 방식은 원본 데이터 변경 여부를 고려하지 않는다.

즉, 원본 데이터가 변경됐더라도 TTL이 만료되기 전이라면 캐시가 계속 유지된다.

따라서, 원본 데이터 변경이 즉시 반영이 필요한 경우는 TTL 적용만으로는 부족할 수 있다.

 

2. 명시적 무효화

원본 데이터가 변경되는 경우, 백엔드 서버의 로직에서 명시적으로 캐시를 제거하는 방식이다.

즉, 데이터 변경과 동시에 캐시를 만료시켜 최신 데이터를 즉시 반영할 수 있도록 한다.

 

⚠️ 하지만 이 방식이 효과적으로 동작하려면 중요한 전제 조건이 하나 필요하다.

→ 서버가 원본 데이터의 변경 시점을 정확히 감지할 수 있어야 한다는 점이다.

만약 데이터가 변경되었음에도 서버가 이를 알 수 없다면.

언제 캐시를 무효화해야 할 지 판단할 수 없어 오래된 데이터가 그대로 유지되는 문제가 발생한다.

 

다음 예시를 살펴보면 어떤 경우에 서버가 데이터 변경을 감지할 수 있는지 이해할 수 있다:

1) API를 통한 데이터 수정

우리 서버가 직접 처리하므로 변경 시점을 정확히 알 수 있다.

 

2) 백오피스 어드민을 통한 DB 수정

어드민 기능도 우리 시스템 내부에 있기 때문에 변경을 추적할 수 있다.

 

3) 외부 시스템에서 DB를 직접 수정

외부에서 직접 DB를 수정하면 우리 서버는 이를 감지할 수가 없다.

 

이처럼 감지 불가능한 경로가 존재한다면,

명시적 무효화 방식만으로는 완전한 캐시 정합성을 보장할 수 없다. (실데이터와 캐싱 데이터가 일치하는가?)

 

우리에게 데이터 변경 사실을 알려주지 않으니,

서버는 캐시가 최신인지 아닌지를 판단할 수 없다.

즉, 명시적 무효화가 불가능한 구조인 셈이다.

 

이 질문은 결국 다음의 본질적인 고민으로 이어진다.

"우리 서비스는 데이터 변경 사항을 얼마나 빠르게 반영해야 하는가?"

 

- 데이터 변경을 즉시 반영해야 하는 경우에는

명시적 무효화 혹은 TTL 조합 등 정합성 중심의 전략이 필요하다

- 반대로 약간의 지연을 허용할 수 있다면,

일정 주기로 캐시를 갱신하는 주기적 리프레시 방식도 고려할 수 있다.

---

✅ 정리하면, 캐시 만료 전략은 다음과 같은 기준으로 결정할 수 있다.

1. 앞서 배운 "어떤 데이터를 캐싱해야 할까?"를 바탕으로 적절한 캐시 대상을 선정한다,.
2. 기본적으로 캐시 시스템의 효율적인 용량 관리를 위해 TTL을 설정하는 것이 좋다.
3. 원본 데이터 변경이 즉시 반영될 필요가 없다면, TTL 설정 만으로 충분하다.
4. 원본 데이터 변경을 즉시 반영해야 하고 모든 변경 시점을 파악할 수 있다면, 명시적 무효화 방식을 적용한다.
5. 데이터 변경 유즈 케이스 중 일부만 감지할 수 있다면, 일정 시간의 반영 지연을 감수하고 TTL + 명시적 무효화를 조합해서 사용한다.
6. 일부 데이터 변경 시점을 알 수 없고, 원본 데이터 변경 시 즉시 반영이 반드시 필요하다면, 캐싱을 적용할 수 없다.