Hive 애널리틱스는 게임을 플레이하면서 발생하는 대용량 로그를 수집하여 분석하고 활용할 수 있는 여러 기능을 제공하고 있습니다.
그런데, 분석 결과를 활용하는 시점에는 이미 유저의 행동이 완료된 상태이고, 때로는 이미 이탈하여 게임을 삭제 한 이후일 수도 있습니다. 이러한 한계점을 극복하기 위해 “유저의 행동을 미리 예측하고 제공하자”라는 미션을 세우고, 머신러닝 기술과 대용량 로그를 기반으로 유저의 이탈 가능성을 예측하는 서비스를 제공하기로 하였습니다. Google Cloud의 Professional Services를 통해 머신러닝 모델을 서비스로 유지하기 위한 MLOps의 개념과 파이프라인, 아키텍처를 제안받았고, 이를 기반으로 Hive 애널리틱스 유저 이탈 예측 프로젝트를 성공적으로 마칠 수 있었습니다.
모델 소개
우리가 예측하려는 것은 특정 게임에서 유저가 이탈할지, 잔존할지를 맞추는 것으로 지도 학습에서도 분류(classification) 모델이 필요했습니다. 분류 알고리즘에도 KNN, 로지스틱 회귀분석, 의사결정 나무 등 여러 기법이 있지만 커스텀한 머신러닝 모델을 만들기 보다 Google Cloud Platform에서 제공하는 머신러닝 서비스 Google Cloud AutoML을 검토했습니다. Google Cloud AutoML은 최소한의 리소스와 머신러닝 지식만으로 간편하게 커스텀 머신러닝 모델을 생성할 수 있으며 Hive 애널리틱스의 대부분의 데이터가 Google의 BigQuery에 저장되어 있기에 정형 데이터를 바탕으로 예측 모델을 생성해주는 Google Cloud AutoML Tables를 사용하기로 결정하였습니다.
1. 이탈 정의
모델을 생성하기 앞서 이탈 유저를 정의해야 합니다. 이에 따라 피쳐와 목표 성능이 달라지고 나아가 모델을 사용함으로써 기대되는 이익도 달라지기 때문입니다. 또한 머신러닝 기술은 100%의 확률로 예측하는 것이 불가능하고, 예측률만 높이는 것은 끝이 없기 때문에, 머신러닝을 활용해 달성해야 할 궁극적인 비즈니스 목표를 명확하게 설정할 필요가 있었습니다. 이에 저희는 사업부와의 많은 커뮤니케이션을 통해 이탈 유저를 정의하였고, 이탈 예측 모델 개발을 목표로 KPI를 산정하였습니다.
모델 성능을 향상시키는 가장 좋은 방법은 신규 피처를 추가하여 모델 학습에 사용할 새로운 데이터를 제공하는 것 입니다. 이탈 유저와 잔존 유저에 관한 여러 가설을 세운 후 EDA(Exploratory Data Analysis, 탐색적 데이터 분석)를 진행했고, 유의미한 변수는 모델에 추가하는 작업을 계속적으로 반복 실행하였습니다.
균형이 맞지 않는 클래스 주의
분류 예측에서 자주 겪는 문제로 이탈 유저와 잔존 유저의 비율이 1:1이 아닌 편향된 분포를 가지고 있었습니다. 언더샘플링과 오버샘플링 기법을 활용해 데이터의 비율을 동등하게 맞춰주는 실험과 상대적으로 적은 비율의 이탈유저 데이터가 Train, Validation, Test 세트에 충분히 포함될 수 있도록 수동 분할하는 실험을 진행 후 성능 향상을 검증했습니다.
Train: 모델을 학습하는데 사용하는 데이터 세트
Validation: 학습된 모델이 좋은 성능을 갖도록 검증하는 데이터 세트
Test: 생성된 모델이 얼마나 좋은 성능을 갖는지 평가하기 위한 데이터 세트
3. 모델 생성
AutoML Tables에서 데이터 세트를 가져오면 타겟 열(라벨. 예측할 데이터)을 지정할 수 있고, 각 변수의 고유값, 상관관계, 분포 등을 간단하게 볼 수 있습니다. 모델을 생성하기 전 누락이 있는지 확인 가능하고 상관관계가 비정상적으로 높은 경우 타겟 값을 누출해 오버피팅된 모델을 만드는지 미리 확인 할 수 있다는 점이 좋았습니다.
참고: 타겟 누출(Target Leakage)이란 실제 예측시에는 사용할 수 없는 데이터가 학습 데이터에 포함되는 것을 말합니다 이 경우 Validation과 Test 단계에서 높은 성능을 보일지라도 실제 모델이 배포 됐을때 제대로 성능을 내지 못합니다.
추가 매개변수를 설정한 후 모델을 생성하면 AUC PR, AUC ROC, accuracy, precision, recall, f1_score 등 예측 성능을 확인할 수 있고, Confusion Matrix도 제공되어 Test 데이터를 얼마나 잘 예측했는지 확인 할 수 있습니다. 또한 각 변수가 차지하는 특성 중요도를 확인할 수 있습니다.
그림1. Google Cloud 의 AutoML Tables의 모델 평가 화면
4. 예측 모델과 지표와의 상관성 분석
우리는 모델을 생성한 이후 예측 성능을 넘어 이탈 예측 유저수와 Hive 애널리틱스에서 보여주는 지표들과의 상관성도 있을지 궁금했습니다. 예를 들어 9일 뒤 이탈로 예측되는 유저의 비율이 증가 추세일 때, 9-day 리텐션이 감소 추세라면 미리 리텐션의 감소를 인지하고 게임 내에서 액션을 취해 이탈 유저를 방지할 수 있기 때문입니다. 우선 분석에 사용한 모델은 진성 유저를 대상으로 예측 수행일 기준 D+6일부터 연속 3일간 접속하지 않은 유저를 이탈로 정의한 모델을 분석했습니다. 실제 이탈 판별 기간은 3일간이고 리텐션은 하루 접속으로 판별하기에 수치가 정확하게 맞지는 않지만 리텐션과의 상관관계가 있는지를 중점으로 분석했습니다.
그림2. 2달간 추이 비교 – (좌) 예측과 실제 이탈자 비율, (우) 예측 이탈자 비율과 리텐션 D+9
우선 상관관계의 실험을 위해 아래 세 가지 수치를 뽑은 후 시간에 따른 그래프로 그려보았습니다.
파랑선: 모수(진성 유저) 중 이탈로 예측된 유저의 비율
주황선: 모수(진성 유저) 중 D+9일에 실제로 접속하지 않은 유저의 비율
초록선: DAU의 D+9일에 리텐션 비율
좌측 그래프를 보면 예측 이탈자 비율과 실제 이탈자의 비율의 추세가 비슷하며 크게 감소하거나 증가하는 부분도 대체로 일치함을 보입니다. 빨간색으로 표시된 부분은 패턴이 일치하지 않는 경향이 보이는데, 게임 내 신규 패키지가 출시된 기간으로 외부 변수로 인한 예측 패턴이 맞지 않는 것으로 추정됩니다. 이는 게임 내 신규 패키지 출시로 이탈 유저를 방지하는데 효과가 있었다고 해석 할 수 있습니다.
우측 그래프를 보면 진성 유저는 DAU 중 일부로 정확히 반비례는 아니지만 이탈자 비율이 증가하면서 리텐션이 감소하는 추세를 보이고 있습니다.
이번 분석을 통해 이탈 모델을 활용하여 진성 유저의 리텐션을 충분히 예측 가능함을 확인 할 수 있었습니다. 위와 같은 지표를 통해 진성 유저의 추세나 리텐션이 급감하는 시기를 미리 인지하는데 유용할 것이며 우리는 이를 제품화 하였고, 성능을 개선하기 위해 계속적으로 연구하고 있습니다.
ML 파이프라인
ML 파이프라인을 구성하기 위한 두 가지를 소개합니다.
1. MLOps
MLOps는 DevOps 개념에 머신러닝을 적용한 개념입니다. ML 시스템의 개발과 통합, 배포의 모든 과정을 자동화하고 생산성을 향상시키면서 추가적으로 모델의 품질을 유지하고 개선하는 것에 중점을 두고 있습니다.
우리는 머신러닝 기술을 이용한 서비스를 안정적으로 운영하기 위해 MLOps 개념이 필수적임을 인지하여, 이를 이해하고 도입하여 구현하는 것에 많은 노력을 하였습니다.
MLOps 개념 아래, 시스템을 자동화 하였고, 특히 모델의 품질을 유지하기 위해 아래와 같은 정책을 유지하고 있습니다.
모델을 주기적으로 재학습하고, 성능 평가를 자동적으로 수행하여 저하가 발생하는 경우 관리자가 인지
모델의 예측 결과가 얼마나 정확한지 자동적으로 비교하고, 정확도가 일정수준이하로 저하되는 경우 관리자가 인지
학습 데이터의 패턴이 동일하게 유지되도록 자동화
2. Kubeflow
Kubeflow는 Kubernetes 기반 환경에서 머신러닝을 사용하기 위한 오픈소스 프레임워크입니다.
온프레미스 환경이나 클라우드 환경 등 다양한 인프라 환경에서 운영이 가능하고, 전체적인 ML 워크플로우 과정을 시각화로 제공하여 쉽게 관리가 가능하며, Tensorflow 등의 다양한 외부 라이브러리를 연동하여 사용할 수 있습니다.
우리는 Google Cloud 환경에서 웹 UI를 통해 몇 번의 클릭으로 Kubernetes Engine을 생성하고, Kubeflow를 간단하게 설치하였습니다.
Kubernetes Engine은 보안을 위해 Private Cluster 설정으로 구성하여 외부에서 접근이 불가능하게 설정하였고, Google Cloud상에서 Kubeflow API를 호출하거나 웹을 통해 Kubeflow에서 제공하는 대시보드로 접근하였습니다.
그림 3. Google Cloud의 Kubernetes 환경에 설치한 Kubeflow의 대시보드
모델 파이프라인 구성
그림 4. 학습 모델 생성 파이프라인 구성도
1. 파이프라인 개발과 배포
개발자는 로컬환경에서 GitLab과 Jenkins를 통해 코드를 통합하고 배포합니다.
배포된 코드는 Google Cloud 환경에서 Cloud Build를 이용해 Kubeflow에 실행 가능한 형태로 빌드되고, 파이프라인은 Google Kubernetes Engine에 설치된 Kubeflow에서 실행됩니다.
2. 모델의 생성
Hive에서 수집된 대용량 데이터를 추출하고, 예측 모델을 생성하기 위해 전처리와 데이터 검증 과정을 수행하게 됩니다.
다음으로 전처리된 데이터를 이용해 Google Cloud AutoML Tables에서 모델을 생성하고 성능을 평가하고 검증합니다.
각 단계는 Docker 이미지로 빌드된 환경 위에서 개별적으로 수행하고 Kubeflow는 각 단계를 순서대로 연결해주는 역할입니다.
3. 모델의 배포
주기적으로 위 과정을 반복하여 새로운 모델을 생성하게 되고, 이전의 모델 성능과 새로 생성된 모델의 성능을 비교하여 성능 저하가 발생하면 개발자에게 모니터링 알림을 전달하게 됩니다.
만약, 모델의 성능이 유지되거나 개선되었다면 해당 모델은 서비스 버전으로 배포됩니다.
4. 예측 서비스
위 과정을 통해 생성된 서비스 버전의 모델을 이용해 예측을 수행하게 됩니다.
김윤기, 최보희, 김석근, 성지현
머신러닝 기술을 활용하여 예측 모델 생성과 운영, 서비스를 제공하고 있습니다. 머신러닝은 완벽하지 않지만, 기존의 한계성을 한 단계 뛰어넘을 수 있는 기술이라고 생각합니다. 이 글을 통해 좋은 기술을 각 분야에서 안정적으로 적용하고 사용할 수 있는데 참고가 되었으면 좋겠습니다. 감사합니다.
