[Unreal Engine] FPS Multiplayer Plugin 만들기(1) 서버구현방식

1. 서버 구현 방식

게임 세션 간에 정보를 공유하기 위해 시스템을 설계하는 방법에는 여러가지가 있다.

• P2P(Peer-To-Peer) :  플레이어끼리 직접 서로 연결하는 방식으로 모두가 클라이언트이자 서버이다.

P2P 서버 방식의 장점:

 

1. 정보를 전송하는 가장 간단한 방법으로 구현이 상대적으로 쉽다.

2. 특정 플레이어가 나가더라도 서버 전체가 죽는일이 발생하지 않는다.

3. 특정 플레이어에게 트래픽이 몰리지 않는다.

4. 어느 지역에서 게임을 하더라도 서로 가까이 위치해 있기만 한다면 낮은 지연시간을 만족시키며 연결할 수 있다.

 

P2P 서버 방식의 단점:

1. 플레이어의 수가 늘어날 수록 주고 받을 데이터 전송량이 급격히 증가한다.

2인 - 1

3인 - 3

4인 - 6

5인 - 10

6인 - 15

7인 - 21

8인 - 28 ... 으로 플레이어가 늘어나면  연결이  급격히 증가한다 ( n명이면 n(n-1)/2개의 연결이 필요하다. ) 

 

2. 어떤 플레이어가 제공하는 데이터가 진실인지 알지 못함.(non-authoritative)

특정 플레이어가 데이터를 변조하여 악용할 수 있고 그런 일이 없더라도 유저의 게임 인스턴스는 모두 다르다.(예를들어 각각의 유저 컴퓨터는 인터넷 핑이 다를 수 있으므로 시차가 발생) 누구의 게임 인스턴스가 올바른 것인지에 대한 답을 내리기 힘들다. 따라서 게임을 동기화 하기가 매우 어려움

 

3. 각 피어는 다음 네트워크 프레임을 시뮬레이션 하기 전에 다른 모든 피어의 메시지를 기다려야 하므로 모든 플레이어는 연결이 가장 나쁜 플레이어와 동일한 대기 시간을 경험한다. 따라서 특정 플레이어의 인터넷 상태가 안좋다면 모두가 피해를 보는 방식이다.

 

 

• 클라이언트-서버 방식(Client-Server) : 단일 시스템을 서버로 지정하고, 다른 모든 유저의 시스템들은 클라이언트로 지정되는 방식

특정 클라이언트가 다른 클라이언트에게 직접 정보를 보내지 않고 모든 클라이언트는 서버하고만 통신한다.

클라이언트- 서버 방식의 장점:

1. 각 클라이언트들은 한명 분량의 전송 및 수신을 위한 대역폭 요구사항만 충족하면 통신하는데 지장 없음

2. P2P 단점 2번에서 해결하지못한 문제를 해결할 수 있음. 서버는 클라이언트들이 올바른 요청을 보내는지 확인할 수 있고 모든 기준과 판정은 서버 시스템을 기준으로 옳고 그름을 판단함. (authoritative)

 

클라이언트-서버 세부 방식에는 리슨 서버(Listen-Server)와 데디케이티드 서버(Dedicated Server)가 있다.

• 리슨 서버: 클라이언트중 하나가 서버 역할을 하는 방식

리슨서버는 실제 플레이어의 컴퓨터중 한대가 서버가 되는 방식이므로 실제 게임에 참여하며 그래픽을 화면에 렌더링하면서 진행한다

 

리슨 서버의 장점:

1. 플레이어가 직접 서버가 되므로 게임회사에서는 서버 비용을 절감할 수 있음

2. 플레이어끼리 가까이 위치한다면 낮은 지연시간의 이점을 볼 수 있음

 

리슨 서버의 단점:

1. 서버(호스트)가 나가버리면 게임이 중지됨

2. 일반적으로 한 명의 유저의 컴퓨터가 대규모 인원을 처리할 컴퓨팅 파워를 갖고있지 않아 대규모 게임에 부적절함(실제 유저가 플레이를 하는 도중에 서버도 처리하는 것이므로 그래픽처리나 호스트 유저의 게임플레이도 컴퓨터가 처리해야함)

 

