Maple Tech

메이플스토리 속 관제탑, 메이플 모니터링 시스템 이야기

2021.12.23

게임 속 세계에서도 현실 세계와 같이 매일 다양한 일들이 일어납니다. 유저들끼리 아이템을 거래하기도 하고, 특정 이벤트로 인한 사건이 벌어지기도 하고, 비정상적인 경로로 인게임 재화를 습득하는 어뷰징이 발생하기도 합니다. 그런데 게임 속에서 일어나는 이런 모든 일들을 모니터링하는 시스템이 있다는 것, 알고 계셨나요?
 

무엇을 모니터링 할까?

먼저 메이플스토리의 모니터링 시스템이란, 메이플스토리의 각종 이벤트와 콘텐츠, 그리고 재화, 아이템 거래와 같은 모든 활동에 대해 이상이 없는지, 어뷰징하는 유저가 없는지를 능동적으로 감지하고 관리자에게 경보를 해주는 시스템입니다.
이 시스템을 개발하게 된 배경에는 개인적인 고충이 있었는데요, 바로 라이브 서비스 중 가장 힘들었던 부분인 — 주말과 밤 늦게 오는 어뷰징과 이슈 확인 요청이었습니다. 어뷰징 이슈들은 주로 금요일 밤 또는 주말에 발생한 동향이나 유저들의 신고로 확인한 후 대응을 해오고 있었는데요, 이러한 이슈들이 사실 대부분 평일부터 이미 발생하고 있다는 것을 곧 알게 됐습니다. 
해커 및 작업장들이 주로 월~목까지 어뷰징을 한 두건 테스트하고, 제재없이 정상 동작할 경우, 주말에 최대한 이익을 노리는 구조였기 때문이었습니다. 이처럼 일반적인 버그가 발생하더라도 평일보다는 유저 수가 많은 주말에 버그에 대한 동향이 크게 발생하는 구조인만큼, 대부분의 이슈는 주말에 보고됩니다. 
그렇기에 어뷰징이 발생하면 최대한 빨리 이슈를 해결하고 싶은 마음에 (그리고 소중한 금요일과 주말에 쉬고 싶은 마음에,) 모니터링 시스템을 개발하게 되었습니다.

모니터링, 그거 어떻게 하는건데?

