분산 서버 설계는 원리 이해가 중요하다. 이를 모르고서는 잘못된 설계로 인해 고생은 고생대로 하고 결과는 결과대로 나쁠 수 있다. 본 강연에서는 분산 게임 서버 구조를 짜기 전에 반드시 이해해야 하는 원리를 설명한다.

1. 분산 게임 서버 구조론
넷텐션
배현직

2. 알아야 할 용어

3. 1400
1200
1000
800
600
400
200
0
5000 10000 15000 20000
플레이어당 처리 시간
동시접속자
성능만 좋음 확장성만 좋음
서버의 성능? 확장성?
• 서버의 성능과 확장성은 서로 별개
사업계획서 Part 2 page 1

4. 확장성을 위한 방법

5. Scale-up vs. scale-out
Scale-up (수직적 확장) Scale-out (수평적 확장)
확장의 종류 서버 머신의 부품을 업그레이드 혹은
서버 머신 안의 CPU, RAM을 증설
서버 머신의 수를 증설
서버 소프트웨어 설계 비용 낮음 높음
확장 비용 높음(기하급수적으로 높아짐) 낮음(선형적으로 높아짐)
과부하 지점 서버 컴퓨터 자체 네트워크 장치
오류 가능성 낮음(로컬 머신 내에서 동기 프로그래밍 방식으로
작동하므로)
높음(여러 머신에 걸쳐 비동기 프로그래밍 방식으로
작동하므로)
단위 처리 속도 높음(로컬 컴퓨터의 CPU와 RAM만을 사용) 낮음(여러 서버 컴퓨터간의 메시징이 오가면서 처리
하므로)
처리 가능 총량 낮음(서버 컴퓨터 1개의 성능만을 사용하므로) 높음(여러 서버 컴퓨터로 부하가 분산되므로)

6. 서버 분산이 없다면?

7. 전혀 분산되어 있지 않은 서버
• 모든 게임서버 로직은 1개의 서버 프로세스에서 수행
• 모든 플레이어 정보는 1개의 데이터베이스에 저장
Client Server Databas
e

8. 동시접속자가 무제한으로 증가할 경우 발생하는 현상
(클라이언트)
• 서버로 보낸 메시지에 대한 처리 응답이 늦게 도착함
• 서버로의 접속 과정이 매우 오래 걸림
• 서버와의 연결이 돌발 해제됨
– TCP retransmission timeout으로 인해
– 사용자 정의 keep alive 메시징의 타임아웃으로 인해
• 서버로의 접속 자체가 실패함 (타임아웃)

9. 서버에서의 현상
• CPU 사용량이 증가
• 클라이언트로부터 메시지를 받는 속도보다 메
시지를 처리하는 속도가 느린 경우 RAM 사용
량이 증가
• 클라이언트에게 보낼 메시지의 발생 속도보다
실제로 메시지를 보내는 속도가 느린 경우
RAM 사용량이 증가
• 즉, CPU의 과부하는 RAM 사용량 증가로 이어
짐
45
40
35
30
25
20
15
10
5
0
Chart Title
시간 1 시간 2 시간 3 시간 4
메시지 수신
메시지 처리
메모리 사용량

10. • x86의 경우: RAM의 사용량이 계속해서 증가하다가,
2~3GB 프로세스 메모리 사용 상황에서 malloc()
returns null이 발생
• x64의 경우: 서버 물리적 메모리보다 더 많은 양의
메모리를 할당하게 되면서 대량의 memory
swapping이 발생함. 이로 인해 프로그램 실행 속도
가 급락하면서 메모리 할당량이 더욱 증가하는 악순
환 발생
• Disk의 최대 처리속도를 상회하는 Disk I/O를 요구
하는 명령(DB query)이 데이터베이스에 쌓이면서
RAM 사용량이 증가하다가 상기와 같은 문제가 데이
터베이스에서도 발생
• 게임 컨텐츠의 구성에 따라 다르나, MMORPG의 경
우 동시접속자 2만명이 넘어가면 이러한 문제가 쉽
게 발생
int* a = malloc(1000);
// access violation if a is null
a[0] = 1;
// throws bad_alloc if no more memory
MyClass* b = new MyClass();