호스트가 나가버리면 게임이 중지되는 문제를 해결하기 위해 '호스트 마이그레이션(Host Migration)'이라는 기술이 존재한다. 호스팅 중인 플레이어의 연결이 끊어지면 다른 플레이어중 한명이 새 호스트로 지정되어 게임을 계속 진행해 나갈 수 있다. 워크래프트 유즈맵을 자주하는 사람이라면 쉽게 떠올릴 수 있겠다.

 

• 데디케이티드 서버:  전용 서버로 애초부터 서버 전용으로 지정해놓은 시스템을 사용하는 방식이다. 실제 게임에 참여하지 않고 그래픽을 렌더링할 필요가 없다. 그래픽 없이 서버에서 게임이 실행되는 방식이라 생각하면 좋다.

데디케이티드 서버를 사용하면 서버 시스템의 신뢰할 수 있는 버전의 시뮬레이션만 처리할 수 있다.

 

데디케이티드 서버의 장점:

1. 게임 회사가 직접 서버를 책임지므로 유저의 부담이 적어지고 서버를 신뢰할 수 있음

2. 악성 유저가 호스트가 되는일이 없으므로 다른 서버에 비해 핵과 같은 악용문제에 상대적으로 자유로움

3. 서버가 직접 게임에 참여하지 않으므로 서버 시스템은 플레이어의 로직처리나 그래픽처리를 할 필요가 없음

(대규모 처리가 가능하다)

 

데디케이티드 서버의 단점:

1. 게임회사의 서버 시스템이 플레이어의 위치와 멀다면 높은 지연시간으로 정상적인 게임플레이가 불가능할 수 있음

(실시간 게임에서 한국서버가 없어 외국서버를 접속하는 경우 크게 체감할 수 있다.)

2. 모든 서버의 부하를 게임회사가 감당함으로 인해 발생하는 비싼 초기 비용, 향후 유지 비용 (게임 회사는 유저 수를 예측할 수 없음. 오픈베타때 인기 게임이 터지는 이유가 바로 이러한 비용문제 때문이다. 오픈 초기의 그 많은 유저 인원을 처리하기 위해 서버를 잔뜩 사들였다가 게임이 인기가 식게 되면 막대한 유지비용과 낭비가 발생할 수 있음)

3. 구현이 어려움(플레이어의 트래픽을 어디까지 처리할 것인지? 필요한 부분만 동기화를 시키려고 최적화 작업을 하면 서버 트래픽은 줄일 수 있지만 개발이 어려워지고 놓치는 부분이 발생할 수 있음)

 

위와 같이 대표적인 서버 방식에 대해 알아보았다. 대규모 게임사는 물리적인 서버를 직접 가지고 있지만

그렇지 않은 중/소규모 게임회사들도 많다. 어떤 방식으로 서버를 운영하고 있을지 알아보자

• IaaS (Infrastructure as a service): 서비스 제공자가 서버 인프라를 제공하는 방식이다. 예를들어 서버 장비, 장소 임대, 전기, 통신 등등을 서비스 제공자가 책임지고 게임회사들은 이러한 서비스 제공자에게 위탁을 하여 서버를 운영하는 방식이다. 대표적으로 Amazon AWS, Microsoft Azure와 같은 서비스들이 있다.
• PaaS (Platform as a Service): IaaS에서 발전한 방식. IaaS는 물리적인 문제만 해결해주는 반면 PaaS는 운영체제, 네트워크 설정, 기타 관리도구(로드 밸런서, 오토 스케일링 등등...)를 제공한다.

요즘에 단일 서버는 거의 없다. 규모가 커지면 로그인 서버도 로그인 서버1, 로그인 서버2... 등이 존재할 수 있고

게임 플레이서버도 단 하나의 머신이 처리를 하는 것이 아니라 게임 플레이 서버1, 게임 플레이 서버2.. 등 많은 수의 컴퓨터가 묶여있는 구조인데 로드밸런서는 부하가 낮은 서버쪽으로 분배해주는 분배기라고 생각하면 쉽다.

위에서 얘기했다시피 게임의 출시 기간에 따라, 특정 나라의 시간이나 날짜에 따라 유저 트래픽이 급격히 바뀔 수 있는데 오토 스케일링은 이를 알아서 늘리거나 줄여주는 기능이다.

 

• 서버리스 아키텍처(Serverless)

