Overview

게임 장르

• Session Based Game
  • MOBA, FPS, FTG
  • 낮은 지연시간(50~100ms) 요구 
  • 하나의 방을 지정한 시작과 끝이 명확한 게임, 적은규모
• Turn Based Light Realtime Game
  • SLG, TCG, TBS
  • 낮은 레이턴시를 요구하지 않음 ← 기술사용에 제한적이지X
  • 가벼운 리얼타임 언리얼 게임, 웹 기반 사용에 적합
• Massive RPG
  • MMORPG, AVG, ACT
  • 높은 IOPS , 계속해서상태를 저장해줘야 함
  • 많은사람들이 즐기는 RPG게임

연결구조

(멀티플레이어를 위한)

• P2P 
  • 플레이어간 직접 연결(← 하나의 연결문제가 전체에 영향)
  • 비교적 낮은 레이턴시
  • 실제 게임 로직 처리는 각자 처리 → 해킹에 취약
• 호스팅 
  • P2P 방식의 변형
  • 플레이어 클라이언트 중 하나가 호스트(Super-peer) 역할 수행(← 호스트에 부하/게임규모 확장의 어려움)
  • 호스트를 통한 패킷 중계→ 해킹에 여전히 취약
• Dedicated Server
  • 데이터센터/클라우드에 전용 서버 → 플레이어중 가까운 지역에 서버를 둘 수 있음(물리적 로케이션) / 게임의 스펙을 컨트롤하기에 용이
  •  대부분 세션형 온라인 게임에서 차용 중
  • 주로 서버 동기화 방식

Dedicated Game Server

• 연산수행 및 상태 저장 역할 수행(패킷 처리/Tick 처리)

장점

• 물리적 로케이션으로 개선된 지연시간
• 더큰 규모의 게임 세션 운영 가능
• 백엔드 구축을 단순화(←서버에서 처리)
• Anti cheat
• 게임 개발 가속(← NAT Punch 사용 X)

구성 요소

• Services plane - 인증, 매치메이킹 서버
• Data plane - 플레이어, 게임, 매치메이킹, 분석 데이터
• Game session plane- 세션관리, 세션 매트릭 체크
• Game server plane - 하나의 서버가 여러개의 세션을 

     +) 아웃 게임(out-game) 시나리오 - 게임 업데이트, 상태 저장, 랭킹, 리플레이, 거래소 등

장르별 아키텍처

비동기형(캐주얼 게임)

• 웹 기술로 구현 가능
  • 2-tier : 웹 서버 + 데이터 스토어
  • 3-tier : 웹 프론트 + 애플리케이션 서버 + 데이터 스토어
• 서버리스 형태에 유리

세부 아키텍처

• Stand alone games - 온라인 요소가 없음

• Semi-online games → 비동기 게임 아키텍처

세션형 (세션 기반)

• 시작과 끝이 명확,로비가 존재→ 실시간 게임 중 가장 많음
• 게임이 STateful함 ← 세션은 서로 독립적
• 로비, 매치메이킹,데디서버 등이 필요 + 채팅이 중요한 요소

세부 아키텍처

classic

Serverless

GameLift

MMO (지속형)

• 게임 월드가 유지되는 형태 (시간의 연속성)
• 월드 또는 채널 별로 다수의 서버로 구성 + stateful
• 상태 저장 (CRUD) 및 게임 내 거래(Transaction)가 빈번 / 고성능

세부 아키텍처

<ac:image ac:height="150">
<ri:attachment ri:filename="image2022-5-24_14-46-6.png"/>
</ac:image>

Web- based

3-tier Web Architecture

• backend로 http(s)기반 RESTful API를 사용

Presentation Layer

실제 browser에서 loading할 html 파일들을 서비스/ Frontend Webserver

• Cloudfront(CDN)- 엣지로케이션 사용, 라우팅 최적화, WAF와 웹방화벽 구성 가능
• S3 - 내구성 높음(백업용 가능), 보안(OAI를 통하여 Cloudfront에서만 접근가능하도록)
• ALB -Web server 기능 대치,L7 라우팅, 스케일링 지원
• API gateway - ALB와 유사, lambda사용시 

Application Layer

business logic의 처리 / : Application server

• EC2 기반 - EC2, Lightsail, Beanstalk
• Container 기반 -  ECS, EKS, Fargate
• Serverless - Lambda를 활용

      +)  오토스케일링 , 보안

• State 관리 필요(← 멀티플레이 관련 요구사항)
  • Client에서 state 관리 -: browser나 game client에서 (비효율적 방법)
  • Server에서 관리 - Sticky Session 기능 사용 또는 Session strage 사용(ex. Redis)(← 

Data Access Layer

Data들을 저장하고 읽을 수 있도록 서비스 /가장높은 수준의 보안 요구

• RDS(RDBMS) - 관리형 in-memory DB 서비스
• DynamoDB(NoSQL) - Serverless NoSQL 서비스, 엔드포인트 분리 불필요, ← Hot partition 문제
• Elasticache(Cache) - 관리형 in-memory DB 서비스

 

Session-based

Session-based?

• 실시간으로 다른플레이어와 상호작용(TCP/UDP기반)
• STateful하게 연결(세션)유지
• 사용 네트워크 패턴  - P2P방식, Dedicated Server

기본 아키텍처

ex.)

Game Server 계층

• Access - 트래픽 가속화 (Amazon CloudFront, Global Accelerator)
• 매치메이킹 - Servelss 기반의 매치메이킹 구현 가능(API gateway, Lambda등)

in-Game Server

• 게임 장르나 기획에 따른 요구사항으로 서버 구현방식에 차이

• • 최신 세대 선택 권장
  • C타입(server Authority방식 구현시), +g(가성비),+n(네트워크 향상)
  • 클러스터 배치그룹사용으로 낮은 지연시간 확보

Outgame Server 계층

• 대부분 웹 API형태
• Message Queue 형태

데이터베이스 계층

• 사용사례에 알맞은 서비스 사용(RDBMS or NOSQL)
• 비동기로도 수행가능
• SQS Queue 활용 가능

Amazon GameLift

멀티 플레이어 게임을 위한 Dedicated Game Server 호스팅 솔루션

ex.)

장점

• 코드의 쉬운 배포와 업데이트
• 비용 효율적인 서버 프로비저닝
• 관리형 매치메이킹 기능
• 지연시간과 대기시간 최소화

서비스

• amazon gamelift custom game servers
• amazon gamelift realtime servers- 자바스크립트 기반, 경량화
• amazon  gamelift FleetIQ - 스팟인스턴스 활용, 관리의 유연함

Demo &  Hands-on

1. Lambda 함수 구성
2. API Gateway 구성
3. (S3 웹 호스팅 환경 구성)
4. 게임 서버 빌드 및 플릿 생성
5. 서버리스 기반의 FlexMatch 로직 및 Lambda API 구성하기
6. FlexMatch 게임 클라이언트와 환경을 연결
7. FlexMatch 매치메이킹 이벤트 활용
8. FlexMatch Ruleset 테스트

https://aws-samples.github.io/aws-gamelift-sample/ko/