11. 네트웍 장치에 과부하가 걸리면
• 원래, 무선 네트워크나 개발도상국의 클라이언
트 쪽에서 발생하는 현상
• 클라우드 서버의 가상 라우터 소프트웨어의 과
부하로도 발생함 
• 라우터 과부하로 인해, packet drop 발생
• TCP retransmission timeout으로 인한 TCP
disconnection 발생

12. 서버 분산 방법

13. 간단한 서버 분산 방법
• 게임 서버와 데이터베이스로 구성
된 세트(서버 채널이라고도 부름)
를 쭈욱 나열하는 것만으로도 간
단히 해결됨
• 계정 인증 부분은 게임 퍼블리셔
에서 알아서 대규모 처리를 할 수
있게 해놓았으므로 문제를 회피함
• 게임 서비스는 국가별로 다름
– 따라서 계정 인증 담당 서버와 장치들
도 전세계 여러 곳으로 나뉨
– 따라서 유저 밀집으로 인한 과부하를
회피 가능
Server Databas
e
Client
Auth
Database
Switch,
Firewall router
Server Databas
Server Databas
e
e
Server Databas
e
Auth
Server

14. • 이 방식의 문제점
– 같은 계정이라도 플레이어 정보가 서로 다른
서버 채널에 다르게 존재함.
– 즉 플레이어는 자기 캐릭터 등의 정보를 알기
위해 자신이 플레이했던 서버 채널을 알고 있
어야 함
• 모바일 게임과 글로벌 서비스 게임에서
는 이러한 서버 채널이 없어지는 것이 추
세
• 논리적 단일 서버의 필요성 대두

15. 논리적 단일 서버를 분산하기

16. 서버의 각 부하 지점
• 서버의 각 지점의 최대 처리량 예시
– Router, switch : 1GB/sec
– Firewall: 500MB/sec
– CPU: 4 core * 3GHz
– Storage: 100MB/sec (SSD), 10MB/sec (HDD)
• 동시접속자가 증가하면서, 위 4가지 자원의 사용량은 한계에 점점 가까워짐
– 한계에 빨리 부딪히는 것을 우선으로 해결해야 함
– 4가지 자원의 한계를 모두 해결하는 것이 궁극적인 해결책이지만, 통상 온라인 게임의 경우
2가지 정도만 해결해도 충분하기도 함
Server Databas
e
Client Switch,
router
Firewal
l

17. 서버의 과부하 지점을 찾는 방법
• 서버의 과부하 지점을 찾는 현실적인(그러나 비경제적인) 방법
– Scale-out을 전혀 고려하지 않은 서버를 먼저 개발한 다음,
– 동시접속자를 증가시키면서 부하 지점의 처리량을 측정하기
• 측정하기 위해, code profiler와 DB query profiler 등을 사용
– 접속자가 늘어날수록 부하가 가파르게 증가하는 요소를 찾아, 해당 요소를 scale out으로 재개
발을 한다.
• 서버의 과부하 지점에 대한 경험이 있을 경우 미리 scale out으로 개발하면 더욱
경제적
• 서버의 과부하 지점의 예
– 몬스터가 많이 등장하는 필드
– 플레이어가 많이 몰리는 광장
– NPC의 AI 처리(path finding)

18. 이렇게 해서 서버의 과부하 지점을 찾은 후에
는 어떻게 분산할 것인가?

19. 데이터 분산 vs. 기능적 분산
• 데이터 분산
– 한 머신이 처리해야 하는 데이
터를 동일한 역할을 하는 여러
머신들이 나누어서 처리
– 시계 공장에 비유하자면, 각 제
작자가 부품 조립, 도색, 포장을
모두 수행하되 이러한 사람들이
다수 포진 재료
부품 조립,도색,포
장
부품 조립,도색,포
장
부품 조립,도색,포
장
부품 조립,도색,포
장
상품

