텐센트 클라우드와 게임 인프라 아키텍처

 

 

 

 

1부. 실시간 온라인 게임의 특징과 요구사항 – 하

 

 

1. 개요

 

지난 ‘1. 실시간 온라인 게임의 특징과 요구사항 – 상’편에서는 게임을 장르별로 분류 해 보았습니다. 이번 하편에서는 패키지 게임들이 실시간 온라인 게임으로 변모하면서 어떤 데이터 특징을 가지는지, 또 어떤 아키텍처 요구사항들이 추가되는지 알아보겠습니다.

 

 

2. 실시간 온라인 게임의 기술적 요구사항

 

2.1 네트워크 전송 시간

 

게임 진행 상황에 따라, 게임 데이터들의 처리 중요도가 다릅니다. 어떤 데이터는 즉시 처리해야 하는 반면, 어떤 데이터는 처리하지 않아도 상관없습니다.
예를 들어, 다른 플레이어에게 즉시 전달해야 하는 데이터들은 다음과 같은 것들이 있습니다.

 

• 근거리 대전 상황
  내 시야 안에 들어와 있는 상대와 대전 중일 때, 공격, 회피, 기술, 힐, 아이템 장착, 아이템 사용 등, 모든 움직임은 즉시 처리되어야 합니다. 게임의 공정성을 유지하기 위해, 레이턴시를 고려해서 처리하기는 하지만, 그렇다고 완전히 공정한 게임을 보장할 수는 없습니다. 보통의 경우, 느린 레이턴시 사용자가 어느 정도 손해를 감수하도록 프로그래밍 합니다.

 

• 게임 내, 음성 채팅
  텍스트 채팅 메시지를 다른 플레이어에게 전달하는 것은 비교적 쉽습니다. 텍스트 채팅은 플레이어가 직접 키보드로 입력을 해야 하며, 데이터 발생 빈도는 낮고, 데이터 크기도 작으며, 전송에 필요한 시간은 짧습니다.
  반면에, 음성 채팅은 텍스트 채팅과는 아주 다른 특징을 가집니다. 음성 채팅은 플레이어가 목소리로 입력을 하기 때문에 입력에 필요한 시간은 짧고, 데이터 발생 빈도는 매우 빈번하며, 데이터 크기 또한 매우 큽니다. 전송에 필요한 시간도 상대적으로 많이 필요합니다. 음성 채팅이 제 시간에 다른 플레이어에게 전달되지 않으면, 게임의 흥미나 몰입도가 떨어집니다. 아키텍처 관점에서 볼 때, 텍스트 채팅에 비해 요구조건이 까다롭다고 할 수 있습니다.

 

 

2.2 데이터 영속성, 무결성

 

실시간 온라인 게임은, 수 많은 게이머가 동시에 게임에 참여하기 때문에, 여러 대의 서버를 사용하여 부하를 분산할 필요가 있습니다. 여러 대의 서버가 분산 처리를 하면서도, 동시에 여러 서버 사이에서 데이터는 무결성을 유지해야 하며, 저장하는 데이터는 영속성을 가져야 합니다.

 

• 게임 캐릭터 데이터
  가장 중요한 데이터 입니다. 가능하면 자주 백업해야 하고, 필요 시 즉시 복구할 수 있어야 합니다. 이 데이터를 잃어버린다면 게임 플레이어는 게임에 흥미를 잃고, 떠날 가능성이 큽니다. 아키텍처 관점에서 액세스 시간보다는 영속성이 중요한 데이터 입니다.

 

• 과금/결제 데이터
  이 데이터를 잃어버리거나, 일부 데이터에 오류가 생긴다면 게임 플레이어들로부터 거센 항의를 받을 것이 자명합니다. 아키텍처 관점에서 정합성과 무결성이 중요한 데이터 입니다.

 

• 로그 데이터
  로그 데이터는 일정 기간 안전하게 보관해야 하며, 효율적인 조회가 가능하도록 정형 또는 반정형 데이터로 보관할 필요가 있습니다. 아키텍처 관점에서, 로그는 분산 저장했다가 시스템 부하가 적을 때 통합하는 방식을 사용하기도 합니다.

 

 

2.3 빠른 액세스

 

• 클라이언트 다운로드
  게임 출시 초반에, 클라이언트 다운로드 속도는 충분히 빨라야 하고 많은 사용자의 다운로드 요청을 처리할 수 있어야 합니다. 게임 클라이언트 배포에는 CDN을 사용하는 것이 좋습니다.

 

• 게임 서버 사이의 세션 데이터 이동
  게임세계 속의 가상세계 사이를 옮겨 다닐 때, 세션 데이터의 이동이 필요합니다. 서버 사이의 세션 데이터의 이동은 IPC 통신보다 느릴 수 밖에 없는 것이 당연합니다만, 가능하면 소요시간을 최소화 할 필요가 있습니다. 세션 데이터를 빠르게 저장하고 조회하기 위해 cache 서버를 사용하기도 합니다.

 

 

