Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 - 2부

1,256 views

Published on

NDC18에서 발표했습니다. 슬라이드 뒤쪽에 Q&A를 첨부했습니다.

SlideShare에 슬라이드 300장 제한이 생겨서 부득이하게 3부로 나눠서 올렸습니다. 보는 데 불편하시겠지만 양해를 부탁드립니다.

- 1부: https://subl.ee/~ndc18
- 2부: https://subl.ee/~ndc18.2
- 3부: https://subl.ee/~ndc18.3

자막은 subpptx로 붙였습니다: https://github.com/sublee/subpptx

Published in: Software
  • Be the first to comment

  • Be the first to like this

〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 - 2부

  1. 1. <야생의 땅: 듀랑고> 서버 아키텍처 Vol. 3 넥슨 • 왓 스튜디오 • 이흥섭 2부
  2. 2. SlideShare에 슬라이드 300장 제한이 생겨서 부득이하게 3부로 나눠서 올렸습니다. 보는 데 불편하시겠지만 양해를 부탁드립니다.
  3. 3. 섬4
  4. 4. 섬4 우선 듀랑고의 섬에 대해서 얘기해보죠.
  5. 5. 단일 채널 저희는 채널 방식을 쓰지 않습니다.
  6. 6. 유입이 몰리면? 그럼 유입이 몰릴 땐 어떻게 대응할 수 있을까요?
  7. 7. 유입이 몰리면? 새로 들어온 플레이어들이 한 곳에 너무 많이 뭉쳐 있으면
  8. 8. 유입이 몰리면? 서버 성능에도 문제가 생기고
  9. 9. 유입이 몰리면? 초반 게임플레이 경험도 나빠질 수 있을 겁니다.
  10. 10. 공간 팽창?채널 증설 다중 채널 방식에선 유동적으로 채널을 늘리는 게 좋은 대응법이 될 수 있지만
  11. 11. 공간 팽창?채널 증설 채널이 없는 저희는 공간을 팽창시켜서 플레이어들을 적당히 떨어뜨려야 했죠.
  12. 12. 단일 대륙 이 점에서 프로젝트 초기에 잠깐 꿈꿨던 단일 대륙 안은
  13. 13. 단일 대륙 일찍이 폐기하고
  14. 14. 군도 크고 작은 여러 섬을 운영하는 군도 안으로 방향을 잡았습니다.
  15. 15. 구역(zone) 일반적으로 MMORPG에선 전체 지역을 여러 구역으로 나눕니다.
  16. 16. 이음새 구역(zone) 보통 한 구역에 있다가 다른 구역으로 넘어갈 땐
  17. 17. 이음새 구역(zone) 로딩창이 뜨거나 주변 상황이 확 달라져서
  18. 18. 이음새 구역(zone) 구역과 구역 사이에 있는 이음새를 느낄 수 있게 됩니다.
  19. 19. 섬 이음새 듀랑고의 섬도 구역과 크게 다르지 않습니다.
  20. 20. 섬 이음새 한 섬에서 다른 섬으로 넘어가려고 하면
  21. 21. 항해 중… 서버와의 연결이 끊어지고 이런 로딩창도 뜨죠.
  22. 22. 섬 안쪽 •이음새 없음(seamless) •면적 제한 없음 살짝 다른 점이 있다면
  23. 23. 섬 안쪽 •이음새 없음(seamless) •면적 제한 없음 단일 대륙을 위해서 준비했던 심리스 기술이
  24. 24. 섬 안쪽 •이음새 없음(seamless) •면적 제한 없음 섬에도 그대로 적용돼 있어서 섬이 아무리 커도
  25. 25. 섬 안쪽 •이음새 없음(seamless) •면적 제한 없음 그 안쪽에선 이음새 없이 돌아다닐 수 있다는 점입니다.
  26. 26. 섬 안쪽 •이음새 없음(seamless) •면적 제한 없음 섬 면적에 게임디자인적인 제한은 있어도 기술적인 제한은 없습니다.
  27. 27. 채널 증설 섬 생성 군도로 인해 유입이 몰리면 채널 대신 섬을 늘려서 대응할 수 있습니다.
  28. 28. 채널 감축 섬 폐쇄? 하지만 유입이 빠졌을 때에도 탄력적으로 대응하기엔 어려움이 있습니다.
  29. 29. 잔뜩 만들어 둔 섬을 폐쇄하자니 그곳엔 이미 플레이어들이 만들어 둔
  30. 30. 집과 사유지가 있어서 함부로 정리할 수 없거든요.
  31. 31. 폭발적으로 늘었다가 줄어드는 플레이어와는 다르게
  32. 32. 섬은 한 번 늘리면 쉽게 줄일 수 없다는 한계가 있습니다.
  33. 33. 인구 부족 인구 과밀 한편 각 섬의 디자인에는 적절한 인구수를 정해두고 있습니다.
  34. 34. 인구 부족 인구 과밀 한 두 명 만을 위해서 수 백 명 짜리 섬을 통째로 만들어내면
  35. 35. 인구 부족 인구 과밀 자원이 과잉공급되고
  36. 36. 인구 부족 인구 과밀 MMO만의 북적거리는 재미도 느낄 수 없을 겁니다.
  37. 37. 인구 부족 인구 과밀 반면 한 섬에 너무 많은 플레이어가 몰리면
  38. 38. 인구 부족 인구 과밀 서버도 클라이언트도 모두 과부하에 걸려서
  39. 39. 인구 부족 인구 과밀 제대로 된 게임플레이를 즐길 수가 없습니다.
  40. 40. 인구 부족 인구 과밀 게다가 땅이라는 한정된 자원을 수 많은 플레이어가 같이 공유하다 보면
  41. 41. 인구 부족 인구 과밀 경쟁이 과열될 수도 있죠.
  42. 42. 인구 부족 인구 과밀 인구 부족과 인구 과밀 사이에 있는 가장 적절한 인구밀도를 맞춰줘야만
  43. 43. 인구 부족 인구 과밀 적당히 다른 플레이어들과 부대끼면서도
  44. 44. 인구 부족 인구 과밀 쾌적한 게임플레이를 이어 나갈 수 있습니다.
  45. 45. 인구 분배기 섬의 인구밀도를 맞추는 데에는 인구 분배기라는 장치가 쓰입니다.
  46. 46. 인구 분배기 이 장치는 플레이어를 적절한 섬에 배정해주는 역할을 하죠.
  47. 47. 인구 분배기 배정할 섬이 없으면 여기서 새로운 섬이 만들어지기도 합니다.
  48. 48. 인구 분배기 •항해시에만 개입 가능 •신중히 섬 생성 •기존 섬을 꾸준히 활용 그런데 이 인구 분배기는
  49. 49. 인구 분배기 •항해시에만 개입 가능 •신중히 섬 생성 •기존 섬을 꾸준히 활용 플레이어가 다른 섬을 찾을 때에만 개입할 수 있습니다.
  50. 50. 인구 분배기 •항해시에만 개입 가능 •신중히 섬 생성 •기존 섬을 꾸준히 활용 그때문에 이미 인구가 과밀해진 섬을 구원할 방법이 마땅치 않고
  51. 51. 인구 분배기 •항해시에만 개입 가능 •신중히 섬 생성 •기존 섬을 꾸준히 활용 한 번 만든 섬을 쉽게 회수할 수 없다 보니
  52. 52. 인구 분배기 •항해시에만 개입 가능 •신중히 섬 생성 •기존 섬을 꾸준히 활용 새로운 섬을 적극적으로 만들지 못 한다는 큰 제약을 갖고 있습니다.
  53. 53. 섬 •동적으로 공간 조절 •여러 섬으로 인구 분산 •단일 채널 세계의 핵심 •다중 채널에 비해 유연성 부족 섬을 동적으로 만들어서 공간을 조절하고
  54. 54. 섬 •동적으로 공간 조절 •여러 섬으로 인구 분산 •단일 채널 세계의 핵심 •다중 채널에 비해 유연성 부족 거기에 인구를 분산시키는 방법은
  55. 55. 섬 •동적으로 공간 조절 •여러 섬으로 인구 분산 •단일 채널 세계의 핵심 •다중 채널에 비해 유연성 부족 단일 채널 MMO 세계에서 가장 핵심적인 요소입니다.
  56. 56. 섬 •동적으로 공간 조절 •여러 섬으로 인구 분산 •단일 채널 세계의 핵심 •다중 채널에 비해 유연성 부족 하지만 다중 채널 방식에 비해선
  57. 57. 섬 •동적으로 공간 조절 •여러 섬으로 인구 분산 •단일 채널 세계의 핵심 •다중 채널에 비해 유연성 부족 빠르고 탄력적으로 대응하지 못 한다는 큰 약점을 갖고 있습니다.
  58. 58. 특히 인구 분배기가 잘 작동하지 않을 때 치명적인 상황으로 치닫을 수 있는데
  59. 59. 실제로 출시 초반 서버장애의 가장 주요한 원인은
  60. 60. 인구밀도 조절 실패였습니다.
  61. 61. 이 얘기는 이따가 다시 다룰게요.
  62. 62. 청크5
  63. 63. 청크5 이번엔 섬 안 쪽으로 들어가 보겠습니다.
  64. 64. 청크 30m 30m 모든 섬은 면적과 무관하게 청크라는 균일한 조각으로 나뉘어 있습니다.
  65. 65. 청크 30m 30m 이렇게 나눈 청크는 여기저기에 쓰이는데요
  66. 66. 섬 전체에서 벌어지는 여러가지 상황 중에서
  67. 67. 어느 정도를 클라이언트에 스트리밍할지도
  68. 68. 9청크 스트리밍 청크 단위로 결정합니다.
  69. 69. 9청크 스트리밍 주변 9청크만 알려주게 돼있죠.
  70. 70. 노드 섬 한 노드가 처리하는 공간의 단위도 섬이 아니라
  71. 71. 노드 청크 청크입니다.
  72. 72. 노드 청크 한 노드가 섬 전체를 통째로 처리하는 대신
  73. 73. 노드 청크 몇몇 청크만 처리하기 때문에 섬이 아무리 넓어도 감당할 수 있는 거죠.
  74. 74. 노드 청크 청크마다 전담하는 노드가 정해져 있지는 않습니다.
  75. 75. 노드 청크 반대로 노드가 스스로 자기가 맡을 청크를 고르게 돼있죠.
  76. 76. 노드 청크 이때 노드와 청크는 1:1 관계가 아니라 N:N 관계입니다.
  77. 77. 노드 청크 한 청크를 한 노드가 전담하지 않고 여러 노드가 나눠서 처리하는 거죠.
  78. 78. 노드 청크 어떤 노드든 자기가 원하기만 하면 아무 청크라도 맡을 수 있습니다.
  79. 79. 이음새 없음 그러다 보니 플레이어가 청크 사이를 오갈 때
  80. 80. 이음새 없음 연결돼 있던 노드에서 다른 곳으로 옮겨갈 필요가 없어서
  81. 81. 이음새 없음 이음새를 느낄 수 없는 겁니다.
  82. 82. 노드 한 청크 이렇게 한 청크를 여러 노드가 나눠서 처리하는 건
  83. 83. 노드 한 청크 가용성을 높이는 데에도 도움이 되는데요
  84. 84. 노드 한 청크 한 노드가 죽더라도 재접속만 하면
  85. 85. 노드 한 청크 게임을 바로 이어 나갈 수 있기 때문입니다.
  86. 86. 노드 한 청크 RPC로 동기화 이때 같은 청크를 맡은 노드끼리는 RPC로 서로의 상태를 동기화합니다.
  87. 87. Pub/Sub 이런 노드 간 RPC엔 비동기 메시징 패턴 중 하나인
  88. 88. Pub/Sub Pub/Sub 패턴이 쓰입니다.
  89. 89. 구독자(Sub) 발행자(Pub) Pub/Sub 패턴에는 발행자와 구독자 역할이 있습니다.
  90. 90. 구독자(Sub) 발행자(Pub) 발행자는 메시지를 쏘는 쪽인데
  91. 91. 구독자(Sub) 채널 별 메시지 발행자(Pub) 각 메시지를 개별 구독자에게 직접 쏘는 대신에
  92. 92. 구독자(Sub) 채널 별 메시지 발행자(Pub) 특정한 채널에 쏘게 됩니다.
  93. 93. 구독자(Sub) 채널 별 메시지 발행자(Pub) 만약 아무 구독자도 그 채널에 관심이 없다면
  94. 94. 구독자(Sub) 채널 별 메시지 발행자(Pub) 메시지는 조용히 버려지죠.
  95. 95. 구독자(Sub) 발행자(Pub) 구독자는 채널을 구독할 수 있습니다.
  96. 96. 구독자(Sub) 구독 구독 구독 발행자(Pub) 구독자가 채널을 구독하면
  97. 97. 구독자(Sub) 발행자(Pub) 그때부터 메시지가 구독자에게 전달됩니다.
  98. 98. 구독자(Sub) 발행자(Pub) 이때 발행자가 메시지를 한 번만 쏘더라도
  99. 99. 구독자(Sub) 발행자(Pub) 그 채널의 구독자가 여럿이면
  100. 100. 구독자(Sub) 발행자(Pub) 여러 구독자가 동시에 같은 메시지를 받을 수 있어서
  101. 101. 구독자(Sub) 발행자(Pub) 멀티캐스팅이나 브로드캐스팅처럼 쓸 수 있습니다.
  102. 102. 구독자이자 발행자 노드 듀랑고 게임서버의 각 노드는 모두 구독자이자 발행자입니다.
  103. 103. 구독자이자 발행자 노드 채널을 매개로 서로 자유롭게 메시지를 주고받을 수 있죠.
  104. 104. 노드 간 RPC의 재료 이는 노드 간 RPC의 재료로 쓰입니다.
  105. 105. 청크 = 채널 각 청크는 하나의 Pub/Sub 채널인데요
  106. 106. 노드 청크 RPC로 동기화 같은 청크를 처리하고 있는 노드끼리는 그 청크의 채널을 통해서
  107. 107. 노드 청크 RPC로 동기화 서로 RPC를 주고받고 필요한 정보를 동기화하죠.
  108. 108. 노드2 노드1 노드3 이런 방법으로 한 청크를 여러 노드로 나눠서 처리할 수 있습니다.
  109. 109. 노드2 노드1 노드3 이때 다른 노드에 접속한 플레이어는
  110. 110. 노드2 노드1 노드3 고스트로 만들어져서 같이 동기화되는데요
  111. 111. 노드2 노드1 노드3 어떤 노드에서 누군가 집을 짓는다면
  112. 112. 노드2 노드1 노드3 모든 노드에서 똑같이 이 인과관계를 파악할 수 있습니다.
  113. 113. 청크 • 임의의 섬을 일정한 크기로 분할 • 노드에 귀속되지 않는다. • 몇 대 죽어도 버티기 청크는 섬을 일정한 크기로 분할해서 섬 면적에 제한을 없애주고
  114. 114. 청크 • 임의의 섬을 일정한 크기로 분할 • 노드에 귀속되지 않는다. • 몇 대 죽어도 버티기 서버의 처리 단위를 작게 규격화 해줍니다.
  115. 115. 청크 • 임의의 섬을 일정한 크기로 분할 • 노드에 귀속되지 않는다. • 몇 대 죽어도 버티기 노드와 청크 사이의 결합이 느슨한 덕에
  116. 116. 청크 • 임의의 섬을 일정한 크기로 분할 • 노드에 귀속되지 않는다. • 몇 대 죽어도 버티기 장애가 발생하더라도 쉽게 대응할 수 있죠.
  117. 117. 청크 • 임의의 섬을 일정한 크기로 분할 • 노드에 귀속되지 않는다. • 몇 대 죽어도 버티기 하지만 명백한 한계가 있습니다.
  118. 118. 2명 9명 4명 9명 3명 9명 한 청크에 몰려있는 플레이어를 여러 노드로 나누면
  119. 119. 2명 9명 4명 9명 3명 9명 게임플레이 로직 부하는 분산시킬 수 있지만
  120. 120. 2명 9명 4명 9명 3명 9명 각 노드가 그 청크에서 동기화해야 되는 플레이어의 수가 줄어들진 않는단 겁니다.
  121. 121. 2명 9명 4명 9명 3명 9명 게다가 노드들끼리 고스트를 동기화하는 데에도
  122. 122. 2명 9명 4명 9명 3명 9명 어느 정도는 비용이 들고요.
  123. 123. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 그래서 한 청크를 얼마나 많은 노드가 나눠서 처리하느냐에 따라서
  124. 124. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 부하 양상이 달라지는데요
  125. 125. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 한 청크를 한 노드가 전담하게 설정하면
  126. 126. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 동기화 부하는 없어지지만 게임플레이 로직 부하가 늘어납니다.
  127. 127. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 반대로 한 청크를 너무 많은 노드에 분산시키면
  128. 128. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 동기화 부하의 비중이 커지죠.
  129. 129. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 그 사이에서 부하의 총합을 낮출 수 있는
  130. 130. 한 청크에 한 노드 한 청크에 너무 많은 노드 게임플레이 부하 동기화 부하 적절한 지점을 찾아야 한다는 어려움이 있습니다.
  131. 131. 하지만 그 균형점을 찾는다고 해도 한 청크에 너무 많은 플레이어가 몰리면
  132. 132. 더 이상 제대로 된 성능을 내긴 어렵습니다.
  133. 133. 지금도 가끔 이런 상황에서 서버 랙이 발생하고 있죠.
  134. 134. 이렇게 되지 않으려면
  135. 135. 인구 분배기의 역할이 굉장히 중요합니다.
  136. 136. 한계 •게임플레이 로직만 부하분산 가능 •더 분산할 수록 동기화 부담 •청크보다 작게 나눌 수 없음 듀랑고 서버의 청크 기반 분산에는 이런 한계가 있습니다.
  137. 137. 한계 •게임플레이 로직만 부하분산 가능 •더 분산할 수록 동기화 부담 •청크보다 작게 나눌 수 없음 아직 해답을 찾은 건 아니지만
  138. 138. 한계 •게임플레이 로직만 부하분산 가능 •더 분산할 수록 동기화 부담 •청크보다 작게 나눌 수 없음 현재 최적화 방법과 구조적으로 개선할 방법을 면밀히 검토하는 중입니다.
  139. 139. 클러스터링6
  140. 140. 클러스터링6 이번엔 노드들이 어떻게 한 클러스터를 이루는지 살펴보겠습니다.
  141. 141. 플레이어 서비스 동물 서비스 전투 서비스 대화 서비스로그인 서비스 부동산 서비스 게임서버 노드 게임서버 노드들은 몇 가지 역할로 구분돼 있습니다.
  142. 142. 플레이어 서비스 동물 서비스 전투 서비스 대화 서비스로그인 서비스 부동산 서비스 게임서버 노드 가령 플레이어 서비스는 클라이언트와 직접 연결을 맺고
  143. 143. 플레이어 서비스 동물 서비스 전투 서비스 대화 서비스로그인 서비스 부동산 서비스 게임서버 노드 동기화나 게임플레이 로직 같은 걸 처리해주고
  144. 144. 플레이어 서비스 동물 서비스 전투 서비스 대화 서비스로그인 서비스 부동산 서비스 게임서버 노드 부동산 서비스는 땅에 박힌 정적인 개체를 관리해줍니다.
  145. 145. 플레이어 서비스 동물 서비스 전투 서비스 대화 서비스로그인 서비스 부동산 서비스 게임서버 노드 이 중 어떤 서비스에도 중앙 집중적인 요소는 없어서
  146. 146. 플레이어 서비스 동물 서비스 전투 서비스 대화 서비스로그인 서비스 부동산 서비스 게임서버 노드 일부 노드가 죽더라도 서비스가 망가지진 않습니다.
  147. 147. 중앙 관리 노드 흔히 Central Server라고 부르는 중앙 관리 노드 같은 것도 없죠.
  148. 148. SPOF 즉, 게임서버엔 SPOF가 없습니다.
  149. 149. 간단한 감축 SPOF가 없으면 서버 성능이 남아돌아서 규모를 축소해야 될 때
  150. 150. 간단한 감축 간단하게 노드를 끄는 것만으로도 감축을 진행할 수 있습니다.
  151. 151. 노드 중계소 한편 게임서버 노드끼리 서로 통신할 땐 중앙에 집중돼있는 메시지 중계소를 거치는 대신
  152. 152. 노드 모두가 서로와 직접적인 연결을 맺습니다.
  153. 153. 노드 이 구조에선 메시징 처리가 완전하게 분산되다 보니
  154. 154. 노드 짧은 시간에 아주 많은 메시지를 주고받아도 충분히 수용할 수 있죠.
  155. 155. 노드 새 노드? 하지만 각 노드가 다른 노드의 주소를 모두 알아내서
  156. 156. 노드 새 노드? 직접 연결을 맺어야 한다는 번거로움이 있습니다.
  157. 157. 주소록 10.123.4.56:12345 10.123.4.42:14242 10.123.52.8:19940 만약에 설정파일에 DB 주소를 적는 것처럼
  158. 158. 주소록 10.123.4.56:12345 10.123.4.42:14242 10.123.52.8:19940 띄울 노드들의 주소도 주소록에 손으로 적는 방식을 쓴다면
  159. 159. 주소록 10.123.4.56:12345 10.123.4.42:14242 10.123.52.8:19940 급하게 노드를 추가하거나 장애로 인해서 제외시킬 때
  160. 160. 주소록 10.123.4.56:12345 10.123.4.42:14242 10.123.52.8:19940 같이 신경 써줘야 하니까 불편할 겁니다.
  161. 161. 주소록 etcd 그러지 않도록 저희는 주소록을
  162. 162. 주소록 etcd etcd라는 컨센서스 코디네이터에서 관리하고 있습니다.
  163. 163. 노드 새 노드 새로운 노드가 켜지면
  164. 164. 주소록 etcd 새 노드 노드 스스로 주소록에 자기 주소를 등록하고
  165. 165. 노드 새 노드 클러스터에도 바로 합류하게 됩니다.
  166. 166. 노드 새 노드 노드를 켜는 것만으로 별도의 설정 없이 쉽게 증설할 수 있죠.
  167. 167. 다른 모든 노드 연결 과다 노드 하지만 이 구조엔 확장성 문제가 있습니다.
  168. 168. 다른 모든 노드 연결 과다 노드 아주 많은 노드를 띄우면 TCP 클라이언트 포트 같은
  169. 169. 다른 모든 노드 연결 과다 노드 시스템 자원이 사용 제한에 걸릴 수 있겠죠.
  170. 170. 다른 모든 노드 연결 과다 노드 이런 연결 과다 문제를 해결하기 위해서
  171. 171. 샤드 한 클러스터를 여러 개의 샤드로 나눴습니다.
  172. 172. 샤드 한 샤드의 노드들은 모두 서로 연결돼 있어서
  173. 173. 자유로운 RPC 샤드 자유롭게 RPC를 주고받을 수 있습니다.
  174. 174. 샤드1 샤드2 반면 다른 샤드에 있는 노드끼리는 직접적인 연결을 맺는 대신
  175. 175. 샤드1 일부 RPC 중계 샤드2 강도가 높지 않은 일부 간단한 RPC만 중계해주는 방식을 쓰고 있죠.
  176. 176. 노드 섬 같은 섬을 처리하는 노드들 사이에는
  177. 177. 노드 섬 자유로운 RPC 필요 지속적인 동기화를 위해서 RPC가 자유롭게 오갈 수 있어야 합니다.
  178. 178. 샤드 섬 자유로운 RPC 모두 한 샤드에 모여 있어야 하는 거죠.
  179. 179. 샤드 섬 귀속 그래서 각 섬은 특정 샤드에 귀속됩니다.
  180. 180. 섬 만약 한 샤드의 모든 노드에서 전부 장애가 발생하면
  181. 181. 섬 그 샤드에 배정된 몇몇 섬은 통째로 먹통이 될 수도 있습니다.
  182. 182. 섬 이렇게 동적으로 망가진 샤드를 배제할 수도 있겠지만
  183. 183. 섬 아직까지 샤드 구성은 정적으로 설정하고 있어서
  184. 184. 섬 이런 상황에서도 안전한 건 아닙니다.
  185. 185. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 여기까지 듀랑고 게임서버의 클러스터 구조를 살펴봤습니다.
  186. 186. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 모든 노드가 이중화 돼있어서 SPOF가 없고
  187. 187. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 몇몇 노드에 장애가 생겨도 서비스에 큰 지장은 없습니다.
  188. 188. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 그 덕에 노드를 끄는 것만으로 쉽게 감축할 수 있고
  189. 189. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 노드가 스스로 클러스터에 합류함으로써
  190. 190. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 증설 또한 쉽게 할 수 있습니다.
  191. 191. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 그 과정에서 겪었던 확장성 문제도
  192. 192. 클러스터링 •SPOF 없음 •유연하게 증설/감축 •높은 확장성 샤드라는 장치로 현재는 안정적으로 해결된 상태입니다.
  193. 193. 무중단 패치7
  194. 194. 무중단 패치7 이런 클러스터 구조를 바탕으로 듀랑고 서버는
  195. 195. 무중단 패치7 서비스 중단 없이 패치하는 게 가능합니다.
  196. 196. 무중단 패치7 무중단 패치라니, 의아해 하시는 분도 많을 것 같은데요
  197. 197. 〈점검의 땅〉 듀랑고는 출시 초기에 매일 시행한 잦은 점검으로
  198. 198. 〈점검의 땅〉 〈점검의 땅〉이라는 슬픈 별명을 갖게 됐습니다.
  199. 199. 잦은 점검 당시엔 기술적인 문제로
  200. 200. 잦은 점검 무중단 패치를 도입할 수 없는 상황이었는데
  201. 201. 잦은 점검 그렇다고 눈앞에 빤히 보이는 문제를 모른 척 방치할 순 없어서
  202. 202. 잦은 점검 지속적인 서비스 시간을 포기하고 잦은 점검을 감행했었죠.
  203. 203. 공멸현상 당시에 무중단 패치를 도입할 수 없었던 건
  204. 204. 공멸현상 서버에서 발생한 공멸현상 때문이었습니다.
  205. 205. 공멸현상 그 내용은 이런데요
  206. 206. 공멸현상 무슨 이유에서든 어떤 노드가 죽으면
  207. 207. 공멸현상 연결 돼있던 주변 노드들에서 일부 크래시가 발생하는 현상이었습니다.
  208. 208. 공멸현상 처음 이 문제를 겪었을 땐 원인규명에 실패해서
  209. 209. 공멸현상 해결을 미루고 무중단 패치는 잠정적으로 포기했었죠.
  210. 210. 공멸현상 하지만 출시하고 나니 여러가지 이유로 죽는 노드가 생겨나면서
  211. 211. 공멸현상 문제의 심각성이 더 높아졌습니다.
  212. 212. 공멸현상 다시 한 번 이 현상을 면밀히 조사하게 됐죠.
  213. 213. libzmq#2942 이 문제는 저희가 노드 간 통신에 쓰는 라이브러리인 ZeroMQ의 버그였습니다.
  214. 214. libzmq#2942 조사 과정에서 재현 조건을 명확히 규명해냈고
  215. 215. libzmq#2942 GitHub ZeroMQ 프로젝트에 제보한 덕분에 현재 최신 버전에선 해결된 상태입니다.
  216. 216. 자유로운 종료 더 이상 다른 노드가 죽는 걸 두려워하지 않고 게임서버 노드를 맘껏 끌 수 있게 됐죠.
  217. 217. 자유로운 감축 자유로운 감축도 비로소 가능해졌습니다.
  218. 218. 무중단 패치 이를 바탕으로 저희가 채택한 무중단 패치 방법은 이렇습니다.
  219. 219. Rolling Update Rolling Update라고 부르는 방법인데요
  220. 220. 구버전 신버전 여기 구버전 클러스터가 있습니다.
  221. 221. 구버전 신버전 우선 각 샤드에서 절반을 끕니다.
  222. 222. 구버전 신버전 플레이어들은 나머지 절반으로 재접속하게 되겠죠.
  223. 223. 구버전 신버전 지금은 이 순간에 튕기는 경험이 그리 좋지 않지만
  224. 224. 구버전 신버전 조용히 재접속하는 것도 조만간 가능할 것 같습니다.
  225. 225. 구버전 신버전 꺼진 절반에는 신버전을 배포하고
  226. 226. 구버전 신버전 다시 켭니다.
  227. 227. 구버전 신버전 이제 새로 접속하는 플레이어들은 신버전 노드로 들어갈 수 있습니다.
  228. 228. 구버전 신버전 그 다음엔
  229. 229. 구버전 신버전 나머지 절반에서도
  230. 230. 구버전 신버전 같은 과정을 거칩니다.
  231. 231. 구버전 신버전 이제 모든 노드가 신버전을 갖고 있죠.
  232. 232. 무중단 패치 무중단 패치는 서비스 중단시간을 최소화하는 훌륭한 방법이지만
  233. 233. 무중단 패치 저희의 경우 모든 경우에 적용할 수 있는 건 아니었습니다.
  234. 234. 릴리즈 핫픽스 •프로토콜 변경 •데이터 구조 변경 •큰 밸런스 조정 •큰 콘텐츠 투입 •로그 추가 •치명적인 버그 수정 •최적화 저희는 git-flow 정책을 따라서 패치를 두 종류로 나눠서 관리하는데요
  235. 235. 릴리즈 핫픽스 •프로토콜 변경 •데이터 구조 변경 •큰 밸런스 조정 •큰 콘텐츠 투입 •로그 추가 •치명적인 버그 수정 •최적화 새 게임플레이를 선보이는 릴리즈 패치엔
  236. 236. 릴리즈 핫픽스 •프로토콜 변경 •데이터 구조 변경 •큰 밸런스 조정 •큰 콘텐츠 투입 •로그 추가 •치명적인 버그 수정 •최적화 구버전을 유지하면서 신버전을 준비하기엔
  237. 237. 릴리즈 핫픽스 •프로토콜 변경 •데이터 구조 변경 •큰 밸런스 조정 •큰 콘텐츠 투입 •로그 추가 •치명적인 버그 수정 •최적화 어려운 변경점이 포함되는 경우가 많습니다.
  238. 238. 신채널 구채널 다중 채널 방식에선 채널 단위로 패치를 적용하면서 확산시킬 수 있지만
  239. 239. 채널을 안 쓰는 저희가 릴리즈 패치를 무중단으로 진행하면
  240. 240. 한 곳에 모인 플레이어들이
  241. 241. 서로 다른 세계를 접하게 되는 일도 벌어질 수 있습니다.
  242. 242. 릴리즈 핫픽스 •프로토콜 변경 •데이터 구조 변경 •큰 밸런스 조정 •큰 콘텐츠 투입 •로그 추가 •치명적인 버그 수정 •최적화 반면 핫픽스에는 게임플레이에 변화 없이
  243. 243. 릴리즈 핫픽스 •프로토콜 변경 •데이터 구조 변경 •큰 밸런스 조정 •큰 콘텐츠 투입 •로그 추가 •치명적인 버그 수정 •최적화 내부적인 개선과 조치만 포함되는 경우가 많아서
  244. 244. 릴리즈 핫픽스 •프로토콜 변경 •데이터 구조 변경 •큰 밸런스 조정 •큰 콘텐츠 투입 •로그 추가 •치명적인 버그 수정 •최적화 무중단 패치로 배포하기에 적합합니다.
  245. 245. 릴리즈 핫픽스 정기점검 무중단점검 그래서 릴리즈는 항상 정기점검으로 배포하고
  246. 246. 릴리즈 핫픽스 정기점검 무중단점검 핫픽스는 가능한 한 무중단점검으로 패치하는 정책을 가지고 있습니다.
  247. 247. 무중단 패치 무중단 패치는 예전부터 오랜 꿈이었고 서버 구조도 거기에 맞춰서 잡아왔는데
  248. 248. 무중단 패치 중간에 엉뚱한 이유 때문에 포기했었지만 이제라도 가능해져서 다행입니다.
  249. 249. 인프라8
  250. 250. 인프라8 지금까지 살펴본 듀랑고의 서버를 운영하기에 가장 적합한 인프라는
  251. 251. Amazon Web Services 단연코 AWS였습니다.
  252. 252. Amazon Web Services 몇 년 전만 해도 업계에 클라우드에 대한 불신과 두려움이 있었던 것 같은데
  253. 253. Amazon Web Services 이제는 클라우드가 새로운 기본값이 된 것 같습니다.
  254. 254. AWS •필요에 따라 수많은 호스트 공급 •풍부한 관리형 서비스 •인프라 자동화 AWS 덕에 저희는 필요에 따라 일시적으로 수많은 호스트를 공급할 수 있었고
  255. 255. AWS •필요에 따라 수많은 호스트 공급 •풍부한 관리형 서비스 •인프라 자동화 AWS에서 제공하는 풍부한 관리형 서비스로
  256. 256. AWS •필요에 따라 수많은 호스트 공급 •풍부한 관리형 서비스 •인프라 자동화 가용성에 대한 고민도 많이 덜 수 있었습니다.
  257. 257. AWS •필요에 따라 수많은 호스트 공급 •풍부한 관리형 서비스 •인프라 자동화 또 DevOps 생태계가 성숙해서
  258. 258. AWS •필요에 따라 수많은 호스트 공급 •풍부한 관리형 서비스 •인프라 자동화 인프라 구축을 자동화하는 데에 있어서도 탁월한 선택이었죠.
  259. 259. IAM VPC EC2 ECS ELB S3 RDS ElastiCache CloudFront Route 53 SQS Lambda EMR Elasticsearch Service Kinesis 듀랑고에 쓰이는 AWS의 서비스만 해도 15가지가 넘습니다.
  260. 260. IAM VPC EC2 ECS ELB S3 RDS ElastiCache CloudFront Route 53 SQS Lambda EMR Elasticsearch Service Kinesis 이렇게 서버 하나 만드는 데 같이 챙겨야 하는 인프라 설정이 많다 보니
  261. 261. IAM VPC EC2 ECS ELB S3 RDS ElastiCache CloudFront Route 53 SQS Lambda EMR Elasticsearch Service Kinesis 이들의 관계를 정리하고 지속적으로 배포할 수 있도록
  262. 262. IAM VPC EC2 ECS ELB S3 RDS ElastiCache CloudFront Route 53 SQS Lambda EMR Elasticsearch Service Kinesis 규격화하는 게 중요했습니다.
  263. 263. Terraform Ansible 저희는 인프라를 만드는 데엔 Terraform을, 게임서버를 배포하는 데엔 Ansible을 씁니다.
  264. 264. 만들고 붓고 부수고, 서버 관리 배포 이야기 김찬웅, NDC18 여기에 관련해서는 백엔드 엔지니어 김찬웅 님이 자세히 다뤘습니다.
  265. 265. 만들고 붓고 부수고, 서버 관리 배포 이야기 김찬웅, NDC18 크고 작은 베타테스트와 라이브 서비스를 거치면서
  266. 266. 만들고 붓고 부수고, 서버 관리 배포 이야기 김찬웅, NDC18 저희의 인프라 관리 체계를 발전시킨 과정을 엿보실 수 있으니
  267. 267. 만들고 붓고 부수고, 서버 관리 배포 이야기 김찬웅, NDC18 DevOps에 관심있는 분들의 많은 참여 부탁드립니다.
  268. 268. EC2 인스턴스 장애 1/2 checks passed AWS를 쓴다고 호스트 장애가 발생하지 않는 건 아닙니다.
  269. 269. EC2 인스턴스 장애 1/2 checks passed 아주 낮은 확률이긴 하지만 EC2 인스턴스라는 가상머신이
  270. 270. EC2 인스턴스 장애 1/2 checks passed 헬스체크에 실패하고 먹통이 되는 경우가 있죠.
  271. 271. EC2 인스턴스 장애 1/2 checks passed 아무리 가상화 돼있다고 해도
  272. 272. EC2 인스턴스 장애 1/2 checks passed 물리적인 장비에서 발생하는 기계 고장까지 극복할 순 없기 때문입니다.
  273. 273. EC2 인스턴스 장애 저희가 개발 단계에서 인스턴스를 몇 십 개만 운영할 땐
  274. 274. EC2 인스턴스 장애 1년에 한 두 번 겪을까 말까 한 드문 일이었는데
  275. 275. EC2 인스턴스 장애 게임을 출시한 후 인스턴스 수를 대폭 늘리면서
  276. 276. EC2 인스턴스 장애 이런 장애를 겪는 일도 많아졌습니다.
  277. 277. EC2 인스턴스 장애 지금도 1주일에 호스트 한 두개 정도는 이 이유로 죽고 있습니다.
  278. 278. 몇 대 죽어도 버티기 하지만 SPOF를 없애고 몇 대 죽어도 버틸 수 있게 설계한 덕에
  279. 279. 몇 대 죽어도 버티기 큰 문제가 되진 않았습니다.
  280. 280. 한편 AWS와 저희 넥슨은 긴밀한 협력관계를 맺고 있습니다.
  281. 281. 덕분에 출시할 때 AWS로부터 직접적으로 많은 도움을 받을 수 있었죠.
  282. 282. 이 자리를 빌어서 같이 고생해주신 AWS 분들께 정말 감사드립니다.
  283. 283. 서버 아키텍처 1. 대규모 샌드박스 2. 고가용성 3. 데이터베이스 4. 섬 5. 청크 6. 클러스터링 7. 무중단 패치 8. 인프라
  284. 284. 서버 아키텍처 1. 대규모 샌드박스 2. 고가용성 3. 데이터베이스 4. 섬 5. 청크 6. 클러스터링 7. 무중단 패치 8. 인프라 지금까지 〈야생의 땅: 듀랑고〉 서버 아키텍처의 8가지 주제를 모두 살펴봤습니다.
  285. 285. 몇 대 죽어도 버티기늘려서 해결하기 영속적 세계 부동산 단일 채널 대규모 샌드박스와 고가용성 저희는 대규모 샌드박스와 고가용성이라는 두 가지 목표를 위해서
  286. 286. 몇 대 죽어도 버티기늘려서 해결하기 영속적 세계 부동산 단일 채널 대규모 샌드박스와 고가용성 SPOF를 없애고 장애가 나더라도 빨리 복구될 수 있도록
  287. 287. 몇 대 죽어도 버티기늘려서 해결하기 영속적 세계 부동산 단일 채널 대규모 샌드박스와 고가용성 새로운 구조와 장치를 만들었습니다.
  288. 288. 몇 대 죽어도 버티기늘려서 해결하기 영속적 세계 부동산 단일 채널 대규모 샌드박스와 고가용성 그 덕에 클러스터를 유연하게 운영하는 데엔 성공했지만
  289. 289. 한계 한 청크에 수많은 플레이어가 몰렸을 때
  290. 290. 한계 서버 성능이 떨어지게 되는 한계를 갖게 됐습니다.
  291. 291. 한계 이런 상황에 도달하지 않으려면
  292. 292. 균형에 민감 섬 별 인구밀도나 청크 당 노드 수 같은 요소를
  293. 293. 균형에 민감 섬세하게 조절해서 균형을 잡아줘야만 했죠.
  294. 294. 게임서버 데이터베이스 로그인 로드밸런서 클라이언트 TCP HTTP 생태계 시뮬레이션 로그 스트리밍 클러스터링 듀랑고의 서버 하나를 지도로 그려보면 이런 모습입니다.
  295. 295. 게임서버 데이터베이스 로그인 로드밸런서 클라이언트 TCP HTTP 생태계 시뮬레이션 로그 스트리밍 클러스터링 다양한 부품들이 한데 연동돼있는 모습을 볼 수 있습니다.
  296. 296. 왓 스튜디오에서 이 서버를 만들기 시작한지 거의 5년이 됐습니다.
  297. 297. 그 중에는 후회하는 선택도 있었고 예상에서 빗나간 점도 있었지만
  298. 298. 오래 개발했음에도 초기에 세웠던 개발원칙을 중간에 갈아엎지 않고 잘 지킨 채로
  299. 299. 출시까지 맞이할 수 있었던 점이 좋았다고 생각합니다.
  300. 300. SlideShare에 슬라이드 300장 제한이 생겨서 부득이하게 3부로 나눠서 올렸습니다. 보는 데 불편하시겠지만 양해를 부탁드립니다.

×