#139 redis 캐시 적용(특정 가게의 모든 메뉴 캐싱)

[lyh7712]

• 특정 가게의 모든 메뉴를 캐시하여 빠르게 조회할 수 있도록 redis 캐시를 적용했습니다
• 메뉴 그룹, 메뉴, 옵션 그룹, 옵션 부분에서 추가, 수정, 삭제가 생각보다 자주 발생해 데이터가 변경될 수 있는 상황이 빈번하다고 생각해서 각 메소드에 @CacheEvict를 적용해서 캐시 데이터를 삭제하는 것 보다, TTL 주기를 짧게 설정해 데이터 일관성을 보장할 수 있도록 설정했습니다.
• TTL을 더 짧게 잡고 특정 가게의 메뉴 조회 + 메뉴 관련 데이터 수정 API를 동시에 많이 부어서 부하테스트도 진행해봤는데 문제가 보이지는 않았습니다.

[soongjamm]

질문(+제 생각) 있습니다!!!

1. 현재 설정이 메뉴 변경이 발생해도 바로 캐시에 반영하지 않고, 최대 15초(ttl)를 대기하는게 맞을까요?
   (맞다면) 메뉴 변경이 캐시에 바로 반영이 안되면 메뉴가 수정되도 유저는 최대 15초간 잘못된 메뉴정보를 보게될 것 같고, 문제가 될 수도 있지 않을까여?
   (만약 메뉴 가격을 잘못 올려서 수정이나 삭제했는데 15초간 삭제된 메뉴의 주문+결제가 쏟아진다거나.. 이런 경우를 생각해봤습니다..)

2. @CacheEvict 를 적용하지 않고 ttl만 짧게 해서 데이터 일관성을 보장했다고 하셨는데, @CacheEvict를 안했을때가 했을때 보다 더 데이터 일관성을 보장하는데 유리하다는 의미일까여??
   (저는 @CacheEvict를 적용하면 메뉴 변경 시점에 바로 캐시를 삭제해서 DB와 캐시의 데이터 일관성을 유지하는데 유리할거 같다는 생각이 들었니당)

[soongjamm]

예를 들어 /menus/1 이라고 하면, id가 1인 메뉴를 조회한다고 오해할 수 있을 것 같습니다
'어떤 가게가 가진 메뉴판' 와 비슷하게 읽히면 좋을 것 같습니다 (저라면 /shops/{id}/menu-board 나 비슷하게 할거같습니다!)

[lyh7712]

이 부분을 수정했어야 하는데 깜빡했네요..ㅎ

[lyh7712]

말씀 감사합니다 :)
저는 모든 변경과 관련된 메소드에 @CacheEvict 적용하여 캐시가 자주 비워지는 것(가게가 많다면 각 가게의 메뉴, 메뉴 그룹, 옵션 그룹, 옵션 변경 부분에 대한 메소드가 많아 TTL을 이용하는 것보다 더 자주 캐시가 비워질 것)을 생각하여, 원래는 이보다 더 짧은 주기의 TTL을 설정해 캐시를 비워줌으로써 비워지는 횟수를 좀 줄일 수 있지 않을까 생각해 적용했는데, 1번과 같은 문제가 충분히 발생할 수 있겠네요.. 그리고 생각해보니 @CacheEvict를 적용하는 게 일관성을 유지하는데 더 유리할 것 같습니다!!

[f-lab-bright]

@lyh7712
지금 구현한 캐시는 어떤 전략으로 구현했고, 왜 그런 선택을 하셨나요?

[lyh7712]

현재 캐시는 Aside 전략으로 특정 가게의 메뉴를 가져오기 떄문에 읽기 작업이 빈번하고 사용되는 데이터만 캐싱할 수 있는 Aside 전략의 장점을 생각하여 적용했습니다. 단점인 데이터 동일성을 보장하는 부분에서는 @CacheEvict를 통해 해결할 수 있을 것 같습니다!