.

Data_Engineering_TIL(20221209)

카카오 개발자 컨퍼런스 자료를 공부하고 정리한 내용입니다.

[세미나 정보]

• 제목 : 생성부터 활용까지, 게임데이터 Flow 따라가기

• 내용 : 카카오게임즈의 모바일 게임 로그 데이터가 어떻게 생성되고 수집되는지, 이 수집된 데이터를 어떻게 처리하고 활용하는지에 대한 전체적인 과정을 소개함

• URL : https://if.kakao.com/2022/session/63

[세미나 목차]

1 ) 인트로

2 ) 데이터 생성 및 수집

3 ) 데이터 처리

4 ) 데이터 활용

5 ) 아웃트로

[공부한 내용]

게임에서 플레이 하는 모든 액션들에 대해서는 로그가 발생한다.

데이터를 다루는 조직의 가치는 이떻게 끊임없이 생성되는 데이터를 어떻게 잘 처리하고, 분석하고, 활용하느냐에 따라 달라지게 된다.

카카오게임즈에서는 기존에 데이터를 저장하고 분석하던 온프라미스의 데이터 웨어하우스의 환경은 유연성과 분석적 측면에서 한계가 점점 왔었다.

MMO RPG등의 게임들을 서비스 하면서 로그의 양이 점점 증가하게 되었고, 게임서비스의 특성상 업데이트시 엄청난 트레픽이 몰리게 되어 빠른 서버 증설과 인프라적 대응이 필요해졌다. (물론 늘어난 리소스를 유연하고 빠르게 다시 줄이는 것도 가능해야 했다.)

데이터 분석 측면에서도 정형화된 데이터를 분석하는 것 외에도 여러 형태의 스키마를 갖은 데이터를 수집해서 분석도 같이 해야하는 니즈가 생겼다.

그래서 카카오 게임즈는 가용성과 운영효율화를 극대화 하기 위해서 AWS 클라우드를 기반으로 데이터 레이크 환경을 구축하여 운영하고 있다.

데이터 생성 및 수집은 어떻게 할까

그러면 게임상에서 로그 데이터는 어떻게 생성이 되고 수집이 되는지 알아보자.

카카오 게임즈는 자체 개발하는 게임도 있지만 배부분은 퍼블리싱 사업을 하고 있다. 그래서 여러 게임사에서 개발한 다양한 게임들을 통합적으로 관리하기 위해 지니 플랫폼 이라는 게임 플랫폼을 사용한다. 게임 로그의 경우 게임 플랫폼에서 사용이 가능하도록 템플릿화하여 개발사에 제공이 되고, 개발사에서는 이 템플릿에 맞게 게임로그를 생성하여 데이터를 전송하게 된다. 게임과 지니 플랫폼을 연동하기 위해서는 게임 어플리케이션에 SDK가 연동이 되어야 한다. 게임 어플리케이션에서는 SDK를 통해 지니 플랫폼과 연동이 되어 ‘카카오 인증’, ‘게임 로그인’, ‘게임 플레이중 각종 액션’에 대한 로그를 전송하는 등에 다양한 기능을 제공하게 된다.

유저가 게임을 플레이 하는 경우 예를 들어서 카카오 인증을 통해 게임을 로그인 하고나서 메인 스테이지에서 몬스터를 사냥해서 아이템을 얻는 것과 같은 액션의 모든 로그들이 전송이 되게 된다. 이러한 로그데이터는 Open API 방식으로 API를 호출하거나 Session 방식을 통해 전송이 되고, 전송된 데이터는 로그 버킷이라고 하는 로그 저장소에 실시간으로 쌓이게 된다.

대용량의 로그 데이터가 로그 버킷에 저장이 되는데 일반적으로 이 로그 데이터는 세가지로 분류를 하고 있다.

이러한 다양한 로그들은 보관주기에 따라 보관이 되며 원카피 기준 파케이나 gzip 압축 형태로 약 420TB로 유지되고 있다. 그리고 점점 늘어나고 있다.

종류 1. 게임 로그

게임을 플레잉할때 발생하는 모든 로그

종류 2. 플랫폼 로그

카카오 인증을 통해 로그인을 하거나 하트비트를 이용한 헬스체크 등 플랫폼에서 발생하는 로그를 말함

종류 3. 서비스 로그

사전예약이나 설문조사 같이 게임을 운영할때 서비스 관점에서 생성하고 관리하는 로그

이러한 대용량의 로그가 로그 버킷에 쌓이고만 있으면 점차 늘어나는 데이터를 감당하지 못할 것이다. 그래서 로그버킷에 쌓인 데이터를 실시간으로 kinesis data streams 이라는 스트리밍 처리에 사용되는 메세징 큐로 전송하고 있다.

