[redis] 캐시(cache) 전략

[캐시, cache 란 무엇일까?]

임시 데이터 저장소라고 생각한다

조금 더 정리해서 이야기 하면 한번 조회된 데이터를 미리 특정 공간에 저장해놓고 똑같은 요청이 발생하게 되면 서버에게 다시 요청하지 않고 저장해놓은 데이터를 제공해서 빠르게 서비스를 제공해준다

 

[cache hit, cache miss]

- cache hit : 레디스에 데이터가 있을 경우 가지고 온다

- cache miss : 레디스에 데이터가 없을 경우 데이터베이스에서 가지고 온다

이론상, 문자 상으로 쉬운 개념처럼 보여지지만, 실제로 동작을 분석해 보면

예) 좋아요 수(1 단위로 표현되는 경우)

캐시는 한시간에 한번씩 업데이트 된다. 그런데 엄청난 인기 동영상을 올려 좋아요 수가 단시간에 폭발적으로 늘었다가..

그만.. 캐시 서버가 터지고 말았다.. 그럼 DB에 저장이 되어 있는 데이터는 한시간 전의 데이터니까.. 어머.. 정합성에 문제가 생길 수 있는 상황이 되는거죠..

그래서 적절한 캐시 읽기, 쓰기 전략이 필요하다고 생각이 됩니다.

 

[캐싱 전략 패턴 종류]

캐시를 사용하게 되면 캐시에서 처리를 해 두었다가 나중에 데이터베이스에 저장해 놓는 상황일텐데, 같은 데이터를 바라보고 있는 상황이지만, 레디스에서 DB에 업데이트 하기 전까지 두 저장소의 값이 다를 수 있다는 것이다.

그래서 캐시 읽기전략과 캐시 쓰기 전략이 필요하다고 생각했다

(이번 프로젝트 같은 경우 재고관리..)

 

[캐시 읽기 전략]

Read Cache Strategy

1. Look aside 패턴 : lazy loading

- 캐시에서 먼저 데이터를 찾고 캐시에 없으면 DB에서 조회함

- 반복적인 읽기가 많은 호출에 적합

- 캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장

일반적인 캐시 전략(가변성이 없는 read 전략)에 잘 맞는다.

캐시에 장애가 발생하더라도 DB에 요청을 전달해 서비스 문제는 대비 가능하지만,

생각해보면 많은 정보 변경이 일어나는 경우 캐시 정보와 DB정보가 다를 때 정합성 문제가 생길 수 있다 .

이럴 때는 쓰기 전략도 같이 고민해야 할 듯 싶다

 

2. Read Through 패턴

- 클라이언트는 캐시에서만 데이터를 읽어오는 전략이다.

- 데이터 동기화를 캐시로부터 한다 

- 데이터 조회를 캐시에다 위임하다 보니 캐시서버에 문제가 생기면 서비스에서도 문제가 생긴다.

- 캐시와 DB간 데이터 동기화가 항상 이루어져 정합성 문제에서 벗어날 수 있다

 

3. Cache Warming

- 필요한 데이터를 캐시로 미리 넣어주는 작업을 이야기 한다.

이 작업을 수행 후 look aside, read through 같은 적절한 전략을 사용하면 처음에 cache miss 가 발생하는 현상을 예방할 수 있을 것이다.

---

[캐시 쓰기 전략]

Write Cache Strategy

1. Write Back 패턴

- 데이터를 저장할 때 DB에 바로 쓰지 않고 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영한다.

- 캐시와 DB 를 동기화 하는 과정이 생략된다. 고로 DB connection 부하가 줄어둘 수 있다

- 반복적인 write(update)상황이 발생하면서 read도 많이 발생하는 상황에 적합하다

- 데이터 정합성에 대한 고려가 필요하면서, 캐시에서 오류가 발생하게 되면 데이터.. 안녕..

- 캐시가 일종의 queue 역할을 할 수 있게 되는 것이다

 

2. Write Through 패턴

- 데이터베이스와 cache 동시에 데이터를 저장한다

- DB 동기화 작업을 캐시에게 위임(like read through)한다

- 캐시가 항상 동기화 되어 있어 캐시 데이터는 항상 최신이다

- 데이터 일관성 유지할 수 있어서 안정적이다

- 매 요청마다 두번의 write가 발생(redis -> DB), update가 자주 발생하는 경우에는 고려해 보아야 한다(성능 이슈)

- 저장한 캐시를 읽어 오느냐?? 에 대한 고민이 필수다.

데이터베이스랑 캐시가 동기화 되어 있으니까.. 캐시에서 조회하나 디비에서 조회하나 같기때문데.. 오히려 리소스 낭비일 수도?

 

3. Write Around 패턴

- 캐시를 갱신하지 않기 때문에 write through 보다 빠르다

- 모든 데이터는 데이터베이스에 저장

- 캐시 미스가 발생하는 경우에만 DB와 캐시에도 데이터를 저장

- 데이터 불일치가 발생할 수도 있음

 

---

[캐시 읽기 + 쓰기 조합]

Look Aside(1) + Write Around(3)

캐시에서 먼저 읽고, 없으면 데이터베이스에서 가지고 온다. 수정사항이 생기면 데이터 베이스에 저장한다

일반적인 캐싱처리 : 캐싱처리 할 때 자주 변하지 않는 상황(read)에 최적화 되어 있기 때문에 수정 시 일단 DB 수정해 두고 이후 캐시미스(read 정보 없을 때) 다시 캐싱한다.

Read Through(2) + Write Around(3)

DB에 쓰고 캐시에서 읽는다. 읽기 시 DB에서 먼저 읽어오기 때문에 데이터 정합성을 맞출 수 있는 장점이 있다. 자주 변하지 않는 데이터들을 캐싱해두면(첫 랜딩페이지 등) 좋을 것 같다

Read Through(2) + Write Through(2)

데이터를 읽어올 때 DB -> 캐시 순으로 읽어와 정확도를 높일 수 있다..

데이터를 쓸 때 항상 캐시에서 DB로 보내므로 데이터 정합성이 보장된다.

하지만 이 방법은 사실 DB로 직접 조회하는 방법 사이에 캐싱이 끼워져 있으므로 언제 사용하는지는 레퍼런스를 더 찾아봐야 할 것 같다..

Read Through(2) + Write Back(1)

가장 최근 업데이트 된 데이터를 항상 캐시에서 이용할 수 있다.

read 와 write 를 레디스에서 처리하기 때문에 성능은 엄청 좋아보이는데..

혹여 레디스 폭발하면 캐시미스가 나는 상황이라 timeout에 대한 전략을 잘 짜는 것이 필요할 것 같다

양날의 검 같은 느낌

---

그래서 어떻게 쓸까?

캐시 솔루션은 자주 사용되면서 변경되지 않은 데이터, 휘발되어도 괜찮은 데이터 기준으로 하는 것이 좋다

 

출처

https://waspro.tistory.com/697

Redis5 설계하기 총정리