[Research] Redis 캐싱 전략

1) 지연 로딩 (Lazy Loading)

• 개념
  • 클라이언트에게 데이터 요청이 들어올 때, Cache에 로딩한다.
  • DB나 API에 접근하기 전, Cache에 접근하여 원하는 데이터가 존재할 경우 Cache 데이터를 활용한다.
  • 없으면, DB나 API에 접근하여 데이터를 가져와 Cache에 올린다.
• 장점
  • 요청받은 데이터만 Cache에 저장 (→ 파르토 법칙에 따라 엄청난 효율성을 불러온다.)
  • 캐시에 존재하지 않는 데이터를 DB에서 가져오며, 후에 캐시에 저장하기 때문에 Cache Miss에 치명적이지 않다.
• 단점
  • 캐시 미스가 많아질수록 딜레이가 심해진다.
  • 캐시 미스 발생시, 캐시에 데이터를 쓴다. 이는, 캐시의 데이터가 최신의 상태를 유지 못할 수도 있음을 의미한다.

 

 

2) Write Through

• 개념
  • 데이터를 추가하거나 수정할 때, Cache와 DB 모두 동시에 업데이트 된다.
    • 첫 번째로 cache write, 두 번째로 DB write.
• 장점
  • 캐시가 항상 최신의 데이터를 갖는다. (항상 동기화 되어 있음)
• 단점
  • 값을 쓰거나 업데이트할 때, 항상 두 번의 패널티를 갖는다.
  • 새로운 노드가 추가될 경우 데이터를 찾지 못할 수도 있다. 새로운 노드에 해당 데이터가 없기 때문.
  • 대부분의 데이터가 읽히지 않으므로 리소스가 낭비될 수 있다.

 

3) Read Through

• 개념
  • 먼저 cache에서 읽고, 캐시 미스가 발생시 DB에서 누락된 데이터를 cache로 로딩한다.
• 장점
  • 동일한 데이터를 반복적으로 요청할 때, 읽기가 많은 워크로드에 적합하다.
• 단점
  • 데이터를 처음 요청하면 항상 캐시 누락이 발생한다.
    • → 개발자가 직접 쿼리를 실행하여 첫 요청 캐시 미스를 나지 않게 하는 방법을 사용하기도 한다.

 

4) Write Around

• 개념
  • 데이터는 데이터베이스에 직접 기록되며, 읽은 데이터만 캐시에 저장된다.
  • Write-Around는 Read-Through와 결합 될 수 있으며, Cache-Aside와도 결합될 수 있다. 
  • 데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공한다
    • 예를들어, 실시간 로그 또는 채팅방 메시지가 있음.

 

 

5) Write Back(Write Behind)

• 개념
  • 애플리케이션이 cache에 먼저 데이터를 쓰고 약간의 지연 후에 DB에 쓰는 방식.
• 장점
  • 쓰기가 많은 워크로드에 적합하다.
  • Read-Through와 결합하여 가장 최근에 업데이트되고 엑세스 된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합하다.
  • 데이터베이스에 대한 전체 쓰기를 줄일 수 있어, 해당 비용을 감소할 수 있다.
• 단점
  
  • 위와 반대의 경우 적합하지 않음.
  • 캐시에서 오류가 발생하면 데이터를 영구 소실 한다.

 

 

참고

• https://luran.me/357
• https://dzone.com/articles/database-caching-with-redis-and-java