게임 서버 구축 방법 비교: GBaaS vs. 설치형 게임 서버 엔진

구글 등의 검색 엔진에 게임 서버 엔진을 검색해보면 GameSparks, Playfab, Fireline 등의 서비스들을 찾아볼 수 있다. 이들은 공통적으로 “게임의 백엔드 시스템을 제공” 하며 인증, 빌링, 매치메이킹이나 랭킹 등의 기능이 이미 만들어져 있다고 설명한다. 이런 류의 서비스들은 “백엔드 시스템을 이미 갖춰두고 이를 필요한 만큼 쓸 수 있게 한다” 라는 의미에서 Backend-as-a-Service, 줄여서 BaaS 라고 부른다. (“-as-a-Service” 는 “클라우드 형태로, 필요한 만큼 쓰고 비용을 지불할 수 있도록 서비스화 한 것” 으로 이해하면 된다.) 그리고 이 중에서도 특히 게임 서비스를 위한 백엔드 서비스를 Game Backend-as-a-Service, 줄여서 GBaaS 라고 부른다. 앞에서 언급된 서비스들은 모두 현재 서비스되고 있는 GBaaS 들이다. 그럼 이런 GBaaS 와 아이펀 엔진과 같은 설치형 게임 서버 엔진은 어떤 점에서 다를까?

먼저 설치형 게임 서버 엔진과 GBaaS가 어떤 방식으로 동작하는지를 구성도로 살펴보겠다.

1. 설치형 서버 엔진을 사용하는 경우
설치형 서버 엔진을 사용하는 경우, 서버 프로그래머는 엔진이 제공하는 기능들을 이용하여 게임 콘텐츠를 구현하게 된다. 서버 엔진은 여러 게임에서 사용될 수 있는 공통의 기능을 제공하기 때문에, 구현하려는 콘텐츠에 따라서 1) 제공되는 기능이 정확히 입맛에 맞는 경우가 있을 수 있고, 경우에 따라서는 2) 서버 프로그래머가 엔진이 제공하는 공통 기능을 이용해 게임에 특화시킨 콘텐츠를 구현해야 될 수도 있고, 3) 필요한 기능이 아예 제공되지 않거나 아니면 구현하려는 콘텐츠와 맞지 않는다면 별도로 기능을 구현해야 될 수도 있다.

설치형 서버 엔진과 게임 콘텐츠 코드는 하나의 실행 파일로 묶여서 한 프로세스로 동작하게 되어 동작 속도가 빠르며, 이렇게 만들어진 게임 서버는 클라이언트와의 통신을 제외하고는 외부 통신을 거의 하지 않고, 모든 처리를 해당 클라우드 계정 혹은 해당 데이터 센터 안에서 끝낼 수 있기 때문에 서버를 보다 안전하게 관리할 수 있고, 클라와의 통신을 제외한 별도의 네트워크 트래픽에 따른 과금 역시 걱정하지 않아도 된다.

또한 유저데이터가 저장되는 디비 서버 역시 같은 클라우드 나 같은 데이터센터 안에 저장할 수 있고, 이에 따라 운영이나 사업상의 이유로 유저 디비를 접근해야 되는 경우 손쉽게 처리할 수 있다.

22-gbaas001

▲그림1: 설치형 서버 엔진의 동작 방식

위의 그림은 유저가 아이템을 사용하기 위해서 화면을 터치한 경우 발생하는 일들에 대한 예시이다. 이렇게 아이템 사용이 발생하는 경우 클라는 서버에 아이템 사용 요청을 전송하고, 게임 서버는 아이템 사용에 따른 효과를 적용하고 아이템을 인벤토리에서 삭제 한 후에 이 데이터를 디비에 저장한다. 그리고 아이템 효과에 따라 유저의 상태값이 바뀐 경우 이를 클라에게 전송해준다.

