[Book] 게임 서버 프로그래밍 교과서 - 9장 분산 서버 구조 (1)

9장 분산 서버 구조

 

서버 클러스터, 수직 확장, 수평 확장, 샤드, 로드 밸런싱, 고가용성 등 이러한 용어들이 사용되는 분야가 바로 분산 서버이다. 게임 서버뿐만 아니라 서버 개발에서 반드시 다루는 주제로 어떻게 설계를 하느냐에 따라 게임 서비스가 안정적으로 작동할 수도 있고 심각한 문제가 발생할 수도 있다.

 

1. 수직 확장과 수평 확장

게임 서버에 품질을 논할 때 나오는 것 중 하나로, 확장성이란 사용자 수가 늘어나더라도 쉽게 대응할 수 있어야 한다는 의미이다. 최대로 처리할 수 있는 사용자 수가 무제한이어도 가능해야 한다는 것이 목표이다.

 

사용자 수가 늘어나도 서버 성능을 유지하려면 보통 다음 두 가지 중 하나를 수행한다.

 

수직 확장과 수평 확장

 

• 스케일 업 = 수직 학장: 서버의 하드웨어를 더 좋은 것으로 교체하여 처리량을 늘리는 것을 의미한다.
• 스케일 아웃 = 수평 학장: 서버 대수를 늘려서 더 많은 처리를 하는 것을 의미한다.

 

수직 확장과 수평 확장의 비교

 

일반적으로 수평 확장이 더 현실적인 방법이다. 수직 확장은 쉽게 할 수는 있지만 하드웨어의 사양이 결국 한계가 있다. 그러나 수평 확장은 설계는 복잡하지만 하드웨어 기기의 대수를 늘리기만 하면 되므로 상한선이 거의 없다.

 

2. 서버 분산이 없다면?

분산 처리를 하지 않는 서버는 모든 게임 서버의 로직을 하나의 서버 프로세스에서 수행한다. 그리고 모든 플레이어 정보는 데이터베이스 하나에 저장한다. 이때 이 게임 서버에 동시 접속자가 증가하기 시작하고 결국 동시 접속자 수가 무제한으로 증가하기 시작했다. 과연 어떤 현상이 발생할까?

 

주로 발생하는 현상은 다음과 같다.

• 서버로 보낸 메시지에 대한 처리 응답이 늦게 도착한다.
• 서버 접속 과정이 매우 오래 걸린다.
• 서버와 연결이 돌발 해제된다.

 

서버에서는 다음 현상이 발생한다.

• CPU 사용량이 증가한다.
• 클라이언트에서 메시지를 받는 속도보다 메시지를 처리하는 속도가 느리다.
• 클라이언트에 보낼 메시지의 발생 속도보다 실제로 메시지를 보내는 속도가 느리다.
• CPU 과부하는 램 사용량 증가로 이어진다.

 

서버에서 시간이 지남에 따라 발생하는 현상

 

3. 고전적인 서버 분산 방법

1990년대 중반부터 이미 분산 게임 서버는 실현되고 있었다. 사실 생각해 보면 매우 간단한 방식이다. 게임 서버와 데이터베이스로 구성된 세트를 쭉 나열하는 것만으로도 해결된다.

 

분산 게임 서버 방식

 

위 서버 클러스터(서버의 집합)는 인증 서버 한 대, 채널 서버 네 대로 구성되어 있다.

• 인증 서버
  • 사용자가 ID와 비밀번호를 입력했을 때 그것을 인증 처리하는 역할을 한다.
  • 사용자 인증을 위한 데이터베이스와 인증을 처리하는 로직 서버로 구성되며 사용자 인증 외에 아무 일도 하지 않는다.
  • 보통은 하는 일이 적어 굳이 수평 확장을 하지 않아도 된다.
• 채널 서버
  • 각 게임 채널 서버는 게임 서버 한 대와 데이터베이스 하나로 구성된다.
  • 게임 채널 서버와 인증 서버는 필요하면 서로 데이터를 주고받는다.
• 방화벽
  • 해커에게서 서버 클러스터를 보호한다.

 

이러한 형태로 서버 클러스터가 구성된 후 게임 클라이언트와 서버는 다음과 같이 상호 작용을 한다.

