[OS] 로컬 캐시와 분산 캐시

WeeklyPaper: 로컬 캐시와 분산 캐시의 개념 차이와 각각의 장단점, 그리고 실무에서 어떤 기준으로 선택해야 하는지 설명해주세요.

---

캐시(Cache)와 캐싱(Caching)

• 캐시 (Cache)
  • 데이터나 값을 미리 복사해 놓는 임시로 저장해두는 고속 메모리를 가리킨다.
  • 캐시의 유형은 여러가지가 있다 - CPU 캐시 (CPU와 RAM사이의 속도를 줄이기 위해 사용됨, L1-L3), 메모리 캐시, 웹 브라우저 캐시, 등
• 캐싱 (Caching)
  • Cache + ing = 데이터를 캐시에 저장하고 필요할 때 빠르게 접근하는 기법이다. 캐싱을 통해 데이터 접근하는 시간을 줄이거나 값을 다시 계산하는 시간을 절약하고 싶을 경우에 사용한다.
  • 캐싱의 전략은 여러가지가 있다 - LRU, FIFO, LFU, Write-Through, Write-Back, 등

로컬 캐시 (Local Cache)

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

어플리케이션 서버가 실행될 때, 캐시 데이터도 해당 서버의 힙 메모리(Heap Memory)영역에 함께 존재한다. 만약 여러 대의 서버 인스턴스가 실행중이라면 각 인스턴스는 자신만의 독립적인 로컬 캐시 저장소를 갖는다.

• 대표적인 구현체는 Caffeine, Ehcache, Guava Cache, Java ConcurrentHashMap이 있다.
• 장점
  • 굉장히 빠른 속도 - 아무래도 어플리케이션 내부 메모리에서 직접 데이터를 읽으므로 네트워크를 통신할 필요가 없어서 속도가 매우 빠르다.
  • 간단한 구현 - 별도의 외부 시스템이나 인프라 구축 없이 라이브러리 추가만 하면 쉽게 사용 가능하다.
• 단점
  • Scale out에 약함 - 한 서버에서 데이터가 변경되어 캐시가 갱신되어도 다른 서버에서는 변경사항이 즉시 반영되지 않아서 데이터 정합성이 깨진다.
  • 메로기 한계 - 캐시 데이터가 많아지면 애플리케이션의 GC 부담을 증가시킨다
  • 휘발성 - 어플리케이션 인스턴스가 재시작되면 로컬 캐시는 삭제된다.
• 실무 선택 기준
  • 데이터 변경이 거의 없는 경우
  • 데이터 일관성이 크게 상관없을 경우 (서비스에 큰 문제 없을 경우)
  • 굉장히 빠른 속도가 필요할 경우
  • 단일 서버 환

분산 캐시

별도의 외부 서버에 데이터를 중앙 집중식으로 저장하는 방식이다. 모든 어플리케이션 인스턴스들은 네트워크를 통해 이 공용 캐시 서버(또는 클러스터)에 접근하여 데이터를 읽고 쓴다.

• 대표적인 구현체는 Redis, Memcached가 있다.
• 장점
  • 데이터 일관성 - 모든 인스턴스는 동일한 중앙 캐시 저장소를 바라본다. 한 곳에서 데이터가 갱신되면 다른 모든 인스턴스도 갱신된 데이터를 조회할 수 있다.
  • 확장성 굿 - 어플리케이션 메모리와 분리해서 저장하므로 캐시 서버 자체의 스케일업/아웃이 자유롭다.
  • 데이터 영속성 - Redis같은 일부 구현체는 디스크에 저장할 수 있게 하여 캐시 서버가 재시작해도 캐시는 삭제되지 않는다.
• 단점
  • 네트워크 지연 - 데이터를 조회할 때마다 네트워크 호출 (round trip)이 발생하고 이는 로컬 캐시보다 느릴 수 밖에 없다.
  • 로컬 캐시보다 인프라 구축이 더 필요하다
• 실무 선택 기준
  • 데이터 일관성이 필수적인 경우
  • 어플리케이션 메모리에 담기에는 너무 큰 데이터를 캐싱해야 할때
  • 데이터가 자주 변경되지만 이 변경 사항이 모든 서버에 즉시 전파되어야 할때

Redis가 자주 쓰이는 방법:

---

연습 질문 1: 응답 속도를 극도로 높이기 위해 로컬 캐시(L1)와 분산 캐시(L2)를 함께 사용하는 '2-Level 캐시' 아키텍처를 도입했습니다. 그런데 DB 데이터가 변경되어 L2(Redis)의 값이 갱신되었을 때, L1(로컬 캐시)에 남아있는 이전 데이터는 어떻게 실시간으로 동기화하거나 무효화(invalidate)할 건가요?

• 가장 표준적인 해결책은 Pub.Sub (발행/구독) 모델입니다. Redis의 Pub/Sub 기능을 사용하면 데이터가 변경될 때 변경됐다는 이벤트를 특징 채널로 발행합니다. 각 다른 서버의 어플리케이션 인스턴스들은 이 채널을 subscribe하고 있다가, 이벤트가 발행되면 자신의 로컬 캐시(L1)에서 해당 키를 삭제하면 됩니다.