Foundry
캐시/Redis
기초

로컬 캐시 vs 분산 캐시

인스턴스 메모리냐 공용 Redis냐, 지연과 정합성의 교환

로컬 캐시 vs 분산 캐시

비교

구분로컬 (인프로세스)분산 (Redis 등)
조회 지연메모리 접근 수준네트워크 왕복 포함
용량프로세스 힙 한도수평 확장 가능
정합성인스턴스마다 값이 다를 수 있음모든 인스턴스가 같은 값
재시작매번 비워짐유지됨
운영 비용추가 인프라 없음별도 서버와 운영 필요

2단계 캐시

요청 -> [L1 로컬] 미스 -> [L2 Redis] 미스 -> [DB]
         짧은 TTL          긴 TTL

실무 포인트

  • 로컬 캐시의 진짜 문제는 무효화다. 인스턴스가 10대면 지울 곳도 10군데다
  • 그래서 로컬 TTL은 짧게 두고 불일치가 남는 시간을 스스로 제한한다
  • 거의 변하지 않는 설정과 코드 테이블은 로컬 캐시가 압도적으로 유리하다
  • 항목 수 상한을 반드시 설정한다. 무제한 로컬 캐시는 힙을 늘려 GC 지연을 만든다
  • 무효화 전파가 필요하면 Pub/Sub 알림이나 서버 보조 클라이언트 캐싱(트래킹)을 쓴다
면접에서 이렇게 나옵니다

Q.로컬 캐시와 분산 캐시를 어떤 기준으로 나눠 쓰나요?

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

Q.로컬 캐시를 여러 인스턴스에서 쓸 때 무효화는 어떻게 하나요?

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

Q.2단계 캐시 구성에서 각 계층의 TTL은 어떻게 정하나요?

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

Q.로컬 캐시가 GC에 미치는 영향은?

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.

더 깊이 공부하기

읽었으면 문제로 확인해보세요

캐시/Redis 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.