클라우드 컨설팅 모험기 part.3 - 모바일 게임의 클라우드화

요즘들어 모바일 게임업체에서 클라우드 컴퓨팅 환경으로 이전 또는 신규 구축 의뢰가 많이 들어오고 있다.

이유는 다음과 같다.

1. 모바일 게임의 수명이 너무 짧아 1년이상 약정은 리스크가 너무 크다.
2. 모바일 게임의 유저수를 책정할 수 없어 스타트 규모를 산정할 수 없다.
3. Latency에 크게 구애받지 않기 때문에 다소 느려도 상관없다.

이러한 이유가 클라우드 인프라를 활용하기에 최적의 니즈가 되고있다.
모바일 게임업체인 A사에서 자신들이 만든 게임서버의 구조를 보여주며 클라우드 환경으로의 이전을 검토해달라고 하였다.

아무리 클라우드 환경으로 이전한다 하더라도 게임인 이상 타 서비스와 영향을 받지 않는 것이 좋기 때문에 Hybrid cloud 의 형태로 제안을 했다.
Hot standby가 불가능한 서버에 대해서는 물리서버 또는 독립가상화 서버를 제안하고, 죽어도 유저의 게임서비스에 문제가 없는 서버를 Public Cloud로, 그리고 이 둘을 VPC로 묶어 로컬 환경과 같은 형태로 제안을 하였다.

그리고 유저가 늘어날때 같이 늘어나야 하는 서버들을 산정하여 Auto Scaling으로 제안을 하였고, 폭발적으로 늘기 쉬운 특성을 감안하여 초기 구조를 Sharding(샤딩, 수평분산구조)으로 변경할 것을 권고하였다.

대부분의 게임이 그러하듯이, 메인 유저DB가 있고, 월드DB가 있어 여러대의 채널서버에서 월드DB에 붙어 유저의 정보를 액세스 한다.
이것은 수십만 유저까지는 커버하는데 전혀 지장이 없지만, 수백만에서 수천만에 달하는 유저를 커버하기에는 역부족이 된다.
이 때 로그성 데이터는 MongDB쪽으로 권하기도 하지만, 개발리소스의 큰 변화를 주지 않도록 하기 위해서는 한 유저당 하루에 쌓을 수 있는 데이터량을 감안하여 수평분산이 가능하도록 Node Server를 별도로 두고 서버를 쉽게 분리 통합이 가능한 구조로 제안을 하였다.

이렇게 하면 100만명 단위로 게임서버 + DB서버를 하나의 물리서버에 가상화를 시켜 유저가 100만명씩 늘어날 때마다 Auto Scaling으로 또는 수동으로 서버가 확장되도록 설계를 하였다.
이렇게 하다가 보면 모바일 게임의 특성상 초기 유저가 빨리 빠져나가는 경향이 있기 때문에 초기 초기 1,2 번 서버를 통합시켜 200만명의 유저데이터를 보관할 수 있도록 하여 지속적인 통합, 신규가 쉽도록 구성을 하게 하였다.

일반적인 SIer로서는 납득이 안가는 비효율적인 Sharding구조지만, Mobile Game에서는 적은 노력으로 최고의 효과를 볼 수 있고, 클라우드 컴퓨팅 환경에서 더욱 빛을 발휘할 수 있게 된다.

앞에 L4가 없어도 되는 구조가 되어 초기 비용도 줄일 수 있다는 장점을 가지고 있고, 유저의 이탈에 빠른 통합으로 서버 유지비용을 절약할 수 있다.
그리고 유저가 언제든 다시들어와 유저가 늘어나게 되어도 자유롭게 확장할 수 있다.

모바일 게임덕분에 비효율적인 구조가 트렌드가 된 듯 하다.
 DB에서 비정규화의 느낌이랄까..