1.
마비노기 영웅전자이언트 서버의 비밀<br />㈜넥슨<br />영웅전 런칭팀 양승명<br />sequoia@nexon.co.kr<br />

2.
발표자 소개<br />@sequoiaxp<br />양승명<br />2002~2005 “다크에덴” 서버 프로그래머<br />2007~2010 “마비노기 영웅전” 서버 프로그래머<br />2010~현재 “마비노기 영웅전” 개발 매니저<br />

3.
마비노기 영웅전 소개<br />

4.
자이언트 서버?<br />자이언트 노예<br />

5.

6.

7.
이 발표의 목적<br />자랑(x)<br />단일 서버 아키텍처 구현 및 운용 노하우 공유<br />뼈 아픈 자아 성찰 자이언트 서버 구현 결산<br />

8.
경고!!<br />이 발표는 프로그래밍 세션입니다.<br />미디어, 업계 외에 계시거나 프로그래밍에 전문 지식이 없을 경우 유용한 내용이 적을 수 있습니다.<br />

9.
목차<br />01. 소개 (이미 했음)<br />02. 초기 계획<br />03. 구현 중 이슈<br />04. 런칭 후 알게 된 것<br />05. 결산<br />

10.
일단 자랑<br />

11.

12.
자랑 아님<br />

13.
깜짝 퀴즈<br />이 날 문제가 된 요소는 무엇이었을까요?<br />

14.
초기 계획2007년 초<br />

15.
“단일 서버로 만들자”<br />커뮤니티 단절<br />신규 유저 장벽<br />운영 비용<br />기술적 도전과제<br />

16.
사실은<br />개발 초기 기획에는 MMO요소가 없었어요.<br />단일 서버를 결정할 수 있었던 자신감의 근원<br />

17.
설계 목표Scale-out아키텍처<br />서버를 추가하면 성능이 증가하는<br />분산 처리 아키텍처<br />

18.
분산 처리 아키텍처?<br />서로 다른 서버들 간의 역할분담이 핵심<br />

19.
기존의역할 분담<br />로그인 서버, 게임 서버, 캐시 서버, NPC서버<br />1채널, 2채널, 3채널<br />K대륙 서버, E대륙 서버, 인스턴스던전 서버<br />

20.
기존 아키텍처들<br />특정 서버가 병목이 될 수밖에 없거나,<br />늘어난 서버를 유저에게 노출시켜야 하거나,<br />게임 디자인 상 서버를 추가하기가 어렵다.<br />

21.
설계 목표<br />추가 구현이나 디자인 변경 없이<br />서버 추가만으로<br />수용량을 증가시킬 수 있는 아키텍처<br />

22.
실마리 발견<br />

23.
GPG 5권 6.1<br />“서비스 기반 아키텍처”<br />아이템 서비스, 전투 서비스, AI 서비스…<br />

24.
Service<br />Frontend<br />Service<br />통합네트워크<br />Service<br />

25.
역할을 서비스로 분담<br />가능한 작은 기능 단위를 서비스로 구현<br />한 서비스에 대한 부하 최소화<br />부하가 심할 것 같은 서비스는 여러 개 띄워서 부하 분산<br />“통합 네트워크”가 서비스 간 통신을 중개<br />

26.
액션 플랜<br />통합 네트워크만 구현하면,<br />필요한 기능들을 서비스로 추가해서,<br />아키텍처를 확장할 수 있겠다.<br />

27.
통합 네트워크 구현<br />

28.
통합 네트워크 라이브러리<br />서비스 구현 및 서비스 간 통신 지원<br />서비스의 물리적인 위치를 게임 로직이 몰라도 되도록 구현<br />

29.
오퍼레이션<br />서비스가 제공하는 기능 단위<br />항상 성공하거나 실패하는 것을보장<br />

30.
Service<br />Operation<br />Frontend<br />Service<br />통합네트워크<br />Service<br />Backend<br />

31.
위치 서비스<br />서비스의 실제 위치를 다루는 서비스<br />서비스가 뜰 때 위치 서비스에 직접 등록<br />오퍼레이션을 요청할 때 통합 네트워크 라이브러리가 위치 서비스에 자동으로 접속<br />

32.
Location<br />Execution<br />클라이언트<br />Frontend<br />Service<br />Backend<br />Service<br />

