게임 서버와 채팅 서버

서비스 분리

채팅과 같은 소셜 기능을 담당하는 서버는 

게임 서버와 분리하는 것이 성능과 확장성 측면에서 좋다.

채팅 서비스, 게임 서버 서비스를 분리해서 운영한다면

마이크로서비스 지향 아키텍처를 더 관리하기 쉬워진다.

monolithic 아키텍쳐에서 멀티플리어 게임 서버를 구축하는 경우

같은 기술 스택-데이터베이스-개발 환경을 사용해야한다.

monotlithic 아키텍쳐에서는 서비스의 한 부분이 망가지면

모든 게임 서비스가 망가지게된다.

게임이라는 서비스를 마이크로서비스화 한다면

전체를 구성하는 하나의 서비스가 망가지더라도

다른 서비스는 정상 운영할 수 있고

고치기 쉽다.

게임 서버는 유저의 움직임 및 상태를

실시간으로 수신해서 처리하는 것이 목적이다.

위의 예시와 같이

하나의 서버에 두가지 목적을 가진 프로그램이 돌고 있다면

탈중앙화한 컴포넌트로 전환하여 관리하는 것이 유지보수 측면에서 좋다.

채팅 서비스 뿐 아니라

게임 서버와 분리하면 좋은 서비스들은

인증-통계-리더보드 서비스 등이 있다.

 

서비스 분리를 하지 않는다면

멀티플레이어 게임의 게임 서버는 성능이 중요하다.

사내 테스트에서는 잘 돌아갈 지몰라도

프로덕션 환경에서 채팅+게임 서버 프로세스가 같이 돌아간다면

지연 시간이 늘어날 것이다.

때문에 마이크로서비스화 한 후에도

cpu와 네트워크 자원을 지속적으로 모니터링하고

효율적으로 사용할 전략을 세울 필요가 있다.

사용자가 100명 정도로, 다수가 참여하는

멀티플레이어 서버를 예를 들면

게임 서버로 동시에 수 천개의 메시지가 전송될 수 있다.

사용자도 많거니와

사용자: 사용자 상태 정보는 1:N이기 때문이다.

채팅 서버가 같이 돌고 있다면

악의적으로 채팅 서버로 채팅을 많이 보내서

전체적인 게임 서버의 성능을 하락시킬 수 있다.

게임 서버는 이미 게임 플레이를 위해

물리/그래픽/사운드 처리를 cpu intensive하게 하고 있어서 대응하기 어렵다.

UDP 대 TCP 게임 서버

턴제 게임같은 경우가 아닌

빠른 페이스로 진행되는 멀티플레이어 게임은

게임의 상태-유저 상태를 갱신하고 싱크를 맞추기 위해(동기화)

UDP 프로토콜을 사용한다.

UDP Header는 이런 류의 게임의 빠른 상태 갱신에 적합하지만

전송된 메시지를 상대가 잘 받았는지는 보장하지 않는다.

하지만 이런 Fast-paced 게임에서는 곧바로 다음 상태 메시지가 따라오기 때문에

큰 영향은 없다.

TCP는 반대로 메시지를 받았다는 메시지를 응답해주기 때문에

게임 서버보다는 채팅 서버에 어울리는 프로토콜이다.

비교적 느린 페이스의 턴제 게임에서는

tcp는 게임 플레이, 채팅에 모두 어울리는 프로토콜이다.

출처

https://www.pubnub.com/blog/difference-between-gaming-and-chat-servers/