2011 NDC(Nexon Developers Conference)에서 발표한 마비노기 영웅전(미국명 Vindictus)의 자이언트 서버 아키텍처에 대한 슬라이드입니다. 게임 서버의 분산 서비스 아키텍처를 바닥부터 만들어낸 과정과 결과에 대한 내용을 담고 있습니다.

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

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

3. 마비노기 영웅전 소개

4. 자이언트 서버? 자이언트 노예

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

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

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

10. 일단 자랑

12. 자랑 아님

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

14. 초기 계획2007년 초

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

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

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

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

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

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

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

22. 실마리 발견

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

24. Service Frontend Service 통합네트워크 Service

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

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

27. 통합 네트워크 구현

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

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

30. Service Operation Frontend Service 통합네트워크 Service Backend

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

32. Location Execution 클라이언트 Frontend Service Backend Service

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

34. Operation Layer Pipe Layer TCP/IP CORE

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

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

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

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

39. 1년여 뒤(2008년)

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

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

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

43. 분산 매커니즘 구현

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

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

46. 엔티티 오퍼레이션 Service Service Operation Entity Entity Entity Entity Operation Entity Entity Entity Entity

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

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

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

50. 크게 보면 이런 모양

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

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

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

55. 자랑 아님

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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