«   2025/03   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Tags
more
Archives
Today
Total
«   2025/03   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Tags
more
Archives
Today
Total
관리 메뉴

코더

잘못된 캐시 사용 본문

카테고리 없음

잘못된 캐시 사용

자바스티안 2025. 3. 7. 17:40

-사용배경-

쿠폰기능에 대한 토의를 하던도중 유저가 다운로드 받은 쿠폰 리스트는 가게에 방문할 때 마다 거의 사용을 한다고 가정을 하고 만들었기 때문에 자주 정해져있는 유저의 쿠폰리스트의 db를 조회할 것 이라 가정을해 cache를 적용해 주었다.

 

-코드-

 

-적용 전/후-

위의 그래프를 보면 확연하게 차이가 나는 모습을 확인 할 수 있었다.

cache를 적용하기 전에는 처음 조회 당시에는 423ms로 조회가 빠르게 되었음에도 불구하고 시도 횟수가 늘어 날 수록 오히려 평균값이 중가하였고

cache를 적용한 후에는 처음 조회 당시에 484ms로 조회가 비교적 느리게 되었음에도 시도 횟수가 늘어 날 수록 오히려 응답시간이 줄어들어 5번만의 시도의 평균값만 비교해봐도( 152.4ms → 122ms )평균값이 줄어드는 결과를 얻게되었다.

 

-의문점 및 결론-

 

그러나 고민이 되었다. 물론 가정을 저렇게 해서 캐싱을 적용해주었지만 과연 적용을 해주는게 맞을까??

라는 생각이 들어 하드웨어로 생각을 해 보았다

레디스는 메모리에 저장 즉 주기억장치인 RAM과 같은 공간에 저장한다고 할 수 있고

mysql은 디스크 즉 보조기억장치인 SSD와 같은 공간에 저장한다고 할 수 있을 때,

레디스를 사용하는게 서버비용문제가 훨씬 크게 들거라는 생각이 들게 되었다.

결국에는 저 기능을 없애고 그럼 어느상황에서 캐싱을 적용해야 하나 라는것을 고민하게 되었는데

 

결론은 거의 변하지 않고 정말 조회를 많이 할 수 밖에 없는 날씨 데이터나 유저의 변하지 않는 정보를 저장하고 자주 사용하게 되는것 이외에는 함부로 캐싱을 사용하지 않는다는게 맞다라고 생각이 들었고

막연하게 ‘쿠폰함에 유저가 많이 조회를 할테니까 사용하자 혹은 그래도 캐시를 사용하면 조회 시간이 줄어든다…’ 까지만 간단하게 생각하지 말고

이 레디스가 어디에 저장이 되는지 그로인해 발생하는 비용은 어느정도인지 혹은 그 비용을 감수하더라도 사용 할만 한것이지에 대해서 깊게 고민하는 시간을 가지자 라고 나를 되돌아 보았고 캐싱 적용을 해봤다는것에 의의를 두자 생각을 했다.

 

 

- 고민에 도움이 된 사이트 링크 -

 

https://wiki.yowu.dev/ko/Knowledge-base/Backend/database-management-with-mysql-and-redis

 

https://velog.io/@sungone/DataBase4