20. • 기능적 분산
– 한 머신이 처리해야 하는 데이터
의 처리 단계를 세분화해서 여러
머신들이 나누어서 처리
– 시계 공장에 비유하자면, 제작의
각 단계를 서로 다른 사람이 수행
• 데이터 분산과 기능적 분산을
혼용하는 것도 가능
부
품
조
립
도
색
포
장
재료 상품

21. 분산된 서버에서의 게임 로직

22. 상호작용 시나리오 예시
• 플레이어 캐릭터가 몬스터 캐릭터를 죽이고, 아
이템을 획득하기
– 플레이어가 가진 총알 1개를 소모
– 몬스터의 체력을 깎음
– 몬스터의 체력이 바닥나면
– 몬스터 사망(10초후 소멸)
– 플레이어는 아이템 획득
• 단일 서버라면 이러한 상호작용은 우측과 같이
구현될 수 있음
• 상호작용의 두 개체(player, monster)는 같은
메모리 공간 즉 서버 프로세스 안에 존재할 때
실행 가능함
Player_Attack(player, monster)
{
player.bullet--;
monster.hitPoint-=10;
if(monster.hitPoint<0)
{
player.item.Add(gold, 30);
DeleteEntity(monster, 10sec);
}
}
서버1
Player
Monster
서버2

23. • 만약 player, monster가 서로 다른 서버 프
로세스에 분산되어 있는데 이들간의 상호작
용을 반드시 해야 할 경우 어떻게 해야 할
까?
• 3가지 방법이 존재함
– 동기 분산 처리
– 비동기 분산 처리
– 데이터 복제(replication)에 기반한 로컬 처리
서버1
Player
서버2
Monster

