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

10장 분산 서버 구조 사례

 

대표적인 몇 가지 기능과 관련해서 분산 서버 설계 유형을 살펴보고
게임 장르별로 분산 서버 설계 유형도 알아볼 것이다.

 

1. 로그온 처리의 분산

보통 로그온 처리는 다음과 같이 한다.

• 클라이언트는 서버에 ID와 비밀번호를 암호화해서 보낸다.
• 로그온 담당 서버(인증 서버)에서 이 메시지를 받고 복호화한다.
• 서버는 복호화된 메시지에서 ID와 비밀번호를 구하고 DB에 질의를 던진다.
• DB에서 질의를 수행한 후 응답을 서버에 회신한다.
• 서버는 이를 받아 로그인 성공 혹은 실패를 판단한다.
• 로그온 결과를 클라이언트에 보낸다.

 

로그온 처리 과정

 

로그온 처리를 하는 단일 서버는 인증 서버 한 대와 데이터베이스 1개로 구성되어 있다.

여기서 클라이언트가 늘어날 때마다 과부하가 발생하는 지점은 어디일까?

 

로그온 - 과부화 지점 파악

 

동시접속자가 많아지면 로그온 메시지를 복호화하는 연산이 증가하고 인증 서버의 CPU 사용량이 점점 과부하에 가까워진다. 자연스럽게 데이터베이스 서버도 질의 분석이나 읽기 액세스를 하는 데 시간이 걸려 과부하에 가까워진다.

 

이제 과부하 지점을 파악했으니 과부하 예상 지점을 수평 확장할 수 있는 방법을 찾아보자.

 

로그온 - 인증 서버 수평 확장

 

인증 서버를 데이터 단위로 분산하면, 위와 같이 같은 역할을 하는 인증 서버를 서버 기기 여러 대로 수평 확장하게 된다. 클라이언트는 인증 서버 주소 목록을 가지고 있으며 그중 랜덤으로 하나를 선택하여 접속한다. 만약 클라이언트가 서버 주소 목록을 가지고 있지 않을 경우, 클라이언트에서 들어오는 연결을 서로 다른 인증 서버에 분배해주는 역할을 하는 하드웨어를 그 사이에 두는 방법도 있다. 이를 로드 밸런서라고 한다.

 

2. 데이터베이스의 수평 확장

인증 서버는 부하가 분산되나 데이터베이스 서버에서는 여전히 과부하가 몰리고 있다. 이때 플레이어 간 상호 작용이 없다면 데이터베이스의 수평 확장은 쉽다. 플레이어 정보를 서로 다른 데이터베이스 샤드에 골고루 나누어 저장하면 된다.

 

로그온 - 데이터베이스 수평 확장

 

• 클라이언트는 여러 서버 중 하나를 무작위로 골라서 로그온 요청을 한다.
• 서버는 로그온 요청을 받으면 입력받은 ID를 해시 함수에 넣어서 샤드 인덱스를 구한다.
• 서버는 해당하는 데이터베이스 샤드에 질의를 던져서 나머지를 실행한다.

 

이렇게 만든 서버를 운영하다 더 많은 서버가 필요할 때가 생길 것이다. 이때는 인증 서버와 데이터베이스 샤드 개수를 늘리면 된다. 인증 서버는 단순하게 늘리면 되지만, 데이터베이스는 조금 다르다.

 

샤드를 추가하면 그전의 샤드 인덱스와 다른 값이 될 수가 있기 때문이다. 해시 테이블 알고리즘에서는 항목 개수가 달라지면 기존에 있던 모든 데이터에서 항목 재배치를 한다. 이를 리해시라 하며 마찬가지로 데이터베이스 샤드가 추가되면 기존 레코드를 리해시해 주어야 한다.

 

그러나 데이터베이스 샤드 개수가 10억 개 정도로 매우 많다면 이는 심각한 문제가 될 것이다. 이를 위해 크게 세 가지 방법이 있다.

• 일관된 해시 알고리즘: 이동하는 레코드 개수가 최소가 되는 알고리즘을 사용한다.

일관된 해시 알고리즘

• 매핑 DB: 이동할 일이 없게 만든다.

매핑 DB

• 매핑 DB 확장: 이동하더라도 이동하는 레코드 크기를 최소로 만든다.

매핑 DB 확장

 

3. 매치메이킹의 분산 처리

멀티플레이 게임에서는 서로 다른 플레이어 간 대전이나 협력 플레이를 위해 다른 플레이어들을 찾아 모은다. 이를 매치메이킹이라고 하며 이러한 일을 담당하는 서버를 로비 서버라고 한다.

 

매치메이킹 사용자 시나리오

 

만약 로비 서버와 게임방 안에서 전투를 담당하는 서버(배틀 서버)가 분리되어 있지 않다면, 동시접속자가 늘어날 때 당연히 과부하가 올 수밖에 없다. 성능을 분석해 보면 게임방 안 전투 플레이를 처리하는 곳이 큰 비중을 차지하므로 게임방 처리를 분산하는 것이 우선이다.

 

매치메이킹 처리 - 배틀 서버 분산

 

한 게임방 안에서 플레이어들은 잦은 상호 작용을 하므로 응집도가 높다. 서로 다른 방에 있는 플레이어끼리는 응집도가 낮다. 따라서 배틀 서버를 응집도가 높은 서버끼리 분산시켜야 한다.

 

매치메이킹 - 배틀 서버 분산 후 네트워크 시퀀스

 

이렇게 함으로써 동시접속자가 증가하는 상황에 어느 정도 대응할 수 있다. 하지만 배틀 서버 개수만 늘리는 것으로는 완전하지 않다. 매치메이킹만 담당하는 로비 서버는 한 대뿐이므로 동시접속자가 계속 증가하면 결국 로비 서버도 과부하에 걸릴 것이다.

 

로비 서버가 여러 대로 나뉘어 있다면 플레이어 목록에 어떻게 액세스해야 할까? ​앞서 알아본 서버 간 상호 작용을 구현하는 방식 세 가지 중 하나를 살펴보자.

• 동기 분산 처리: 서버 간 통신 횟수가 너무 많으므로 패스
• 비동기 분산 처리: 서로 응답을 하지 못하므로 패스
• 데이터 복제에 기반을 둔 로컬 처리: 당첨

 

플레이어 목록을 로비 서버 간 복제하지 않고, 플레이어 목록을 한 군데 별도 서버(메모리 저장소)에 보관하는 방법도 있다. 이 방식은 로비 서버 안에 연산량이 많을 때 효과적이다.