gksrudtlr
|2025. 3. 11. 17:00
온라인 게임 종류
- 종류
- 싱크(Synchronous, Sync)
- 어싱크(Asynchronous, Async)
CAP 이론과 게임 동기화
- CAP이론이란?
- 분신 시스템의 동기화 "조건 3개를 모두 만족하는 시스템은 없다"라는 이론
- Consistency(일관성)
- 전체 시스템은 동일한 상태 값을 갖고 있어야 함
- Availability(가용성)
- 언제든 시스템에 접근해 값을 읽고 쓸수 있어야함
- Partition Toerance(분할 용인)
게임에서 동기화 방법
- 게임 동기화의 관건은 여러대가 묶여있는 시스템의 상태를 동일하게 유지하는 것이나, CAP 이론에 따라 일관성을 추구하면서 가용성과 분할 용인 둘중 하나를 포기해야함
- 초기
- 초기 온라인 게임은 일관성을 유지하고 가용성을 포기
- 사용자가 입력시 서버로 보내 일정 시간(Round 또는 Tick)마다 클라이언트로 브로드캐스팅하여 수신받은 이벤트로 게임 클라이언트의 상태를 업데이트 처리를 함
- 클라이언트: 서버 접속
- 서버 : 모든 클라이언트 게임 접속후 게임 시작(상태 초기화)
- 클라이언트 A,B: 이벤트 발생(이동, 발사, 점프 등)
- 서버 : 이벤트 수집 후 Round(또는 Tick)마다 브로드캐스팅
- 클라이언트 A,B 업데이트
- 빠른 반응 속도가 필요 없을 때 비교적 쉽게 구현 가능
- 현재
- 다수의 사용자가 게임을 동시 실행하는 MMO, FPS, Sports와 같이 반응성이 우선인 게임 장르의 경우 기본적인 캐릭터 이동은 Round(또는 Tick)을 짧게 브로드캐스팅함
- 실시간 별도의 채널을 통해 다중 브로드캐스팅 방식으로 진화
- 주의!!
- 위 그림은 Tick/Round로 기본 정보를 주기적으로 보내면서 추가적 이벤트를 보내는 동작을함
- 이때 사용자가 컨트롤하고 있어 클라이언트를 먼저 업데이트하기 때문에 가용성을 우선하고, 일관성 포기
가용성 보정
- 가용성을 포기하고 일관성을 우선하는 CP(또는 PC)설계
- 마우스 클릭 -> 게이머에게 피드백하면서, 서버에 이벤트 전송 -> 서버가 브로드캐스팅한 데이터로 클라리언트 상태 업데이트
- 위 과정을 거치는 설계는 플레이어가 입력한 이벤트 시간과 서버에서 오는 데이터를 수신하는 시간 간의 Gap이 발생
- 이를 보안하기 위해 옛날 게임들은 클라이언트 업데이트 전 플레이어에게 사운드나 이펙트를 줘 기다리는 시간이 없는 것처럼 위장
- 사용예시
- Hearts Stone, 체스, 장기, 고스톱 => 플레이어 입력이 끝날 때까지 다른 플레이어 입력 차단
- 스타 => 일정 시간 이벤트를 모아 브로드캐스팅
- 특징
- 가용성이 떨어지는 경우 세션을 폭파시키고 남은 플레이어 승리
- 일관성을 포기하고 가용성을 우선으로 하는 AP(PA)설계
- 최근 게임에 대표적으로 사용하는 설계
- 클라리언트를 우선 업데이트 후 일관성을 보장하는 방법 사용
- 응답속도가 낮을 경우 게임을 하다보면 갑자기 죽거나 하는 경우 발생
- 사용예시
- 포트나이트=>클라이언트 예측, 서버 조정
- 예측과 서버 값이 맞으면 그대로 진행
- 틀리면 서버 값으로 반영
- 특징
- 특정 플레이어가 Latency가 떨어지더라도 세션을 그대로 유지
클라이언트 보간
- 사용 이유
- 네트워크는 강하게 결합되어 있지 않은 불안정한 전기신호
- 1/20 초마다 브로드캐스팅되는 데이터가 클라이언트에 1/20마다 도달한다 생각하면 사용자 경험(UX)가 매우 좋지 않아 보간을 사용
- 서버 데이터 수신
- 서버는 일정 간격으로 캐릭터 위치를 클라에 전송
- EX) t = 0s (x =0,y =0), t = 0.05(x=0.5,y=0)
- 클라이언트 버퍼링
- 클라에 수신된 위치값을 바로 렌더링 하지않고, 약간의 지연을 두고 버러에 저장
- 이는 네트워크 지터(Jitter, 패킷 도착 시간 변동)를 보정하고 보간에사용할 데이터 확보
- 보간 계산
- 클라는 두 위치 값 사이를 시간 비율에 따라 계산
- EX) t = 0.025s일때 (x=0,y=0)와 (x =5,y=0) 사이를 보간하면 중간 위치(x =2.5,y=0)
- 렌더링
- 매 프레임마다 보간 된 위치를 화면에 반영해 부드러운 이동 구현
비동기( Async)
- 네트워크에서 세션을 유지하기 어려운 모바일에서 사용하는 방법
- "보장된 데이터를 사용"하여 게임 환경 구축
- 느리지만 손실 허용이 안되는 TCP 프로토콜 사용
- 이벤트만 서버로 전송하고, 서버는 이벤트를 검증하고 그 결과를 DB에 저장
- 게임 플레이어 외에 다른 플레이어의 접속 여부와 관계없이 게임 진행이 가능 => 이론상 확장이 무한
채팅 서버와 온라인 게임서버의 차이
- 유사점
- 사용자 입력을 전체 사용자에게 브로드캐스팅
- 사용자의 세션 관리
- 채널(또는 서버) 별로 다른 상태
- 채널을 선택하거나, 내 아바타를 커스텀하거나, 친구 목록을 보는 등의 로비가 있음
- 차이점
- 채팅에선 사용자를 그래픽으로 표현하지 않음
- 채팅에선 사용자의 상태를 그래픽으로 표현하지 않음
- 게임에선 승패, 성공 실패가 그래픽으로 표현
- 채팅은 데이터 량이 작아 접속이 끊겨 새로 접속하면 채널의 모든 정보를 줄 수 있음
- 채팅은 낮은 Latency를 고려하지 않지만, 게임 서버는 경우에 따라 고려
네트워크 구성 진화
- 작은 규모
- 서버 1대로 DB 구성
- 제대로 된 서비스는 DB 분리
- 서버 분리
- 각종 데이터등이 많아지면서 서버를 분리하여 관리하기 시작
- 병목(Bottleneck)현상을 방지하기 위함
- 병목 현상이란? : 일하고있는 서버에 과부하가 걸려 전체 시스템 성능을 떨어지게 하는 현상
- 서버의 확장
- 서버와 서버의 동기화는 많은 동기화 시간을 필요하고, 서버를 월드 단위로 확장하면서 생기는 트래픽 몰아주기, 서버 장애시 전체 시스템 마비를 막기위해 중간 장치를 두게 됨
- 방화벽 설치 및 DB 문제
- 해킹에 따른 방지책으로 방화벽을 설치
- 사용자 증가에 DB가 버티지 못하여 DB Cluster(NoSQL과 같은 분산 DB 또는 Active-Active 모드의 Replication DB)를 적용
- DB 서버간 동기화 문제
- 분산 DB 구성으로 저장소를 공유하거나, DB 서버간 데이터를 항상 동기화 해야하는 문제 발생
- DB의 잦은 사용을대신해중 메모리 캐쉬 서버(Redis, Memcashed) 사용
- 로그인 서버 과부화
- 사용자 폭등으로 로그인 서버 역시 과부화
- 캐시서버 적용
- 채팅서버, 게임 서버간 통신 손실
- 한쪽 서버의 과부화등에 따라 통신이 손실
- 이 경우와 사용자에게 전체 전달 메시지등을 Message Queue(RabbitMQ)를 적용
필수 키워드
- 게임 시스템에서 플레이어 세션 동기화 기법 원리]
- 네트워크 시스템 구성
- 네트워크 기본 용어
