SlideShare a Scribd company logo
분산 서버 구조
넷텐션
배현직
과거 수업 내용 상기
확장성 scalability
• 사용자의 수가 늘어나더라
도 쉽게 대응할 수 있어야
• 최대 처리할 수 있는 사용
자의 수를 (이론적으로라도)
무제한이 가능할 수 있어야
서버의 확장성이 한계에 부딪히는 예
확장성을 위한 방법
Scale-up vs. scale-out
Scale-up (수직적 확장) Scale-out (수평적 확장)
확장의 종류 서버 머신의 부품을 업그레이드 혹은
서버 머신 안의 CPU, RAM을 증설
서버 머신의 수를 증설
서버 소프트웨어 설
계 비용
낮음 높음
확장 비용 높음(기하급수적으로 높아짐) 낮음(선형적으로 높아짐)
과부하 지점 서버 컴퓨터 자체 네트워크 장치
오류 가능성 낮음(로컬 머신 내에서 동기 프로그
래밍 방식으로 작동하므로)
높음(여러 머신에 걸쳐 비동기 프로그
래밍 방식으로 작동하므로)
단위 처리 속도 높음(로컬 컴퓨터의 CPU와 RAM만
을 사용)
낮음(여러 서버 컴퓨터간의 메시징이
오가면서 처리하므로)
처리 가능 총량 낮음(서버 컴퓨터 1개의 성능만을 사
용하므로)
높음(여러 서버 컴퓨터로 부하가 분산
되므로)
서버 분산이 없다면?
전혀 분산되어 있지 않은 서버
• 모든 게임서버 로직은 1개의 서버 프로세스에서 수행
• 모든 플레이어 정보는 1개의 데이터베이스에 저장
Client Server Database
동시접속자가 무제한으로 증가할 경우 발
생하는 현상 (클라이언트)
• 서버로 보낸 메시지에 대한 처리 응답이 늦게 도착함
• 서버로의 접속 과정이 매우 오래 걸림
• 서버와의 연결이 돌발 해제됨
• TCP retransmission timeout으로 인해
• 사용자 정의 keep alive 메시징의 타임아웃으로 인해
• 서버로의 접속 자체가 실패함 (타임아웃)
서버에서의 현상
• CPU 사용량이 증가
• 클라이언트로부터 메시지를 받는 속도보
다 메시지를 처리하는 속도가 느린 경우
RAM 사용량이 증가
• 클라이언트에게 보낼 메시지의 발생 속
도보다 실제로 메시지를 보내는 속도가
느린 경우 RAM 사용량이 증가
• 즉, CPU의 과부하는 RAM 사용량 증가로
이어짐 0
5
10
15
20
25
30
35
40
45
시간 1 시간 2 시간 3 시간 4
Chart Title
메시지 수신 메시지 처리
메모리 사용량
• 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();
네트워크에서는 이러한 문제가 발생
• 라우터 과부하로 인해, packet drop 발생
• TCP retransmission timeout으로 인한
TCP disconnection 발생
서버 분산 방법
간단한 서버 분산 방법
• 게임 서버와 데이터베이스로 구
성된 세트(서버 채널이라고도
부름)를 쭈욱 나열하는 것만으
로도 간단히 해결됨
• 계정 인증 부분은 게임 퍼블리
셔에서 알아서 대규모 처리를
할 수 있게 해놓았으므로 문제
를 회피함
• 게임 서비스는 국가별로 다름
• 따라서 계정 인증 담당 서버와 장
치들도 전세계 여러 곳으로 나뉨
• 따라서 유저 밀집으로 인한 과부
하를 회피 가능
Server Database
Client
Switch,
routerFirewall
Server Database
Server Database
Server Database
Auth
Server
Auth
Database
• 이 방식의 문제점
• 같은 계정이라도 플레이어 정보가 서
로 다른 서버 채널에 다르게 존재함.
• 즉 플레이어는 자기 캐릭터 등의 정보
를 알기 위해 자신이 플레이했던 서버
채널을 알고 있어야 함
• 모바일 게임과 글로벌 서비스 게임
에서는 이러한 서버 채널이 없어지
는 것이 추세
• 논리적 단일 서버의 필요성 대두
논리적 단일 서버를 분산하기
서버의 각 부하 지점
• 서버의 각 지점의 최대 처리량 예시
• Router, switch : 1GB/sec
• Firewall: 500MB/sec
• CPU: 4 core * 3GHz
• Storage: 100MB/sec (SSD), 10MB/sec (HDD)
• 동시접속자가 증가하면서, 위 4가지 자원의 사용량은 한계에 점점 가까워
짐
• 한계에 빨리 부딪히는 것을 우선으로 해결해야 함
• 4가지 자원의 한계를 모두 해결하는 것이 궁극적인 해결책이지만, 통상 온라인 게임
의 경우 2가지 정도만 해결해도 충분하기도 함
Server Database
Client Switch,
router
Firewall
서버의 과부하 지점을 찾는 방법
• 서버의 과부하 지점을 찾는 현실적인(그러나 비경제적인) 방법
• Scale-out을 전혀 고려하지 않은 서버를 먼저 개발한 다음,
• 동시접속자를 증가시키면서 부하 지점의 처리량을 측정하기
• 측정하기 위해, code profiler와 DB query profiler 등을 사용
• 접속자가 늘어날수록 부하가 가파르게 증가하는 요소를 찾아, 해당 요소를
scale out으로 재개발을 한다.
• 서버의 과부하 지점에 대한 경험이 있을 경우 미리 scale out으로 개
발하면 더욱 경제적
• 서버의 과부하 지점의 예
• 몬스터가 많이 등장하는 필드
• 플레이어가 많이 몰리는 광장
• NPC의 AI 처리(path finding)
이렇게 해서 서버의 과부하 지
점을 찾은 후에는 어떻게 분산
할 것인가?
데이터 분산 vs. 기능적 분산
• 데이터 분산
• 한 머신이 처리해야 하는
데이터를 동일한 역할을
하는 여러 머신들이 나누
어서 처리
• 시계 공장에 비유하자면,
각 제작자가 부품 조립, 도
색, 포장을 모두 수행하되
이러한 사람들이 다수 포
진
재료
제작자
부품 조립,도색,포장
제작자
부품 조립,도색,포장
제작자
부품 조립,도색,포장
제작자
부품 조립,도색,포장
상품
• 기능적 분산
• 한 머신이 처리해야 하는
데이터의 처리 단계를 세분
화해서 여러 머신들이 나누
어서 처리
• 시계 공장에 비유하자면, 제
작의 각 단계를 서로 다른
사람이 수행
• 데이터 분산과 기능적 분
산을 혼용하는 것도 가능
재료 상품
제작
자
부품
조립
제작
자
도색
제작
자
포장
분산된 서버에서의 게임 로직
상호작용 시나리오 예시
• 플레이어 캐릭터가 몬스터 캐릭터를 죽이고,
아이템을 획득하기
• 플레이어가 가진 총알 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
• 만약 player, monster가 서로 다른 서
버 프로세스에 분산되어 있는데 이들
간의 상호작용을 반드시 해야 할 경우
어떻게 해야 할까?
• 3가지 방법이 존재함
• 동기 분산 처리
• 비동기 분산 처리
• 데이터 복제(replication)에 기반한 로컬
처리
서버1
Player
서버2
Monster
동기 분산 처리
• 어떠한 연산을 다른 서버에
던져놓고, 그 결과가 올 때까
지 대기를 하고 있음
• 대기할 뿐만 아니라, 그 연산
과 관계된 데이터가 도중에
변경되지 않도록 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);
}
}
DamageCharacter(attacker, character, damage)
{
character.hitPoint-=damage;
result.hitPoint = character.hitPoint;
Reply(result);
}
1.요청3.응답
2.대기 발생!
처리성능 병목 문제의 심각성
• 암달의 법칙
• 병렬 처리할 수 있는 장치에
서, 병렬로 처리하지 못하는
시간에 크게 비례해서 병렬
효과가 급감하는 현상
• 암달의 저주라고도 부름
• 따라서 동기 분산 처리의
잘못된 사용은 분산 서버
의 효과를 떨어뜨릴 수 있
음
병렬로 처리하지 못하는 시간(붉은색)의 비
중이 클수록 병렬 처리 효과는 크게 감소함
비동기 분산 처리
• 어떠한 연산을 다른 서버에
던져놓고 그 결과를 기다리
지 않고 일방적으로 다음 처
리를 수행
• 단위 처리의 시간이 길어지
는 만큼 병목 문제가 발생하
는 일은 없음
• 그러나, 로직의 구현에 한계
가 발생함
• 리턴값 없는 함수만으로 로직
을 구현하는 것과 유사함
• 리턴값을 반드시 받아야 다음
진행이 가능한 로직을 구현할
때 한계에 부딪힘
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);
}
메시징
메시징
비동기 분산 처리, 동기 분산 처리의 단점
• 비동기 분산 처리, 동기 분산 처리 모두 어
떠한 연산이 여러 서버에 걸쳐 처리되기 때
문에, 그 과정에서 머신간 송수신 과정이 들
어가게 됨
• 네트웍으로 메시지를 보내는 데 걸리는
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
데이터 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);
}
}
이 연산을 신뢰할 수
없을 수도 있음
응집도 낮은 데이터만 서로 다른 서버로
분산하기
• 분산하는 데이터의 단위가 지리적
영역을 기반으로 할 경우, player와
monster는 대부분의 경우(혹은 항
상) 같은 서버 프로세스에 있게 된
다.
• player와 monster가 서로 같은 서
버 프로세스 안에 있으면 안전한 상
호작용 구현은 쉬워짐
• 많은 온라인 게임들의 월드가 완전
히 격리된 여러 지역으로 나뉘어있
는 이유 중 하나는 서버 분산을 지
리적 영역이라는 데이터 분산을 했
기 때문
기능적 분산 처리
• 데이터 처리를 서로 다른 서버를 거쳐가면서 처리하기
• 데이터 분산 처리를 할 수 없는 경우의 대안.
예: 경매장 서버
• 입찰 경쟁과 낙찰 과정이 atomic하게 이루어져야 하기 때문에
경매장 서버의 거래 처리는 여러 서버가 데이터 분산하기 어려
움.
• 대신 경매장 서버는 경매장 처리만을 전담하여 다른 부하를 제
거
• 서비스 품질 저하의 영향을 줄이고자 할 때도 기능적 분산 처
리가 도움되기도 함
• 예: 채팅 서버와 전투 처리 서버를 분리하는 경우, 전투 처리 서
버에 과부하가 걸려도 채팅 기능은 원활하게 작동함
• 기능적 분산 처리는 데이터 분산 처리보다 분산 유연성이 떨
어짐
• 기능 A,B,C중 B에만 과부하가 걸릴 경우?
• 기능적 분산 처리에서 한계에 부딪히는 경우 해당 기능을 데
이터 분산 처리로 다시 세분화가 가능한 경우도 있음
게임 서버
경매장
서버
게임 서버
게임 서버
채팅 서버
클라이언트
클라이언트
클라이언트
지나친 분산 처리는
피해야
• 지나친 분산 처리  네트워크
장비에 부하 몰림네트워크 장
비 과부하로 인한 서비스 장애
• 네트워크 장비는 쉽게 과부하에
걸리지 않지만 일단 걸리면 해결
이 어려움
• 분산 처리 프로그램은 디버깅이
까다로움
• 여러 프로그램에 원격 디버깅?
• 로그 출력을 보고 암중모색하기
분산 처리의 전략
• 데이터의 응집력을 확인하자
• 다룰 데이터간의 상호작용이 높은 것들은 분산하지 말고,
• 다룰 데이터간의 상호작용이 매우 적은 것들만 골라 분산하자.
• 즉, 응집력이 높은 데이터를 구별하는 기준이 무엇이 될까? 를 찾자.
• 게임 월드 내 지리적 구분? (MMORPG의 예)
• 플레이어의 레벨이나 등급에 따른 구분? (매치메이킹 시스템의 예)
• 분산 처리 방식으로 가능하다면 다음 순으로 가능한 방법을 찾도록 하자
• 데이터 동기화에 기반한 로컬 처리
• 비동기 분산 처리
• 동기 분산 처리
• 분산 처리 자체는 구현과 디버깅이 까다롭고 불필요한 과부하를 일으킴
 불필요한 분산 처리를 피해야 하는 이유