모니터링 시스템의 구조는 매우 간단합니다. 게임 서버에서 모니터링할 액션에 대한 모든 로그를 DB와 Text 로 남기고(1), 분석 툴이 이를 가공하여 이상감지 여부를 판단(2)하여 관리자에게 노티(3)하는 구조입니다. 편의상 각각 (1) 로그작업 / (2) 분석작업 / (3) UI작업 이라고 하겠습니다. 간단해 보이지만, 고려할 사항은 상당히 많습니다. 
저, 로그작업의 경우 로그의 갯수라던지 로그를 남기면서 서버에 부하를 주지 않는 방법 등에 대한 고려를 해야 합니다. 또한, 유지보수가 자동으로 되면 가장 좋겠죠. 
그 다음, 분석작업의 경우 이상감지 및 가공속도가 빠르게 나와야 실시간에 가깝게 이상을 감지할 수 있습니다. 
마지막으로, UI작업은 수많은 데이터 지표들을 얼마나 직관적으로 한눈에 확인이 가능하도록 구성하는지가 중요합니다. 이제 각각의 작업을 조금 더 세부적으로 들여다볼까요?
(1) 로그작업
로그작업에 대해 메이플스토리의 인게임 화폐인 ‘메소’를 예로 들어 설명해 보겠습니다. 메소의 이상감지를 위해서는 어떠한 경로에서 메소의 어뷰징이 발생했는지를 파악하는 것이 가장 중요합니다. (통계상 관점에서도 각 행위마다 메소의 증감이 중요하지요)
따라서 로그에 기입할 정보는 유저정보, 발생경로, 그리고 메소량이 될 것입니다. 그러나 단순히 메소의 증감이 있을 때마다 로그를 남기게 되면 서버에서 너무 많은 로그를 남기게 되어 부하를 주게 됩니다. 따라서 서버에서는 특정 시간 동안 데이터를 모아서(캐싱) 한 번만 기록하도록 구현되었습니다.
또한 메소 증감 시점마다 로그를 추가하게 되면, 만일 새로운 메소의 입수처, 소모처가 생길 경우 로그가 누락이 되기가 너무 쉽기 때문에, 코드에서 메소의 증감은 하나의 함수만을 이용할 수 있도록 제한을 걸고, 해당 함수에는 무조건 메소의 경로(Type)에 대한 정보를 인자로 호출하도록 구현되었습니다. 또한 사용하지 않는 디폴트 인자를 만들어, 모니터링에서 디폴트인자가 감지되면 관리자에게 노티를 주어 경로(Type) 정보를 입력하게 합니다.
이에 따라 남기는 로그는 다음과 같습니다. 캐싱을 하기 때문에 Count정보도 함께 기록하게 됩니다.
추가로, 작업된 로그의 신뢰도를 계속해서 체크하는 것도 매우 중요한 작업입니다. 고생해서 분석된 로그가 누락되어 쓸모없는 자료가 되면 곤란하니까요. 메소 모니터링의 로그 신뢰도 확인을 위해서는 로그상의 변화량과 실제 DB 상의 변화량을 체크하여 오차가 발생하는지 체크하고 있습니다.
(2) 분석작업
오차가 없다면, 이제 로그에 대해 분석작업을 진행할 수 있습니다. 분석을 위한 데이터 가공시에 고려할 사항은 속도입니다. 데이터를 가공하는 속도도 빨라야 하지만, 또 그 결과물을 빠르게 조회할 수 있는 방식으로 가공된 데이터를 저장하는 것도 중요합니다. 
데이터를 가공할 때는 대부분 라이브 서비스 중인 장비의 로그에 접근해서 가공을 하는 경우가 많습니다. 따라서 라이브 서버에 부하를 주지 않도록 주의해야 합니다. 부하를 주지 않기 위해서는 로그 기록시 데이터 가공작업에 대해서도 고려해서 로그를 설계해야 합니다. 조회조건 및 가공조건에 따라 테이블의 인덱스를 설계하고, 테이블의 Row 수도 많지 않게 유지하도록 캐싱 같은 기법을 사용해야 합니다. 
원하는 집계 결과물로 가공이 된 후에는 별도 DB에 가공된 결과물만을 저장해야 합니다. 로그와 마찬가지로 테이블의 인덱스도 UI 조회 시 검색할 조건에 따라 설계해야 결과물을 가져올 때에 빠른 시간에 조회가 가능합니다. 속도를 강조하는 이유는 모니터링에서 결과 조회는 한 번에 끝나지 않고, 여러가지 조건으로 여러 데이터를 비교하기 위해 수 차례 조회를 하게 되기 때문입니다. 따라서 한 번 조회할 때마다 1초 이상의 시간이 걸린다면, 관리자가 기다리다 지치는 일이 생길 수 있으므로 속도가 매우 중요합니다.
(3) UI 작업 
데이터 분석이 끝났다면, 이제 가공된 데이터와 비정상 데이터에 대해 관리자에게 노티를 하는 기능을 개발해야 합니다. 메이플스토리의 경우 1) 메일 발송2) 이상 감지 웹페이지를 통한 조회, 두 가지 방식으로 관리자에게 노티를 하고 있습니다. 그래프와 표를 이용하여 UI를 구성하고 있으며, 그래프의 경우 전체적인 흐름 추적을 위해서 사용하고, 표의 경우에는 세부적인 수치 정보나 이상 유저 또는 특이 유저 노티를 위해 사용하고 있습니다.
*) UI 작업중 그래프로 조회 작업을 적용한 메소 모니터링 중 일부 항목

UI와 관련해서 더 자세히 설명드리고 싶지만, 내부 보안상 더 이상 자세히 설명해드릴 수 없는 점 양해 부탁드립니다. (_ _)

무궁무진한 모니터링의 세계

이해하기 쉬운 메소를 예시로 들어 소개해 드렸지만, 앞서 설명드린 바와 같이 다양한 시스템을 통해 이와 같은 모니터링을 진행하고 있습니다. 이벤트나 콘텐츠의 모니터링은 다소 오픈하기 민감한 정보라 말씀드리긴 어렵지만요.
서버 성능 모니터링과 관련해서는 서버에서 렉을 유발할 수 있는 수많은 요소들에 대해 모니터링하고 있습니다. 기본적인 장비의 CPU나 VM 수치를 포함해, 메이플 서버에서 사용하는 각종 서버 지표와 관련한 수치들을 모니터링한다고 보시면 될 것 같습니다. (실제로 아래 정보뿐 아니라 수십개의 정보가 더 있습니다.)

그래서 잡아냈냐구요?

