간단한 게임 서버 모니터링 시스템 구축

이번 글에서는 게임 서버 모니터링에 도움이 되는 간단한 테크닉에 대해서 알아보도록 하겠다.

게임 개발 과정은 고난의 연속이다. 출시를 목표로 피곤에 쩔은 몸과 피폐해진 정신을 인내하지만, 클라이언트-서버 개발 완료로 끝날 것이라 생각되었던 그 고난들은 안타깝게도 서비스 출시 이후까지도 계속된다. 단순히 계속되는 정도가 아니라, 많은 이들이 주지하다시피 사실 출시부터가 본격적인 고난의 시작인 경우가 대부분이다.

출시가 끝이 아니라 여정의 시작이 되는 이유는 여러가지가 있는데, 먼저 서비스가 죽지 않고 안정적으로 동작하도록 해야되며, 유저 피드백에 따라 게임의 운영이나 업데이트를 신속하게 조정해야되는 것이 큰 이유 중 하나이다. 출시 후 첫 업데이트에 대해서 사전 계획을 가지고 준비하고 있던 경우라 할지라도, 많은 경우 급작스레 계획이 수정 되곤 한다.

여기서 말하는 유저 피드백은 공식 까페 등에서 유저들이 올리는 글이라기 보다는 KPI 라고 불리우는 객관적인 성능 지표를 의미한다. 까페의 글들은 정량화 되기 어렵고 개인 취향에 따른 것들도 많기 때문이다.

KPI 종류

KPI 는 관점에 따라 1) 재무적인 KPI, 2) 게임 콘텐츠 상의 KPI, 3) 서버 운영에 있어서의 KPI 로 구분할 수 있다. 재무적인 KPI 는 우리가 일반적으로 많이 들었던 수익(revenue), 유료 유저 비율 (paying user rate), 유저당 평균 수익 (ARPU), 유료 유저당 평균 수익 (ARPPU), 유저 생애 가치 (LTV) 등 돈과 직접적인 관련이 있는 중요한 것들이다. 이런 지표들은 회사의 사업담당자가 주로 관심을 갖는 지표이다.

재무적 KPI 가 이익 창출을 위한 궁극적인 KPI 라면, 게임 콘텐츠 상의 KPI 는 게임 안에서 벌어지고 있는 일들에 대한 KPI 로서 재무적 KPI 의 선행 지표격이라고 할 수 있다. 여기에는 일간 활동 사용자수 (DAU), 월간 활동 사용자수 (MAU), 잔존율 (retention rate) 등 게임에 공통적인 KPI 와 게임 콘텐츠 각 단계별 통과 비율 (funnel analysis), 게임내 경제의 인플레이션 흐름 (전체 재화 수준, 혹은 재화별 수준) 등 게임에 따라 다른 의미를 갖게 되는 KPI 로 나눌 수 있다. 이런 지표들은 주로 게임을 설계하는 기획자나 프로듀서가 관심있게 봐야되는 KPI 에 해당한다.

앞의 두 KPI 종류와 다르게 서버 운영에 있어서의 KPI 는 서비스의 안정성에 관련된 KPI 이다. 이 때문에 이 KPI 는 급격한 변화를 목표로 하기 보다는 주로 안정적인 수치 안에서의 관리를 목표로 한다. 여기에는 수용 가능 최대 동접, 클라이언트 패킷에 대한 반응시간, CPU 나 메모리 등의 리소스 사용량, DB 나 캐시와 같은 외부 시스템에 대한 요청 처리량 및 반응 시간 등이 포함된다. 이 KPI 들은 주로 서버 개발자가 주의깊게 살펴봐야되는 지표다.

KPI 모니터링

재무적인 KPI 나 게임 콘텐츠 KPI 에 대해서는 꽤 오래전부터 사람들이 많은 관심을 가져왔고, 많은 상용 솔루션이 나와있다. 그리고 존재하는 솔루션의 전형적인 형태는 클라이언트에 원격 로그용 SDK 를 심고, 로그인, 로그아웃, 결제 등과 같은 주요 이벤트에 대해서 SDK 를 통해서 기록을 남기는 방법이다. 클라이언트 SDK 를 통해서 수집된 내용은 분석 서버에서 통합되어 의미있는 KPI 로 생산되게 된다. 그런데 이런 솔루션들은 주로 일반화된 KPI 가공에 촛점이 맞춰져 있기 때문에 게임에 특화되어있는 지표는 여전히 게임에서 직접 생산해야되는 경우가 많다.

