[Redis] 캐싱 전략-Cache Aside, Write Around / 캐싱 뜻 / TTL 뜻

캐시라는건... 전공 수업 들으면서 수도없이 배운거지만..

새삼 간략히 내 언어로 정리해본적은 없는 듯 해서 정리하는 중

 

 

📍Cache 란?

RAM에 저장되는 임시 데이터 저장소.

 

우리가 흔히 아는 DB는 디스크에 저장됨.

따라서 읽어오기, 쓰기에 시간이 걸림. 

 

반면에 RAM에 데이터가 저장되게 되면, 빨리 왓다갓다가 가능하기때문에 조회 성능이 매우 빨라짐.

하지만 RAM가격이 비싼데엔 다 이유가 잇지요..

 

 

📍캐싱 전략 2가지

 

1. Cache Aside 전략

어떻게 "조회"할지에 관한 전략이다.

우선, 내가 특정 데이터를 조회하고 싶을때, 일단 캐시로 가.

 

그리고 캐시에 내가 찾는 데이터가

있으면(=Cache Hit) 걍 그대로 가져오고

없으면(=Cache Miss) 그제서야 DB로 가서 찾음.

 

그리고 DB에 있으면, 그걸 갖고와서 다시 Cache에도 저장.

 

2. Write Around 전략

어떻게 "쓸지"에 관한 전략이다.

데이터를 새로 쓰거나, 업데이트할일이 있을 때 무조건 DB에다가만 하는거임.

내가 새로 데이터를 저장한다고 해서, 자주 쓸거같으니까 cache에 써야지~ 이런거 안된다는거임.

 

쓰는건 무조건 DB에!

+조회할때는 cache aside 전략써서 조회하는거임.

 

➡️ 따라서 Cache Aside전략, Write Around 전략은 둘이 같이 쓰임.

 

 

근데 당연히 단점 존재함.

 

✔️단점?

단점1. DB데이터와 Cache데이터가 다를 수 있음.

최초로 데이터 조회했는데 캐시에 없음 -> Cache Miss 발생

-> DB가서 데이터 가져옴

-> 캐시 서버에 쓰기.(ver1)

~~시간이 흐르고 그 데이터 수정하게 됨(ver2)~~

당연히 DB에만 반영됨

-> 다시 그 데이터 조회할 일이 생김

-> 캐시 가서 조회, 있음! (Cache Hit) 근데 ver1.

-> 그거 그대로 가져오는거.

 

이렇게 되면 DB에는 ver2가, 캐시에는 ver1이 저장되게 됨.

 

데이터 일관성 유지가 안된다는 단점.

 

단점2. 캐시 서버에 용량 제한이 있음.

redis같은 캐시는 RAM에 쓰이는 임시데이터 저장소임.

RAM이 빠른만큼.. 가격도 비싸고 용량도 적음.

따라서 당연히 캐시 서버를 무한대로 놓고 쓸 수 없음.

 

 

➡️ 이 두가지를 해결하기 위한 방법으로 TTL이 있음!

이 TTL아니고요

 

TTL은 데이터의 만료기간을 설정하는 기능이다.

 

ttl을 설정함으로써 데이터는 특정 시간이 지나면 캐시에서 지워짐.

그러고 자주 조회되는거면 계속 캐시 서버에 있게 되는거고..

자주 조회 안되면 자연히 캐시 서버에서 사라지게 되는거다. (새롭게 캐시에 안쓰여지는거니까)

이렇게 되면, 단점1과 단점2가 모두 커버 가능함.

 

만료기간이 다 지나면 데이터가 지워지고(ver1)

DB에서 해당 데이터가 바뀌고 나서(ver2)

다시 조회했을 때 캐시 서버에 ver2로 쓰이게 되는거니까...

 

 

---

📍데이터 조회 성능을 높이는 방법들

SQL문 튜닝

캐시 서버 두기

..

 

등등 많은데, 제일 먼저 해야할건

SQL문 튜닝이다.

 

가성비 있게 제일 먼저 고쳐야 하는 부분이다.

캐시 서버를 두는것보다 먼저 봐야하는 부분.

 

사실 캐시 서버를 두는건 그에 따라 또 다른 비용이 발생하는 것이기 때문이다..