여기까지 읽으신 분들은 아마 그래서 이 모니터링 시스템으로 구체적으로 뭘 캐치할 수 있는지, 실제로 어떤 성과를 냈는지가 궁금하실 수 있을 것 같습니다. 그래서 메소 모니터링 시스템 도입 후 어뷰징을 감지했던 사례를 하나 소개해드리려고 합니다. 아래 그래프에서 초록색 실선은 NPC 상점에서 아이템을 판매하여 얻은 메소의 총합입니다.
그림이라 확인이 조금 어려우시겠지만, NPC 상점에 의한 메소 습득이 크게 상승한 것을 확인할 수 있었습니다. 당시 이벤트나 콘텐츠에서 특별히 NPC 상점 판매량이 크게 늘어날 이유가 없었는데요, NPC 상점에서 아이템을 판매한 유저들을 모아 아이템 입수 로그들을 모두 조사해보니, 일부 유저들에게서 비정상적인 프로그램을 사용한 로그가 다수 발견되었습니다.
해당 유저들을 조금 더 자세히 트래킹해본 결과, 비정상적인 플레이 패턴을 이용하여 아이템을 다수 획득하고, 이를 NPC 상점에 판매함으로써 메소를 습득하였음이 확인되었고, 해당 유저들에 대해 즉시 제재 및 메소 회수 조치 등을 진행했습니다.
이어서 들려드릴 두 번째 사례는 서버 모니터링을 통해 메모리 누수를 탐지했던 이야기입니다. 우선 서버 지표를 모니터링하던 중 VM 수치와 메모리 관련 지표가 계속해서 상승하는 것이 감지되어, 메모리 누수가 발생하고 있다고 확인할 수 있었습니다.

이와 관련한 원인을 확인하기 위해 Object Counter 라는 지표를 체크했는데요, Object Counter는 서버에서 특정 object를 추가하면서 메모리를 할당하거나 object를 지우면서 메모리를 해제할 때마다 이를 +/- 로 계산한 Object의 수치 정보입니다.
이들 중에 회색의 NPC Object 수치가 VM 수치와 유사하게 상승하는 것을 확인할 수 있었고, 최근 추가되어 할당하는 NPC Object 중에 문제가 있는 NPC를 확인했습니다. 이 NPC는 유저의 퀘스트 수행 시마다 NPC Object를 새로 할당하여 생성한 후, NPC를 지워서 메모리를 해제하는 로직이 없음을 확인할 수 있었고, 빠르게 원인을 파악한 만큼 바로 조치를 취할 수 있었습니다.
물론 위에 말씀드린 사례들은 좋은 기억으로 남았던 사례들이고, 좋지 않은 기억으로 남은 사례도 있었습니다. 대표적으로, 2021년 1월에 있었던, 루나 크리스탈을 사용했을 때 특정 펫이 나오지 않았던 사건이 기억에 남습니다. 당시 루나 크리스탈은 캐시 확률 아이템으로 중요도가 높은 아이템 중 하나라, 확률 모니터링 시스템이 이미 개발이 된 상태였는데요, 확률 이상 체크를 하루 동안의 데이터를 모아서 검증을 하고 있었던 터라 인지가 다소 늦었습니다. 해당 사건 이후로 패치날, 출시날에는 이보다 더 짧은 주기로 자주 데이터를 취합하여 확률을 검증하며 빠르게 이슈를 감지하기 위해 노력하고 있습니다.

메이플스토리의 관제탑

초기 모니터링 시스템은 단순히 인게임 재화인 메소나 메포의 어뷰징이나 이상을 감지하는 것을 염두에 두고 개발된 것이 사실입니다. 그러나 이러한 이상 감지를 진행하다 보니, 결국에는 메이플스토리에서 벌어지고 있는 모든 이벤트, 콘텐츠, 서버상태 또는 외부 환경요인과 같은 수많은 조건에 영향을 받게 된다는 것을 알게 되었습니다.
따라서 현재는 단순히 어뷰징 및 이상 감지가 아니라 메이플스토리 내에서 일어나고 있는, 유저에게 영향을 주고 있는 모든 요소들에 대한 모니터링 및 관제 시스템을 만드는 것을 목표로 개발을 진행하고 있습니다. 쉽게 말해서 “메이플에서 내가 모르는 일은 일어나지 않아야 한다”를 모토로 작업을 진행하고 있습니다. 이에 더해, 모니터링 시스템과 과거의 지표 데이터를 바탕으로 앞으로 진행할 이벤트 및 콘텐츠의 각종 이슈 및 지표 예측도 진행하면서 이슈를 미리 방지할 수 있는 방안도 마련하려고 노력하고 있습니다.
이상 메이플스토리의 관제탑, 모니터링 시스템 개발에 대한 이야기를 들려드렸는데요, 이 분야에 관심 있으셨던 분들께 조금이나마 흥미로운 내용이었길 바라며 마치겠습니다. 감사합니다.

11년차 라이브 서비스 프로그래머 이상윤