앞서 로그의 종류를 세가지라고 언급을 했었는데 이러한 로그들은 별도의 구분없이 로그버킷으로 들어와서 키네시스 데이터 스트림으로 전송이 되고 있어서 데이터를 잘 활용하기 위해서는 스트리밍 데이터를 용도와 특성에 맞게 잘 분류하는 작업이 필수적이다.

로그 버킷에서 실시간으로 키네시스로 전송되는 데이터가 S3에 저장되기까지 과정이다. 키네시스 데이터 스트림즈에서 람다를 거치게 되는데 아래에 스크린샷과 같이 앞서 언급했던 로그가 특성에 따라 분류하는 그 과정을 담당하고 있는 부분이다. 키네시스 데이터 스트림즈에 데이터가 쌓일때마다 람다 트리거가 실행이 되어 들어오는 스트림 데이터를 읽어서 로그상에 code 에 따라 세종류로 분기를 하게 된다. 이 분기된 데이터를 딜리버리 스트리밍인 키네시스 firehose로 전송을 하고, firehose에서는 분기되어 들어오는 스트리밍 데이터를 data id, 하위의 hour 단위로 파티션을 생성하여 S3에 저장하게 된다.

그러면 실시간으로 수집되는 데이터를 바로 볼 수 있을까

실시간으로 수집되는 데이터를 아래와 같은 아키텍처를 통해서 실시간 대시보드에서 확인이 가능하다. 아키텍처의 윗부분은 지니 플랫폼으로 들어오는 로그 데이터에 대한 처리과정이다. 데이터가 로그버킷을 통해 키네시스 데이터 스트림즈로 전송이 되고 이 데이터를 람다에서 분기처리하고 firehose를 통해 opensearch(elasticsearch)로 보내고 있는 구조이다.

아래쪽 부분은 개발사에서 관리하는 디비데이터와 같이 플랫폼으로 들어오는 템플릿화 된 데이터가 아닌 다른 정보의 데이터가 카프카를 통해 들어오고 있는 구조이다. 여기서는 오토스케일링 그룹으로 구성된 EC2에서 카프카 브로커에서 데이터를 컨슘하여 오픈서치로 보내고 있다.

오픈서치로 수집된 데이터는 키바나를 통해 시각화되어 사내 BI 시스템에서 실시간으로 이용자 또는 매출과 관련된 데이터를 확인할 수 있게 된다.

외부에서 수집해야 하는 데이터들도 있는 이것들은 생성이랑 수집은 어떻게 할까

게임 로그인시 카카오 인증을 거치기 때문에 카카오 계정에 대한 최소한의 정보수집이 필요하다. 또한 카카오 게임즈가 분사하기 전부터 사용하던 기존의 시스템에서 데이터를 수집하는 경우와 같이 카카오의 하둡이나 카프카 등 인프라를 통해 수집하는 데이터가 있다. 뿐만아니라 외부 API를 이용하여 환율이나 광고 데이터도 수집을 해야한다. 이렇게 수집된 모든데이터들이 집계에 사용이 되기 때문에 중요하다. 이를 위해 수집을 담당하는 ingestion 서버가 데이터를 수집하여 S3에 저장을 하고, 수집이 종료되면 Airflow를 트리거 하여 이후 집계작업을 진행하게 된다.

이렇게 다양한 방법으로 수집한 데이터는 어떻게 할까

데이터가 처리되는 과정은 마치 공장이 돌아가는 과정으로 비유할 수 있다. 먼저 앞서 봤듯이 다양한 경로를 통해 데이터가 수집이 된다. 이 데이터들은 공장에 체계화된 설비가 돌아가는 것처럼 일정시간이 되면 구조화되고 집계가 된다. 최종적으로는 이 수많은 데이터가 축약이 되어 한눈에 파악이 가능해지고 새로운 insight를 얻을수 있게 된다.

카카오 게임즈는 아래와 같이 Airflow를 중심으로 하는 데이터 파이프라인을 운영하고 있다.

각 부분별로 알아보자. 먼저 ingestion 서버에서 데이터 수집이 끝나면 에어플로우를 트리거 하거나 특정시간이 되면 스케쥴러에 따라 DAG 작업이 시작되게 된다. 카카오 게임즈에서는 MWAA를 사용하고 있다. 배치작업을 수행하기 위해 MWAA의 DAG BAG과 연동된 특정 S3 버킷에 DAG file과 requrements.txt, SQL file 들이 저장되어 있어야 한다. 해당 file들은 깃헙에서 관리가 되고 있고 이 file들은 젠킨스라는 배포툴을 통해 해당 S3 버킷으로 배포가 되게 된다. MWAA에서는 S3에 연동된 이 file들을 통해 작업을 수행하게 된다.