분산 서버의 또다른 장점
• 확장성 뿐만 아니라 안정성에도 효과
• 데이터 분산 서버의 경우
• 중지된 서버가 처리하는 데이터는 전체 플레이어 중 일부의 데이터일 뿐이기 때
문에 서비스 장애 영역이 전체로부터 국소로 줄어듦
• 예: 전체 플레이어의 20%만이 접속이 끊어지나 다시 접속해서 게임 재시작 가능
• 기능적 분산 서버의 경우
• 중지된 서버가 처리하는 기능 외의 다른 기능은 정상 작동하고 있기 때문에 서비
스 장애로 인한 불편함이 줄어듦
• 예: 게임 내 NPC들이 모두 사라졌지만 PVP와 채팅은 가능함. 조금 있다가 다시
NPC들이 상태 리셋 상태로 등장함
Scale-out 관련 용어
• Load balancing (부하 분산)
• 클라이언트의 네트워크 연결을 여러 서버 머신으로 분산해서 처리하기
• 컴퓨터 클러스터
• 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집
합
• 즉 scale-out의 결과물이 클러스터
• Fail-over
• 동일한 역할을 하는 서버 컴퓨터 중 하나가 죽더라도 다른 서버가 즉시 역할
을 대행
• Active-active: 동일한 역할을 하는 서버 컴퓨터가 2개
• Active-passive: 서버 1대만이 역할을 수행하고 나머지 서버는 대기하고 있다
가 첫번째 서버가 죽으면 역할을 대행 (그동안 죽은 첫번째 서버는 점검 후
재시작)
다음 시간에는
• 게임 구성요소별 서버 구성 사례들을 살펴보자.
• 로그온
• 매치메이킹
• 메신저
• 몬스터 사냥
• 몬스터 NPC
• 로그, 데이터마이닝

