겜섭알못의 게임서버 아키텍처 101 #1

2020년 6월 4일

5분

서론

별다른 언급 없이 서버라 하면 당연히 웹서버를 떠올릴만큼, 웹기술은 서버-클라이언트 모델의 대세다. 웹 서버 기술은 상당히 많은 연구와 응용이 수십년간 진행되었기에 표준, 프레임워크, 아키텍처 등이 정형화되었고, 따라서 서버 개발자는 거의 도메인 모델 구현만 신경쓰면 되는 수준에 이르렀다. 허나 게임 서버는 웹과는 많은 것들이 다르다. 게임 장르와 대상, 목적에 따라 기술이나 아키텍처가 달라지기 때문에 정형화할 만한 영역이 많지 않다. 또한 웹과는 다르게 게임 진행중 서버-클라이언트는 연결성을 유지하고 있어야 한다. 이러한 요구사항, 기술적 차이 외에도 규모의 차이가 있다. 시장 규모, 매출을 기준으로 하면 게임 서버 시장이 결코 작지 않으나 개발자 인력 풀 관점에서 게임 개발자는 다른 도메인에 비해 소수다. 웹서버 개발 10년차 베테랑이라 할지라도 멀티쓰레드 환경에서 발생하는 다양한 동시성 문제나 소켓 통신에 따른 네크워크 문제, 위상 변화에 따른 위치문제 등을 현업에서 겪었을 가능성은 높지 않다. 때문에 게임 업계는 다른 업계 종사자가 전직하기엔 진입장벽이 높은 고인물들의 닫힌 시장인 경향이 있다.

본인의 커리어에 게임서버 백엔드 경험이 없기 때문에 이쪽 분야에 대한 기술적 특징이나 아키텍처를 짚고 넘어가야 할 필요를 느낀다. 다행스럽게도(?) 본인의 커리어가 워낙 잡스러웠던 탓에 다른 사람들 보다 게임 서버 기술을 이해하는데 조금은 낫지 않나 싶다. 이 글에선 게임 서버 기술 및 아키텍처의 일반론을 서술하고, 필요한 경우 웹 기술과 비교하면서 그 특징의 이해도를 높이도록 하겠다. 본인도 겜섭알못이기 때문에 글에 깊이가 없을 수 있음은 감안해 달라. 게임 개발에 흥미가 있는 주니어나 전업을 고민하는 개발자에게 도움이 되었으면 좋겠다.

Stateless vs Stateful

웹은 기본적으로 stateless 하다. 100명의 사용자에게 하나의 동일한 페이지를 제공하는 것이다. 반면 게임은 기본적으로 이전의 상태를 저장하고 있어야 한다. 같은 아이템을 사용해도 사용자 레벨이나 능력치에 따라 다르게 적용되는 경우도 있고, PvP 상황에선 누가 먼저 공격을 했는지에 따라 결과가 달라질 수 있다.

물론 현재의 웹은 로그인도 필요하고 장바구니도 필요하고 결제, 배송 내역을 확인할 필요도 있기 때문에 이전의 상태값을 저장해야 한다. 비즈니스 모델의 요구사항이 사용자 개개인의 상태를 저장하도록 발전해왔기 때문에 웹에도 다양한 방법으로 이전 상태를 저장하는 기술이 추가되었다.

허나 어떤 특정 상황에서 웹기술로 이전 상태를 저장하는 데에는 근본적인 한계가 있다. 1) 아주 짧은 시간 동안, 2) 상태가 계속 바뀌는데, 3) 상태변화의 순서가 나와 타인에게 영향을 주는, mmorpg에선 일반적으로 발생하는 그런 상황은 웹기술로 처리하기가 곤란하다. 웹프로토콜이 http이기 때문이다.

가장 흔한 http 클라이언트인 웹브라우저로 예를 들어보자. 웹브라우저는 사용자가 브라우저를 사용하는 대부분의 시간동안 서버와의 연결이 끊어져 있다. 어떤 페이지에 접근을 하기 위해 요청을 하면 그때 서버와 연결을 하고, 응답을 받으면 바로 서버와 연결을 끊는다. 간단하게 원하는 리소스를 가져올 수 있는 장점이 있지만 리소스를 가져올 때 마다 매번 새로 연결 / 연결 해제하므로 아무리 응답이 빨라도 연결 수립을 위한 시간이 소요된다. 요즘 흔한 웹기반 모바일 게임 장르에 fps 나 mmorpg가 없거나, PvP 관련 컨텐츠가 존재하지 않는 이유가 웹기술의 이러한 한계 때문이다.

Realtime event

반면 게임서버는 빠르게 요청되는 유저 간의 이벤트를 순서대로 처리하기 위해 클라이언트/서버 간에 연결을 유지한다. 위치의 이동, 스킬 또는 아이템의 사용, 공격과 회피에 따른 상태 변경 등을 게임월드에 요청하면 게임서버는 이를 순서대로 적용하여 결과를 사용자에게 돌려주는데 이때 소요되는 시간은 게임 진행에 무리가 없도록 충분히 짧아야 한다.

Key pain points of web application development — 웹페이지 컨텐츠를 기다려 주는 시간은 일반적으로 3초 정도라고 한다.

