[넘블-딥다이브의 방문자 수 트래킹 서비스 구축하기] 참여 후 작성한 일지
후기보단 일지에 가깝다.
이 프로젝트는 기능의 CRUD 보단 특정 한 기능에서 발생될 수 있는 이슈를 고민해 보며 해결해 가는 게 목적이다.
기본적으로 이 프로젝트는 https://hits.seeyoufarm.com/ 사이트를 클론코딩하라고 한다. (클론코딩보단 기능 벤치마킹 프로젝트에 가깝다.)
일단 기능 구현을 위해 요구사항을 먼저 분석해야 됨으로 hits.seeyoufarm 개발자분이 남기신 블로그글을 읽게 되었다.
Github Repository 방문수를 트래킹 하는 방법
Github READEME에 badge 달고, 일별 트래킹을 해보자.
medium.com
여기서 요구사항에 대한 중요포인트를 알 수 있었다.
사실 방문자 수 트래킹은 용도에 따라 많은 제약조건이 들어갈 수 있는 기능이다. 수익창출을 위한 체크부터 해서 회사내부에서 요구하는 사항 등이 있을 수 있다.
예를 들어 "본인이 쓴 글은 조회수 체크가 안된다", "같은 IP로 들어온 연속된 체크는 막는다." 등 개인정보를 이용한 제약사항을 둘 수 있다.
하지만 여기서는 그런 개인정보를 활용한 조회수 체크는 진행하지 않고 순수하게 사이트로 들어온 조회는 모두 체크한다가 기본 설정이다.
쉽게 말하면, 1번 들어오면 조회수 1이 체크되고 100번 들어오면 조회수 100이 체크되어야 한다.
이러면 기능적으로는 매우 단순하지만 트래픽에 따른 동시성은 매우 중요한 요소가 된다.
동시성을 처리하는 방법은 최근에는 Redis 같은 NoSQL를 활용하는 방법이나 Kafka를 사용한 메시지큐로 분산 처리 등을 주로 이용한다.
사실 저런 걸 처음부터 사용하면 좋으나 경험이 없으니 공부 후 적용해 보도록 하고 나는 RDBMS을 이용한 동시성 처리 방법을 일단 우선순위를 두고 진행하였다.
1차적으로 RDBMS가 개발이 완수되면 프로젝트 피드팩권을 구매했기 때문에 그거 기반으로 프로젝트를 수정한 후 Redis까지 적용해 보도록 해야 될 것 같다.
추가적으로 CI 요소가 필요항목 중 하나였는데 그 부분을 못하고 넘어갔다. 이 부분도 꼭 빼먹기 말고 적용해보도록 한다.
아래 #은 프로젝트 진행 간에 정리하고 싶은 내용을 간단하게 표시한 것들이다. 해당 내용을 정리 후 포스팅 후 링크로 남겨 정리하자.
# 프로젝트 Readme에 어떤 내용이 포함되어야 할까?
# 스프링 프로젝트 시작 전 정리해야할 내용
ExceptionHandler, ResponseEntity, Validation, 패키지 구성 등
# github 이슈와 PR
각각의 컨벤션과 이슈와 PR 단위는 어떻게 구성하여야할까?
# 동시성을 해결하는 방법
RDMS에서 트랜젹션을 활용한 동시성 처리
Redis를 활용한 동시성 처리
# 트러블 슈팅
프로젝트 간 이슈사항 정리
# CI 도구 중 하나를 선택해서 적용해 보기
일단 서버에서 구현하기엔 무료 서버밖에 사용할 수 없으니 로컬 환경에서 구현해보자