캐시 전략

캐시 종류

캐시는 로컬 캐시와 글로벌 캐시로 나뉜다.

캐시를 적용하기에 앞서 개념을 살펴보자.

로컬 캐시(Local Cache)

로컬 캐시는 애플리케이션 내부 메모리(JVM)에 데이터를 저장하는 캐시 방식이다.

애플리케이션 프로세스 내부에서 직접 접근하기 때문에
네트워크 왕복 비용이 없고, 조회 성능이 매우 빠르다는 특징을 가진다.
대표적으로 Caffeine, Guava가 있다.

• 특징

  • 애플리케이션 내부 메모리에 캐시 저장
  • 네트워크 호출 없이 메모리 직접 접근
  • 조회 속도가 매우 빠름
  • 서버 인스턴스별로 캐시가 각각 존재
  • 서버 재시작 시 캐시 데이터가 초기화됨

• 단점

  • 서버 인스턴스 간 캐시가 공유되지 않음
  • 다중 서버 환경에서는 데이터 정합성이 맞지 않을 수 있음
  • 캐시 갱신 전략(TTL, Eviction)에 대한 고려가 필요함

글로벌 캐시(Global Cache)

글로벌 캐시는 애플리케이션 외부에 별도의 캐시 서버를 두고 데이터를 저장하는 방식이다.
여러 서버 인스턴스가 하나의 캐시를 함께 사용하며,
대표적으로 Redis나 Memcached가 있다.

애플리케이션과 분리된 캐시 서버를 통해 데이터를 조회하기 때문에
네트워크 통신이 발생하지만,
여러 서버가 동일한 캐시 데이터를 공유할 수 있다는 특징을 가진다.

• 특징

  • 애플리케이션 외부(별도 캐시 서버)에 캐시 저장
  • 여러 서버 인스턴스가 동일한 캐시 데이터 공유
  • 서버 재시작과 무관하게 캐시 유지 가능
  • 대규모 트래픽 환경에서 일관된 캐시 제공에 유리

• 단점

  • 네트워크 왕복 비용 발생
  • 캐시 서버 장애 시 서비스 전반에 영향 가능
  • 별도의 인프라 운영 및 관리 비용 필요
  • 구조가 상대적으로 복잡해짐

캐시 만료 전략

캐시 만료 전략에는 대표적으로 TTL(Time To Live)과 명시적 무효화 방식이 있다.

두 방식은 캐시를 언제, 어떤 기준으로 제거할 것인지에 대한 접근 방식이 다르며
데이터의 변경 특성에 따라 적합한 전략이 달라진다.

TTL(Time To Live)

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

이 방식은 원본 데이터의 변경 여부와 관계없이 설정된 만료 시간에 따라 캐시를 제거한다.

따라서 원본 데이터가 변경되더라도
TTL이 만료되기 전까지는 기존 캐시 데이터가 유지되며,
데이터 변경이 즉시 반영되어야 하는 경우에는 한계가 있다.

다만 구현이 단순하고 운영 부담이 적어,
변경 빈도가 낮거나 일정 수준의 지연을 허용할 수 있는 데이터에는 적합하다.

명시적 무효화

명시적 무효화는 데이터 변경이 발생하는 시점에 백엔드 로직에서 직접 캐시를 제거하는 방식이다.

데이터가 변경됨과 동시에 캐시를 무효화하기 때문에
항상 최신 데이터를 즉시 반영할 수 있다는 장점이 있다.

하지만 모든 데이터 변경 지점을 정확히 인지하지 못하는 경우,
캐시를 언제 무효화해야 할지 판단하기 어렵다.

이 경우 캐시가 제거되지 않은 채로 남아
오래된 데이터가 지속적으로 제공될 위험이 있다.

캐시 읽기 전략

캐시를 적용할 때는 데이터 접근 패턴과 읽기/쓰기 비율에 따라 적합한 전략을 선택할 수 있다.
대표적으로 읽기 집중형(Read-Heavy)과 쓰기/읽기 혼합형(Read-Write Mixed) 전략이 있다.

읽기 집중형(Read-Heavy)

읽기 요청이 압도적으로 많고 데이터 변경은 드문 경우에 적합하다.

예: 상품 목록 조회 시마다 카테고리를 참조하지만, 카테고리 변경은 관리자만 수행하고 거의 발생하지 않는 경우

장점: 캐시 활용 시 성능 개선 효과가 크다. DB 조회를 최소화하여 응답 속도를 높일 수 있다.

단점: 데이터가 변경될 경우 캐시와 DB 간 일시적인 불일치 가능성이 있다.

이 전략은 카테고리, 설정 값, 정적 레퍼런스 데이터처럼 구조가 작고 자주 바뀌지 않는 데이터에 적합하다.

쓰기/읽기 혼합형(Read-Write Mixed)

읽기와 쓰기가 모두 자주 발생하는 경우, 캐시를 단순히 읽기용으로만 두기 어렵다.

예: 재고, 주문 상태, 사용자 잔액 등 즉시 정합성이 필요한 데이터

장점: 캐시를 쓰기와 읽기 모두에 활용하면 DB 부하를 줄일 수 있다.

단점: 캐시와 DB 간 동기화 로직이 복잡하고, 캐시 무효화 실패 시 오래된 데이터를 제공할 수 있다.

이 경우는 명시적 무효화와 TTL 보조를 병행하거나, 캐시보다 DB 직접 조회 중심으로 설계하는 것이 안전하다.