이름은 서버가 없다는 뜻이지만 사실 서버가 없을 수는 없다. 서버가 없는 것처럼 작동한다는 의미이다. 대표적으로 BaaS(Backend as a Service), FaaS(Function as a Service)에 의존해서 처리를 하게 된다. 

• BaaS(Backend as a Service): 서버에서 제공할 수 있는 특정 기능들(DB 관리, 푸시 알림, 원격 업데이트, 사용자 인증 등등)을 서비스 제공자가 API로 구현해두면 개발자가 이를 가져와 사용하는 방식으로 Google Firebase 같은 것이 있다.
• FaaS(Function as a Service): 사전에 작성된 API 라이브러리에 의존하지 않고 개발자에게 더 많은 제어 권한을 제공하는 방식. 개발자가 작성한 백엔드 코드를 서버에 업로드하면 해당 서버는 코드를 함수나 모듈 단위로 쪼개서 대기상태로 두었다가 요청이 들어오면 함수 단위로 실행시켜 처리하는 방식이다. 주로 함수 호출 횟수를 기준으로 비용을 청구함. AWS Lambda, MS Azure Function과 같은 것들이 있다.

 

많은 서비스와 서버 종류들에 대해 알아보았다. 이외에도 구글 스태디아, 엔비디아 지포스 나우등 게임 클라이언트 자체를 서버에서 실행시키고 화면만 전송해주는 방식도 있기도 하다. 이외에도 다른 많은 서버방식이 있을 수 있다.

 

이렇게 서버 종류가 많은데 내가 만드는 게임은 어떤 서버를 사용해야할까?

제일 좋은 방법은 내가 만들고자 하는 장르의 게임회사들이 어떤 방식을 사용하는지 찾아보는 것이다

크게 1. 지연시간 2. 게임의 규모로 나눌 수 있겠다

 

FPS, 레이싱게임과 같이 밀리세컨드 단위로 승패가 판가름 나는 게임은 무엇보다 지연시간이 매우 중요할 수 있으며 이를 위해서 다른 많은 것들을 포기해야하는 경우가 많다. 예를들어 정말 최소한으로 쳐내고 쳐내서 필요한 것들만 서버에 주고 받는다던가 핵과 같은 악용문제에 취약하지만 지연시간이 빠른 방법을 선택해야할 수도 있다.

 

카드게임과 같은 턴제 게임(롤토체스, 하스스톤 등등)과 같은 경우는 그렇게 긴박한 서버처리가 필요하지 않다. 상대적으로 지연시간엔 관대하고 비용이나 안전성과 같이 다른 장점이 있는 서버방식을 채택하는것이 좋아 보인다.

 

RTS(전략시뮬레이션) 게임은 실시간 처리도 해야하는데 등장하는 유닛도 많다보니 사실상 엄청난 부하가 걸리게 되므로 다른 기술이 필요하다 전통적으로 락스텝(Lock Step)이란 기술을 사용한다. 예를 들어 12마리의 유닛을 특정 위치로 이동시키면 12마리의 위치정보를 전부 전송하는 방식이 아니라 12마리의 유닛을 부대지정 했다는 정보와 그 부대가 어디로 이동했다는 정보만을 보내고 유닛마다 발생하는 세세한 위치이동은 클라이언트에서 해석해서 처리하는 방식을 채택하고 있다. 

 

게임이라고 게임 플레이 서버만 있는것이 아니다 게임 로그인 서버, 게임 로비 서버 등등이 존재할 수 있고 모두 다른 방식으로 구현될 수 있다. 실시간 처리를 위해 주로 C++를 사용하는 FPS 게임서버들도 로그인서버까지 급박하게 밀리세컨드 단위로 처리할 필요는 없다. 이러한 로그인 서버나 로비 서버등은 느슨하고 상대적으로 생산성이 좋고 엄청 빠를 필요가 없는 개발언어를 사용하는 경우가 많다.

결론적으로 중요한건 하나의 게임도 여러가지 파트의 서버가 존재할 수 있다는 것

장르별로 구현의 장단점을 잘 파악하여 서버 방식을 선택해야 한다는 것

게임의 규모나 게임 플레이 방식에 따라 달라질 수 있으니 여러가지 방식을 알아둬야 한다는 것이다