More Related Content

What's hot

임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013devCAT Studio, NEXON
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
Heungsub Lee
 
[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기
[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기
[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기
강 민우
 
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
Heungsub Lee
 
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
Heungsub Lee
 
Windows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCPWindows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCP
Seungmo Koo
 
Ndc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCNdc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABC
Ho Gyu Lee
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
Amazon Web Services Korea
 
중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직
Hoyoung Choi
 
[0903 구경원] recast 네비메쉬
[0903 구경원] recast 네비메쉬[0903 구경원] recast 네비메쉬
[0903 구경원] recast 네비메쉬KyeongWon Koo
 
Multiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theoremMultiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theorem
Seungmo Koo
 
NDC2011 - 절차적 지형과 트렌드의 추적자들
NDC2011 - 절차적 지형과 트렌드의 추적자들NDC2011 - 절차적 지형과 트렌드의 추적자들
NDC2011 - 절차적 지형과 트렌드의 추적자들Jubok Kim
 
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
강 민우
 
게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델
게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델
게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델
Seungmo Koo
 
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
devCAT Studio, NEXON
 
조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012
조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012
조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012devCAT Studio, NEXON
 
양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012
양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012
양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012devCAT Studio, NEXON
 
게임서버프로그래밍 #2 - IOCP Adv
게임서버프로그래밍 #2 - IOCP Adv게임서버프로그래밍 #2 - IOCP Adv
게임서버프로그래밍 #2 - IOCP Adv
Seungmo Koo
 
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
devCAT Studio, NEXON
 
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games ConferenceKGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
Xionglong Jin
 

What's hot (20)

임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
 
[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기
[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기
[IGC 2017] 펄어비스 민경인 - Mmorpg를 위한 voxel 기반 네비게이션 라이브러리 개발기
 
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
 
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
 
Windows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCPWindows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCP
 
Ndc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCNdc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABC
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
 
중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직
 
[0903 구경원] recast 네비메쉬
[0903 구경원] recast 네비메쉬[0903 구경원] recast 네비메쉬
[0903 구경원] recast 네비메쉬
 
Multiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theoremMultiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theorem
 
NDC2011 - 절차적 지형과 트렌드의 추적자들
NDC2011 - 절차적 지형과 트렌드의 추적자들NDC2011 - 절차적 지형과 트렌드의 추적자들
NDC2011 - 절차적 지형과 트렌드의 추적자들
 
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
 
게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델
게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델
게임서버프로그래밍 #0 - TCP 및 이벤트 통지모델
 
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
 
조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012
조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012
조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012
 
양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012
양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012
양승명, 다음 세대 크로스플랫폼 MMORPG 아키텍처, NDC2012
 
게임서버프로그래밍 #2 - IOCP Adv
게임서버프로그래밍 #2 - IOCP Adv게임서버프로그래밍 #2 - IOCP Adv
게임서버프로그래밍 #2 - IOCP Adv
 
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018
 
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games ConferenceKGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
 

Viewers also liked

채팅서버의 부하 분산 사례
채팅서버의 부하 분산 사례채팅서버의 부하 분산 사례
채팅서버의 부하 분산 사례
John Kim
 
Shadow mapping 정리
Shadow mapping 정리Shadow mapping 정리
Shadow mapping 정리
changehee lee
 
Visual shock vol.2
Visual shock   vol.2Visual shock   vol.2
Visual shock vol.2
changehee lee
 
NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉
NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉
NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉
iFunFactory Inc.
 
프라우드넷의 IL2CPP 적응 기록-정종채
프라우드넷의 IL2CPP 적응 기록-정종채프라우드넷의 IL2CPP 적응 기록-정종채
프라우드넷의 IL2CPP 적응 기록-정종채
Hyunjik Bae
 
KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론
Hyunjik Bae
 
프라우드넷의 연결 유지 기능과 홀펀칭-윤현민
프라우드넷의 연결 유지 기능과 홀펀칭-윤현민프라우드넷의 연결 유지 기능과 홀펀칭-윤현민
프라우드넷의 연결 유지 기능과 홀펀칭-윤현민
Hyunjik Bae
 
라이브 서비스를 위한 게임 서버 구성
라이브 서비스를 위한 게임 서버 구성라이브 서비스를 위한 게임 서버 구성
라이브 서비스를 위한 게임 서버 구성
Hyunjik Bae
 
ProudNet 1.7 소개
ProudNet 1.7 소개ProudNet 1.7 소개
ProudNet 1.7 소개
Hyunjik Bae
 
Unity에서 회전하는 cube 만드는 법
Unity에서 회전하는 cube 만드는 법Unity에서 회전하는 cube 만드는 법
Unity에서 회전하는 cube 만드는 법
Hyunjik Bae
 
KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직
KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직
KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직
Hyunjik Bae
 

Viewers also liked (11)

채팅서버의 부하 분산 사례
채팅서버의 부하 분산 사례채팅서버의 부하 분산 사례
채팅서버의 부하 분산 사례
 
Shadow mapping 정리
Shadow mapping 정리Shadow mapping 정리
Shadow mapping 정리
 
Visual shock vol.2
Visual shock   vol.2Visual shock   vol.2
Visual shock vol.2
 
NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉
NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉
NDC14 범용 게임 서버 프레임워크 디자인 및 테크닉
 
프라우드넷의 IL2CPP 적응 기록-정종채
프라우드넷의 IL2CPP 적응 기록-정종채프라우드넷의 IL2CPP 적응 기록-정종채
프라우드넷의 IL2CPP 적응 기록-정종채
 
KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론
 
프라우드넷의 연결 유지 기능과 홀펀칭-윤현민
프라우드넷의 연결 유지 기능과 홀펀칭-윤현민프라우드넷의 연결 유지 기능과 홀펀칭-윤현민
프라우드넷의 연결 유지 기능과 홀펀칭-윤현민
 
라이브 서비스를 위한 게임 서버 구성
라이브 서비스를 위한 게임 서버 구성라이브 서비스를 위한 게임 서버 구성
라이브 서비스를 위한 게임 서버 구성
 
ProudNet 1.7 소개
ProudNet 1.7 소개ProudNet 1.7 소개
ProudNet 1.7 소개
 
Unity에서 회전하는 cube 만드는 법
Unity에서 회전하는 cube 만드는 법Unity에서 회전하는 cube 만드는 법
Unity에서 회전하는 cube 만드는 법
 
KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직
KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직
KGC 2014: 클라이언트 개발자를 위한 컴퓨터 네트워크 기초 배현직
 

Similar to 게임 분산 서버 구조

Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
Jinuk Kim
 
Network programming report
Network programming reportNetwork programming report
Network programming report
Jongwon
 
사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)
사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)
사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)
Seungmo Koo
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
cranbe95
 
Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)
HyoungEun Kim
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
devCAT Studio, NEXON
 
모바일 SNG 비동기 네트워크 통신 사례
모바일 SNG 비동기 네트워크 통신 사례모바일 SNG 비동기 네트워크 통신 사례
모바일 SNG 비동기 네트워크 통신 사례
성수 이
 
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
NAVER D2
 
스마트폰 온라인 게임에서 고려해야 할 것들
스마트폰 온라인 게임에서 고려해야 할 것들스마트폰 온라인 게임에서 고려해야 할 것들
스마트폰 온라인 게임에서 고려해야 할 것들
Hyunjik Bae
 
게임 디자이너와 게임 서버
게임 디자이너와 게임 서버게임 디자이너와 게임 서버
게임 디자이너와 게임 서버
ByungChun2
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
Amazon Web Services Korea
 
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
준철 박
 
분산저장시스템 개발에 대한 12가지 이야기
분산저장시스템 개발에 대한 12가지 이야기분산저장시스템 개발에 대한 12가지 이야기
분산저장시스템 개발에 대한 12가지 이야기
NAVER D2
 
Rankwave moment™ desc3
Rankwave moment™ desc3Rankwave moment™ desc3
Rankwave moment™ desc3
Sungwha Shim
 
Tdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalabilityTdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalability흥배 최
 
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
NAVER D2
 
Azure로 MMO게임 서비스하기
Azure로 MMO게임 서비스하기Azure로 MMO게임 서비스하기
Azure로 MMO게임 서비스하기
YEONG-CHEON YOU
 
나만의 엔진 개발하기
나만의 엔진 개발하기나만의 엔진 개발하기
나만의 엔진 개발하기
YEONG-CHEON YOU
 
게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018
게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018 게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018
게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018 Amazon Web Services Korea
 
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
Amazon Web Services Korea
 

Similar to 게임 분산 서버 구조 (20)

Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
 
Network programming report
Network programming reportNetwork programming report
Network programming report
 
사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)
사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)
사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
 
Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)Rankwave MOMENT™ (Korean)
Rankwave MOMENT™ (Korean)
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
 
