[SpringBoot] 서버측 캐시(Cache)

---

0. 개요

서버측에서 Cache를 부르는 용어와 종류가 여러가지 있는거같아서 그에 대해 알아보기 위해 정리한다.

 

 

 

 

 

 

1. 로컬 캐시(Local Cache)

WAS내부의 자체 메모리(RAM) 공간을 직접 사용하는 방식이다.
네트워크로 별도의 캐시공간을 접근할 필요가 없어서 제일 빠르다!

대신 WAS를 재구동하면 로컬 캐시도 다 날아가서 그때는 캐시히트률이 낮을수밖에없다....

 

 

 

 

 

 

1-1.Java Caffeine

Java 8 이상에서 동작하는 고성능 로컬 캐싱 라이브러리이다.
Spring Boot에서도 의존성을 추가하면 어노테이션으로 간단하게 사용할수있다.

 

https://github.com/ben-manes/caffeine

 

@Cacheable(value = "categories")
public List<Category> getAllCategories() {
    return categoryRepository.findAll();
}

 

 

 

 

 

 

2. 리모트 캐시(Remote Cache)

캐시 데이터를 저장해 두는 공간이 WAS 밖에 있는 캐시를 의미한다.
네트워크 통신 비용은 발생하지만 WAS가 여러대일때도 데이터 정합성을 유지할수있고, WAS와 별개의 서버로 운용되기 때문에 WAS 서버가 재시작되어도 캐시를 그대로 유지할수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

3. Look-Aside 전략

데이터를 조회할 때 애플리케이션이 먼저 캐시를 확인하고, 데이터가 없을 때만 데이터베이스(DB)에서 조회하여 캐시에 저장하는 가장 표준적이고 널리 쓰이는 캐싱 전략이다.

기본적으로 캐시를 사용하는 방식을 떠올린다면 아마 이 전략을 Default로 가지고 사용하고있을 가능성이 높다.

 

 

 

 

 

 

 

4. 캐시 스탬피드 (Cache Stampede)

대규모 트래픽을 처리하는 백엔드 시스템에서 일어날수있는 문제 시나리오중 하나이다.

많은 트래픽이 몰리는 캐시데이터의 TTL이 만료되는 순간에도 많은 데이터 읽기 요청이 들어와 캐시 미스가 동시에 많이 발생하면서 동시에 수많은 애플리케이션 스레드요청이 DB쪽에 가해지는 상황이다.

 

 

 

 

 

4-1. 해결전략 1 -  캐시 뮤텍스(Mutex)

캐시 미스가 발생했을 때, 오직 첫번째로 도착한 요청만 DB에 접근할 수 있는 권한을 주는 방식이다.
1000개의 요청이 동시에 캐시 미스상황에 도달했을때 그중 1개만 DB에 접근해 다시 캐시에 적재하는 과정을 수행하고, 그 사이에 나머지 999개의 요청은 대기하다가 캐시에 적재가 성공하는 순간 나머지 999개의 요청도 그 캐시에 접근하도록 하는 방법이다.

 

 

 

 

4-2. 해결전략 2 - 확률적 조기 만료(Probabilistic Early Expiration, PER)

만료 시간이 가까워질수록 점진적으로 확률을 높여 캐시를 미리 갱신하며, 조기 갱신에 당첨된 요청은 기존 캐시 값을 반환하고 백그라운드에서 데이터를 재생성한다.

 

재계산을 수행하는 조건은 아래의 수식을 통해 결정되며 만료 직전일수록 확률은 늘어나서 다시 캐시가 최신 데이터로 업데이트될 확률이늘어나서, 실질적으로 캐시미스가 발생하는 상황 자체를 거의 없도록 만든다.

대신 백그라운드에서 갱신되기 때문에, 아주 잠깐 동안은 낡은 데이터가 사용자들에게 보여질수 있는 기술이다.

 

 

 

 

 

 

 

5.캐시 관통(Cache Penetration)

캐시에서 존재하지 않는 데이터에 대한 요청이 캐시를 거쳐 데이터베이스까지 직접 도달하는 현상이다.

보통 캐시에서는 데이터가 없다(null)를 저장하지않는데, 때문에 없는 데이터의 대한 요청이 들어오게 된다면 캐시를 지나 그대로 데이터베이스에 요청이 들어가 부하를 가할수도있다는게 캐시 관통이다.

 

 

 

 

5-1. 해결전략 1 - Null 값 캐싱

DB를 조회했음에도 데이터가 없다면, 이 데이터는 비어있다(Null)는 사실 자체를 캐시에 저장하는 방식이다.
단순히 생각해도 동일한 존재하지 않는 ID로 요청이 다시 들어올 때 DB를 보호할수있는 방법이지만, 악의적으로 없는 데이터들을 여러개 조회하면 Null값들로 캐시가 차버려서 메모리를 낭비하는 결과로 돌아올수 있다.

 

 

 

 

5-2. 해결전략 2 - 블룸 필터 (Bloom Filter)

위의 Null 값 캐싱이 가진 메모리 낭비 문제를 해결하는 확률적 자료구조 기반의 필터이다.
DB에 존재하는 실제 Key들을 비트 배열을 저장하고 데이터가 DB에 '확실히 존재하지 않음'을 빠르게 판단하여 불필요한 DB 조회를 차단한다.

하지만 알고있겠지만 블룸필터는 거짓 긍정이 발생할수있기 때문에 이경우 DB 조회를 가끔씩 허용해줄 때가 존재할수밖에 없다.