AWS에서 실시간 멀티플레이 게임 구현하기 - 넥슨 (박준규 선임연구원, 기술지원팀)

1. AWS에서 실시간 멀티플레이어 게임 구현하기
넥슨코리아 로켓쉽스튜디오 기술지원팀
박준규

2. 박준규
http://about.me/segfault
NexG (2009 - 2012)
StyleShare (2012)
넥슨코리아 (2012 -)
KartRider Dash 라이브
KartRider Coin Rush 개발 참여
현재 모바일 게임 서버 기술지원 업무 중

3. KartRider Dash

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

6. 왜 AWS를?

7. 왜 AWS를?
어플리케이션
데이터
운영체제
런타임
네트워크
하드웨어
스토리지
가상화

8. 왜 AWS를?
데이터
운영체제
우리가 신경 쓸 필요 없음
어플리케이션
런타임
네트워크
하드웨어
스토리지
가상화
IaaS (Infrastructure as a Service)의 가장 큰 미덕!

9. 왜 AWS를?
월드와이드 서비스
전세계에 걸쳐있는 아마존의 인프라는 월드와이드 서비스에 최적!
적은 초기비용
장비 구입 비용 “0”
사용한 만큼만 내면 된다

10. 왜 AWS를?
확장에 매우 용이
가상화의 가장 큰 장점
On-demand
수요에 유연한 대응이 가능
Automatic scaling 구성도 가능함!
이 경우에는 Scaling 전략을 잘 세워야…

11. 왜 AWS를?
쉬운 관리
웹 콘솔로 모든 작업이 가능
API를 통한 관리작업 자동화
소규모 팀일수록 큰 장점!
안정성
여러 개의 Availability zone
스토리지 가상화 (EBS; Elastic Block Store)

12. 서버의 구현 목표

13. 서버의 구현 목표
클라우드에 최적화된 구조
수평 확장 (Scale-out)이 가장 중요!
낮은 성능의 인스턴스 여러 개로 서비스가 가능
서버 확장에 따라 linear한 가용성 증가
어떤 노드에 문제가 생겨도 서비스에는 지장이 없도록!
실시간 멀티플레이 게임으로서의 반응성 확보

14. 서버 아키텍쳐

15. 서버 아키텍쳐
Ubuntu Linux 기반
서버 코드는 Python으로 작성
us-east-1
비대칭적 (asymmetric)
서버들은 서로 다른 역할이 있음
E.g., 웹 서버, 메인 서버, 패킷 릴레이 서버, …
각 서버들은 수평 확장 가능
싱글 스레드, 멀티 프로세스
gevent 기반
서버에서 행하는 대부분의 작업은 I/O-bound
CPU-bound 작업을 위한 별도의 독립된 worker가 있음

16. 서버 아키텍쳐
서버/워커간 통신 (RPC)
역할이 나뉘어져 있으니만큼 서버들은 상호의존적
Redis의 Publish/Subscribe 기능을 활용
Fan-out, Round robin 방식
서버 확장/축소가 매우 쉽다.
서버 클러스터에 등록만 되면 정상적인 요청 처리가 가능한 구조

17. 서버 아키텍쳐
Elastic Load Balancer (ELB)
(말 그대로) 로드 밸런서
사용하기가 매우 쉽다!
노드에 장애 발생시 자동으로 exclude

18. 서버 아키텍쳐
메인 DB로는 Couchbase 사용
Document-oriented DBMS (NoSQL)
수평 확장에 최적화된 구조
서비스 중에도 노드 추가/삭제가 가능하다!
다만 Querying에는 취약
2.0에 들어서야 View 기능 추가
대쉬에서는 Moxi에 ELB를 붙여서 운용

19. KartRider Coin Rush

20. KartRider Coin Rush

21. KartRider Coin Rush
카카오톡 플랫폼 모바일 게임
2012년 11월 런칭
서버 코드와 인프라는 KartRider Dash 기반으로 제작
비교적 짧은 개발기간

22. KartRider Coin Rush
VPC (Virtual Private Cloud)
코인러쉬에서는 VPC를 사용
보안성 강화
서브넷별로 다른 접근 제어가 가능
더욱 철저한 access control이 가능
VPN을 통해 내부 네트워크에 접근

23. KartRider Coin Rush
코인러쉬는 국내 시장을 대상으로 한 게임
Region을 ap-northeast-1 (도쿄)로 설정
도쿄 지역의 핑은 만족스러움.
모바일 플랫폼에 맞춰 서버 튜닝이 필요
3G, LTE 환경은 안정적인 RTT가 나오기 어렵다.
게임패킷 송신은 UDP, 수신은 TCP로
너무 많은 패킷은 휴대폰 배터리 사용량에도 영향을 미침
초당 전송되는 게임패킷 수 조정

24. 도전

25. 도전
멀티플레이 게임으로서의 빠른 반응성 확보
AWS 인프라와 구현된 서버 로직을 통해 충분히 확보!
관리 작업의 많은 부분을 자동화
AWS API 짱짱
수평 확장이 무엇보다도 중요
서버 로직은 물론 DB까지도 철저히 수평 확장을 고려
서버들의 RPC 허브 역할을 하는 Redis가 잠재적인 SPoF (Single
Point of Failure)가 될 수도 있다는 점은 아쉬움

26. AWS 활용 사례

27. AWS 활용 사례
EC2
가상화 서버
VPC
가상화 사설 서버 (Coin Rush)
S3
정적 컨텐츠 서빙
CloudFront
CDN (S3과 연동)
R53
도메인 네임 관리

28. 서버 확장
미리 만들어진 AMI 런칭
R53 도메인 등록
서버 코드 체크아웃
설정 파일 편집
서버 이름
어떤 유형의 서버/워커를 구동할 것인지
10~15분 만에 가능!

29. 서버 장애 처리
어플리케이션 서버의 경우
장애가 발생한 인스턴스 Terminate 처리
같은 유형의 인스턴스 하나 더 런칭
데이터베이스 서버의 경우
Couchbase에서 Automatic Failover 기능을 지원
따라서 장애가 난 인스턴스는 그냥 버려도 무방
같은 종류의 Couchbase instance 런칭
관리 콘솔에서 새로 띄운 인스턴스를 클러스터에 추가
Rebalance

30. 배치 (deployment)
서버 코드에 Deployment 로직이 내장
Mercurial 사용
AWS API 사용
S3에 변경된 리소스 업로드와 CloudFront invalidation이 자동화
명령 두줄로 모든 과정이 완료!
사실상 업데이트시 “점검” 불필요

31. 백업
EBS snapshot 기능
API를 통해 프로그램적으로 가능
다만, 스냅샷 작업이 원자적이진 않음
Consistency가 보장된 백업을 위해서는 별도의 백업 로직에 대한 고려가
필요!

32. 결론

33. 결론
빠른 개발과 쾌적한 운영이 가능
SE, NE를 통해 작업해야 하는 상황에서 발생하는 커뮤니케이션 코스트가
거의 발생하지 않음
KartRider Coin Rush의 빠른 런칭에 AWS가 많은 도움이 되었음!
수요에 따라 빠르고 유연한 대처가 가능
비용 절감 효과
좋아요!

34. Q&A

35. 감사합니다!
박준규
segfault@nexon.co.kr
010-4031-2264