airflow DAG가 트리거링 되거나 스케쥴링으로 작업이 실행되면 실시간으로 수집된 로그데이터에 대한 가공이 시작된다.

아래와 같이 실시간으로 수집된 로그데이터를 수집하고 있다. 코드가 리소스인 경우인데 재화와 관련덴 로그데이터이고 json 형태로 되어 있다. 아래와 같이 여러가지의 정보가 키벨류 형태로 되어 있으며 정형화 시키지 않을 경우 눈으로 파악하기 어려운 형태다. 이러한 형태의 로그들은 각 게임의 코드마다 각각 생성되어 1초에도 수만개씩 쌓이고 있다.

예시 (code = ‘resource’)

{"appId": “666111", "playerId": "**********", "amount": 58050203, "character1Id": "**********", "character1Lv": 69, "character1Nm": "**********", "country": "TW", "delta": 200, "gameWorld": "world1", "modTime": 1661792516000, "modType": "add", "os": "Windows", "paid": "u", "playerLv": 69, "rCurrency": "Gold", "reason": "A_QUEST", "resourceAttr3": "10", "subReason": "EliteDungeon", "lang": "zh􏰀hant", "sessionId": "/0.0.0.0:00000/00000000", "clientIp": ”0.0.0.0, 0.0.0.0", "market": "unknown", "code": "resource", "publishTime": 1661792531013, "logId": " *********-****-****-****-************"},
{"appId": “444332", "playerId": "**********", "amount": 79313461, "character1Id": "**********", "character1Lv": 59, "character1Nm": "**********", "country": "KR", "delta": 200, "gameWorld": "world2", "modTime": 1661620241000, "modType": "add", "os": "Windows", "paid": "u", "playerLv": 66, "rCurrency": "Gold", "reason": "A_PLAY", "resourceAttr3": "10", "subReason": "Field", "lang": "ko", "sessionId": "/ 0.0.0.0:00000/00000000 ", "clientIp": " 0.0.0.0, 0.0.0.0 ", "market": "unknown", "code": "resource", "publishTime": 1661620236663, "logId": "*********-****-****-****-************"}

다음은 에어플로우에서 배치작업이 수행되어 EMR의 Spark 엔진을 통해 작업이 수행되는 과정이다. 에어플로우 DAG에 구성된 대부분의 workflow는 다음과 같은 구조로 구성되어 있다. 먼저 날짜 변수를 사용하기 위해 작업 처리시간을 입력받고, 두번째로는 spark 실행을 위한 task 그룹을 생성하여 1개의 마스터노드와 10개의 코어노드로 구성이 되어 있는 EMR에 spark submit을 실시한다. 세번째로는 집계작업이 완료되면 리포트 및 대시보드에 사용되는 큐브를 갱신하는 과정으로 대부분의 워크플로우가 흘러간다. 이러한 DAG는 약 90여종이되며 테이블은 약 500개 정도 운영이 되고 있다.

다음은 EMR spark에서 데이터가 처리되어 데이터가 집계되는 모습이다. 로그버킷으로부터 수집된 키벨류 json 형태의 로그데이터가 테이블 형태로 파싱이되고 외부에서 수집한 별도의 유저 디비 데이터나 각종 마스터 테이블과 join이 되어 1차적으로 아래에 왼쪽과 같은 테이블이 생성이 된다. 이렇게 생성된 테이블이 동일한 처리과정을 다시한번 거치며 칵 컬럼별로 group by 집계가 되어 아래에 우측 테이블과 같이 요약된 서머리 테이블이 생성이 된다.

다음은 최종적으로 집계된 데이터가 대시보드나 리포트 형태로 시각화 되는 단계이다.

아래에 좌측의 표는 앞서 봤던 최종적으로 축약되는 서머리 테이블인데 게임내 로그분류 즉 코드가 리소스인 경우를 아주 간단한 예시로 보여줬지만 item, action, round 등 다양한 로그에 대해서도 집계 데이터가 생성이 되어 S3에 저장이 된다. 이렇게 저장된 데이터가 마트용 혹은 분석용으로 사용되는 redshift라는 디비의 테이블로 직접 적재가 되어 시각화 되거나 아니면 redshift에서 s3로 저장된 데이터를 바로 읽을수 있는 spectrum 을 사용하여 해당 데이터를 대시보드에서 확인이 가능하다.

그러면 수집한 데이터는 어떻게 활용할까

데이터 처리과정을 거친 집계 데이터를 피시나 모바일을 통해 언제 어디서든지 데이터의 추이를 실시간으로 혹은 시간, 일, 주, 월 단위로 살펴볼수 있다. 주로 매출이나 이용자와 같은 표준 항목들은 물론이고, 히스토리성인 로그를 집계한 지표, 그리고 재화나 아이템, 캐릭터 등에 보유량이나 유저들의 최종상태를 집계한 종류의 지표들도 확인할 수 있다. 뿐만아니라 인프라 비용현황, 광고현황, 사전예약 등 게임지표외에 다양한 현황들을 확인할 수 있다.

좀더 정확한 데이터 검증이 필요하거나 데이터 추출이 필요한 경우에 아테나를 통해 사용자가 데이터가 필요할때 즉시 쿼리를 수행하여 데이터를 분석할 수 있다. BI팀이나 사업팀 또는 마케팅 팀에서도 이벤트 타게팅이나 이벤트 대상자를 추출하는 하는 분석작업을 직접 수행하거나 특정 이벤트 이후에 게임 내에 플레이에 대한 추이를 직접 추출할 수 있다.

다음으로는 게임 오픈이나 업데이트와 같이 중요 이벤트 이후 관련된 디테일한 리포트도 제공한다. NRU, DAU, PU 등 이용자와 관련된 항목들에 각각 성별, 나이별, 플랫폼별 혹은 다른 게임사례와 비교 하는 등의 다양한 항목을 활용하여 insight를 제공하고 의사결정 방향에 도움을 준다. 뿐만 아니라 모델을 통해 확인한 모델의 이용자 추이, 혹은 매출에 대한 예측값을 제공하고 게임상에서 이루어지는 비정상적인 행위에 대해 파악하여 대응할 수 있도록 도와준다.

다음은 실시간 데이터를 이용한 어뷰징 탐지이다. 아래에 아키텍처는 실시간 대시보드에 구성된 아키텍처와 동일한 환경이다. 이렇게 리얼타임 데이터를 실시간을 활용하여 정상범위를 벗어나는 이상 탐지로도 시스템을 구축해두었다.

카카오 게임즈에서 사용하는 실시간 이상탐지는 크게 두가지로 나뉘어진다.

첫번째로는 룰베이스의 이상탐지이다. 정상범위를 룰로 정의하고 이 정상범위를 벗어나는 행위를 하는 유저를 탐지하게 된다. 주로 이상탐지 대시보드에서 어뷰징을 파악하고 이상현상이 발생할 경우 아지트나 카카오톡으로 알람을 보내고 정확한 확인을 위해 데이터를 조회하기도 한다. 또한 정해진 스케쥴링에 의해서 유저들이 보호조치가 되거나 보호 해제조치가 이루어지게 된다.

다음은 데이터나 알고리즘, 머신러닝 모델을 이용한 이상탐지의 케이스이다. 유저의 행동을 백터화하여 재화 획득의 패턴을 분석하는 이상탐지 모니터링과 보스 사냥시 이상행동을 파악하여 작업장을 파악하는 보스 메크로 탐지, 거래소의 거래별 가치 패턴을 트래킹하여 이상현상을 탐지하는 거래소 모니터링 등 모델을 이용해서 이상탐지를 하고 있는 부분도 있다.

이외에도 데이터 분석적인 측면에서 게임마다 유저들의 유입경로별 가입일자에 따른 LTV(Life Time Value)를 예측하여 앞으로의 수익을 예측하거나 유저의 플레이 동향에 따른 이탈예측 분석, 또는 게임 오픈전에 진행되는 경로별 광고에 대한 효율분석에도 활용이 되고 있다.

카카오 게임즈 로그 데이터 파이프라인의 향후 발전 방향

데이터 관리 인프라가 데이터 환경으로 구성되어 있어서 데이터를 필요로 하는 누구나 데이터 접근이 용이해졌지만 데이터를 처음 접하는 사람들은 데이터의 매타정보 등을 확인하기는 어려운 상황이다. 이와 같은 문제로 데이터의 활용성을 높이기 위해 데이터 허브 및 리엑트 기반의 자체적인 데이터 디스커버리 플랫폼인 코스모스를 개발하고 있다.

다음으로는 큐레이팅 서비스와 비슷한 추천 시스템이다. 이미 OTT와 음원서비스와 같은 구독형 서비스에서 많이 제공하고 있는데 카카오 게임즈도 게임과 관련된 많은 데이터를 수집하고 있기 때문에 개인별 추천과 같은 서비스를 제공할 수 있다고 판단했다. 유저그룹별로 어떤 구간에서 어떤 상품에서 매력을 느끼는지, 혹은 게임에 흥미를 잃지 않도록 적절하 난이도를 조절해주며 때에 따라서는 미션을 클리어 할수 있는 맞춤형 가이들 제공하는 등에 유저별 추천시스템을 개발하고 있다.