Node.js 기반 백엔드 시스템,#8

Log의 시작과 끝.

백엔드 시스템을 만드는 경우에 고민하는 것 중에 또 다른 대표적인 고민 내용 Log와 관련된 기능이거나 Log 수집과 관련된 시작과 구성 형태를 어떻게 할 것이며.

이러한 수집 행위와 시기, 주기, 빈도와 수집 내용들에 대해서 얼마나, 어느 정도 규모로 시작하고 관리할 것에 대한 갈등을 하기 시작할 때이다.

가장 먼저 주의해야 할 것은 이거다!

먼저, 초기에 구축된 로그 시스템은 버리게 된다는 것을 잊지 말자.

그렇다. 대부분 그러하다. 초기에 구축된 로그 시스템을 끝가지 이용하거나, 의미 있는 유료 모델이나 데이터 가공 수준으로 정의할 수 있도록 만드는 것은 사실상 불가능하다.

대부분 비즈니스가 변화하고, 기능이 변화되면서 초기에 구현된 로그 시스템은 버리게 되거나, 대부분 고장 나거나 잘못된 형태로 망가지는 것이 99.9%라고 경험상 이야기할 수 있다.

더군다나, 게임 서버를 만들 때에 '게임 로그'를 DB에 담는 경우가 있다. 이 경우에는 100% 버려지게 된다고 2 장담한다.

게임이 조금만 활성화돼도 데이터가 유실되거나 소실되며, DB에서 받아들일 수준의 게임 로그라면 의미도 없는 데이터라고 평가할 수 있다.

DB에 게임 Log, 담는 행위는 삽질

그냥, 삽질입니다. 담을 수 있을 정도면 게임이 실패한 경우가 많습니다. 성공적으로 안착되는 게임이라면 DB에 게임 Log는 담을 수 있는 수준을 넘어섭니다. 말 그대로, 택~~ 도 없습니다.

그리고, 사용자 패턴 등은 계속 형태가 증가되면서 어뷰징이나 해킹, 이상 동작 등을 방어하기 위해서 JSON의 형태로 만들어지는 경우가 대부분입니다. 파일로 해당 내용을 떨구도록 디자인해야 합니다.

명심해야 할 것은 또 있습니다.

심플해야 한다

그렇습니다. 심플해야 소실될 가능성도 줄어들고, 관리하기도 편합니다. 시작부터 끝까지 심플한 구조로 작업해야 합니다.

Hadoop이나 이런 거창한 시스템은 초기에는 결코 고려할 사항들이 아닙니다. 나중에 능력 되면 그 상황에 맞추어서 진행하면 됩니다.

그리고, 다시 한번 이야기하지만.. '결제'와 같은 내용은 파일 시스템이나 NoSQL로 만들지 마세요.

철저하게 트랜잭션과 정합성 중심의 DBMS를 사용하여야 합니다.

자.. 하여간 어떻게든 로그는 모일 것이고, 관리는 할 것입니다. 가장 흔하게 사용되는 것은 ElasticSearch와 Logstash, Kibana로 이야기되는 ELK스택이 일반적입니다. 정말 훌륭하고, 널리 사용됩니다. 

그것으로 충분합니다. 다만, 돈이 많다면 Splunk도 추천합니다.

많이 투자받았다면... 전환하는 것도 고려해볼 만합니다.

분명한 것은 초기를 넘어서고 수익을 올리기 시작하면서부터 어뷰징이나 C/S응대, 데이터 분석을 위한 Log와 관련된 작업이 증가됩니다.

정답은..

흥행 이후에 Log시스템은 구축해도 무방하다.

입니다.