24. 동기 분산 처리
• 어떠한 연산을 다른 서버에 던져
놓고, 그 결과가 올 때까지 대기
를 하고 있음
– 대기할 뿐만 아니라, 그 연산과 관
계된 데이터가 도중에 변경되지 않
도록 lock을 하고 있어야 함
• 단위 처리의 시간이 길어지는만
큼 lock 영역이 발생시키는 처리
성능 병목 문제도 발생함
Player_Attack(player, monster)
{
lock(player)
{
player.bullet--;
e = otherServer.DamageCharacter(
player.id, monster.id, 10);
waitForResult(e);
if (e.hitPoint < 0)
{
player.item.Add(gold, 30);
}
}
3.응답 1.요청
2.대기 발생!
DamageCharacter(attacker, character, damage)
{
character.hitPoint-=damage;
result.hitPoint = character.hitPoint;
Reply(result);
}

25. 처리성능 병목 문제의 심각성
• 암달의 법칙
– 병렬 처리할 수 있는 장치에서,
병렬로 처리하지 못하는 시간에
크게 비례해서 병렬 효과가 급감
하는 현상
– 암달의 저주라고도 부름
• 따라서 동기 분산 처리의 잘못
된 사용은 분산 서버의 효과를
떨어뜨릴 수 있음
병렬로 처리하지 못하는 시간(붉은색)의 비
중이 클수록 병렬 처리 효과는 크게 감소함

26. 비동기 분산 처리
• 어떠한 연산을 다른 서버에 던져
놓고 그 결과를 기다리지 않고
일방적으로 다음 처리를 수행
• 단위 처리의 시간이 길어지는 만
큼 병목 문제가 발생하는 일은
없음
• 그러나, 로직의 구현에 한계가
발생함
– 리턴값 없는 함수만으로 로직을 구
현하는 것과 유사함
– 리턴값을 반드시 받아야 다음 진행
이 가능한 로직을 구현할 때 한계에
부딪힘
Player_Attack(player, monster)
{
player.bullet--;
otherServer.DamageCharacter(player.id, monster.id, 10);
}
메시징
DamageCharacter(callerServer, attacker, character, damage)
{
character.hitPoint-=damage;
if(character.hitPoint<0)
{
callerServer.GiveItem(attacker.id, gold, 30);
DeleteEntity(character, 10sec);
}
}
메시징
GiveItem(character, item, amount)
{
character.item.Add(item, amount);
}

27. 비동기 분산 처리, 동기 분산 처리의 단점
• 비동기 분산 처리, 동기 분산 처리 모두 어떠한
연산이 여러 서버에 걸쳐 처리되기 때문에, 그
과정에서 머신간 송수신 과정이 들어가게 됨
• 네트웍으로 메시지를 보내는 데 걸리는 CPU
연산량과 network device I/O 처리에 걸리는
연산량은 수만 clock cycle을 소모
• Switch를 거치는 동안에도 딜레이가 밀리초
단위로 발생
• TCP를 통해 전송하는 경우 nagle algorithm에
의해 밀리초 단위의 시간이 소모됨
• 즉 지나치게 분산 처리 단계가 많을수록 배보
다 배꼽이 큰 사태가 발생
Socket IO call
OS File Plexer
OS layer
Network
device driver
Device I/O
Switch
Router
Socket IO call
OS File Plexer
OS layer
Network
device driver
Device I/O

28. 데이터 replication에 기반한 로컬
처리
• 각 서버 프로세스는 데이터들이 변할 때마다 다른 서버
들에게도 그 변화를 나머지 서버들에게 지속적으로 전
송(replicate)
• 따라서 각 서버 프로세스는 데이터 사본(replica)을 가지
고 있음
• 이러한 전제하에 어떠한 연산을 할 때는 프로세스 내의
원본(자기 서버에서 연산되는 데이터)와 사본(다른 서버
로부터 받은 데이터)를 가지고 연산을 수행
• 병목도 없으며, 여러 머신에 걸쳐 연산하지 않으므로 응
답 속도도 분산하기 전과 동일하게 빠름
• 그러나, 사본 데이터는 원본 데이터와 간발의 순간(밀리
초)으로 차이가 있을 수 있기 때문에(stale data
problem) 이때 데이터를 모두 신뢰할 경우 데이터 불일
치로 인한 잘못된 연산(하이젠버그)이 발생할 수 있음
Player_Attack(player, monster)
{
player.bullet--;
monster.hitPoint-=10;
if(monster.hitPoint<0)
{
player.item.Add(gold, 30);
DeleteEntity(monster, 10sec);
}
}
이 연산을 신뢰할 수
없을 수도 있음

29. 응집도 낮은 데이터만 서로 다른 서버
로 분산하기
• 분산하는 데이터의 단위가 지리적 영
역을 기반으로 할 경우, player와
monster는 대부분의 경우(혹은 항상)
같은 서버 프로세스에 있게 된다.
• player와 monster가 서로 같은 서버
프로세스 안에 있으면 안전한 상호작
용 구현은 쉬워짐
• 온라인 게임들의 월드가 완전히 격리
된 여러 지역으로 나뉘어있는 이유 중
하나는 서버 분산을 지리적 영역이라
는 데이터 분산을 했기 때문

30. 기능적 분산 처리
• 데이터 처리를 서로 다른 서버를 거쳐가면서
처리하기
• 데이터 분산 처리를 할 수 없는 경우의 대안
예: 경매장 서버
– 입찰 경쟁과 낙찰 과정이 atomic하게 이루어져야
하기 때문에 경매장 서버의 거래 처리는 여러 서
버가 데이터 분산하기 어려움.
– 대신 경매장 서버는 경매장 처리만을 전담하여 다
른 부하를 제거
• 서비스 품질 저하의 영향을 줄이고자 할 때
도 기능적 분산 처리가 도움되기도 함
– 예: 채팅 서버와 전투 처리 서버를 분리하는 경우,
전투 처리 서버에 과부하가 걸려도 채팅 기능은
원활하게 작동함
• 기능적 분산 처리는 데이터 분산 처리보다
분산 유연성이 떨어짐
– 기능 A,B,C중 B에만 과부하가 걸릴 경우?
• 기능적 분산 처리에서 한계에 부딪히는 경우
해당 기능을 데이터 분산 처리로 다시 세분
화가 가능한 경우도 있음
게임 서
버
경매장
게임 서 서버
버
게임 서
버
채팅 서
버
클라이언
트
클라이언
트
클라이언
트

31. 지나친 분산 처리는 피해야
• 지나친 분산 처리  네트워크 장비
에 부하 몰림네트워크 장비 과부하
로 인한 서비스 장애
– 네트워크 장비는 쉽게 과부하에 걸리지
않지만 일단 걸리면 해결이 어려움
• 분산 처리 프로그램은 디버깅이 까다
로움
– 여러 프로그램에 원격 디버깅?
– 로그 출력을 보고 암중모색하기

32. 분산 처리의 전략
• 데이터의 응집력을 확인하자
– 다룰 데이터간의 상호작용이 높은 것들은 분산하지 말고,
– 다룰 데이터간의 상호작용이 매우 적은 것들만 골라 분산하자.
• 즉, 응집력이 높은 데이터를 구별하는 기준이 무엇이 될까? 를 찾자.
– 게임 월드 내 지리적 구분? (MMORPG의 예)
– 플레이어의 레벨이나 등급에 따른 구분? (매치메이킹 시스템의 예)
• 분산 처리 방식으로 가능하다면 다음 순으로 가능한 방법을 찾도록 하자
– 데이터 동기화에 기반한 로컬 처리
– 비동기 분산 처리
– 동기 분산 처리
• 분산 처리 자체는 구현과 디버깅이 까다롭고 불필요한 과부하를 일으킴  불필요
한 분산 처리를 피해야 하는 이유

33. 분산 서버의 또다른 장점
• 확장성 뿐만 아니라 안정성에도 효과
– 데이터 분산 서버의 경우
• 중지된 서버가 처리하는 데이터는 전체 플레이어 중 일부의 데이터일 뿐이기 때문에 서비스 장애 영
역이 전체로부터 국소로 줄어듦
• 예: 전체 플레이어의 20%만이 접속이 끊어지나 다시 접속해서 게임 재시작 가능
– 기능적 분산 서버의 경우
• 중지된 서버가 처리하는 기능 외의 다른 기능은 정상 작동하고 있기 때문에 서비스 장애로 인한 불편
함이 줄어듦
• 예: 게임 내 NPC들이 모두 사라졌지만 PVP와 채팅은 가능함. 조금 있다가 다시 NPC들이 상태 리셋
상태로 등장함

34. Scale-out 관련 용어
• Load balancing (부하 분산)
– 클라이언트의 네트워크 연결을 여러 서버 머신으로 분산해서 처리하기
• 컴퓨터 클러스터
– 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합
– 즉 scale-out의 결과물이 클러스터
• Fail-over
– 동일한 역할을 하는 서버 컴퓨터 중 하나가 죽더라도 다른 서버가 즉시 역할을 대행
– Active-active: 동일한 역할을 하는 서버 컴퓨터가 2개
– Active-passive: 서버 1대만이 역할을 수행하고 나머지 서버는 대기하고 있다가 첫번째 서버가
죽으면 역할을 대행 (그동안 죽은 첫번째 서버는 점검 후 재시작)

35. 마무리
• 성능 vs. 확장성
• Scale up vs. out
• 서버 과부하가 발생하면 나타나는 현상
• 논리적 다중 서버 vs. 논리적 단일 서버
• 서버 분산의 필요 지점 찾기
• 데이터 응집력 식별하기
• 데이터 분산 vs. 기능적 분산
• 동기 분산 처리 vs. 비동기 분산 처리 vs. 데이터 복제 후 처리