33.
네트워크 레이어 구현<br />오퍼레이션을 지원하는 네트워크 모듈 구현<br />하나의 TCP연결을 통해 여러 오퍼레이션 동시 처리 필요<br />서비스 간 TCP 연결 내에서 멀티플렉싱<br /> 가상 “파이프”구현<br />파이프를 통해서 오퍼레이션 처리<br />

34.
Operation Layer<br />Pipe Layer<br />TCP/IP CORE<br />

35.
“Process” Operation Processor<br />“Request” Operation Processor<br />PIPE<br />“yield” 코루틴 사용<br />TCP Connection<br />

36.
게임 로직 코드<br />(예: 아이템 파기 코드)<br />DestroyItem op = new DestoryItem(cid, slot);<br />op.Success += () =>{ 성공 메시지 전달; };<br />op.Fail += () => { 실패 메시지 전달; };<br />RequestOperation(“ItemService”, op);<br />실제 코드와는 차이가 있습니다.<br />

37.
개발 프로세스<br />책임을 맡은 서비스를 구현<br />그 서비스가 처리할 오퍼레이션들을 구현<br />클라이언트의 요청에 따라 적당한 오퍼레이션을 호출  결과를 클라이언트에 전달<br />

38.
그리고 게임 로직을열심히 만들었습니다.<br />

39.
1년여 뒤(2008년)<br />

40.
사내테스트 당시<br />Party Service<br />Frontend Service<br />Unified Network<br />Story Service<br />Character Service<br />Microplay Service<br />Item Service<br />Postal Service<br />Quest Service<br />

41.
사내 서비스 후<br />생각보다 저조한 성능<br />서비스 1종 = 물리적 서버 1대로도 부족<br /> 이대로는 단일서버 서비스 불가<br />

42.
그래서통합 네트워크 개선 작업<br />1) 성능 향상  다루지 않음<br />2) 동일한 서비스를 여러 개 띄운 경우 분산 매커니즘 구현<br /> 병목이 되는 서비스를 여러 서버 기계에 걸쳐서 여러 개 띄울 수 있도록<br />

43.
분산 매커니즘 구현<br />

44.
서비스에 오퍼레이션 요청<br />DestroyItem op = new DestoryItem(cid, slot);<br />RequestOperation(“ItemService”, op);<br />아이템 서비스가 여러 개면?<br /> 둘 이상의 서비스가 같은 아이템에 접근<br />한 아이템은 한 서비스가 처리하도록 보장하는 매커니즘 필요<br />

45.
엔티티<br />분산 처리의 단위<br />“한 캐릭터의 인벤토리 전체”<br />“한 캐릭터의 우편함 전체”<br />“전투 1회”<br />등을 하나의 엔티티로 구현<br />하나의 엔티티는 한 서비스에서 담당<br />

46.
엔티티 오퍼레이션<br />Service<br />Service<br />Operation<br />Entity<br />Entity<br />Entity<br />Entity<br />Operation<br />Entity<br />Entity<br />Entity<br />Entity<br />

47.
엔티티 획득<br />같은 종류의 서비스가 여러 개 있는 경우<br /> 엔티티 중복 로드 방지 프로토콜<br />DB를 통해 동기화 유지<br />

48.
엔티티 간 연결 유지<br />엔티티 찾기 매커니즘이복잡하고 비싸다<br /> 오퍼레이션을 보낼 때마다 엔티티를 새로 찾으면 낭비<br />엔티티 간에 파이프를 열어두고 유지<br />엔티티가필요없어지면<br /> 모든 연결을 닫고 엔티티언로드<br />  로그아웃, 전투 종료 등<br />

49.
변경된 게임 로직 코드<br />(로그인할 때)<br />ItemConnection = service.Connect(clientEntity, cid, “ItemService”);<br />(아이템 파기)<br />DestroyItem op = new DestoryItem(slot);<br />op.Success += () => { 성공 메시지 전달; };<br />op.Fail += () => { 실패 메시지 전달; };<br />ItemConnection.Request(op);<br />CID가 오퍼레이션에서 사라짐 <br />

50.
크게 보면 이런 모양<br />

51.
엔티티 모델 구현 성공<br />이제<br />아이템 서비스가 느리면 아이템 서비스를 열 개 띄우고, <br />캐릭터 서비스가 느리면 캐릭터 서비스를 열 개 띄우고…<br />