재미있는 것은 서버 관련 KPI 가 안정적인 서비스를 위해서 필수불가결함에도 이를 위한 솔루션들이 거의 존재하지 않는다는 점이다. 그 때문에 많은 경우 서버 개발자는 일반적인 ganglia 나 nagios 등 OS 수준의 모니터링 툴이나 프로세스 모니터링 툴, 혹은 DB 성능 툴들을 대신 사용하곤한다.

하지만, 이런 툴들이 따로따로 존재하는 경우 서비스의 현 상황을 한눈에 파악하기 힘들고, 그리고 앞의 게임 콘텐츠 KPI 에서 설명한 것처럼 일부 커스텀 기능의 추가 때문에 직접 개발해야되는 경우를 피할 수 없는 경우도 종종 있다.

이런 이유들 때문에 게임 콘텐츠 KPI 및 서버 운영 관련 KPI 를 모니터링 하는 툴을 직접 만들어야되는 경우 손쉽게 적용할 수 있는 구조로 다음과 같은 두 가지 방법을 생각할 수 있다.

방법1: 게임 서버에 내부 카운터를 유지하는 방법

이 방법은 게임내의 정보를 카운터로 노출하고 외부에서는 이를 단순히 그래프로 표시해주는 방법이다. 주로 후처리 없이 지속적으로 변동되는 휘발성 정보를 기반으로 하는 경우에 해당하며 다음과 같은 두 가지 layer 로 구성된다.

  1. 기초 데이터 생성 layer: 게임 서버는 주기적으로 주요 지표들을 (이를 counter 라고 부르겠다) 특정 DB 에 저장하는 역할을 한다.
  2. 표시 (presentation) layer: 앞에서 DB 에 저장된 데이터를 읽어들여 그래프로 표시해준다. 보통 dashboard 형태가 된다. Django 나 Flask 와 같은 framework 을 이용해 쉽게 구성할 수 있다.

기초 데이터 생성 layer 를 위해 게임 서버는 counter 라는 hash map 이나 dictionary 를 관리한다. 그리고 기초데이터에 해당되는 주요 숫자가 바뀌게 되면 이를 반영해준다. 예를 들어, 각 패킷 별로 처리 지연 시간을 보고 싶다면, counter 에 <패킷 이름, 패킷 개수, 처리 지연 시간의 누적값> 을 관리할 수 있을 것이다. 그리고 이를 통해서 각 패킷별 처리 시간의 평균과 표준 편차를 DB 에 저장할 수 있을 것이다.

이런 형태로 모니터링 될 수 있는 데이터는 CPU/메모리 등 OS 리소스 사용량, 앞에서 예를 든 것처럼 패킷 별 처리시간, 패킷 별 트래픽량, DB 요청 숫자 및 반응 시간 등이 있을 수 있다.

방법 2: 로그 분석을 이용한 방법

앞의 방법은 별도의 가공이 필요없는 데이터를 기반으로 하였으나, KPI 생성을 위해 가공이 필요한 데이터를 기반으로 하는 경우는 이를 로그로 저장하고 로그를 분석해야된다. 이 때는 다음과 같은 세 가지 계층 구조를 갖게 된다.

  1.기초 데이터 생성 layer: 게임 서버는 주요 상황에 대해서 유실되지 않는 방법으로 로그를 남긴다. DB 에 저장하는 것도 가능하고 파일로 남기는 것도 가능하다. 로그인, 로그아웃, 결제 등을 로그로 남기는 것을 생각할 수 있겠다.
  2. KPI 생성 layer: 기초 데이터를 읽어들여 KPI 를 생성하는 작업을 한다. 예를 들어 로그인 정보를 통해 평균 플레이 시간이나, 잔존율 등을 계산 할 수 있을 것이다. 매번 KPI 를 계산하는 것이 큰 부하를 줄 수 있으므로 한번 계산된 KPI 는 DB 에 저장하는 역할도 한다. 
  3. 표시 (presentation) layer: 앞의 방법1 에서와 마찬가지로 생성된 KPI 를 표시해주는 dashboard 라고 생각하면 된다.

주의할 점은 위의 두 방법이 상호 배타적인 방법이 아니라 데이터의 성격상 후처리가 필요한지 여부에 따라 구분이 될 뿐이라는 점이다. 그리고 많은 경우 모니터링 툴은 두가지 데이터 형태 모두를 필요로 한다. 따라서 “표시 layer” 로 언급된 dashboard 는 두 방법에 의한 데이터를 모두 표시하는 것이 일반적이다.

아이펀팩토리 문대경 대표

답글 남기기

댓글을 게시하려면 다음의 방법 중 하나를 사용하여 로그인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중