Redis 읽기 전략 관해서

[kgy1008]

현재, 우리는 대학교 목록을 Redis에만 의존하여 데이터를 저장하고 있음. 때문에 만약 Redis에 문제가 생긴다면 모든 기능이 정상적으로 작동되지 않는 치명적인 SPOF 문제가 발생할 수 있을 것.

---

https://minnseong.tistory.com/49?pidx=2
위 글을 읽어보면 알겠지만 Redis의 캐싱 전략에는 2가지 방법이 있음. 현재 우리가 대학교 목록을 레디스 캐시에 저장하는 방식은 Read-through 방식인데, 이 경우에는 SPOF 문제가 치명적이라는 문제가 존재함
-> 대학교 목록 경우에는 우리 앱에서 핵심적이고 필수적인 데이터인 만큼, 만약 Redis 서버에 문제가 생겼을 때 서비스 전체 장애를 피할 수 없을 것으로 예상합니다.

때문에 캐싱 전략을 Look-aside 방식으로 바꾸는 것은 어떨까요?
DB에도 대학교 목록을 저장하기 때문에 Redis에 문제가 생기더라도 DB에서 값을 읽어올 수 있으므로 장애에 훨씬 유연하게 대응할 수 있게 됩니다. 물론 이 경우에는 캐시와 DB간의 동기화도 신경써야하고 캐시 미스 상황에서 트래픽이 몰리면 DB 부하가 굉장히 심해진다는 단점이 존재하지만 SPOF 문제 보다는 나을 것 같다고 생각되네요. 특히, DB 부하는 현재 우리 서비스에서도 심하지 않기 때문에 괜찮을 것 같습니다.

이 부분 담당자 : @Parkjyun 생각은 어떤가요

[Parkjyun]

늦게 봐서 지금 답장 드립니다, 정확히 말하자면 저희는 레디스에 대학교 목록을 캐싱하는 것이 아니라, userpk를 키로 university pk를 value로 저장합니다.
이 값은 디비에 있는 값이 아닙니다. 저장하는 이유는 클라이언트에서 대학교 필터의 상태 유지를 위임해서 저장하는 것입니다.
말씀하신 내용을 적용하려면 레디스에 저장하는 값을 디비에도 저장을 해야하는데 자주 변경되는 사용자의 대학교 필터 값을 디비에 저장하는 것은 옳지 않다고 생각합니다.

적어주신 내용은 맞지만 redis를 캐시가 아닌 저장소의 역할로 사용하는 저희의 상황에는 적용되지 않는 문제 같습니다.