[레디스] 캐싱 전략에 대해 알아보자

레디스 캐싱 전략

캐시를 어떻게 사용할지에 대한 전략이 있어야 한다. 상황에 따라 다른 캐싱 전략을 사용해야 한다.

 

캐시 전략은 2개의 읽기 전략과 3개의 쓰기 전략으로 총 5가지가 있다.

 

읽기 전략

1. Cache-Aside

2. Read-Through 

 

쓰기 전략

1. Write-Around

2. Write-Through

3. Write-Back

 

읽기 전략

---

1. Cache-Aside

과정

1. 캐시를 우선적으로 확인한다.
2. 있으면 해당 데이터를 읽어온다.
3. 없다면 DB에 접근해 데이터를 가지고 온 뒤에 캐시에 저장하게 한다.

데이터를 읽는 일이 많을때 사용하는 전략으로 일반적으로 레디스를 쓸 때 사용하는 방법이다.

캐시에 찾는 데이터가 없을때 DB에 직접 조회되어 입력되기에 Lazy Loading이라고 한다.

레디스가 장애가 나도 DB에서 데이터를 가져올 수 있다.

Cache-Aside와 함께 Write-Around 전략을 일반적으로 같이 쓴다. 그러나 캐시와 DB 간 데이터 불일치가 발생할 수 있다. 따라서 TTL을 사용하고 최신성 보장을 위해 캐시를 무효화할 수도 있다.

 

2. Read-Through

과정

1. 모든 데이터를 캐시로부터 읽어온다.
2. 캐시 미스가 발생한 경우 직접 DB를 조회한다.

오로지 캐시를 통해서만 데이터를 읽어온다. Cache Miss가 되면 DB에서 읽어 해당 데이터를 캐시에 저장한다. 즉 애플리케이션과 DB 사이에 캐시를 두는 것이다. 첫 요청은 항상 Cache Miss가 뜨게 된다. 

 

두 읽기 전략의 차이점은 조회 주체에 있다. cache-aside는 애플리케이션이 조회하고 캐시에 저장한다. read-through는 레디스가 주체가 되면 자체적으로 DB를 조회해 캐시에 넣는다.

 

Cache Warming이란
캐시가 다운되면 새 캐시를 넣어야 할때나 첫 요청에서 캐시 미스가 나는 경우에 DB에 성능 저하가 오게 된다.
이럴땐 캐시로 미리 데이터를 밀어넣는 작업을 해주면 된다.
블랙 프라이데이 기간의 할인 상품 조회수가 몰릴 것을 예상해 상품 정보를 캐시하는 작업이 그 예라고 볼 수 있다.

 

쓰기 전략

---

1.  Write-Through

데이터를 DB에 쓸 때마다 캐시에 데이터를 추가 또는 업데이트를 한다. 이로 인해 캐시 데이터를 항상 최신으로 유지할 수 있다. 그러나 이러한 점때문에 쓰기 지연 시간이 증가하고 쓰지 않는 데이터도 함께 저장되기에 리소스가 낭비된다. 보완하기 위해 TTL 전략을 사용하는 것이 좋다.

 

Read, Write-Through 전략을 함께 사용하면 읽기 전략의 단점을 보완할 수 있다.

Ex) DynamoDB Accelerator

 

2. Write-Around

데이터는 DB에 직접 저장되고, 읽은 데이터만 캐시에 저장한다. 자주 읽히지 않는 데이터를 저장하지 않아 리소스를 절감할 수 있다.

캐시 데이터와 DB 데이터가 다를 수 있다는 단점이 있다. 

EX) 실시간 로그, 채팅방 메시지

 

3. Write-Back

애플리케이션이 확인하려는 캐시에 데이터를 쓰고 약간의 지연 후에 DB에 쓰기 작업을 수행합니다.

쓰기가 많은 작업에 적합합니다. Read-Through와 결합해 최근 업데이트되고 액세스 된 데이터를 사용할 수 있는 작업에 적합합니다. DB에 대한 쓰기를 줄일 수 있어 비용이나 부하가 감소합니다.

 

(조회수 문제) -> 이 경우엔 조회수 카운트를 캐시에 담아 일정 시간마다 DB에 반영하는 방식을 사용할 수도 있다.