2023-01-14

멘토링 시간에 멘토님께 두가지 질문을 준비해서 하게 되었던것에 대한 답변으로 글을 시작...

 

 

 

Redis 캐시 관련

@EnableCahing 을 사용해서 Redis 의 캐시 기능을 사용한다고 가정하겠습니다. 그러면 저희 프로젝트에서는 비회원의 정보가 11시간 뒤에 자동 파기가 됩니다. 그리고 처음 로그인할 때 말고는 정보 변경이 일절 없습니다.
따라서, 저희 프로젝트에서는 이를 캐시로 사용하면 어떨까 하는데 이 방법 중에서 write back 방식에서 wirte around를 사용해서 하면 어떨까 하는데 이 방법을 사용하는 게 맞을까요?
그리고 회원, 비회원 검증에서 repo를 통한 db에 접근해서 존재 유무 확인으로 검증을 거치는데 이러면 이 때에도 캐시를 설정해주면 캐시에 접근하는 건가요?

Redis 채팅 관련

메세지 브로커를 쓰는 이유는 메세지를 발신할 때 다른 서비스들에 대해 알 필요가 없으며, Sub 측에서 원하는 시점에 메세지를 처리할 수 있는 장점이 있습니다.
그러면 여기서 내부 메세지 브로커를 사용하느냐 아니면, Redis 를 메세지 브로커로 사용 하느냐로 갈립니다.
그런데 Redis 에서 자체적으로 지원하는 Pub/Sub 의 경우에는 메세지 지속성이 없어서 현재 저희 서비스의 가벼운 게임 한두판의 목적에 부합한다고 생각합니다.
이렇게 보면 레디스의 in-memory 의 장점인 빠른속도 또한 살리면서 저희의 가벼운 게임에 있어서도 좋은것 같습니다만, 제가 이해한 것이 맞을까요?

 

 

위와 같이 질문을 했고 이에 대한 답변으로는...

 

 

Redis 캐시 관련

우선 이해를 잘못했었다....
write back 방식에서 갈리는 것이 아니라 write 방식에 세가지의 방식이 있다.
즉, 내가 질문 자체를 잘못 이해하고 한 부분이 있었고 Redis 는 기본적으로 write through 의 방식이 기본이다.
그리고 비회원은 이후 변경이 없기에 최초에 한번만 사용하는 경우에는 through 와 around 의 방식에 있어서 사용할 때 큰 차이가 발생하지 않는다.
따라서, 유스케이스를 잘 따지되 너무 깊게 고민할 필요는 없다고 해주셨다...

 

Redis 채팅 관련

정확하게 잘 이해하고 결정을 내린 것 같다. 지금 이해한대로 사용하면 될 것 같다고 하셨다.
메세지 큐 방식의 경우 kafka 와 비슷한 개념이라고 할 수 있다고 해주셨다.(이 부분은 나중에 차차 알아보자)

 

 

우선 답변을 너무 잘 해주셔서 감사했읍디다...

위에 팀원들과 같이 있을 때 말고 마지막에 혼자서 따로 한번 더 물어봤었는데...

이 때는 Redis 캐시에 관해서 질문을 했었다. 그 내용은 아래와 같다.

 

 

 

1. 질문)
   Redis 에서 @EnableCahing 를 선언해주는데 이를 선언하는 위치는 블로그마다 다르다..
   그래서 현재 이를 선언하는 위치는 애플리케이션에 해놓은 상태인데 여기다 하는것이 적절한 것인지..
   답변)
   @EnableCahing 에 대한 이해를 좀 더 할 필요가 있다.
   지금 우리 프로젝트에서는 Redis 를 활용한 부분에만 캐시를 사용할 것 이기 때문에 별도로 만든 RedisConfig 에서 추가를 해주고 @EnableRedisRepositories 같이 사용해주면 된다.
2. 질문)
   @Cacheable 을 통해서 만들고 @CacheEvict 를 통해서 캐시를 삭제한다.
   그렇다면 이를 어디에 선언해서 활용하는것이 좋은지...
   답변)
   현재 내 프로젝트 내에서는 비회원 정보가 만들어지는 메서드 위에서 하는것이 맞을 것 같다.

 

위와 같은 대답을 받을 수 있었다...

이제 다른 글들을 참고하면서 코드를 작성하면 되는데, 아주 큰(?) 문제가 발생...

 

다른 블로그들을 보니 대부분이.. 아니 죄다 opsForValue 를 사용해서 레디스에 정보를 만들고 있었고 레디스 관련해서 정보를 읽는 순간에 만들어지게 되어있었다.

 

그런데 현재 내 프로젝트의 문제는 모듈화를 통해서 전역적으로 정보를 가져오고 @Cacheable 을 사용해서 만들어질 때는 반드시 key, value 의 입력이 필요했고, 이는 매개변수에서만 가져올수 있는 구조였다...

이를 무시하고 이용하려면 자동값 증가로 value 에 입력이 되거나 요청한 비회원에 대한것을 매개변수에서 가져올 필요가 있었는데...

 

이는 현재 모듈화를 통해서 모든 회원, 비회원 정보를 가져오는 부분 때문에 어디에다가 특정 회원을 가져오는 부분을 추가할수가 없는 코드 구조가 문제였다...

 

그래서 이를 어떻게 해야할지 도저히 생각이 나지 않아서 몇시간이나 고민했는데 해결한 방법은 생각보다도 너무 간단해서 허탈했다...

 

 

비회원 정보는 모듈에서 레디스 DB 에서 정보를 찾아서 검증하는 부분이 있었다...

이말은 즉, 그냥 Repo 에다가 해당 부분을 추가해주는 것으로 아주 간단하게 해결이 되었다...

 

 

이렇게 여기다가 한줄 추가해주면 끝이었다...(내 몇시간의 고민이 코드 한줄로...)

 

그래서 이제 이것을 테스트 해보니...

 

 

위 이미지를 보면 user::guest:10003 이라는 캐시가 생긴것을 볼 수 있었다.

게다가 만료시간도 설정한대로 잘 작용하는 것도 확인할 수 있었으며, 조회시간이 회원과 비회원과 비교시 회원은 27ms 비회원은 7ms 로 제법 유의미한 차이가 있는것 같기는 한데, 회원 비회원이 담고있는 정보도 좀 다르고 단건 조회만 비교를 해보았고(한명만 조회) 실제로 얼마나 차이가 발생할지 프로젝트가 완성에 가까워 져야 알 수 있을듯 하다.

 

우선은 이제 적용은 되니까 여기까지 하고 마무리...