지난번엔 네이버 스포츠의 응원하기 기능을 분석해 보았습니다.
오늘은 분석한 내용을 토대로 만들어보기 위해서 요구사항을 정하고, 설계를 해보도록 하겠습니다. 최대한 간단하게 만들어보는걸 목표로 정했습니다.
요구사항
응원하기 기능은 크게 두개의 기능으로 나눠집니다.
- 응원 갯수를 주기적으로 받아와야한다.
- 응원할 팀을 선택 할 수 있어야한다.
이렇게인데요 우선 첫번째 기능에 대해서 구체적으로 정해봅시다.
1. 응원 갯수를 주기적으로 받아와야한다.
- 응원 갯수는 Home, Away팀 두개의 응원 갯수를 말합니다.
- 3초 간격으로 응원 갯수를 받아와야 합니다. (모든 유저가 3초 간격으로 받아야함)
- sportId, 즉 경기의 ID에 따라 데이터가 별도로 관리되어야합니다.
2. 응원할 팀을 선택 할 수 있어야한다.
- Home, Away팀 중 하나의 팀을 선택할때 마다 해당 팀의 카운트가 1 증가한다.
- 양팀을 중복으로 선택이 가능하다.
- 선택의 횟수는 제한이 없다.
위와같이 간단하게 요구사항을 정리해보았습니다. 생각보다 많지는 않은거 같은데 개발하다보면 더 많은 내용이 나올거 같습니다.
설계
설계를 하면서 가장 중요하게 생각해야할 부분이 응원 갯수를 어디에 어떻게 저장할것인가?
하는 것이었는데요. 아래와 같은 조건을 고려했습니다.
- 삽입, 조회가 빈번하게 일어난다.
- 응원갯수는 정수형으로 관리한다.
위 사항을 고려했을때 redis를 사용하는게 제일 적합하다고 판단했고, 레디스의 Hash와 hincrby 명령어를 이용해서 응원 갯수를 카운트 하는 형태로 구현하면 될거 같습니다.
DB외에 나머지는 이전 포스팅에서 분석한 내용을 토대로 Node.js / Socket.io를 이용해 구현해보려고 합니다.
간단하게 도식화를 해보았는데요 샘플이기때문에 Node.js에 서버와 클라이언트를 모두 구현하고, 레디스에 모든 데이터를 다 넣는 형태로 만들어볼 생각힙니다.
실제로 서비스를 운영단계까지 만든다고 하면 여러대의 레디스 서버와 함께 경기별, 사용자별 응원 데이터를 분리해서 저장하거나,
빈번한 입출력이 없을거 같은 사용자별 데이터는 RDB에 저장해도 될거 같고, 레디스도 레플리케이션을 이용해서 만약을 위한 이중화 작업을 해두는게 좋을거 같습니다.
샘플이기 때문에 경기를 관리하는 기능은 제외하였습니다.
API
- 최초 응원갯수를 가져오는 API
GET: /sports/cheer/${SPORTS_ID}
Response
1 | { |
- 응원을 하는 API
POST: /sports/cheer/${SPORTS_ID}
Request
1 | { |
Response
1 | { |
최대한 단순하게 만들어볼 생각으로 간단하게 API 설계를 진행해보았는데요.
다음번엔 이런 형태로 개발을 진행하면 될거 같습니다.