2. GBaaS 를 사용하는 경우
GBaaS 는 유저의 인벤토리, 게임 내 재화 등을 포함해서 유저데이터의 전체 혹은 일부를 GBaaS 상에 저장하고, 게임 서버가 이 데이터들에 접근할 수 있도록 REST API 를 제공한다. 그리고 매치메이킹처럼 공통적으로 많이 사용되는 게임 콘텐츠 기능들 중 일부도 GBaaS 상에 구현하고 이를 쓸 수 있도록 REST API 를 제공한다. REST API 는 쉽게 말해서 HTTP 를 이용해서 컴퓨터 간에 통신을 하게끔 구현한 것이라고 생각하면 된다. (우리가 웹 브라우저 주소창에 http:// 라고 쓰는 것도 HTTP 방식으로 사이트를 접근하겠다는 의미인데, HTTP 는 이렇게 사람이 볼 수 있게 웹사이트를 구축할 때도 쓰이지만, 컴퓨터끼리 통신을 할 때도 이용된다.) GBaaS 는 중요 유저 데이터가 GBaaS 상에 저장되고, 매치 메이킹이나 랭킹 같은 주요 기능이 아예 GBaaS 상에서 구현되어 제공되기 때문에, GBaaS 가 지원하는 기능에 잘 들어맞는 게임의 경우 정말 손쉽게 게임을 구현할 수 있다는 장점이 있다. 또한 GBaaS 사업자가 자기들 서버를 관리하기 때문에 유저 데이터 저장을 위한 DB 관리, 그리고 기능이 구현된 서버 관리를 별도로 하지 않아도 된다는 것도 큰 장점이 될 수 있다. 하지만, GBaaS 가 제공하지 않는 기능을 사용하는 콘텐츠는 아예 구현할 수 없게 되거나 혹은 직접 구현하고 싶으면 GBaaS 에 저장되는 데이터 외에 별도로 디비 서버를 만들어서 저장해야 된다는 문제점이 있다. 그리고 경우에 따라서는 별도의 디비 서버를 둔다고 하더라도 GBaaS 상에 저장되는 유저데이터를 같이 접근해야 되는 콘텐츠 구현은 굉장히 복잡해진다는 단점이 있다. 그 때문에 GBaaS 는 해당 기능에 잘 들어 맞는 양산형 게임에는 적합하지만, 실시간 대전이나 창의적인 게임 콘텐츠의 게임 구현에는 적합하지 않을 수 있다. 또한 중요 유저 데이터가 GBaaS 에 저장되기 때문에, 보안 때문에 유저 데이터 관리에 민감한 경우 곤란할 수 있고, GBaaS 사업자가 폐업하는 경우 게임을 내려야 되는 일이 발생할 수도 있다. 그리고 GBaaS 역시 클라우드 상에 존재하는 서버들이기 때문에, GBaaS 를 통해 유저 데이터를 접근하거나 매치메이킹 같은 기능을 호출해야 된다면 게임 서버가 매번 외부에 있는 GBaaS 서버들과 통신을 해야 됨을 의미한다. 이는 클라-서버 간의 트래픽에 따른 네트워크 비용 외에 서버-GBaaS 간의 트래픽에 따른 네트워크 비용의 발생을 의미하고, GBaaS 서버가 어떤 지역의 클라우드에 있느냐에 따라 높은 딜레이를 겪을 수도 있음을 의미한다. (게임 서버가 돌게 될 클라우드에 GBaaS 서버들을 추가하면 쉽게 해결될 수 있다고 생각할지도 모르겠지만, GBaaS 사업자 입장에서도 확장하려는 클라우드에 충분한 고객 (자사의 GBaaS 를 쓰는 게임들) 이 없는 경우 비용상의 문제로 쉽게 확장을 하지 못할 수도 있다) 이런 딜레이 문제 때문에 GBaaS 는 비동기 방식의 게임에 좀 더 적합하고 실시간 게임 지원에는 한계가 있을 수 밖에 없다.

23-gbaas002

▲그림2: GBaaS 를 사용하는 경우 동작 방식

위의 그림은 GBaaS 가 제공하는 유저 인벤토리 기능을 이용했을 때, 아이템을 사용하면 어떤 단계들을 밟게 되는지를 보여준다. 먼저 클라가 게임 서버에 아이템 사용 요청을 보내면, 서버는 GBaaS 가 제공하는 REST API 를 호출한다. 이 때, REST API 들은 공통 기능별로 작게 잘라서 제공되기 때문에, 인벤토리에서 아이템을 삭제하는 API 와 아이템의 효과에 따라 유저 데이터를 갱신하는 API 를 따로 호출해 줘야 된다. (GBaaS 가 특정 게임의 특정 아이템의 특성을 모두 대응해 줄 수 없기 때문에, 이처럼 “인벤토리에서 아이템을 소모한다”, “유저 데이터를 갱신한다” 등과 같이 작은 단위로 쪼개진 API 가 제공된다) 이렇게 API 를 호출하게 되면, GBaaS 는 요청대로 아이템을 인벤토리에서 지우는 작업과 유저 데이터를 지우는 작업을 수행하고 각각의 결과를 게임 서버에 반환한다. 게임 서버는 이 두 작업이 모두 성공적으로 수행되었다면 클라에게 변경된 유저 상태값을 전송해주게 된다. 앞에서 설명한 것처럼 이 경우에는 게임 서버가 GBaaS 의 API 를 호출하는 단순한 역할을 수행하고, API 를 호출할 때마다 GBaaS 와의 트래픽이 발생하고, GBaaS 상에 유저데이터가 저장됨을 알 수 있다. 만일 게임 서버가 GBaaS 에서 제공해주지 못하는 기능을 별도로 구현하고 있다면 이렇게 따로 게임 서버를 주는 것이 의미가 있겠지만 정말 모든 것을 GBaaS 에 의존하고 있다면 별도의 게임 서버를 제거할 수도 있을 것이다. 아래 그림은 게임 서버를 제거하고 게임 클라가 직접 GBaaS 에 접근하는 경우이다.

.
24-gbaas003

▲그림3: GBaaS 의 다른 예: GBaaS API 를 호출하는 게임 서버를 별도로 두지 않고 게임 클라가 직접 GBaaS 의 API 를 호출한다.

이렇게 바꾸더라도 아이템 사용에 따른 동작이 2개의 API 호출을 발생시킨다는 점에서는 변함이 없다. 그리고 이제는 GBaaS 에서 제공하는 것 외에 별도의 기능 구현은 아예 불가능하다. 정리하면, [GBaaS 의 장점] GBaaS 가 제공하는 기능 셋에 잘 들어맞는 게임이라면 정말 빨리 게임 서버를 만들 수 있다. 특히 별도의 서버 관리도 필요 없고, 기능이 GBaaS 를 통해서 제공되기 때문에 서버 프로그래머도 필요 없다. 만일 구현해야 되는 게임이 이 경우라면 질문의 여지 없이 GBaaS 는 최고의 선택이 될 수 있다. [GBaaS 의 단점] 1. 구현하려는 게임 콘텐츠가 제공되는 기능에 완전히 들어맞지 않는 경우, GBaaS 외에 별도로 게임 서버를 두고 구현해야 되는데, 이 작업이 그냥 게임 서버를 만드는 것보다 훨씬 어렵고 복잡할 수 있다. 2. 게임의 주요 데이터가 GBaaS 상에 저장됨으로 인해 유저데이터 관리 문제와 GBaaS 사업자 폐업으로 인한 서비스 중단 문제가 발생할 수 있다 3. 게임 서버가 매번 GBaaS 와 통신을 해야되기 때문에 게임 서버 비용 외에, 서버-GBaaS 간에 높은 네트워크 트래픽 비용이 발생하며, GBaaS 사용료도 별도로 발생한다. 4. GBaaS 와 게임이 서비스되는 지역 사이의 네트워크 딜레이에 따라 게임의 장르가 영향을 받을 수 있다. 특히 실시간 콘텐츠 구현은 GBaaS 에서 사실상 불가능하다.

아이펀팩토리 문대경 대표

답글 남기기

댓글을 게시하려면 다음의 방법 중 하나를 사용하여 로그인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중