ݺߣ

ݺߣShare a Scribd company logo

게임 분산 서버 구조

•
•
Hyunjik Bae
Hyunjik Bae

게임 서버 개발을 다루는 대학 수업 과목의 수업 내용 중 하나를 공개합니다. 분산서버 개발에 대한 기초 내용을 다루고 있습니다.

1 of 35
분산 서버 구조 넷텐션 배현직
과거 수업 내용 상기
확장성 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

게임 분산 서버 구조

  • 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 • 로그, 데이터마이닝