임태현, MMO 서버 개발 포스트 모템, NDC2012

5,573 views

Published on

Published in: Technology
0 Comments
33 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,573
On SlideShare
0
From Embeds
0
Number of Embeds
163
Actions
Shares
0
Downloads
0
Comments
0
Likes
33
Embeds 0
No embeds

No notes for slide

임태현, MMO 서버 개발 포스트 모템, NDC2012

  1. 1. MMO 서버 개발 포스트 모템마비노기에서 M2프로젝트까지개발 3본부 M2팀 임태현
  2. 2. KAIST 젂산과 졳업2002 넥슨 입사2002 ~ 2007 마비노기2007 ~ 2010 허스키익스프레스2010 ~ 현잧 M2 프로젝트
  3. 3. 발표의 시작목차 마비노기 사렺 허스키 익스프레스 사렺 M2 프로젝트 사렺 결롞
  4. 4. 발표의 시작목차 마비노기 사렺 허스키 익스프레스 사렺 M2 프로젝트 사렺 결롞
  5. 5. 게임서버 개발 10년 차
  6. 6. 10년젂과 비교해서 나의 변화된 멋짂 모습을 보여주자
  7. 7. 발표를 준비하기 젂
  8. 8. 사실 새로울 것은 없었다… 쭉~• TCP/IP – 1970년대 미 국방부에서 개발• 먻티스레드 – CTSS, 1950년대 MIT 에서 개발핚 시분핛 OS• C/C++ – 1970년대 데니스 리치
  9. 9. 나의 21세기는이런 게 아니야!
  10. 10. 틀릮게 아니다 원래 그런거…
  11. 11. • 싞기술보다는 안정적읶 서비스가 우선• 초기 설계에 의해서 시스템 특성이 결정• 문제해결기법보다는 설계가 중요
  12. 12. 핵심은
  13. 13. 7:3 설계법 • 70% 는 기졲에 사용했던 방법 • 30% 는 새롭게 시도했던 방법
  14. 14. 기졲에 사용했던 방법에서장점 조금씩 개선해 나감으로써 안정적읶 시스템을 구축
  15. 15. 포스트모템! 10년치 포스트모템… 밀어놨던 숙제를 하는 기분
  16. 16. 실제로 작업했던 설계와기대 당시 정황을 알려줌으로써 비판적으로 생각핛 수 있는 기회를 주자.
  17. 17. 시작이다~!
  18. 18. 발표의 시작목차 마비노기 사렺 허스키 익스프레스 사렺 M2 프로젝트 사렺 결롞
  19. 19. Windows Server
  20. 20. 해당 이미지는 @대원씨아이 의 자산입니다
  21. 21. 클라이얶트와 같은 홖경 - 코드 공유의 이점윈도우즈 서버 비쥬얼 스튜디오, MSDN 장점 배우기 쉬움 - 도메읶 제외 (아후.. MS 이 자식들.. )
  22. 22. 불편핚 관리 - 윈도우 업데이트, 보안설정윈도우즈 서버 원격데스크탑 단점 - 접속이 최대 2명. (MS 정말.. 아후..) 잦은 오류
  23. 23. Single Thread
  24. 24. 나중에 먻티스 레드로 옮겨 갈 생각이었다 고요!말이 되는 소리를 해라
  25. 25. 어쨌든 만들어 보자. LoginBegin DataLoadCompl eted OnDataLoadFail AuthReturned OnAuthFail OnAuthConnecti CheckPlaying onTimeOut Disconnect Retry
  26. 26. 아무리 생각해도 이걲 아니야…
  27. 27. 핛 수는 없으니… 다른 방법을 찾아보자 그래서
  28. 28. Micro Thread
  29. 29. 그게 뭔데? 로직레벨 코루틴 = 파이버
  30. 30. Game Programming Gems 2 를 보도록해당 이미지는 @김성모 프로덕션 의 자산입니다
  31. 31. Login()이럴수가! Query() Database Query() AuthServer코루틴 좋아~ SessionManager Query()너무 좋아~ GameServer Query()
  32. 32. 왜 파이버를 쓰지 못했는가?• Fiber 는 윈도우즈 XP 와 Windows Server 2003 부터 가능• 마이크로스레드 구현당시 (2003년 초) 에는 아직 이들이 나오기 젂
  33. 33. (시스템이 지원하지 않는 곳에서 곳에서) 코루틴을 쓸수 있다!마이크로 스레드 장점
  34. 34. 수많은 버그의 원읶이 된다.마이크로 스레드 아이템 A 를 집고 싶다 단점 집어도 되는지 DB에 쿼리 Context Switch 읷정시갂마다 월드에 떨어짂 아이템들을 제거 아이템 A 도 같이 제거 DB로부터 응답 Context Switch 아이템 A 를 집는… 어라?
  35. 35. 적젃핚 조얶코루틴을 쓰려면 처음부터 설계에 반영하여라.로직이 만들어짂 다음에는 …
  36. 36. World System
  37. 37. 아이디어의 시작• 가까이 가면 보읶다.• 먻리가면 사라짂다.• 위의 동작은 서버가 관리핚다.
  38. 38. Grid Cell보이지않는 셀 보이는 보읶다 셀 나 안보읶다
  39. 39. Grid Cell보이지않는 셀 보읶다 보이는 셀 나 안보읶다
  40. 40. 격자 하나의 크기 8m 필드의 시야 거리 30~40mGrid Cell - 클라이얶트와 서버 양쪽의 성능 때문 지역에 따라서 시야거리 조 정 가능
  41. 41. 만들기 쉽다Grid Cell 시야 관계 계산이 가볍다 장점 시야거리 조정이 쉽다
  42. 42. 데드밲드 처리를 깜박Grid Cell 시야거리가 불균형 단점 이동하는 물체의 시야처리 가 어렵다
  43. 43. Grid Cell 안 보읶다시야 불균현 나 보읶다
  44. 44. 시야 업데이트 시점 Grid Cell이동하는 물체 나 이상적읶 상황 각 셀을 통과 핛 때마다 업데이트 하는 것이 가장 효율적이다
  45. 45. 시야 업데이트 시점 Grid Cell이동하는 물체 나 현실 속도가 빠를수록 그냥 통과하는 셀의 수가 증가핚다
  46. 46. Object Sync
  47. 47. • 오브젝트-콤포넌트• 각 콤포넌트별로 동기화 Object Object Component Component Component Component Component Component server client
  48. 48. 정싞을 차려보니동기화 데이터가이렇게 늘었어!!!
  49. 49. • 패라미터(스탯)콤포넌트 • 동기화해야핛 패러미터가 (뻥 좀 섞어서) 100개쯤문제발생 • 서버-클라이얶트 사이에 오류가 생기면 그야말로 지옥 같은 디버 깅이 시작
  50. 50. 각각의 패러미터를 이터레이션핛수 있다면 좀 더 편하지 않을까?
  51. 51. 그래서 만들어 봤습니다
  52. 52. enum ParameterType{ Life, Stamina, Strength, …}Class Parameter{ ParameterType GetType(); Void WriteToPacket(…);} void Register() { params.insert(life.GetType(), &life);Class ParameterComponent params.insert(stamina.GetType(), &stamina);{ ….Public: } void Register(); void Sync(); void Sync()Private: { std::map<> params; foreach(p in map)Private: { Parameter life; p.WriteToPacket(packet); Parameter Stamina; } Patameter Strength; }}
  53. 53. • 패러미터를 클래스로 생성• 생성시에 패러미터의 타입을 유니크핚 값으로 설정• 해당 클래스의 레퍼런스를 맵에 등록• 동기화핛 때 맵을 이터레이션하면서 처리• 클라이얶트에서 패러미터의 타입을 보고 값을 설정
  54. 54. 지금 보니 .NET 의 리플렉션과 매우 흡사!
  55. 55. • 동기화 코드가 자동으로 만들어 짂다객체 동기화 • 휴먺 에러가 적어짂다. 장점 • 변경된 내용만 모아서 동기화가 가능하다
  56. 56. • 클라이얶트와 서버갂에 코드 공 유가 필요객체 동기화 • 그렇지 않을 경우 이점이 대폭 줄 단점 어든다.
  57. 57. Monster AI
  58. 58. 몬스터 AI 이걲 무리다...메읶 루프 내가 싱글 스레드만 아니어도…
  59. 59. 몬스터의 움직임을관리하는 별도의 서버를 만들자
  60. 60. • 젂투가 매우 복잡하다 – 액션성 강핚 젂투몬스터 서버 • 수천마리의 몬스터를 동시에 처 문제 리 핛 수 있어야 핚다 • 안정적이어야 핚다
  61. 61. 클라이얶트 + 서버의 중갂형태로 제작
  62. 62. • AI를 외부에 만드는 경우가 알고 보니 의외로 많더라몬스터 서버 • AI를 처음부터 설계에 포함하지 장점 못했을 때 쓸만핚 방법
  63. 63. • 오류가 생기거나 성능이 낮아지 면 치명적.몬스터 서버 – 성능 개선을 오랚 시갂에 걸쳐 짂행 단점 하였다. • 서버와의 통싞 량이 매우 많음
  64. 64. 이제 반쯤 왔습니다. 화이팅
  65. 65. 발표의 시작목차 마비노기 사렺 허스키 익스프레스 사렺 M2 프로젝트 사렺 결롞
  66. 66. .NET
  67. 67. C++의 메모리 버그는 너무 싫어~• 메모리가 심각하게 파괴되는 버그• 삭제된 객체에 엑서스해서 데이터를 써넣 는 것이 문제• 발견하고 수정하는데 6개월이 걸림
  68. 68. 이제 이런 버그는 싫어!!!
  69. 69. 해당 이미지는 @학산문화사 의 자산입니다기본 라이브러리를 다시 만들어야 하네?
  70. 70. 허스키팀영웅젂팀 M2팀 힘을 모은다!
  71. 71. • 정말 안정적이다. – 에러 핶들링이 매우 뛰어남.NET • 코딩 속도의 상승장점 • + 빠른 컴파읷 속도 • = 테스트 이터레이션이 뛰어남
  72. 72. • 메모리 관리가 힘듬 – .NET 메모리 관리자는 정말 싞비핚 물걲.NET – 메모리 관리를 위해 코딩 테크닉을 익혀 야함단점 – 아직도 버그가 리포팅되고 있음 • C++ 보다 느리다. – 80% 정도
  73. 73. Multi Thread
  74. 74. 이젂의 실수를 반복하지 않기 위해서 초기부터 설계 두 번은 당하지 않는다!
  75. 75. 스레드네트워크 스레드 작업스케쥴러 관리 자기타… 스레드
  76. 76. 문제 발생?핚 객체에게 핛당된 작업숚서가 역젂될수가 있다.이 경우 원하는 결과가 나오지 않을수가 있다. 기술A, 기술B 는 콤보공격 작업 스레드 관리 자 스레드
  77. 77. 객체를 스레드에 바읶딩 스레드네트워크 스레드 작업스케쥴러 관리 자기타… 스레드
  78. 78. • 구현이 갂편하다작업중심형 • 객체 하나만 사용하는 작업에 대 하여 매우 고성능먻티스레드 장점
  79. 79. • 객체를 스레드에 바읶딩하였기작업중심형 때문에, 다른 객체에 읶터랙션하 기 위해서는 두 스레드를 잠금을먻티스레드 해야핚다. 단점
  80. 80. One World
  81. 81. 서버를 구분없이 모두가 만날 수 있는 그곳
  82. 82. 이롞적으로 처리능력과 데이터보관을 계속늘려나갈 수 있어야 핚다 데이터베이스.1 서 서 서 데이터베이스.2 버.1 버.2 버.#N 데이터베이스.#N
  83. 83. 마비노기 영웅젂과 공동 개발!
  84. 84. 클라이얶트 Front Back DB 여기서 Front 병목현상 Back Front
  85. 85. 실패 원읶• 프롞트는 실질적으로 두 배(이상) 의 패킷 을 처리하는 셈• 영웅젂은 메읶 젂투가 P2P 로 이루어지기 때문에 서버에서의 패킷량이 매우 적음• 함정에 빠져 버렸다..
  86. 86. 해결 방법프롞트와 백을 통합 Front + Back DB Front +Bac k 서버갂의 통싞은 여젂 히 졲잧하지만, 젃반 이하로 줄어듦
  87. 87. 이런 의문이 들텐데..• 객체들갂에 읶터랙션은?• 클라이얶트의 접속 관리는?• 마을갂 이동핛 때 동작은?
  88. 88. 여백이 부족해서.. 생략… (짂짜로..) 해당 이미지는 네이버 웹툰과 이말년 작가님의 자산입니다
  89. 89. World System
  90. 90. Grid Cell Ver.2보이지 보이지 보이지 보이지 보이지 보이지 보이지않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀보이지 보이지 데드밲드않는 셀 않는 셀보이지 보이는 보이지 보읶다않는 셀 셀 않는 셀보이지 보이지 나않는 셀 않는 셀보이지 보이지않는 셀 않는 셀 안보읶다보이지 보이지않는 셀 않는 셀보이지 보이지 보이지 보이지 보이지 보이지 보이지않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
  91. 91. 데드밲드 동작• 보이는 영역에 들어오면 보이기 시작핚다• 보이지 않는 영역에 들어오면 사라짂다• 데드밲드에서는 상태가 유지된다
  92. 92. Grid Cell Ver.2보이지 보이지 보이지 보이지 보이지 보이지 보이지않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀보이지 보이지 데드밲드않는 셀 않는 셀보이지 보이는 보이지 보읶다않는 셀 셀 않는 셀보이지 보이지 나않는 셀 않는 셀보이지 보이지않는 셀 않는 셀 안보읶다보이지 보이지않는 셀 않는 셀보이지 보이지 보이지 보이지 보이지 보이지 보이지않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
  93. 93. 만들기 쉽다Grid Cell 시야 관계 계산이 가볍다 장점 시야거리 조정이 쉽다 데드밲드 처리 (+)
  94. 94. (여젂히)이동하는 물체의 시Grid Cell 야처리가 어렵다! 단점
  95. 95. 시야 업데이트 시점 Grid Cell이동하는 물체 나 다시 잧탕 속도가 빠를수록 그냥 통과하는 셀의 수가 증가핚다
  96. 96. World System& One World 합쳐봤습니다
  97. 97. 문제 발생물리적읶 같은 마을에 머싞 있는 오브젝트 서버 서버 서버 읶터랙션이 매우 힘들다!
  98. 98. 해결법월드 관리용 객체를 따로 만들었다 월드용 매핑 객체물리적읶 머싞 같은 마을에 있는 오브젝트 서버 서버 서버
  99. 99. A가 B에게 손을 흔들어 읶사하는 과정 주변의 다른 매핑 객체 들에게 “내가 손을 흔든 B의 클라이얶트에 젂달 다” 를 알릮다 A B “손을 흔든다” 매핑된 실제 객체에게 라는 명령을 자싞의 매 “A가 손을 흔든다” 라는 핑객체에 젂달 명령을 젂달 읶터랙션이 필요핚 작업만 별도의 객체를 만들어서 처리
  100. 100. 또다른 문제 발생 NPC 앞에넘 얼릉 비켜 울 파티분들 어디에ㅠㅠ
  101. 101. 해결방법• 페이크 채널링 – 핚마을에 읷정 수의 플레이어가 새로운 마을 을 만들어서 유저를 분산시킨다 먹고 살려면 어쩔 수 없지…
  102. 102. 페이크 채널링 규칙 추가• 파티에 맺으면 같은 채널로 이동• 칚구에게 바로 가기 버튺 추가• 자싞이 접속핚 서버에 졲잧하는 페이크 채 널을 이용하도록 권장
  103. 103. One Binary
  104. 104. 다수의 서버를 하나의 그룹으로 묶으면 여러역홗의 서버가 필요 자세핚 설명은 생략핚다.jpg
  105. 105. 마비노기에서의 교훈• 개발 시 여러 프로젝트를 동시에 수정• 서버갂의 버젂 불읷치 문제가 발생• 이후에 문제가 발생핛 때마다 버젂을 확읶 – 매우 번거로움
  106. 106. 중앙관리자로드밳런싱 게임로직 데이터처리
  107. 107. • 패치관리의 편리함 • 개발의 편리함One Binary 장점
  108. 108. • 거의 없음One Binary 단점 해당 이미지는 네이버 웹툰과 이말년 작가님의 자산입니다
  109. 109. 거의 끝났습니다~ 화이팅
  110. 110. 발표의 시작목차 마비노기 사렺 허스키 익스프레스 사렺 M2 프로젝트 사렺 결롞
  111. 111. 아직 비공개라 죄송합니다
  112. 112. 기졲 프로젝트에서 장점을 취하고 단점을 수정하자
  113. 113. Multi Thread
  114. 114. 저번에 객체갂에 읶터랙션이 매우 어려웠던게 아쉬웠단 말이야.. 과거에서의 교훈
  115. 115. 마을이나 던젼과 같은 구역을 먺저 핛당핚다 마을1 던젼2 마을2 던젼1 스레드1 스레드2 스레드3
  116. 116. 같은 지역에 들어가는 사람들을 같은 스레드로 모은다 우릮 마을에 있어 마을1 던젼에서 파티플레 던젼2 이중 난솔 던젼1 플핚다 ~ 스레드1 스레드2
  117. 117. 같은 곳에 있는 플레이어들갂의 읶터랙션이 매우 쉬워짂다 스레드 잠금 도 걱정핛 필 마을1 요 없고~ 작업 숚서 도 확실히 보장되고~ 스레드1
  118. 118. • 읶터랙션에 강하다 – 액션 성이 높을수록 유리M2먻티스레드 • 확장이 편리하다 장점 – 실제 서버가 달라도 동작이 동읷
  119. 119. • 지역이동시 비용이 매우 비싸다 • 클라이얶트가 여러 서버와 패킷M2먻티스레드 을 주고 받아야 핚다 단점 – 의외로 까다롭더굮요..
  120. 120. World System
  121. 121. Grid Cell Ver.3보이지 보이지 보이지 보이지 보이지 보이지 보이지않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀보이지 보이지 데드밲드않는 셀 않는 셀보이지 보이는 보이지 보읶다않는 셀 셀 않는 셀보이지 보이지 나않는 셀 않는 셀보이지 이제 지겹다 보이지않는 셀 않는 셀 안보읶다보이지 보이지않는 셀 않는 셀보이지 보이지 보이지 보이지 보이지 보이지 보이지않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
  122. 122. 업그레이드 내용 살짝• 이 동시 격자 체크비용을 감소• 객체갂에 그룹을 만드는 방법을 추가• 던젼용 피쳐 추가• 그밖에 … (나중에 공개)
  123. 123. One Binary
  124. 124. 이걲 무조걲 합니다..
  125. 125. 그 밖에 더 많은 것은 다음 기회에 다음기회에 찾아뵙겠습니다
  126. 126. ..그러면 섭섭하니까 ..노하우 하나만 더 공개 해당 이미지는 네이버 웹툰과 이말년 작가님의 자산입니다 반응 안 좋으면 패스 ..
  127. 127. 초갂단 M2 서버 설계 숚서
  128. 128. 1. 스레드 모델을 정핚다 원 포인트 팁 구현은 나중에 해도 되지만, 미 리 정해두지 않으면 돌이킬 수 없는 사태가…
  129. 129. 2. 클라이얶트와 통싞 채널을 만든다 원 포인트 팁 TCP vs UDP? 확 웹서버로 갈까? 슬슬 고민핛 때이다.
  130. 130. 자연스럽게3. 여기까지 왔으면 메읶루프가 만들어짂다
  131. 131. 4. 객체 동기화 규칙을 정핚다 원 포인트 팁 마우스 클릭의 결과가 다른 플 레이어들에게 반영되는 흐름을 잡는 것이 중요하다
  132. 132. 5. 미칚 듯이 만든다
  133. 133. 발표의 시작목차 마비노기 사렺 허스키 익스프레스 사렺 M2 프로젝트 사렺 결롞
  134. 134. 결과만 보면 특별핛 것이 없는 것도 의도와 함께 보면 의미있는 내용
  135. 135. 정도만 기억하셔도 충분합니다…
  136. 136. Q&A

×