refactor: 캐싱 적용

[seokjun01]

📄 설명

프로젝트 규모 상, 캐싱을 적용하는 것이 과연 적합할까 고민해보았습니다.
도전 겸 개인 공부겸사 해서 캐싱 적용 계획을 세워보려합니다.

우선, 캐시 (cache) 란
자주 조회되는 데이터를 "임시 저장소"에 넣어두고, 다음 요청 시에 바로 꺼내쓰는 기법입니다.

왜 캐싱을 하는가?

1. 속도 향상
2. DB 부하 감소
3. 일관된 데이터 값 반환
4. 운영 및 확장성의 편의

아무 데이터나 캐시를 적용하면 이는 더 효율이 낮아질 수 있기 때문에,

캐싱 적용 기준을 3가지 세웠습니다.

캐싱 기준

첫 번째, 요청마다 동일한 데이터를 반환하는 조회에만 사용한다.
두 번째, 업데이트가 자주 발생하지 않는 데이터에 사용한다.
세 번째, 자주 조회되는 데이터에 사용한다.

캐싱 적용 대상

현재 chikahae 프로젝트에서 위 3가지 기준을 만족시키는 데이터 항목들로는 , 아이템 조회 , 퀴즈 문제 조회, 공지사항 FAQ,JWT, +a로 마이페이지 등등 이있다고 판단하였습니다.

캐싱 대상을 선정하고 난 후, 캐싱 전략에는 Local캐싱과 Global 캐싱이 있음

추후에 사용자가 많아지고 서버 확장된다고 가정하고 Global 캐싱을 Redis DB를 사용하여 구현 할 생각

-> 공부용이므로 더 좋은 의견이나 리뷰 주셔도 좋습니다🙂

✅ 작업할 내용

• 캐싱 적용 기준에 맞는 데이터 대상 선정
• Prometheus + Grafana 혹은 레디스 자체 도구로 성능 비교

🙋🏻 참고 자료

https://1-7171771.tistory.com/138