2.4 보안

 

• 게임 데이터의 보호
  게임 서버 영역의 데이터들은 모두 다 중요한 데이터들입니다. 데이터 유출은 해커의 공격으로만 발생하지 않습니다. 내부자의 고의 또는 실수에 의해서도 정보유출 사고가 발생합니다. 내/외부의 위협으로부터 게임 데이터를 보호하려면 관리적/물리적/기술적인 관점에서 정보보호 수단을 마련하고 데이터를 보호해야 합니다.

 

 

 

3. 실시간 온라인 게임의 기술적 요구사항과 S/W 아키텍처

 

지금까지, 게임에는 여러 장르가 있고, 온라인 게임 및 실시간 게임들에는 특별한 데이터 처리 요구사항이 있다는 것을 살펴 봤습니다.
게임 데이터들이 가진 요구사항들을 게임 개발자는 어떻게 만족시킬 것인지, 게임 S/W 아키텍처에 대해 알아보겠습니다.

 

 

3.1. UDP 프로토콜

 

다수의 상용 게임들은 UDP 프로토콜을 기반으로 하고 있습니다. UDP 프로토콜은, 데이터를 빠르게 전송하는데 가장 적합합니다. TCP와 비교했을 때 UDP에는 전송제어나 오류제어가 없지만, 게임 개발사 입장에서는 전송제어와 오류제어를 직접 필요한 방식대로 구현할 수 있는 것이 오히려 장점입니다.

 

게임 데이터의 특성상, 전송에 실패해도 관계없는 데이터들도 있습니다. 대체로, 실시간 온라인 게임 데이터는 빠르게 전송하는 것이 중요하며, 데이터가 몇 개쯤 누락되어도 괜찮다는 정책을 가지고 있습니다. 이런 점은 비즈니스 데이터 전송 요구사항과는 극명한 대조를 이룹니다. 음성채팅 데이터 같은 경우, 데이터 전달 순서도 중요하기 때문에 FEC(Forward Error Correction)을 적극적으로 사용하는데, UDP를 사용해서 구현하는 것이 가장 적합합니다.

 

 

3.2. 비동기 이벤트 기반 처리

 

‘c10k 제약’이라는 오래된 이슈가 있습니다. 전통적인 web서버는 1개의 요청을 처리하기 위해, 1개의 thread를 생성하는 것이 기본 처리방식 이었습니다. 이 방식은 구현은 비교적 쉽지만, 다수의 연결(10k 이상)이 어렵다는 제약이 있는데, 이 제약을 해소하기 위한 방법 중에 하나가 비동기 이벤트 기반 처리 입니다. 게임 서버들은 web서버보다 c10k 문제를 훨씬 더 일찍 직면해야 했고, 많은 수의 연결뿐만 아니라, 많은 요청까지도 감당해야 했습니다.

 

이러한 제약은 게임 서버를 개발할 때, 비동기 이벤트 방식으로 개발하게 하는 이유가 되었고, Linux기반의 epoll이나, Windows에서 IOCP를 사용하게 되었습니다.

 

 

 

4. 실시간 온라인 게임의 기술적 요구사항과 시스템 아키텍처

 

데이터 처리의 요구사항 외에도, 여러 가지 시스템 요구사항들이 있습니다. 게임 데이터들이 가진 요구사항들을 시스템 엔지니어는 어떻게 만족시킬 것인지, 게임 시스템 아키텍처에 대해 알아보겠습니다.

 

 

4.1. 분산 처리

 

유한한 컴퓨팅 자원을 사용해서, 최대한 많은 게임 플레이어를 지원하려면 어떤 아키텍처를 사용해야 할 까요?

 

게임 아키텍처에서도 Divide and conquer 전략을 그대로 채택합니다. 게임 세계를 몇 개의 가상세계로 나눈 다음, 각 세계 별로 다른 서버를 배치하는 방법이 있고, 또는 전세계 글로벌 대륙 별로 다른 서버를 배치하는 방식을 사용합니다. 같은 지역의 서버라 하더라도, 다수의 서버를 분산 배치함으로써, 유저의 접속을 분산하고 트래픽이 집중되는 것을 막고, 과도한 시스템 부하를 예방합니다.

 

 

4.2. 분산 데이터베이스

 

RDBMS는 게임뿐만 아니라, 다른 많은 산업 군에서도 종종 병목 구간으로 작용합니다. RDBMS에서 발생하는 병목 현상을 해결하기 위해, 분산 데이터베이스를 적용하는 방법이 있습니다. 분산 데이터베이스를 사용함으로써 얻을 수 있는 이점은, 읽기 성능이 향상된다는 점 입니다. 읽기 작업은 data에 변경을 가하지 않으므로, 여러 DB 인스턴스가 동시에 수행할 수 있습니다. 분산 데이터베이스에서 ‘저장’ 또는 ‘업데이트’ 작업은, 데이터의 일관성 유지를 위해 하나의 DB 인스턴스에서만 수행해야 하며, 즉시 다른 DB로 복제 해야 합니다. 이런 특성은, ‘쓰기 작업’에 한해서는, 성능 향상을 기대하기 어렵게 합니다. 다른 접근 방법으로는, NoSQL을 사용하면서 데이터 일관성을 어플리케이션 레벨에서 해결하는 방법도 있습니다.

 