일반적으로 웹 컨텐츠의 응답시간은 3초 이내로 상정한다. 반면 게임 서버는 100ms 이내에 응답이 와야 원활한 플레이가 가능하다. 네트워크에서 가장 코스트가 큰 작업이 연결이므로 연결 비용을 줄이려면 게임 클라이언트/서버는 연결을 유지하여야 한다.

게임에서 요구되는 빠른 응답성과 연결성, 이 두 가지 특징은 서버 운영 및 아키텍처에 큰 도전 과제다. 후술할 게임 서버의 다른 특징들은 상기 두 가지 특징으로부터 파생되었다 하여도 과언이 아니다.

Logical / physical topology – Load balancing

다수의 사용자를 처리하기 위한 서버 운영 기술 중 여러 개의 서버를 로드밸런싱하는 방법이 있는데, 게임 서버에서는 이런 구성을 하기 전에 한 번 더 고민하여야 한다. 사용자 간에 데이터 교환이 일어나기 때문이다. 쿠팡이나 11번가 같은 쇼핑몰 사용자들은 서로 통신할 일이 없기 때문에 다른 사용자가 어느 서버에 접속하던 전혀 상관할 필요가 없다. 반면 게임 서버는 사용자 간 논리적 거리가 가까우면 물리적으로도 가까워야 한다. 최소한 서버간 데이터 교환에 걸리는 시간이 응답성에 영향을 주지 않을 정도로 짧아야 한다. 때문에 게임서버는 같이 게임을 진행하는 유저들을 물리적으로도 같은 서버에 위치시키도록 유도한다.

오버워치 서버 탐색기 A to Z : 이런 것도 가능해?! : 네이버 포스트 — 어떤 게임은 함께 플레이하는 유저들을 물리적으로 같은 서버에 위치시키도록 대기실에 입장하는 단계를 거치기도 한다.

이러한 토폴로지적 특징(특정 유저군을 물리적/논리적으로 동일한 위치에 모아야만 하는) 때문에 게임 서버는 로드밸런싱이 어렵다. 웹 서버의 로드밸런서 – 백엔드 구성을 떠올려보자. 웹의 특징 – connectionless / stateless – 에 따라 모든 서버는 독립적이다. 사용자는 어느 서버에 접속하여도 동일한 리소스를 제공받는다. 따라서 로드밸런서는 부하 분산의 역할에 충실하여 접속하는 사용자들을 골고루 분산시키기만 하면 된다. 허나 게임서버의 부하분산은 기술적 도전과제다.

Long connection – Scalability

컴퓨터 네트워크에서 가장 코스트가 높은 작업은 커넥션이다. 바꿔말하면 최초로 커넥션을 생성할 때 걸리는 시간이 가장 길다는 뜻이기도 하다. 물론 최근의 웹소켓이나 스트리밍 컨텐츠 같은 예외들이 있지만, 일반적으로 웹은 요청 시 마다 새로 연결을 생성하고 응답을 받으면 연결을 종료한다. 이러한 특성 때문에 웹서비스는 서버의 사용량에 맞추어 수평적 스케일링을 하기 용이하다. 모든 요청 시 마다 새로 커넥션을 생성하는 구조이기 때문에 기존 유저가 신규 서버에 접속하여 리소스를 요청하여도 문제가 없다.

반면 게임 서버 같은 경우는 앞서 말한 빠른 응답성을 보장해야 하기 때문에 커넥션을 매번 새로 맺는 비용을 감당할 수 없다. 따라서 게임 서버는 일반적으로 커넥션을 유지한 상태로 데이터 교환을 한다. 이러한 연결성을 유지해야 하는 제약조건 때문에 게임 서버는 스케일링이 웹서비스처럼 용이하지가 않다. 높은 연결성과 관련한 문제들은 물리적인 한계이기 때문에 게임 디자인 / 서버 아키텍처를 잘 구성하여 게임 서비스 중에도 스케일링을 하기 좋은 형태로 처음부터 설계하여야 한다.

게임의 성격에 따라 서버-클라이언트 네트워킹 외에 서버-서버 간 통신이 이루어져야 하는 경우도 많다. 다수의 월드 서버로 구성된 MMORPG 게임이 있다고 가정하자. 월드 내에서 일어나는 이벤트 중에선 모든 서버에 공유되어야만 하는 사건들도 존재한다. 이러한 니즈 때문에 게임 서버들은 각각의 게임 서버들 끼리 거미줄처럼 서로 통신하게 된다.

game_server_arch — 좌측의 웹서버는 서버간 연결이 불필요한 반면, 우측의 게임서버는 거미줄처럼 n대n 통신을 하여야 한다. – 출처 NetEase/pomelo

하지만 이러한 n대n 연결 구조에서 큰 고민 없이 아키텍처를 구성하면 가용성 향상을 위해 서버를 늘렸을 때 오히려 커뮤니케이션 비용이 올라가버린다. 서버를 추가하였으나 도리어 성능이 저하되는 원치 않는 결과를 초래하기 때문에 주의하여야 한다.

다음 글에선 일반적인 게임 아키텍처 패턴, 그리고 게임서버와 관련된 기술들을 열거해 보도록 하겠다.