방문자 통계 API 개발
방문자 통계 수집 로직을 만든 이야기입니다.
상황은 이렇습니다.
- 가맹점들을 위한 성별/나이 통계 서비스 개발
- Open API 를 사용해 사용자 통계 데이터 수집 (MakeShop OpenAPI)
- 유저가 들어올 때 마다 Open API 를 통해서 데이터를 수집하는걸로 설계
문제점과 해결 방법
- Open API 관련 🦾
-
문제
처음에는 시청자 유입 시점에 시청자마다 Open API로 조회해서 통계 데이터를 적재 했습니다. 하지만 만약 방송에 많은 트래픽이 몰릴 때 유입 시점에 적재를 하면 Open API 서버에 영향을 줄 수 있다는 문제가 생깁니다.
-
해결
생각한 해결 방안은 일괄처리입니다. 일괄 처리를 하려면 방송별 방문 유저 데이터(ID)가 필요합니다. 개발 시에 기존 유저 테이블은 유저의 순수 정보만 담고 있었습니다. 때문에 방송별 참여 리스트 테이블을 생성해서 방송 종료 시점에 통계 데이터 적재를 일괄 처리했습니다.
-
- 방문자 리스트 테이블 🗣️
-
문제
일괄 처리를 위해 개발을 진행하던 도중, 데이터의 적재량이 걱정되었습니다. 채팅 적재를 RDB에 하고 있지만 채팅보다 방문자수가 훨씬 더 많기에 한 방송마다 데이터가 무수히 쌓일 것 입니다.
-
해결
MariaDB에 있는 데이터 타입, JSON을 활용하였습니다. 방송별 방문자(ID)를 JSON 형식(List)으로 저장해 Update 처리를 해줬습니다. 통계용 데이터 테이블도 row가 동일하기에 위와 같이 방식으로 처리해주었습니다.
-
- 방송 종료 로직 처리 시간 ⏱️
-
문제
방송 종료 시점에 백엔드가 하는 일은 너무나도 많습니다. 채팅 수집이나 VOD 처리 등등 하는 일이 많았기에 방송 종료 응답이 느린 편이었습니다.
-
해결
조금이나마 방송 종료를 빠르게 처리하기 위해 방문자 통계 수집 로직만 비동기 처리를 하였습니다.
-
마무리와 느낀점
MySQL이나 MariaDB에 JSON 타입이 있는 것을 알았습니다. 새로 나온 기술이나, 업데이트된 사항을 꼼꼼하게 체크하는 습관을 들여야겠다고 생각하였습니다.
한 서비스 로직을 만들면서 여러 가지 상황을 가정하여 개발하는 것이 즐거웠습니다. 어떠한 프로세스를 개발할 때에는 고려해야될점이 많다고 느꼈습니다. 그리고 OpenAPI를 사용하면서 우리 회사의 서버뿐만아니라 OpenAPI의 서버도 중요하다는 것을 깨달았습니다.
마지막으로 방문자가 방문할 때 마다 방송 방문 리스트에 DML 처리를 해야되는게 성능 부분으로 걱정이 되었습니다. 향후 다른 아키텍처를 찾아보고 적재 부분을 리메이크하기로 결정했습니다.
👉🏻 관련 블로그