모바일 SNG 비동기 네트워크 통신 사례
모바일 SNG 비동기 네트워크 통신 사례모바일 SNG 비동기 네트워크 통신 사례
모바일 SNG 비동기 네트워크 통신 사례
 
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
 
스마트폰 온라인 게임에서 고려해야 할 것들
스마트폰 온라인 게임에서 고려해야 할 것들스마트폰 온라인 게임에서 고려해야 할 것들
스마트폰 온라인 게임에서 고려해야 할 것들
 
게임 디자이너와 게임 서버
게임 디자이너와 게임 서버게임 디자이너와 게임 서버
게임 디자이너와 게임 서버
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
 
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
 
분산저장시스템 개발에 대한 12가지 이야기
분산저장시스템 개발에 대한 12가지 이야기분산저장시스템 개발에 대한 12가지 이야기
분산저장시스템 개발에 대한 12가지 이야기
 
Rankwave moment™ desc3
Rankwave moment™ desc3Rankwave moment™ desc3
Rankwave moment™ desc3
 
Tdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalabilityTdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalability
 
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
 
Azure로 MMO게임 서비스하기
Azure로 MMO게임 서비스하기Azure로 MMO게임 서비스하기
Azure로 MMO게임 서비스하기
 
나만의 엔진 개발하기
나만의 엔진 개발하기나만의 엔진 개발하기
나만의 엔진 개발하기
 
