[성능 개선] 게시물 조회 캐시 적용
메인페이지에서 [좋아요수를 가장 많이 받은 게시물 top5를 조회하여 보여주는 api] 에 대해서 캐시를 적용하였습니다.
메인페이지는 사용자가 가장 많이 접속하는 페이지이기 때문에 메인페이지에 접속할 때마다 게시물 조회 api를 호출하여, db로부터 데이터를 조회해오는 것은 비효율적이라고 생각했습니다. 따라서, 메인페이지에서의 게시글 조회에 캐시를 적용하여 중복적인 쿼리의 수를 감소시켰습니다. 물론 메인페이지에서의 게시글 조회 뿐 아니라 [검색조건과 페이징처리]가 되어있는 게시글 조회에서도 캐시를 적용할 수 있었지만 적용하지 않았습니다. 페이징 특성상, 페이지 번호 별로 각각 key를 생성하고, 캐시 데이터를 저장해야 합니다. 이렇게 되면, 하나의 게시글이라도 수정이나 삭제가 발생할 경우, 캐시에 저장되어 있는 모든 데이터를 삭제하여 데이터의 불일치를 해결해줘야 합니다. 이는 trade-off 가 있지만, 저장되는 캐시데이터는 많지만, 그에 비해 캐시데이터의 삭제의 빈도수가 너무 높다고 판단하였습니다. (삭제가 빈번히 일어날 수 있는 상황에서, 무분별하게 캐시에 저장하는 것은 비효율적이라고 판단)
캐싱는 redis를 사용하여 구현하였습니다. local-memory 기반의 캐시인 ConcurrentMapCacheManager를 사용하여 구현할 수 있지만, 다중 서버에 대비하여 global하게 사용하기 위해 외부 캐시 db인 redis를 사용하였습니다.
- 캐시 key : 게시글 카테고리
- 캐시 value : 좋아요수 게시글 top5
스프링에서 제공하는 @Cacheable , @CacheEvict 사용하여 구현하였습니다.
최초의 게시글 조회에서는 db에서 데이터를 조회하고, 조회한 데이터를 캐시에 key-value 형태로 저장합니다. 이 후, 요청에서는 db를 조회하지 않고, 캐시에서 데이터를 조회하여 반환합니다. -> @Cacheable
또한, 게시글의 변경(수정,삭제)가 발생할 경우, 캐시데이터를 삭제합니다. -> @CacheEvict
캐시 데이터의 유효기간은 3시간으로 설정하였습니다. 서비스 초기의 상태여서 캐시데이터의 변경빈도가 많이 발생하지 않을 것이라 판단하였고, 추후에 사용자가 늘어남에 따라 유효기간을 줄일 예정입니다.
결과적으로 같은 요청에 대한 응답시간을 단축하였습니다. (158ms -> 39ms)