52.
추가 기능<br />오퍼레이션 싱크:<br />다른 오퍼레이션이 끝날 때까지 기다렸다가 그 결과를 사용해서 처리<br />엔티티옵저버:<br />엔티티가 변경되면 다른 서비스의 엔티티에 알림<br />

53.
어쨌든이 상태로 그랜드 오픈2010년 1월<br />

54.

55.
자랑 아님<br />

56.
깜짝 퀴즈<br />이 날 문제가 된 요소는 무엇이었을까요?<br />

57.
답 : DB<br />로그 DB에 과량의 로그가 INSERT<br />모든 서비스가 같은 DB에 접속<br />

58.
DB의 scale out을 간과!!<br />사실은 방법이 없었던 건 아니지만…<br />아직도 DB는 영웅전 게임서버의 병목<br />타개하기 위해 여러 가지 시도 중<br />일단 좋은 사양의 서버로 커버<br />

59.
아키텍처의 문제<br />서버라고 문제 없는 건 아니에요…<br />

60.
엔티티릭<br />커넥션 카운팅으로언로드<br /> 순환 참조 문제<br />언로드 조건 변경<br /> 댕글링엔티티<br />분산 GC를 돌릴수도 없고…<br />

61.
랙 전파<br />오퍼레이션이 다른 오퍼레이션을 기다림<br />한 서비스만이라도 느리면 연쇄적으로 모든 서비스의 대기 큐가 길어짐<br />일부 오퍼레이션은 근본적으로 많은 오퍼레이션을 기다림<br /> 캐릭터 로그인, 배 띄우기등<br /> 항해노기, 배 띄우다 시간 초과…<br />

62.
오퍼레이션 폭발<br />한 엔티티에 너무 많은 옵저버<br />엔티티의 변경이 너무 많은 서비스에 영향<br />엔티티가 자주 바뀌면 DOS효과<br />

63.
오퍼레이션 오버헤드<br />메시지 시리얼라이즈가 여전히 부담<br />실제 프로세싱보다 오퍼레이션 자체가 늘어나는 게 성능에 악영향<br />서비스를 너무 세분화한 게 역효과<br />

64.
서비스 간 로드 밸런싱<br />같은 종류의 서비스 사이의 로드 밸런싱<br />랜덤에 의존한 유니폼 로드 밸런싱<br /> 서버 머신 간에 사양 차이가 있는 경우?<br />적응형 로드 밸런싱 필요<br />

65.
프론트엔드 비대화<br />클라이언트가 요청<br /> 프론트엔드가 오퍼레이션으로 변환<br /> 프론트엔드가 오퍼레이션 결과 처리<br />프론트엔드가 거의 모든 로직을 내장<br /> 메시지 시리얼라이즈만도 바쁜데…<br /> I/O 로드와 CPU로드가 모두 과다<br />지금도 프론트엔드가 가장 바쁜 서비스<br />

66.
기타 알 수 없는 문제<br />아키텍처의 복잡도에 비해 진단 프레임워크가 약함  문제 발생 시 추적이 어려움<br />실제로 런칭 후 수 개월 간 서버 불안정<br />

67.
자이언트 서버 총평<br />바닥부터 만든 닷넷 기반 엔진<br />유연한 scale out이 가능한 아키텍처 구현<br />성능은 만족스럽지 못하다<br />

68.
더 잘할 수 있었는데…<br />네트워크 부하를 줄이는 방향으로 서비스 분할<br />병목/부하 실시간 모니터링 및 제어<br />DB 최적화 및 분산<br />투명 프론트엔드 기반 컨텐츠 아키텍처<br />

69.
다루지 못한 주제들<br />닷넷언어로 서버 만들기<br />섀도우 채널 및 MMO 마을<br />단일 스레드로직아키텍처 및 멀티스레딩<br />P2P 지원 아키텍처 및 미들웨어<br />컨텐츠로직 프레임워크<br />닷넷 메시지 시리얼라이즈 최적화<br />

70.
Q&A<br />게임 서비스 운영 관련 질문, 게임 디자인 관련 질문이나 세션 내용과 관계없는 질문은 삼가 주시기 바랍니다.<br />

71.
영웅전 관련 세션<br />5월 30일 월요일<br />5월 31일 화요일<br />6월 1일 수요일<br />6월 3일 금요일<br />