부경대학교 WAP 동아리에서 사용해주길 바라고 제작한 팀 빌딩 서비스의 서버 코드입니다.
프로그래밍 동아리에서 한 학기 동안 진행할 프로젝트를 위해 팀을 빌딩하는 것은 중요한 일입니다.
WAP 동아리에서는 정형화된 방식이 없고 그때그때마다 방법이 달라 정보를 얻기가 쉽지 않습니다.
이를 도와주기 위한 팀 빌딩 및 회원 관리 서비스를 개발하게 되었습니다.
서버 -> SWAGGER
프론트 -> 관리자, 사용자
자세한 내용은 Notion에서 볼 수 있습니다.
- 깃허브 소셜 로그인
- 임원진(관리자)의 팀/회원 관리 ex) 회원가입 후 승인 여부
- 동아리원(일반회원)/임원진의 팀 빌딩 및 가입신청
- 내 활동내역 및 자기소개
- 팀장의 팀원 관리
부하테스트 도구인 Locust를 활용해 부하가 크게 몰릴 것으로 예정되는 팀 빌딩 시간을 상정해
80개의 클라이언트가 1.5-2초 간격으로 유저 프로필, 팀 상세 페이지에 접근하는 상황으로 테스트를 진행했습니다.
서버의 부족한 성능을 감안하더라도 평균 응답 시간이 약 3000ms로 사용자의 사용 경험에 큰 불편함이 있을 것으로 예상되었습니다.
Redis를 활용해 캐시 적용 후 같은 조건으로 실시한 테스트입니다.
캐시 서버에 데이터가 모여 캐시 히트율이 올라가면서 평균 응답 시간이 약 1000ms로 빨라져 약 66.7%의 향상률을 보였습니다.
-
중복 조회 방지 로직 조회 시에 조회수를 ++1 하는 로직은 중복 유저의 조회인 경우에도 합산되는 사태가 벌어질 수 있습니다.
따라서 중복 여부를 판단하여 조회수 합산을 해야합니다.
중복 여부를 확인하며 조회하는 방법 중 쿠키를 사용하는 방법이 있습니다.
쿠키를 사용하는 방법은 쿠키를 사용자가 임의로 삭제하는 방식, 저장공간이 한정적이다는 단점이 있습니다.
이와 더불어 Celery 기술스택을 더 응용해보고자 Redis와 Celery-Beat를 활용해 조회수를 집계해보기로 했습니다.하루에 한 번만 조회수가 집계되는 것을 기준으로 구현했습니다.
- 게시물 조회 시 Redis에 view_{post_id} 키에 {ip}_{user_id} 밸류를 SADD 명령으로 추가
- Redis는 SADD 명령으로 데이터 추가 성공 시 1, 실패 시 0을 반환
- 반환받은 데이터를 통해 중복 조회인지 아닌지 판별 가능
Crontab으로 자정마다 Celery Beat 스케쥴링을 통해 조회수 관련 Redis 데이터를 삭제 해 조회수를 다시 집계할 수 있도록 했습니다.
- 게시물 조회 시 Redis에 view_{post_id} 키에 {ip}_{user_id} 밸류를 SADD 명령으로 추가
-
캐시된 게시물에 대한 조회수 업데이트 로직 캐시 전략을 도입하게 되며 조회수 업데이트 로직도 변화를 주어야 했습니다.
DB I/O를 줄이기 위해 캐시를 사용하는데 조회수가 증가할 때마다 DB에 업데이트 할 수는 없었기 때문입니다.
- 게시물을 조회할 때 위 로직을 통해 캐시 데이터에 조회수를 ++1
- 여기에 추가적으로 조회수가 업데이트 된 게시물이라면 Redis의 view_updated 키에 {post_id}를 SADD 명령으로 추가
- 캐시 데이터의 지속시간을 5분으로 설정해놨으므로 3분마다 Celery Beat를 활용해 DB에 bulk update
- 게시물을 조회할 때 위 로직을 통해 캐시 데이터에 조회수를 ++1
개발 도중 프론트 측에서 기존의 상태 코드로는 어떤 에러인지 특정하기 어려워 디버깅의 난이도가 높으며,
어디에서 발생한 에러인지 세분화된 에러 처리를 위한 추가 정보가 필요하다는 의견을 냈습니다.
이에 따라 프론츠의 디버깅 편의 증진 및 에러 세분화를 통한 사용자 경험 개선을 위해 에러 코드를 정의해 사용하자는 결론을 내렸습니다.
회의를 통해 에러의 범주를 정하고 적용했습니다. 커스텀 에러 코드 명세서
Exception을 종류별로 구분해 유지 보수하기 용이하게 폴더 구조를 구성하였습니다.
에러 코드 세분화로 인한 프론트 다양한 응답은 반영 후 캡쳐 예정