개요
같은 검색어로 반복되는 조회 요청이 많다고 가정했을 때,
DB에 매번 접근하는 것은 비효율적이다.
검색 결과는 자주 바뀌지 않는 데이터이므로
일정 시간 동안 캐싱해두는 것이 유리하다.
두 가지의 서버 캐시
대표적으로 두 가지의 서버캐시를 많이 사용한다.
인메모리 캐시, 리모트 캐시이다.
인메모리(In-Memory) 캐시
로컬 메모리 캐시(Local Memory Cache)라고도 한다.
JVM 내부 또는 애플리케이션 안에 데이터를 캐싱하는 방식이다.
- 대표 라이브러리: EhCache, CaffeineCache
- 사용 방식: @Cacheable 어노테이션 기반 AOP 방식
- 기본 구현체: ConcurrentMapCache`
장점
- 캐시 접근 속도가 매우 빠르다.
(ex. 거실에서 화장실 가는 거리처럼 가깝다) - 외부 시스템(Redis, DB 등)에 의존하지 않는다.
- 설정이 간단하고 별도 인프라(ex. Docker)가 필요 없다.
단점
- 서버가 재시작되면 캐시가 초기화된다. (휘발성)
- 서버 간에 캐시가 공유되지 않는다.
(스케일 아웃 시 동일 데이터에 대해 중복 조회 가능) - 전역 동기화에 딜레이가 생길 수 있다.
추후에 서버 확장(Scale-out)을 생각한다면, Remote Cache를 사용하는 것이 바람직하다.
❓ Scale-out (스케일 아웃)
Scale-out: 서버를 여러 대 추가하여 시스템을 확장하는 것을 말한다.Scale-out 환경에서 인메모리 캐시는 서버 간 공유되지 않음
서버마다 캐시가 따로 존재 → 중복 DB 접근, 효율 저하
Remote Cache
서버(스프링 부트) 외부에 Redis, Memcached 등의 별도 저장소를 두고 사용하는 캐시다.
- 대표 라이브러리: Redis, Memcached
- 네트워크를 통해 접근하므로 속도는 인메모리보다 느릴 수 있다.
- 여러 서버가 캐시를 공유할 수 있으므로
스케일 아웃에 적합하다.
❓ 인메모리(로컬) 캐시는 언제 합리적으로 사용할 수 있을까?
보통의 캐싱구현을 생각했을 때, 레디스(Remote Cache)를 떠올린다.
인메모리 캐시를 염두해두지 않을 수 있지만, 각 개발상황에 따라 달라질 수 있다고 생각한다.
레디스를 도입한다는건 외부시스템 하나를 도입한다는 것이고,
이는 곧 비용이 증가된다는 뜻이기 때문이다!
따라서 분산서버가 아니면서 서버간 데이터가 공유되지 않아도 되고, 서버가 재부팅되어도 캐싱이 되어있지 않아도 되는 데이터이라면 인메모리 캐시 적용을 고려해볼 수 있다.
출처
개발바닥 인메모리캐시
[네이버페이] 인메모리캐시 CaffeinCache vs EhCache
[사용자 추천 피드] 인메모리캐시 적용
[관리자페이지 5초마다 회원수 조회] 인메모리 캐시 적용
인메모리 캐시 리팩토링