• 게임 클라이언트는 인증 서버에 접속한 후 ID와 비밀번호로 로그인 처리를 한다.
• 로그인에 성공한 게임 클라이언트에서 게임 사용자는 게임 플레이를 할 수 있는 채널 서버를 선택한다. (보통 국가적, 문화적 차이가 있어 서로 다른 서버로 분리된다.)
•  게임 클라이언트는 사용자가 선택한 채널 서버에 접속하여 게임 플레이를 시작한다.

 

지금까지 알아본 간단한 분산 서버 구성은 즉시 할 수 있다는 장점이 있지만, 몇 가지 문제점도 있다.

• 같은 계정이라도 플레이어 정보가 서로 다른 채널에 있다면, 그 캐릭터는 다른 채널에서 사용할 수 없다.
• 플레이어는 자기가 플레이했던 채널 서버에서만 계속 게임을 해야 한다.
• 게임 플레이를 하는 동안 채널 서버를 선택하는 과정이 없다면, 플레이어 입장에서 채널 서버는 하나만 있는 것처럼 보여야 한다. 따라서 논리적으로는 단일 서버이지만 실제로는 서버 클러스터인 형태를 개발할 필요도 있다.

 

4. 논리적 단일 서버 분산

게임 서버를 분산하면 어떤 모양이 되어야 한다는 규정은 딱히 없다. 게임 장르도 다양하고 같은 장르의 게임이라도 게임 플레이를 어떻게 기획했느냐에 따라 분산 서버 구성이 달라지기도 하기 때문이다. 하지만 이 책에서는 다음과 같이 분산 절차를 규정할 것이다. 단일 서버 기준에서 과부하가 걸리는 지점을 분석한 후 과부하가 걸리는 지점을 분산 처리 방식으로 분산한다.

 

다행히 게임의 이상적인 분산 서버 구조는 어느 정도 비슷하다. 분산 서버 구조를 어떻게 해야 할지 잘 모를 때는 몇 가지 대표적인 분산 서버 구조를 참고하면 된다. (10장)

 

먼저 과부하가 걸리는 지점을 분석해서 파악해보자.

 

논리적 & 물리적 단일 서버

 

여기 논리적으로도 물리적으로도 단일한 서버가 있다. 그리고 다음과 같은 최대 처리량을 가졌다고 가정한다.

• 라우터, 스위치: 1GB/초
• 방화벽: 500MB/초
• CPU: 4 코어 * 3 GHz
• 스토리지: 100MB/초(SSD), 10MB/초(HDD)

 

여기서 "처음부터 분산 서버를 개발하면 되지 굳이 단일 게임 서버를 만들어서 이렇게 성능 분석을 해야 하나" 이러한 의문이 들 것이다. 단일 게임 서버 개발은 분산 게임 서버 개발보다 훨씬 쉽다. 따라서 처음에는 단일 게임 서버로 개발한 후 분산 처리를 해야 되는 지점만 분산 처리하도록 추가 개발하는 것이 더 경제적이다.

 

동시 접속자가 증가하면서 네 가지 최대 성능은 점점 한계에 가까워지고 있다. 네 가지 중 하나가 한계에 부딪힐 때 바로 우리가 분산 처리를 해야 하는 지점이 된다. 이때 네 가지 자원의 한계를 모두 해결하고 싶을 것이지만, 처음부터 그렇게까지 할 필요는 없다.

 

위험 수위

 

단일 게임 서버에서 CPU 사용량이 절정에 이르렀다. 성능 과부하 지점을 알아냈지만 더 자세한 성능 분석이 필요하다. CPU 사용량이 높은 경우 CPU 안에서도 어느 부분이 사용량이 높은지 따로 체크할 필요가 있다. 이때 코드 프로파일이나 성능 분석 도구를 사용하면 된다.

 

VS의 코드 프로파일러

 

성능 분석 도구를 사용해서 어떤 함수가 가장 많은 처리량을 차지하는지 확인했다면, 일단 코드 최적화를 한다. 가끔은 분산 처리를 하기 전 코드 최적화를 하면서 문제가 쉽게 해결되기도 하기 때문이다.

 

이렇게 해서 서버의 과부하 지점을 찾았으면, 이제 두 조합의 분산 처리 유형에 따라 분산 처리를 할 것이다.

• 분산 단위
  • 데이터 단위 분산
  • 기능 단위 분산
• 게임 로직의 분산 처리 방식
  • 동기 분산 처리
  • 비동기 분산 처리
  • 데이터 복제 및 로컬 처리