AWS에서 실시간 멀티플레이어 게임 구현하기

넥슨코리아 로켓쉽스튜디오 기술지원팀 박준규

NexG (2009 - 2012)

StyleShare (2012)

넥슨코리아 (2012 -) KartRider Dash 라이브

KartRider Coin Rush 개발 참여

현재 모바일 게임 서버 기술지원 업무 중

박준규

http://about.me/segfault

KartRider Dash

Facebook 친구들과 카트라이더를! 2012년 5월 런칭 월드와이드 서비스 Facebook 캔버스 앱 https://apps.facebook.com/kartriderdash

KartRider Dash

왜 AWS를?

왜 AWS를?

데이터 어플리케이션

운영체제 런타임

네트워크 하드웨어

스토리지 가상화

왜 AWS를?

데이터 어플리케이션

운영체제 런타임

네트워크 하드웨어

스토리지 가상화

우리

가 신

경 쓸

필요

없음

IaaS (Infrastructure as a Service)의 가장 큰 미덕!

왜 AWS를?

월드와이드 서비스

전세계에 걸쳐있는 아마존의 인프라는 월드와이드 서비스에 최적!

적은 초기비용

장비 구입 비용 “0”

사용한 만큼만 내면 된다

왜 AWS를?

확장에 매우 용이

가상화의 가장 큰 장점

On-demand

수요에 유연한 대응이 가능

Automatic scaling 구성도 가능함!

이 경우에는 Scaling 전략을 잘 세워야…

왜 AWS를?

쉬운 관리

웹 콘솔로 모든 작업이 가능 API를 통한 관리작업 자동화 소규모 팀일수록 큰 장점!

안정성

여러 개의 Availability zone 스토리지 가상화 (EBS; Elastic Block Store)

서버의 구현 목표

서버의 구현 목표

클라우드에 최적화된 구조

수평 확장 (Scale-out)이 가장 중요!

낮은 성능의 인스턴스 여러 개로 서비스가 가능

서버 확장에 따라 linear한 가용성 증가

어떤 노드에 문제가 생겨도 서비스에는 지장이 없도록!

실시간 멀티플레이 게임으로서의 반응성 확보

서버 아키텍쳐

서버 아키텍쳐

Ubuntu Linux 기반 서버 코드는 Python으로 작성 us-east-1 비대칭적 (asymmetric)

서버들은 서로 다른 역할이 있음

E.g., 웹 서버, 메인 서버, 패킷 릴레이 서버, …

각 서버들은 수평 확장 가능

싱글 스레드, 멀티 프로세스

gevent 기반 서버에서 행하는 대부분의 작업은 I/O-bound CPU-bound 작업을 위한 별도의 독립된 worker가 있음

서버 아키텍쳐

서버/워커간 통신 (RPC)

역할이 나뉘어져 있으니만큼 서버들은 상호의존적

Redis의 Publish/Subscribe 기능을 활용

Fan-out, Round robin 방식

서버 확장/축소가 매우 쉽다.

서버 클러스터에 등록만 되면 정상적인 요청 처리가 가능한 구조

서버 아키텍쳐

Elastic Load Balancer (ELB)

(말 그대로) 로드 밸런서

사용하기가 매우 쉽다!

노드에 장애 발생시 자동으로 exclude

서버 아키텍쳐

메인 DB로는 Couchbase 사용

Document-oriented DBMS (NoSQL)

수평 확장에 최적화된 구조

서비스 중에도 노드 추가/삭제가 가능하다!

다만 Querying에는 취약

2.0에 들어서야 View 기능 추가

대쉬에서는 Moxi에 ELB를 붙여서 운용

KartRider Coin Rush

KartRider Coin Rush

KartRider Coin Rush

카카오톡 플랫폼 모바일 게임

2012년 11월 런칭

서버 코드와 인프라는 KartRider Dash 기반으로 제작

비교적 짧은 개발기간

KartRider Coin Rush

VPC (Virtual Private Cloud)

코인러쉬에서는 VPC를 사용

보안성 강화

서브넷별로 다른 접근 제어가 가능

더욱 철저한 access control이 가능

VPN을 통해 내부 네트워크에 접근

KartRider Coin Rush

코인러쉬는 국내 시장을 대상으로 한 게임

Region을 ap-northeast-1 (도쿄)로 설정

도쿄 지역의 핑은 만족스러움.

모바일 플랫폼에 맞춰 서버 튜닝이 필요

3G, LTE 환경은 안정적인 RTT가 나오기 어렵다.

게임패킷 송신은 UDP, 수신은 TCP로

너무 많은 패킷은 휴대폰 배터리 사용량에도 영향을 미침

초당 전송되는 게임패킷 수 조정

도전

도전

멀티플레이 게임으로서의 빠른 반응성 확보

AWS 인프라와 구현된 서버 로직을 통해 충분히 확보!

관리 작업의 많은 부분을 자동화

AWS API 짱짱

수평 확장이 무엇보다도 중요

서버 로직은 물론 DB까지도 철저히 수평 확장을 고려

서버들의 RPC 허브 역할을 하는 Redis가 잠재적인 SPoF (Single Point of Failure)가 될 수도 있다는 점은 아쉬움

AWS 활용 사례

AWS 활용 사례

EC2 가상화 서버

VPC 가상화 사설 서버 (Coin Rush)

S3 정적 컨텐츠 서빙

CloudFront CDN (S3과 연동)

R53 도메인 네임 관리

서버 확장

미리 만들어진 AMI 런칭

R53 도메인 등록

서버 코드 체크아웃

설정 파일 편집

서버 이름

어떤 유형의 서버/워커를 구동할 것인지

10~15분 만에 가능!

서버 장애 처리

어플리케이션 서버의 경우 장애가 발생한 인스턴스 Terminate 처리 같은 유형의 인스턴스 하나 더 런칭

데이터베이스 서버의 경우 Couchbase에서 Automatic Failover 기능을 지원

따라서 장애가 난 인스턴스는 그냥 버려도 무방

같은 종류의 Couchbase instance 런칭 관리 콘솔에서 새로 띄운 인스턴스를 클러스터에 추가 Rebalance

배치 (deployment)

서버 코드에 Deployment 로직이 내장

Mercurial 사용

AWS API 사용

S3에 변경된 리소스 업로드와 CloudFront invalidation이 자동화

명령 두줄로 모든 과정이 완료!

사실상 업데이트시 “점검” 불필요

백업

EBS snapshot 기능

API를 통해 프로그램적으로 가능

다만, 스냅샷 작업이 원자적이진 않음

Consistency가 보장된 백업을 위해서는 별도의 백업 로직에 대한 고려가 필요!

결론

결론

빠른 개발과 쾌적한 운영이 가능

SE, NE를 통해 작업해야 하는 상황에서 발생하는 커뮤니케이션 코스트가 거의 발생하지 않음

KartRider Coin Rush의 빠른 런칭에 AWS가 많은 도움이 되었음!

수요에 따라 빠르고 유연한 대처가 가능

비용 절감 효과

좋아요!

Q&A

감사합니다!

박준규

segfault@nexon.co.kr

010-4031-2264