Amazon GameLift와 DynamoDB를 중심으로 서버리스 서비스를 활용한 멀티플레이 게임 개발/최적화 사례

라온엔터테인먼트(http://www.rhaon.co.kr/)는 1998년에 설립되어, 2005년 테일즈 런너를 국내 정식 서비스를 시작했으며, 2014년 전설의 도둑왕 ,2017년 테런R 국내출시를 비롯하여 2020년 캐쥬얼 게임인 고스트워 캐주얼 배틀아레나 를 출시한 중견기업입니다.
특히 고스트워는 실시간 모바일 멀티플레이 캐주얼 전략 모바일 게임으로 앱다운로드 횟수 200만이상, 일별 최대접속자 20만이상, 월 최대접속자 79만으로, 2020년부터 현재까지도 서비스 중인 인기 게임입니다.

라온엔터테인먼트의 고스트워 게임 아키텍쳐는 서버리스로 구성되어 운영 및 비용 효율을 극대화하였습니다.
서버리스의 장점은 적은 인원으로 효율인 개발과 운영이 가능하다는 것입니다. 예측하지 못한 트래픽에 대하여 성능과 가용성을 빠르고 충분히 확보할수 있고, 운영업무의 오버헤드가 적으며, 사용한만큼 비용을 지불하므로 운영과 비용 두가지 측면의 리소스를 최적화할수 있습니다. 라온엔터테인먼트는 적은 인원으로 이러한 장점을 충분히 살려서 고스트워를 지금까지 안정적으로 잘 운영해왔습니다. 특히 방학등 사용자가 급격히 몰리는 시즌에도 고스트워는 큰 문제없이 서비스하면서 4년이 넘는 기간동안 롱런한 게임으로 자리잡았습니다. 고스트워의 가장 큰 특징은 대전형 게임의 매치메이킹 서비스를 Amazon GameLift 를 사용해서 구현하고, Amazon DynamoDB 를 이용해서 모든 데이터를 저장하고 있다는 것입니다.

고스트워의 서버리스 아키텍쳐의 핵심 서비스 : DynamoDB와 GameLift

고스트워의 모든 서비스는 서버리스 및 매니지드 서비스로 구성되어있습니다. 고스트워를 개발하고 운영하는 초기부터 크게 두가지 어려움이 있었습니다. 첫번째는 게임 개발부터 운영까지 소규모의 인원으로 모든작업을 진행해야 했습니다. 두번째는 예측하기 어려운 트래픽에서 안정적인 서비스를 지원하는 것입니다. 그런면에서 람다와 다이나모디비와 같은 AWS의 서버리스 서비스와 게임리프트가 큰 도움이 되었습니다.

대전형 게임에서 가장 중요한 게임 유저들의 매칭메이킹 서비스와 게임서버는 GameLift를 사용합니다. 그리고 게임유저 정보등 데이터를 저장하는 메인 데이터베이스는 DynamoDB를 사용합니다. 두 개의 핵심서비스를 이어주는 Amazon SQS서비스와 AWS Lambda를 이용하여 게임로직을 구현하고 있습니다.

유저의 랭킹정보를 저장하기 위해서는 Amazon Elasticache Redis를 사용하고 있으며, 게임 로그를 저장하고 분석하기 위하여 DynamoDB Streams와 Amazon Kinesis Data Firehose를 이용하여 게임 로그를 Amazon S3에 저장하며 AWS Glue로 메타데이터를 분석하고 Amazon Athena로 데이터를 분석합니다.
이 블로그에서는 고스트워의 가장 핵심서비스인 DynamoDB와 GameLift를 중심으로 게임운영 사례를 소개하고자 합니다.

DynamoDB를 메인DB로 선택하게 된 이유

• 게임 개발 당시 인력부족으로 데이터베이스의 관리의 어려움
  • 개발 당시 서버인력이 부족하여 직접 MySQL등의 Database를 설치하고 운영하기에는 큰 부담이 되었으나, DynamoDB는 간단하게 콘솔로 테이블만 생성하면 바로 데이터를 저장하고 읽을수 있고, DB를 운영하기 위한 업무가 필요없는 서버리스 서비스입니다. 보안패치, 업그레이드와 같은 업무도 내부에서 자동으로 처리되고 모든 사용자 데이터는 암호화되어 처리됩니다. 보통 Database를 관리하기 위해 여러가지 운영업무가 필요한데, 이와 같은 부분들을 처리하지 않고도 안전하게 데이터를 보관할수 있다는 점도 DynamoDB를 선택하게된 이유중의 하나였습니다.
• NoSQL 데이터베이스에 대한 장점
  • NoSQL의 장점인 Schemaless한 유연한 구조 또한 개발및 운영에 도움이 되었습니다. 게임특성상, 자주 바뀌는 스키마와 어트리뷰트들을 새롭게 적용하려면 다양한 데이터 타입이 필요했습니다. DynamoDB는 String, Number외에도 여러 다양한 데이터 타입을 지원하기때문에, 테이블에 컬럼이 추가되거나 변경되는 경우에도 기존의 소스코드를 많이 수정하지 않고 추가적인 개발및 유지보수를 쉽게 할 수 있다는 장점으로 선택하게 되었습니다. DynamoDB Table의 데이터 타입에 대한 문서는 오른쪽의 링크를 클릭해서 확인해보시면 됩니다. (링크)
• 예측하기 어려운 트래픽에 대한 안정성
  • • DynamoDB를 선택하게 된 가장 큰 이유는 바로 예측하기 어려운 트래픽에 유연하게 대응할수 있었기 때문입니다. 게임런칭당시나 사용자들이 갑자기 몰리는 이벤트에도, 리플리카를 추가하거나 인스턴스 사이즈를 크게 하는 업무나 페일오버로 인한 다운타임을 걱정하지 않아도 되었습니다.

GameLift를 선택하게 된 이유 및 장점

• 다양한 방식의 매치메이킹 서비스를 쉽게 구축하고 활용할수 있는 점
  • 게임유저들간에 매치메이킹 서비스를 만드는 것은 복잡한 프로세스를 수반하며, 개발하기 위해 많은 공수가 들어가는 반면, GameLift의 MatchMaking 서비스를 이용하면 이러한 게임 개발을 위한 시간과 노력들을 최소화 할 수 있었습니다. 특히 플렉스매치와 큐를 이용하면, 사용자간의 특성, 적절한 레벨과,레이턴시 기반등 다양한 룰을 쉽고 유연하게 바로 적용할수 있습니다. 이를 통해서 게임유저들의 재미를 극대화할수 있었고 이러한 부분이 고스트워를 오랫동안 유지할수 있었던 비결이라고 생각합니다.
• 무중단 서비스 업데이트가 가능한 점
  • 일반적으로 새로운 게임패치를 서버에 업데이트하기위해 서비스를 중단하고 점검시간을 가져야 하는데, GameLift의 Alias기능을 이용하면 미리 준비된 새로운 버전의 게임 빌드 서버로 바로 서비스를 대체할 수 있어서 버전 업데이트에 따른 점검시간을 최소화할 수 있었습니다.
• Autoscaling 기능으로 효율적인 세션 및 서버관리
  • 게임리프트의 관리형 플릿을 이용하면, 게임서버를 직접 운영/관리 하지 않고도 새로운 트래픽을 수용할 수 있는 세션의 비율을 설정하는 것 만으로 자동으로 서버를 늘리고 줄이면서 변화하는 유저의 트래픽에 대응할 수 있었습니다. 결과적으로 두 명의 서버운영 인력만으로 모든 서비스를 관리할 수 있을 정도로 운영업무를 최소화하였습니다.
• Spot instance를 활용한 비용최적화
  • GameLift의 관리형 플릿의 인스턴스를 사용하면, 중단율이 가장 낮은 스팟 인스턴스에 게임 세션을 배치할 수 있습니다. 이를 최대한 활용함으로써 안전한 게임운영과 더불어 게임서버의 비용을 크게 아낄 수 있었습니다. 스팟인스턴스를 이용하면 온디맨드 인스턴스 대비 50%에서 최대 90%까지 비용을 절감할수 있습니다. 스판인스턴스의 비용은 여기(클릭)를 참조하세요.

고스트워를 운영하면서 겪은 어려움과 해결과정 그리고 교훈

DynamoDB를 운영하면서 겪은 어려움

계속되는 컨텐츠 추가에 따른 테이블추가로 관리의 부담 증가

새로운 기능이나 게임 구성요소가 늘어날때마다 새로운 테이블을 추가하여 저장 하였더니, 테이블이 점점 늘어나 관리하기가 어려운 문제가 발생했습니다. 테이블들에 대한 설정을 변경할때, 모든 테이블을 찾아 일일이 변경하는 작업 또한 시간이 많이 소요되지만 쉽지 않은 업무가 되었습니다.

DynamoDB로 스코어 랭킹정보 구현하는데 드는 비용 증가

DynamoDB는 OLTP성 데이터를 빠르게 가져오는데 최적화 되어있다보니, 몇백만건이 되는 모든 게임유저 데이터를 가져와서 정렬하고 순위를 매기거나 일괄 업데이트 하게 되면 많은 비용이 발생할수 밖에 없었습니다.

온디맨드 백업관리로 인한 비용 증가와 데이터 전달의 어려움

데이터 백업을 수작업으로 온디맨드 백업을 진행해야되는데, 테이블 갯수가 많아 데이터를 백업받는 업무도 늘어났으며, 데이터 분석을 위해서도 BI팀이 필요할때마다 전체 테이블을 Export받아서 전달하기 때문에, 늘어난 테이블관리와 더불어 데이터를 추출하는데도 비용도 증가하고, 운영업무도 그만큼 부하가 걸리게 되었습니다.

데이터 증가에 따른 데이터 보관 비용 증가

게임을 런칭하고 안정적으로 운영하면서, 들어오는 매출은 꾸준한 반면, 게임 런칭 후 트래픽과 사용자 수가 점차 안정화되면서 수익은 일정한 반면, DynamoDB의 데이터를 보관하는데 드는 비용은 데이터가 계속 증가함에 따라 증가하기 시작했습니다. 그렇다고 해도 이미 적재된 데이터를 삭제하는데도 많은 비용이 발생할 수 밖에 없고, 보관해야 될 데이터의 사이즈도 꽤 크기 때문에 비용을 감소할 방법이 필요했습니다.

DynamoDB를 운영이슈에 대한 해결과정

계속되는 컨텐츠 추가에 따른 테이블추가로 관리의 부담 증가

Amazon DynamoDB는 테이블당 읽기/쓰기 용량에 따라 비용이 과금됩니다. 이로 인해 다수의 테이블로 관리를 할 경우 각 테이블별로 용량 관리를 해야하기 때문에 관리의 부담이 있었지만 하나의 테이블로 관리하면 프로비저닝 용량 파악이 쉽고, 비용 절감 효과가 있었습니다. 뿐만아니라 테이블 간의 조인 연산을 할 필요가 없어지고, 여러 엔터티 타입의 데이터를 하나의 요청으로 검색할 수 있어서 성능 향상도 기대해볼 수 있습니다.

따라서, 새로 추가되는 게임 기능과 데이터들을 분석하여, 기존 테이블의 구조와 유사한 경우 기존테이블에 합치며, 가능한 하나의 테이블 안에 여러개의 엔터티를 담으려고 키 디자인을 변경하였습니다. 기존의 테이블도 분석하여 추후에 마이그레이션을 할 예정입니다. 다만 기존에는 컨텐츠별로 테이블이 분리되어 있었기 떄문에 테이블 단위로 비용 비교를 했다면 하나의 테이블을 사용할 때는 컨텐츠별로 비용 비교를 해보기 위해서는 레코드 단위로 계산해야했습니다. 컨텐츠별로 비용을 확인하는것은, 별도의 로그분석을 수행하여 해결하였습니다.

원테이블 디자인 전략으로 테이블을 운영하면서 개별 테이블 별로 프로비져닝 관리를 하다 보니 관리의 부담도 많고 낭비되는 프로비저닝 용량이 있어지만 하나의 테이블에서 프로비저닝 용량이 공유되면서 프로비져닝 용량 파악이 쉽고 낭비가 적게 되었다는 부가적인 장점도 있습니다. 다만 작은 단점이라면 컨텐츠별 비용계산이 테이블단위가 아니라 레코드 단위로 바뀌고 나서 컨텐츠 별로 비용을 확인하기 위해서는 별도의 로그 분석을 수행해야 합니다. 불편한 부분도 있습니다.

DynamoDB로 스코어 랭킹정보 구현하는데 드는 비용 증가 및 데이터 분석을 위한 전달과정 개선

DynamoDB Stream을 이용해서 ElastiCache for Redis에 스코어 정보 업데이트 후 정렬하여 서비스하였습니다. DynamoDB Stream은 DynamoDB에서 일어나는 추가/업데이트/삭제와 같은 모든 데이터 변경작업을 스트림형태로 전달하는 기능입니다. 이 부분을 람다를 이용하여 Elasticache for Redis에 업데이트 하여 실시간 랭킹정보를 구현할수 있었습니다.

BI팀을 위한 데이터 분석에도 DynamoDB Streams를 통해 S3에 저장한 데이터를 전달하여 Amazon Athena로 데이터를 분석하도록 변경하였습니다. BI팀은 게임의 사용자피드백등 중요한 사용자 트렌드를 분석하여 게임서비스에 반영하는것을 지원합니다. 그전에는 BI팀에서 요구할때마다 DynamoDB 테이블 데이터를 온디맨드 백업을 해서 전달했고, 잦은 데이터 요청은, 작지만 운영업무에 부담을 주었으며, 비용이 증가하는 원인도 되었습니다.

그러나 DynamoDB Stream을 이용하면서, 데이터는 S3에 쌓이도록 변경하였고, BI관계자는 필요할때 아테나를 통해서 원하는 데이터를 언제든지 뽑을수 있게 되어, 운영업무가 많이 줄어들었습니다. S3 데이터를 조회할때도 년/월/일 시간으로 자동으로 파티셔닝을 지정하여 필요한 데이터만 조회할수 있도록 하여 아테나를 조회할때 드는 비용도 절감할수 있었습니다.

온디맨드 백업관리로 인한 업무와 비용 증가: 백업정책의 변경

그전까지는 특정시점에 해당하는 주기적인 데이터 백업을 매번 수작업으로 진행했습니다. 이것도 부담을 주는 정기적인 운영업무였으나, PITR(Point In Time Recovery)로 간단하게 백업/복구관리를 하게 되었고, 불필요한 온디맨드 백업을 줄여 비용도 절약할수 있었습니다.

데이터 증가에 따른 데이터 보관 비용 증가 에 대한 개선안

오래된 로그와 같이 불필요한 데이터는 DynamoDB Streams를 이용해서 S3에 저장하고, DynamoDB TTL(Time To Live) 기능을 이용해서, 추가비용을 들이지않고 데이터를 자동으로 삭제하도록 처리하였습니다. 데이터 스토리지 또한 Standard-IA 테이블 클래스로 변경함으로써, 오래된 데이터에 대한 저장비용을 추가로 아낄수 있었습니다.

GameLift를 운영하면서 겪은 어려움

고스트워는 세션기반의 대전게임으로 사용자간 매칭을 통해 게임플레이를 합니다. 게임 유저간 매치메이킹이 보통 원활하게 잘 진행되다가, 일주일에 한번 꼴로 특정 시간 동안 매칭오류가 발생하지만, 왜 이런지 이유를 알수가 없어서 게임 서비스 운영에 어려움을 겪었습니다.

GameLift 운영이슈에 대한 해결과정

모니터링을 통한 이슈 감지와 원인 파악

GameLift 콘솔대시보드에서 제공하는 지표들을 통해서 특정 인스턴스 타입의 스팟 인스턴스가 가용량이 없을 때 이슈가 발생하는 것을 알게 되었습니다. Gamelift 콘솔에서 참고할 지표들을 여기(클릭)을 참고하세요. 또한 게임리프트 샘플(클릭)에 있는 샘플을 이용한 대시보드를 구축하면 중요한 지표들을 편리하게 모니터링할수 있습니다.

아래 그림은 스팟인스턴스로 1개의 타입만 사용하고, 스팟인스턴스의 가용량이 없는 경우에 현재 운영되는 서버가 없는 상황을 보여주는 그래프 입니다.

GameLift Best Practice 적용

여러 인스턴스타입의 스팟 인스턴스를 활용하여 가용량에 없을 때의 위험을 분산하고, 백업으로 온디맨드 인스턴스를 설정하여 스팟 인스턴스의 가용량이 없는 경우에도 온디맨드 인스턴스를 통해 게임 진행에 문제가 없도록 하였습니다.

GameLift 대기열의 효율성과 안정성을 높이기 위해 다음과 같이 다양한 인스턴스 유형을 전략적으로 구성했습니다. c5.xlarge, c5.2xlarge, c6i 타입 등 여러 스팟 인스턴스를 대기열에 포함시켜 비용 효율성을 극대화했습니다. 동시에 온디맨드 인스턴스도 대기열에 추가하되, 우선순위를 가장 낮게 설정했습니다.

이러한 구성을 통해 정상적인 상황에서는 비용 효율적인 스팟 인스턴스를 주로 활용하면서도, 모든 스팟 인스턴스가 사용 불가능한 상황을 대비하여 온디맨드가 실행될 수 있도록 구성함으로써 비용 효율성과 운영 안정성을 확보할 수 있었고, 결과적으로 매치메이킹이 중단 없이 원활하게 이루어질 수 있도록 보장할 수 있게 되었습니다.

위와 같은 해결책을 통해서 스팟인스턴스 단일 타입,단일 사이즈를 사용할때와 달리 항상 매치메이킹이 원활하게 이뤄지는것을 확인할수 있었습니다. 아래 그림을 보면 첫번째 그래프의 스팟인스턴스가 가용량이 없는 구간을 두번째 그래프인 온디맨드 인스턴스가 메워주고 있는 것을 볼수 있습니다.

DynamoDB와 Gamelift 서비스를 운영하면서 얻은 교훈

아래그림은 2022년과 2023년의 고스트워 운영 비용을 나타냅니다.

왼쪽 그림의 전체운영 비용을 보면 2022년 오른쪽 기준으로 볼때, 68%에서 2023년에는 38%로 크게 줄은 반면, 고스트워의 유저비율은 2022년 80%에서 2023년 56%로 줄어들어, 비용감소가 단순히 유저의 감소때문에 발생한 것이 아니라, 아키텍쳐를 개선하면서 비용 최적화가 일어난것을 확인할수 있습니다. (각 그림 왼쪽의 100%는 2022년의 1월 당시의 비용과 유저갯수를 기준으로 비교하기 위해 설정한 기준입니다)

이는 서버리스 라는 서비스의 특성으로, 사용한 만큼만 비용을 지불하여 필요할때만 유연하게 사용했기때문이며, DynamoDB 설계변경을 통한 최적화와 오래된 데이터에 대한 TTL 정책을 적용등 불필요한 리소스에 대한 적극적인 최적화로 인한 것이었습니다.

DynamoDB와 GameLift를 운영해보며 느낀 교훈을 정리하면 아래와 같습니다.

• DynamoDB
  • 키디자인을 변경하는 것만으로도 업무와 비용에서 많은 최적화를 이룰수 있음을 알수 있었습니다. DynamoDB에 있어서는 그래서 키디자인이 가장 중요합니다. 키디자인을 최적화하면, 비용/성능/관리 또한 최적화 될수 있습니다. 그러나 키디자인 최적화 가이드로서, 원테이블 디자인을 제안 드리면, 기존의 RDBMS의 정규화 설계에 익숙한 대부분의 고객분들께서는 어렵게 느껴지시는 경우가 많습니다. 원테이블 설계를 포함하여 다양한 키디자인 방법들이 있습니다. 자세한 내용은 문서(클릭)를 참조해주세요.
  • 또한 DynamoDB의 기능안에서 모든것을 해결하기보다, DynamoDB Streams를 이용해서 다른 서비스로 데이터를 전달하여 데이터 정렬및 데이터 분석등의 다양한 기능들을 쉽게 구현할수 있었습니다.
  • DynamoDB의 PITR 백업 기능과 TTL과 같은 기능들을 잘 사용하여 불필요한 비용을 절감하고, 업무또한 효율화 할수 있었습니다.
• GameLift
  • GameLift의 대시보드에서 보여지는 지표 그래프 및 로그 분석을 통해 그동안 풀기 어려웠던 문제의 원인을 쉽게 파악할수 있었습니다.
  • Spot instance를 최대한 활용하여 게임서버의 운영비용을 아낌과 동시에 Spot instance를 사용하면서 발생할수 있는 Spot interruption을 줄이기 위하여 Gamelift Queue를 이용하고 Spot interruption을 최소화할 수 있는 GameLift 자체 알고리즘을 통해 다양한 스팟 인스턴스 타입을 게임서버에 활용함으로써 보다 쾌적한 게임서비스를 제공하여 게임유저의 만족도를 높이는데 도움을 받을수 있었습니다.

마치며

이번 블로그에서는 서버리스를 최대한 활용하여, 게임을 쉽게 개발하고 운영하는 라온엔터테인먼트의 사례를 살펴보았습니다.
서버리스는 개발및 운영 그리고 비용을 최적화 해줄수 있는 한편으로는 생각지 못한 관리의 어려움도 있었습니다.

게임리프트를 사용하시는 고객분들도 비용에 대한 고민을 하시는 경우도 있는데, 스팟인스턴스의 적극활용외에도, Linux게임서버,
Graviton인스턴스들을 사용하시면 많은 비용절감 효과를 얻으실수 있습니다.

오늘 소개드린 라온엔터테인먼트와 같이 비슷한 고민들을 하시고 계신다면, 저희에게 적극적으로 문의를 주시기 바랍니다.
서버리스의 취지에 맞게 개발/운영/비용의 최적화를 통해서 보다 나은 게임서비스를 구축하실수 있도록 도움을 드릴수 있습니다.
aws-game-korea@amazon.com
감사합니다.