[Gaming on AWS] AWS에서 실시간 멀티플레이 게임 구현하기 - 넥슨

16,218 views

Published on

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

Published in: Technology
0 Comments
60 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
16,218
On SlideShare
0
From Embeds
0
Number of Embeds
7,615
Actions
Shares
0
Downloads
215
Comments
0
Likes
60
Embeds 0
No embeds

No notes for slide

[Gaming on AWS] AWS에서 실시간 멀티플레이 게임 구현하기 - 넥슨

  1. 1. AWS에서 실시간 멀티플레이어 게임 구현하기 넥슨코리아 로켓쉽스튜디오 기술지원팀 박준규
  2. 2. 박준규 http://about.me/segfault NexG (2009 - 2012) StyleShare (2012) 넥슨코리아 (2012 -) KartRider Dash 라이브 KartRider Coin Rush 개발 참여 현재 모바일 게임 서버 기술지원 업무 중
  3. 3. KartRider Dash
  4. 4. KartRider Dash Facebook 친구들과 카트라이더를! 2012년 5월 런칭 월드와이드 서비스 Facebook 캔버스 앱 https://apps.facebook.com/kartriderdash
  5. 5. 왜 AWS를?
  6. 6. 왜 AWS를? 어플리케이션 데이터 운영체제 런타임 네트워크 하드웨어 스토리지 가상화
  7. 7. 왜 AWS를? 데이터 운영체제 우리가 신경 쓸 필요 없음 어플리케이션 런타임 네트워크 하드웨어 스토리지 가상화 IaaS (Infrastructure as a Service)의 가장 큰 미덕!
  8. 8. 왜 AWS를? 월드와이드 서비스 전세계에 걸쳐있는 아마존의 인프라는 월드와이드 서비스에 최적! 적은 초기비용 장비 구입 비용 “0” 사용한 만큼만 내면 된다
  9. 9. 왜 AWS를? 확장에 매우 용이 가상화의 가장 큰 장점 On-demand 수요에 유연한 대응이 가능 Automatic scaling 구성도 가능함! 이 경우에는 Scaling 전략을 잘 세워야…
  10. 10. 왜 AWS를? 쉬운 관리 웹 콘솔로 모든 작업이 가능 API를 통한 관리작업 자동화 소규모 팀일수록 큰 장점! 안정성 여러 개의 Availability zone 스토리지 가상화 (EBS; Elastic Block Store)
  11. 11. 서버의 구현 목표
  12. 12. 서버의 구현 목표 클라우드에 최적화된 구조 수평 확장 (Scale-out)이 가장 중요! 낮은 성능의 인스턴스 여러 개로 서비스가 가능 서버 확장에 따라 linear한 가용성 증가 어떤 노드에 문제가 생겨도 서비스에는 지장이 없도록! 실시간 멀티플레이 게임으로서의 반응성 확보
  13. 13. 서버 아키텍쳐
  14. 14. 서버 아키텍쳐 Ubuntu Linux 기반 서버 코드는 Python으로 작성 us-east-1 비대칭적 (asymmetric) 서버들은 서로 다른 역할이 있음 E.g., 웹 서버, 메인 서버, 패킷 릴레이 서버, … 각 서버들은 수평 확장 가능 싱글 스레드, 멀티 프로세스 gevent 기반 서버에서 행하는 대부분의 작업은 I/O-bound CPU-bound 작업을 위한 별도의 독립된 worker가 있음
  15. 15. 서버 아키텍쳐 서버/워커간 통신 (RPC) 역할이 나뉘어져 있으니만큼 서버들은 상호의존적 Redis의 Publish/Subscribe 기능을 활용 Fan-out, Round robin 방식 서버 확장/축소가 매우 쉽다. 서버 클러스터에 등록만 되면 정상적인 요청 처리가 가능한 구조
  16. 16. 서버 아키텍쳐 Elastic Load Balancer (ELB) (말 그대로) 로드 밸런서 사용하기가 매우 쉽다! 노드에 장애 발생시 자동으로 exclude
  17. 17. 서버 아키텍쳐 메인 DB로는 Couchbase 사용 Document-oriented DBMS (NoSQL) 수평 확장에 최적화된 구조 서비스 중에도 노드 추가/삭제가 가능하다! 다만 Querying에는 취약 2.0에 들어서야 View 기능 추가 대쉬에서는 Moxi에 ELB를 붙여서 운용
  18. 18. KartRider Coin Rush
  19. 19. KartRider Coin Rush
  20. 20. KartRider Coin Rush 카카오톡 플랫폼 모바일 게임 2012년 11월 런칭 서버 코드와 인프라는 KartRider Dash 기반으로 제작 비교적 짧은 개발기간
  21. 21. KartRider Coin Rush VPC (Virtual Private Cloud) 코인러쉬에서는 VPC를 사용 보안성 강화 서브넷별로 다른 접근 제어가 가능 더욱 철저한 access control이 가능 VPN을 통해 내부 네트워크에 접근
  22. 22. KartRider Coin Rush 코인러쉬는 국내 시장을 대상으로 한 게임 Region을 ap-northeast-1 (도쿄)로 설정 도쿄 지역의 핑은 만족스러움. 모바일 플랫폼에 맞춰 서버 튜닝이 필요 3G, LTE 환경은 안정적인 RTT가 나오기 어렵다. 게임패킷 송신은 UDP, 수신은 TCP로 너무 많은 패킷은 휴대폰 배터리 사용량에도 영향을 미침 초당 전송되는 게임패킷 수 조정
  23. 23. 도전
  24. 24. 도전 멀티플레이 게임으로서의 빠른 반응성 확보 AWS 인프라와 구현된 서버 로직을 통해 충분히 확보! 관리 작업의 많은 부분을 자동화 AWS API 짱짱 수평 확장이 무엇보다도 중요 서버 로직은 물론 DB까지도 철저히 수평 확장을 고려 서버들의 RPC 허브 역할을 하는 Redis가 잠재적인 SPoF (Single Point of Failure)가 될 수도 있다는 점은 아쉬움
  25. 25. AWS 활용 사례
  26. 26. AWS 활용 사례 EC2 가상화 서버 VPC 가상화 사설 서버 (Coin Rush) S3 정적 컨텐츠 서빙 CloudFront CDN (S3과 연동) R53 도메인 네임 관리
  27. 27. 서버 확장 미리 만들어진 AMI 런칭 R53 도메인 등록 서버 코드 체크아웃 설정 파일 편집 서버 이름 어떤 유형의 서버/워커를 구동할 것인지 10~15분 만에 가능!
  28. 28. 서버 장애 처리 어플리케이션 서버의 경우 장애가 발생한 인스턴스 Terminate 처리 같은 유형의 인스턴스 하나 더 런칭 데이터베이스 서버의 경우 Couchbase에서 Automatic Failover 기능을 지원 따라서 장애가 난 인스턴스는 그냥 버려도 무방 같은 종류의 Couchbase instance 런칭 관리 콘솔에서 새로 띄운 인스턴스를 클러스터에 추가 Rebalance
  29. 29. 배치 (deployment) 서버 코드에 Deployment 로직이 내장 Mercurial 사용 AWS API 사용 S3에 변경된 리소스 업로드와 CloudFront invalidation이 자동화 명령 두줄로 모든 과정이 완료! 사실상 업데이트시 “점검” 불필요
  30. 30. 백업 EBS snapshot 기능 API를 통해 프로그램적으로 가능 다만, 스냅샷 작업이 원자적이진 않음 Consistency가 보장된 백업을 위해서는 별도의 백업 로직에 대한 고려가 필요!
  31. 31. 결론
  32. 32. 결론 빠른 개발과 쾌적한 운영이 가능 SE, NE를 통해 작업해야 하는 상황에서 발생하는 커뮤니케이션 코스트가 거의 발생하지 않음 KartRider Coin Rush의 빠른 런칭에 AWS가 많은 도움이 되었음! 수요에 따라 빠르고 유연한 대처가 가능 비용 절감 효과 좋아요!
  33. 33. Q&A
  34. 34. 감사합니다! 박준규 segfault@nexon.co.kr 010-4031-2264

×