비동기 (Async)
네트워크에서 세션을 유지하기 어려운 모바일 환경 등에서 사용하는 방법으로 “보장된 데이터를 사용” 하여 게임 환경을 구축하는 경우이다. 대표적으로 “크래시 오브 클랜”과 같은 게임들이 AP 설계에 기반한다.
- 느리지만, 손실 허용이 안되는 TCP 프로토콜을 사용.
- 이벤트만 서버로 전송하고, 서버는 이벤트를 검증하고 그 결과를 DB에 저장.
- 게임 플레이어 외에는 다른 플레이어의 접속 여부와 관계없이 게임 진행 가능.
⇒ 이론적으로 확장이 무한
채팅 서버와 온라인 게임 서버의 유사점과 차이점
유사점
- 사용자의 입력을 전체 사용자에게 브로드캐스팅한다.
- 사용자의 세션을 관리한다.
- 채널(또는 서버) 별로 다른 상태를 가진다.
- 채널을 선택하거나, 내 아바타를 커스텀 하거나, 친구 목록을 보는 등의 로비가 있다.
차이점
- 채팅에서는 사용자를 그래픽으로 표현하지 X
- 채팅에서는 사용자의 상태를 그래픽으로 표현 X
- 게임은 승과 패, 성공과 실패가 그래픽으로 표현되지만, 채팅은 부모님 안부 묻는 걸로 표현
- 채팅은 데이터 량이 작으므로 접속이 끊겨서 새로 접속하면 채널의 모든 정보를 줄 수도 있다.
- 채팅은 낮은 Latency를 고려하지 않지만, 게임 서버는 경우에 따라 고려(클라이언트 예측과 서버 보정을 한다) 한다.
온라인 게임 회사의 네트워크 구성 진화
작은 규모의 경우 서버 1대로 DB까지 구성했지만, 꽤 오래전부터 제대로 된 서비스는 DB 만큼은 분리하였다.
네트워크 시스템에서의 가장 큰 적은 병목(Bottleneck) 현상이다. 다른 서버는 노는데 어느 한 서버는 과부하가 걸려서 전체 시스템의 성능이 떨어지는 현상을 말한다. 이 때문에 DB 서버를 분리하였습니다만, 사용자의 로그인이 많은 시스템의 경우 로그인 서버만 따로 분리하기도 한다. 로그인 서버에서 생성한 인증, 사용자 정보 등의 세션을 가지고 게임 서버로 접속하는 방식을 사용했다.
이후에 개발자들은 채팅량이 많아짐에 따라 게임 서버에서 분리하기 시작.
업데이트가 빈번해지자 게임서버에서 별도의 패치서버를 분리하였다.
이후로 게임 서버의 증설이 필요하다는 걸 알게 됨. 서버와 서버의 동기화는 대단히 많은 동기화 시간을 필요로 하기 때문에 게임 서버를 월드 (또는 그냥 북미 서버, 아시아 서버, 샤드 등) 단위로 확장하면서, 노는 서버에게 트래픽을 더 몰아주거나 서버가 장애가 발생하였을 때 전체 시스템 마비를 막기 위한 장비가 필요하게 된다.
이제 해킹이 막 들어온다. 방화벽을 설치하여 적극적으로 차단하기로 했다.
이쯤 되자 사용자의 폭증으로 DB가 혼자 못 버티는 상황이 된다. 그래서 DB 클러스터(NoSQL과 같은 분산 DB 또는 Active-Active 모드의 Replication DB)를 적용하기로 했다.
이제 문제는 더 심각해진다. 분산 DB를 구성한다는 건, 저장소(Disk)를 공유하거나, DB 서버간 데이터를 항상 동기화해야 하는 문제가 생긴다. DB의 잦은 사용을 대신해 줄 수 있는 무언가가 필요하게 됐다. 그래서 등장한 솔루션이 메모리 캐쉬 서버이다. (Redis, Memcached)
이번에는 로그인 서버에도 과부하가 걸린다. 그래서 캐시 서버를 적용.
이번에는 채팅 서버와 게임 서버 등 서버 간의 통신이 소실되는 경우가 생긴다. 한쪽 서버가 과부하가 걸려서 못 받는 경우 또는 사용자에게 전체 메시지를 보내야 하는 경우 등을 위해 Message Queue (RabbitMQ)를 적용.
