아무래도 서버 프로그래머로 일해다 보면, 데이터에 대한 요청을 많이 받게 된다.
사실 프로그래머로써 개인적인 (그리고 꽤나 많은 서버 프로그래머 분들도 같은 생각을 가지고 있었던) 목표는 뛰어난 퍼포먼스의 서버를 만들자는 것이었다.
하지만 서버 프로그래머에게 기대하는 최우선은 최상의 안정성의 서버이지, 최상의 성능의 서버가 아닌 경우가 많다.
그럼에도 최고의 성능의 서버를 만들고 싶은 것은 일종의 로망 아닐까?
안정성과 함께 서버 프로그래머에게 기대되는! 하지만 조명 받지 못하는 그것…!
바로! 데이터 수집과, 통계, 지표에 대한 이야기를 하고자 한다.
흔히 게임 로직이나, 가용성 확보, 성능에 대한 고민,고찰은 많지만 로그 작업은 크게 중요치 않게 여겨지곤 한다.
하지만 사업적으로, 기획 적으로, 서비스 적으로…그래 인정하자. 모든 측면에서 데이터는. 로그는 중요하다.
그것도 매우.
통계는 많은 것을 알게 해준다. 물론 통계를 통한 원인이나 현상 파악에 오류가 있을 수 있으나, 통계 그 자체가 가진 오류는 아니다.
게임 접속 과정에서의 이탈 원인을 알아 내려면 게이트웨이, 패치, 로그인 어느 시점에서 이탈했는지, 패치 시간이 얼마가 소요될 때 이탈하는 지를 알아야 한다.
매칭이 오래 걸린단다. 평균 몇초가 소요되는지, 구간 별 매칭 시간, 매칭 취소율, 매칭 취소시 기다렸던 시간을 알아야 한다.
특정 퀘스트를 통한 재화가 크게 증가했다. 버그가 생겨, 무한 클리어가 되는건 아닐까? 통계는 검증과, 근거, 추정 등 다양한 역할로 쓰인다. 내가 배워온, 내가 갖게 된 지론인 “엔지니어는 가설이 아니라 증명 해야 한다”는 이론과도 일맥상통한다.
다년간 통계로 데이터를 추출, 분석 하며 깨닳은 게 있다.
첫째로, 발생한 이벤트 단위로 추적이 쉽게 구성이 되어야 한다. 즉, Timeline 구성이 가능해야 한다. 보통 컨텐츠 특수화 등 데이터가 다양하게 구성되기에 테이블이 쪼개지는 경우가 많다. join으로 처리할 수도 있지만, 단일 테이블로 관리되는게 훨씬 편리한게 사실이다. Timestamp가 초단위 이기 이기 때문에, Timestamp를 키로 못잡고 DateTime으로 잡아야하는데, 그만큼 시간 단위가 정밀해지지만, 데이터 용량이 커지기도 한다. 대안으로 두가지 방식을 제안하는데,
- JSON 컬럼에 상세 데이터 저장.
- detail 이라는 컬럼을 두고 해당 컬럼에 json으로 상세 정보를 기록해둔다.
- mysql 5.7에선 json 컬럼을 정식 지원하므로, 훨씬 더 유연하게 쿼리할 수 있는 장점이 있다.
- detail 이라는 컬럼을 두고 해당 컬럼에 json으로 상세 정보를 기록해둔다.
- 추가 데이터는 확장 테이블에 저장.
- 예를 들어 상점 구매로그면, 상세 상점 확장 정보는 shop_log_extend 테이블에 저장하는 식이다.
둘째로, 그룹화가 쉬워야 한다. 데이터가 행 단위로 기록되지만, 통계로는 보통 키가 되는 정보를 바탕으로, 그룹화된 정보를 요구한다. 예를 들어, 상점 통계로써 요구되는 것은 주로 상품 별 판매 횟수, 상품 별 판매 시간, 상품 별 구매자 레벨 등 상품이 키로 잡히는 것이다. 또 로그인 기록이라고 치면, 시간 별 로그인 횟수가 의미가 있고, 스테이지 클리어 정보의 경우에도 스테이지 별 클리어 횟수, 시간 별 스테이지 진행 횟수 등을 요청 받게 된다. 즉, 스테이지도 키로 잡혀야 하며, 위 세 로그에서 모두 기준이 된 시간도 키로 잡혀야 한다.
셋째로, 로그는 실시간에 근접한 데이터를 다뤄야 한다. 통계에 생명은 정확성이다. 하지만 그에 못지 않게 신속성도 중요하다. 왜냐하면, 서비스 신뢰도나, 버그로 인한 사이드 이펙트등을 빠르게 분석할 수 있으며, 해당 컨텐츠가 어떠한 반응인지도 통계로 빠르게 확보할 수 있기 때문이다.
마지막으로, 데이터 폭발에 대비 해야 한다. 유저가 많고 이벤트가 많을 수록 데이터가 폭발한다. 보통 게임 컨텐츠는 결과만 들고 있기 때문에 생각보다는 데이터가 적다. 데이터간 연관성이 적은 경우도 많아서, 행 단위 access가 이루어져 그에 따른 부하는 더더욱 작다. 하지만 플레이시 발생한 이벤트가 많을 수록, 로그 테이블은 폭발한다. 그래서 일반 RDB에 기록하긴 쉽지 않다. 로그용 DB는 RDB가 아닌 NoSQL을 사용하거나, 파일 로그로 남긴 후 background log shipping 등의 처리로 로그로 인한 부하를 줄여야 한다. 특히 인스턴스 서버 (게임 서버)는 여러개이고, 그 결과를 취합한 곳이 통계 DB가 될텐데, 여러 퍼져 있는 서버에서의 로그를 모두 취합하려면 RDB에선 쉽지 않다. 또한 검색도 쉽게 이루어져야 한다는 의미에서 NoSQL을 로그 저장소로 쓰는 방향을 추천한다.
이상 너무나 중요하지만, (특히 게임 업계에서는. 그리고 개발 과정에서는 더더욱) 비중 있게 다뤄지지 않는 통계에 대한 이야기였다.