Using Redis Cluster for the cache

[great-park]

Description

현재 Server Driven UI 설계를 적용한 홈화면 API의 응답 속도가 많이 느립니다. 테스트 당시 response 응답 시간이 약 3초 정도 걸렸습니다. 따라서 Redis를 사용해서 일부 메소드의 결과를 caching하여 응답 시간을 줄여보도록 하겠습니다.

@Cacheable과 @CacheEvict 을 사용하여 AOP 기반으로 메소드를 캐싱할 계획입니다.

1. 캐시를 저장/조회하기 위한 @Cacheable
   • 캐시에 데이터가 없을 경우에는 기존의 로직을 실행한 후에 캐시에 데이터를 추가
   • 캐시에 데이터가 있으면 캐시의 데이터를 반환

해당 어노테이션은, 쉽게 변하지 않으면서 많은 요청들에서 호출하는 메소드에 붙이면 좋을 것 같습니다.

2. 캐시 제거를 위한 @CacheEvict
   • 메소드가 실행될 때 캐시의 내용이 제거된다

캐시는 적절한 시점에 제거되어야 하는데, 만약 값이 달라진다면 캐시를 제거해야 합니다. 이때, 일정한 주기로 캐시를 제거하거나, 값이 변할 때 캐시를 제거하는 경우가 있을 겁니다. 하지만 일정한 주기로 캐시를 제거하는 것은 추가적인 관리가 필요하기 때문에 좋지 않은 방법 같고, 값이 변할 때 캐시를 제거하는 편이 더 나을 것입니다.

만약 값이 자주 변경되고, 중요한 데이터의 경우 실제 DB와 값이 다른 경우를 최소화하기 위해서 값이 변화될 때 마다 캐시를 제거하고 업데이트해야 합니다. 따라서 해당 어노테이션은 캐시를 초기화해야 하는 경우에 붙이도록 합시다.

To-do

• [x] Cache manager 빈 등록
• [x] CacheKey 정의
• [x] @Cacheable을 사용하여 값 캐싱

ETC

홈화면 api에서 동작하는 여러 비즈니스 로직을 담당하는 메소드들이 많은데, 그 중에서 특히 repository layer의 코드들을 유심히 살펴보고 어떤 곳에 캐싱 AOP을 붙어야 할 지 같이 논의해보면 좋을 듯 합니다. @ray-yhc

[great-park]

홈화면 API wirh SDUI 성능 개선

완벽한 성능 분석은 아니지만, API Response 응답 시간이 매우 빨라졌음을 확인하였다.

캐싱 적용 전 : 1727ms

캐싱 적용 후 : 285ms