게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018
게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018 게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018
게임을 위한 최적의 AWS DB 서비스 선정 퀘스트 깨기::최유정::AWS Summit Seoul 2018
 
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
 

게임 분산 서버 구조

  • 3. 확장성 scalability • 사용자의 수가 늘어나더라 도 쉽게 대응할 수 있어야 • 최대 처리할 수 있는 사용 자의 수를 (이론적으로라도) 무제한이 가능할 수 있어야 서버의 확장성이 한계에 부딪히는 예
  • 5. Scale-up vs. scale-out Scale-up (수직적 확장) Scale-out (수평적 확장) 확장의 종류 서버 머신의 부품을 업그레이드 혹은 서버 머신 안의 CPU, RAM을 증설 서버 머신의 수를 증설 서버 소프트웨어 설 계 비용 낮음 높음 확장 비용 높음(기하급수적으로 높아짐) 낮음(선형적으로 높아짐) 과부하 지점 서버 컴퓨터 자체 네트워크 장치 오류 가능성 낮음(로컬 머신 내에서 동기 프로그 래밍 방식으로 작동하므로) 높음(여러 머신에 걸쳐 비동기 프로그 래밍 방식으로 작동하므로) 단위 처리 속도 높음(로컬 컴퓨터의 CPU와 RAM만 을 사용) 낮음(여러 서버 컴퓨터간의 메시징이 오가면서 처리하므로) 처리 가능 총량 낮음(서버 컴퓨터 1개의 성능만을 사 용하므로) 높음(여러 서버 컴퓨터로 부하가 분산 되므로)
  • 7. 전혀 분산되어 있지 않은 서버 • 모든 게임서버 로직은 1개의 서버 프로세스에서 수행 • 모든 플레이어 정보는 1개의 데이터베이스에 저장 Client Server Database
  • 8. 동시접속자가 무제한으로 증가할 경우 발 생하는 현상 (클라이언트) • 서버로 보낸 메시지에 대한 처리 응답이 늦게 도착함 • 서버로의 접속 과정이 매우 오래 걸림 • 서버와의 연결이 돌발 해제됨 • TCP retransmission timeout으로 인해 • 사용자 정의 keep alive 메시징의 타임아웃으로 인해 • 서버로의 접속 자체가 실패함 (타임아웃)
  • 9. 서버에서의 현상 • CPU 사용량이 증가 • 클라이언트로부터 메시지를 받는 속도보 다 메시지를 처리하는 속도가 느린 경우 RAM 사용량이 증가 • 클라이언트에게 보낼 메시지의 발생 속 도보다 실제로 메시지를 보내는 속도가 느린 경우 RAM 사용량이 증가 • 즉, CPU의 과부하는 RAM 사용량 증가로 이어짐 0 5 10 15 20 25 30 35 40 45 시간 1 시간 2 시간 3 시간 4 Chart Title 메시지 수신 메시지 처리 메모리 사용량
  • 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 발생
  • 13. 간단한 서버 분산 방법 • 게임 서버와 데이터베이스로 구 성된 세트(서버 채널이라고도 부름)를 쭈욱 나열하는 것만으 로도 간단히 해결됨 • 계정 인증 부분은 게임 퍼블리 셔에서 알아서 대규모 처리를 할 수 있게 해놓았으므로 문제 를 회피함 • 게임 서비스는 국가별로 다름 • 따라서 계정 인증 담당 서버와 장 치들도 전세계 여러 곳으로 나뉨 • 따라서 유저 밀집으로 인한 과부 하를 회피 가능 Server Database Client Switch, routerFirewall Server Database Server Database Server Database Auth Server Auth Database
  • 14. • 이 방식의 문제점 • 같은 계정이라도 플레이어 정보가 서 로 다른 서버 채널에 다르게 존재함. • 즉 플레이어는 자기 캐릭터 등의 정보 를 알기 위해 자신이 플레이했던 서버 채널을 알고 있어야 함 • 모바일 게임과 글로벌 서비스 게임 에서는 이러한 서버 채널이 없어지 는 것이 추세 • 논리적 단일 서버의 필요성 대두
  • 16. 서버의 각 부하 지점 • 서버의 각 지점의 최대 처리량 예시 • Router, switch : 1GB/sec • Firewall: 500MB/sec • CPU: 4 core * 3GHz • Storage: 100MB/sec (SSD), 10MB/sec (HDD) • 동시접속자가 증가하면서, 위 4가지 자원의 사용량은 한계에 점점 가까워 짐 • 한계에 빨리 부딪히는 것을 우선으로 해결해야 함 • 4가지 자원의 한계를 모두 해결하는 것이 궁극적인 해결책이지만, 통상 온라인 게임 의 경우 2가지 정도만 해결해도 충분하기도 함 Server Database Client Switch, router Firewall
  • 17. 서버의 과부하 지점을 찾는 방법 • 서버의 과부하 지점을 찾는 현실적인(그러나 비경제적인) 방법 • Scale-out을 전혀 고려하지 않은 서버를 먼저 개발한 다음, • 동시접속자를 증가시키면서 부하 지점의 처리량을 측정하기 • 측정하기 위해, code profiler와 DB query profiler 등을 사용 • 접속자가 늘어날수록 부하가 가파르게 증가하는 요소를 찾아, 해당 요소를 scale out으로 재개발을 한다. • 서버의 과부하 지점에 대한 경험이 있을 경우 미리 scale out으로 개 발하면 더욱 경제적 • 서버의 과부하 지점의 예 • 몬스터가 많이 등장하는 필드 • 플레이어가 많이 몰리는 광장 • NPC의 AI 처리(path finding)
  • 18. 이렇게 해서 서버의 과부하 지 점을 찾은 후에는 어떻게 분산 할 것인가?
  • 19. 데이터 분산 vs. 기능적 분산 • 데이터 분산 • 한 머신이 처리해야 하는 데이터를 동일한 역할을 하는 여러 머신들이 나누 어서 처리 • 시계 공장에 비유하자면, 각 제작자가 부품 조립, 도 색, 포장을 모두 수행하되 이러한 사람들이 다수 포 진 재료 제작자 부품 조립,도색,포장 제작자 부품 조립,도색,포장 제작자 부품 조립,도색,포장 제작자 부품 조립,도색,포장 상품
  • 20. • 기능적 분산 • 한 머신이 처리해야 하는 데이터의 처리 단계를 세분 화해서 여러 머신들이 나누 어서 처리 • 시계 공장에 비유하자면, 제 작의 각 단계를 서로 다른 사람이 수행 • 데이터 분산과 기능적 분 산을 혼용하는 것도 가능 재료 상품 제작 자 부품 조립 제작 자 도색 제작 자 포장
  • 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); } } DamageCharacter(attacker, character, damage) { character.hitPoint-=damage; result.hitPoint = character.hitPoint; Reply(result); } 1.요청3.응답 2.대기 발생!
  • 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. 다음 시간에는 • 게임 구성요소별 서버 구성 사례들을 살펴보자. • 로그온 • 매치메이킹 • 메신저 • 몬스터 사냥 • 몬스터 NPC • 로그, 데이터마이닝