분산시스템의 한계에 관한 CAP이론과 PACELC 이론이 있습니다. 여기서는 보다 이해하기 쉬운 CAP이론을 소개하겠습니다.

 

CAP이론에 따르면, 분산 시스템은 일관성(Consistency), 가용성(Availability), 분할내성(Partition tolerance) 세 가지 특성 중에서, 동시에 두 가지 특성만 만족할 수 있습니다. 분산 시스템에서 세 가지 특성을 모두 가지는 CAP(Consistency-Availability-Partition tolerance) 시스템은 존재하지 않습니다.

 

특성	설명
일관성(Consistency)	모든 요청에 대해, 모든 분산노드가 가장 최신의 데이터(같은 데이터)를 응답한다.
가용성(Availability)	특정 노드에 장애가 발생해도, 시스템은 정상 응답한다.
분할내성(Partition tolerance)	시스템은 정상이지만 (네트워크 등의 문제로) 노드 사이의 통신이 불가능한 경우에도, 시스템은 정상 동작 한다.

 

분산 시스템은 네트워크 환경을 기본으로 하기 때문에, ‘분할내성’은 우리의 의지와 상관 없이 무조건 선택할 수 밖에 없습니다. 우리는 나머지 두 가지 특성 중에서 하나를 선택해야 합니다.

 

일관성(Consistency)을 선택하면 그 시스템은 ‘CP(Consistency-Partition tolerance) 특성을 가졌다’ 라고 말합니다. 가용성(Availability)을 선택하면, 그 시스템은 ‘AP(Availability-Partition tolerance) 특성을 가졌다’ 라고 말합니다.

 

NoSQL 제품들은 대체로 CP특성과 AP특성의 중간쯤을 가집니다. AP특성에 가까운 NoSQL 제품들은, ‘일관성을 다소 지킬 수 없는 순간이 존재할 수 있음’을 기본으로 인정합니다. 이것을 ‘궁극적일관성(Eventually Consistency)’이라고 부릅니다.

 

빠른 액세스가 필요하면서, 동시에 ‘일관성을 다소 지킬 수 없는 순간이 존재’하더라도 별로 상관 없는 경우라면, AP 특성의 NoSQL이 적합합니다. 예를 들어, 게임 서비스 중에서 랭킹 서버가 비슷한 사례가 될 수 있습니다.

 

여기서는 비교적 이해하기 쉬운 CAP 이론을 소개했습니다만, 분산시스템의 한계에 대해서 더 정확한 정리는, 이 문서 마지막에 있는 PACELC이론을 참고하는 것이 좋습니다.

 

 

4.3. Cache

 

실제 데이터 access 속도보다 더 빠른 읽기 성능이 요구된다면, cache를 사용합니다. cache는 실제로 여러 곳에서 매우 많이 사용하는 기술입니다. 여러 서버 사이에서 사용자 session 데이터를 공유하기 위해, NoSQL Redis를 cache로 사용하기도 합니다. 뒤에 설명할 CDN도 네트워크 cache중에 하나입니다.

 

읽기뿐만 아니라, 쓰기 성능 향상을 위해서도 cache를 사용합니다. RDBMS에서 읽기 성능 향상을 위해 index를 추가하면, 반대로 insert 시간은 더욱 증가하는 부작용이 있습니다. 이런 경우, DB 앞에 queue 기반의 write cache를 사용하는 것도 한 가지 해결방법이 될 수 있습니다.

 

수고하셨습니다. 이번 1부 하편에서는 패키지 게임들이 실시간 온라인 게임으로 변모하면서 어떤 데이터 특징을 가지는지, 또 어떤 아키텍처 요구사항들이 추가되는지 알아보았습니다.

 

다음 2부에서는 ‘실시간 온라인 게임 아키텍처’를 주제로, 게임 아키텍처에 구성에 관한 이야기를 이어 가겠습니다.

 

 

 

 

기술 블로그 내용 중에 궁금한 점이 있다면, 질문하기를 통해 문의 해 주세요.

 

 

 

 

참고링크

• • Tencent Cloud 문서 센터
  • PACELC이론 바로가기(영문)
  • 이 콘텐츠는 저작권법에 의해 보호받는 저작물로 메가존클라우드에 저작권이 있습니다.
  • 이 콘텐츠는 사전동의 없이 2차 가공 및 영리 목적으로의 이용을 금합니다.