Redis 캐시 전략

[skarltjr]

읽기 전략 / look aside

• 

• 캐시에서 먼저 데이터를 검색 후 없으면 디비에 접근한다

장점 :

• 반복적이며 재사용성이 많은 데이터 읽기에 적합하다.
• 캐시 장애에 대비할 수 있다 / 다만 캐시가 죽으면 커넥션이 모두 디비로 접근하여 부하 발생 가능

단점 :

• 캐시에서 먼저 데이터를 읽기 때문에 정합성 문제가 발생할 수 있다
• 단건 조회는 피해야한다. 단건 조회마다 캐싱하게되는 경우 심각한 부하

읽기 전략 / read through

• 

• cache miss 발생시 서버단에서 캐시하는것이 아니라 데이터스토어가 직접 캐시하는것

장점 :

• look aside의 경우 cache miss가 발생할때 서버가 쿼리 결과를 얻어온 후 이를 다시 캐시하는것
• 반면 이 방법은 서버가 쿼리한 내용으로 cache miss가 발생하면 디비가 서버에게 질의 결과를 돌려주는 동시에 캐시도한다

단점 :

• 내가 생각하는 치명적인 단점은 디비의 역할이 증가하고 부하가 발생할 수 있다고 생각
• 서버를 스케일 아웃하는 공수가 디비를 늘리는것은 고민이 보다 많이 필요할것이라고 생각

---

쓰기 전략 / write behind

• 

  
  장점 : 

• 캐시에 데이터를 저장함으로써 디비 write 부하를 줄일 수 있다
• 데이터 최신성 보장이 가능하다

단점 :

• 정합성 확보 어려움
• 캐시가 망가지면 데이터 유실 발생 / 치명적
• 불필요한 데이터가 캐시될 수 있고 메모리를 잡아먹는다 / ttl 설정이 매우 중요
• 캐시에 write가 많아질수록 성능 저하

### 쓰기 전략 / write through
- <img width="776" alt="스크린샷 2022-08-22 오전 1 49 55" src="https://user-images.githubusercontent.com/62214428/185802032-c7f4e2b8-2149-49ab-a288-4a14555a1570.png">

장점 :

• 정합성 유지
• 최신성 보장

단점 :

• 캐시에 쓰고 디비에 쓰는 과정으로 속도 저하

[skarltjr]

캐시 저장 방식 지침

캐시는 자주 사용되면서, 자주 변경되지 않는 데이터에 아주 적합하다

캐시 데이터는 언제든지 데이터가 날아갈 수 있는 휘발성이 기본이라는것을 인지해라

캐시 제거 방식 지침

캐시의 경우 대부분 디비에 저장된 데이터의 복사본으로 동작된다
이는 정합성의 문제가 분명히 발생할 수 있다.
따라서 캐시의 기본 만료 정책을 설정해야한다

이때 캐시의 ttl이 너무 짧아도 길어도 문제다. 고민이 매우 필요하다

• ttl이 짧은 경우 cache stampede 현상 발생 가능

  
  만약 ttl이 너무 짧은 경우 자주 디비 접근하는 경우가 발생

문제는 캐시에 매우 많은 커넥션이 물려있을때 캐시가 만료되는 경우 해당 커넥션이 동시에 디비로 향한다. 이는 곧 디비 부하를 가져올 수 있으며 여러 커넥션이 동시에 필요 데이터를 함께 읽는 중복 읽기 읽어온 데이터를 여러 커넥션이 동시에 캐시하는 중복 쓰기가 발생하고 ttl이 짧은 경우 해당 상황이 더욱 빈번하게 일어날 수 있다

이 현상을 해결하기 위해 PER(Probablistic Early Recomputation) 알고리즘을 도입할 수 있습니다. 이 알고리즘은 키의 TTL이 실제로 만료되기 전에 일정 확률로 캐시를 갱신하는 방법입니다.

- ttl이 긴 경우

불필요한 데이터가 메모리를 잡아먹게되는 경우가 발생할 수 있다

[skarltjr]

cache stampede를 예방하는 방법

PER(Probablistic Early Recomputation)

• 일정 확률로 캐시 만료를 미리 예상하여 미리 캐시해온다

디바운싱

• 프론트에는 단위시간내 마지막으로 호출되는 함수만 호출하는 방법인 디바운싱이 존재
• 이 방법을 캐시에 적용하면?
• cache miss가 발생할때마다 디비에 접근하는것이 아니라
• 단위시간마다 첫번쨰 miss에 대해서 디비에서 데이터를 읽어올때까지 나머지 Miss는 대기한다