-
Notifications
You must be signed in to change notification settings - Fork 0
Description
✍ Description
여행 조회수 기능 추가
요구조건
- 비로그인 추적이 가능해야한다.
- 중복 조회수를 컨트롤 할 명확한 기준을 확립해야 한다.
Todo
- 여행 조회수 기능 추가
- 조회수 중복 방어로직
- 레디스와 DB 데이터 싱크 맞추기
- 조회수 동시성
Additional Information
-
비로그인 추적을 위해서 ip와 mac 주소값을 사용할 계획인데, 그럴경우 로그인 유저는 Id를 사용할지 일관성을 위해 로그인 유저에게도 ip 와 mac을 적용해서 판단할지 정해야 한다.
-
중복 조회수 로직에 고려했던 기술로 쿠키 세션 DB가 있었다.
차례대로 기술 선점 기준을 정리하자면
세션: 현재 인가를 jwt를 이용하는 쿠키를 사용하고 있기 때문에 세션을 중복조회를 위해 사용하게 되면 상태성 관리의 일관성이 깨지고, 세션 구현자체의 오버헤드에 더불어 잦은 호출이 되는 조회수기능에 서버 리소스를 사용하는 세션은 결이 맞지 않다고 판단하여 배재한다.
쿠키: 클라이언트 리소스를 사용하기 때문에 세션보다는 좋다고 판단되지만, 쿠키는 조작이 되기 때문에 로직을 파악하고 있는 클라이언트의 조회수 조작 가능성이 존재한다. 추가적으로 쿠키 자체의 용량 제한 때문에 한명의 유저가 많은 게시글을 보게 된경우 쿠키의 용량 제한을 초과할 수 있다. 이러한 근본적인 쿠키의 특성을 해결하기 어렵기 때문에 배재한다.
DB: 디비를 사용할 경우 안정적인 관리가 가능하다. 안정적인 만큼 리소스 사용에 대한 부담성이 커지게 된다. 이러한 문제를 인메모리 캐시인 Redis를 사용해서 해결하려 한다. 인메모리 자체의 데이터 휘발성이 존재하지만, 데이터가 휘발되어도 최악의 케이스 기준 한명의 유저가 동일 게시글 두번 조회가 전부라고 판단되며 레디스의 장애로 데이터가 휘발되어도 데이터의 정합성이 크게 흔들리진 않기 때문에 중복 검사에 레디스를 이용한다.
추가적으로 조회수 자체 관리를 레디스로 할예정이였지만, 전체 조회수가 휘발되는건 큰 문제이기 때문에 이 경우 방어로직으로 조회수를 특정 시간마다 스캐쥴링 해서 디비에 업데이트 하는 방향으로 가려고 한다. 조회수 증가로직 또한 자주 변경되며 디비를 사용하는 것보다 레디스를 사용하는것에서 성능 이점을 챙길 수 있을것이라고 판단되며, 레디스를 사용한 동시성 관리도 진행하려 한다.