[2단계 - DB 복제와 캐시] 페드로(류형욱) 미션 제출합니다. #153
Conversation
| @Configuration | ||
| public class RedisConfig { | ||
|
|
||
| private static final int CACHE_TTL_IN_HOURS = 1; |
There was a problem hiding this comment.
사실 명확한 기준을 세우고 값을 설정한 것은 아닙니다. TTL 기준을 잡으려면 실제로 운영되고 있는 서버의 통계정보가 필요하다고 생각해요.
최소한의 기능으로 쿠폰을 우선 제공해 보고, 필요에 따라 더 다양한 사용 조건이나 발급 조건을 추가하려고 한다.
미션 설명에서 위와 같은 언급이 있었는데요, 현재의 쿠폰은 변경이 일어나지 않는 도메인이기 때문에 TTL을 너무 짧게 설정하면 캐시에 다시 데이터를 적재해야 하는 일이 너무 빈번하게 일어납니다.
반대로 TTL을 너무 길게 설정하면 특정 사용자에게 발급되는 한시적 쿠폰(시크릿 쿠폰 등)들도 캐시에 너무 오래 남아 있게 되어 메모리가 낭비될 것으로 예상했습니다.
우선 가장 기본적인 단위인 1시간으로 설정해 둔 것이고, 실제 운영환경이라면 캐시 히트율을 분석하여 조정하는 과정이 필수적으로 수행되어야 한다고 생각합니다!
| @@ -20,6 +21,7 @@ public long create(Coupon coupon) { | |||
| return saved.getId(); | |||
| } | |||
|
|
|||
| @Cacheable(value = "coupon", key = "#couponId") | |||
There was a problem hiding this comment.
조회할 때만 캐싱하도록 설정했는데, 이렇게 한 이유가 궁금해요 💭
There was a problem hiding this comment.
현재 미션의 요구사항대로라면 쿠폰의 정보가 수정되지 않으므로, 조회 시에만 캐싱해도 정합성 문제 없이 충분히 캐시의 효과를 누릴 수 있을 것이라 생각했어요!
만약 쿠폰정보가 수정될 수 있거나, 쿠폰 정보다 방대하여 캐시 엔트리가 커지고, 첫 캐시 로드 시 시간이 많이 소요되어 최초 조회 API 호출 시 사용자가 불편을 겪는다면 쿠폰 삽입/수정 시에도 캐시에 반영하도록 하거나 아예 캐싱 로직을 사용자 트랜잭션과 분리시키는 선택지를 고려해 볼 것 같네요🙂
| @Configuration | ||
| public class RedisConfig { | ||
|
|
||
| private static final int CACHE_TTL_IN_HOURS = 1; |
There was a problem hiding this comment.
오.. 이런 개념이 있었네요😄
- TTL(Time to live): 설정한 시간 경과 후 데이터 소멸
- TTI(Time to idle): 설정한 시간 경과 후 데이터가 소멸되지만, 해당 캐시 엔트리에 접근이 일어났을 때 타이머 초기화
Spring 공식문서에 따르면, Redis 자체로는 TTI를 지원하지 않아 개발자가 직접 로직을 구현해야 하지만, Redis 6.2.0이상, spring-data-redis 3.2.0이상을 사용하면 라이브러리 단에서 이를 지원한다고 해요.
자주 사용되는 쿠폰 정보가 상수로 지정된 시간 후에 일괄적으로 만료되는 것을 방지할 수 있다는 점에서 지금은 TTL보다는 TTI를 사용하는 게 좀 더 적절한 구현 같네요! 반영해두었습니다~
|
안녕하세요 망쵸~ 코멘트에 답글 남겨두었습니다! TTI 라는 개념이 별도로 존재하는지 모르고 있었는데 알려주셔서 감사해요! 설정 반영 후 다시 리뷰 요청 드립니다. 시간 나실 때 확인 부탁드려요! p.s) |
망쵸 안녕하세요! 2단계 구현을 완료하여 리뷰 요청 드려요.
캐싱이 되고 있는지 어떻게 테스트해야 하는지 고민하다가 그냥
CacheManager를 주입받아 엔트리가 존재하는지 확인하는 방법을 택했어요.처음에는
@SpyBean으로 레포지토리 스파이를 만들고, 레포지토리 메서드를 호출하는 횟수를 카운트하고 싶었는데 로그상으로는 캐시에서 데이터를 읽어옴에도 메서드 호출은 2회 이상 호출한 것으로 기록되더라구요.스프링부트 프록시 체인 상에서
@Transactional이@Cacheable보다 앞에 있어서 그렇다~ 라는 이야기를 얼핏 봤는데 좀 더 알아봐야 할 것 같아요🥲리뷰 잘 부탁드립니다!