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 - 인증, 매치메이킹 서버
![](https://velog.velcdn.com/images/sjk326/post/63a3de62-43fb-4963-9f00-c67588219aad/image.png)
-
Data plane - 플레이어, 게임, 매치메이킹, 분석 데이터
![](https://velog.velcdn.com/images/sjk326/post/fc11878f-ec45-4cbf-b6ca-ff4adc1e5282/image.png)
-
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
- Lambda 함수 구성
- API Gateway 구성
- (S3 웹 호스팅 환경 구성)
- 게임 서버 빌드 및 플릿 생성
- 서버리스 기반의 FlexMatch 로직 및 Lambda API 구성하기
- FlexMatch 게임 클라이언트와 환경을 연결
- FlexMatch 매치메이킹 이벤트 활용
- FlexMatch Ruleset 테스트
https://aws-samples.github.io/aws-gamelift-sample/ko/