중앙 서버 없는 게임 로직

1. 중앙 서버 없는 게임 로직 <야생의 땅: 듀랑고> 0. 듀랑고의 서버 1. 실시간 동기화 2. 농사와 날씨 3. 협동 건설 4. 사유지 5. 부족

2. 최호영 테크니컬 디자이너, 8년차 게임 프로그래머

4. 야생의 땅: 듀랑고

5. “공룡시대야생환경에던져진현대인이되어, 로망있는생존,탐험,사냥,개척,사회건설을플레이하는 새로운체험의모바일MMORPG”비전 게 임 의

6. 탐험, 개척 탐험의 매력은 이 세상의 모든 곳을 눈으로 확인하고 그곳에 발자국을 찍는 것 개척의 매력은 주인이 없는 거친 땅을 다듬어 나의 소유로 만드는 것

7. 넓은 땅, 하나의 세계 되도록 넓은 땅을 유저에게 제공하고 싶다 어떤 유저든지 원한다면 서로 만날 수 있게 해주고 싶다

8. 분산 서버 안정성과 부하의 분산을 위한 구조 부분적 장애가 전체 서비스에 영향을 주지 않음

9. 듀랑고의 서버

10. 객체가 중심이 되는 서버 • 하나의 지역을 물리적인 서버가 담당하는 것은 땅의 크기가 서버의 성능에 의해 제한될 수 밖에 없다 • 서버가 어떤 지역을 담당하지 않는다 • 서버는 모종의 규칙에 의해 배정된 객체를 담당한다 최적화에 유리한 방향으로

11. 객체

12. 다른 서버의 객체

13. 각 객체 시야

14. 각 객체 시야의 합

15. 다른 서버 객체의 환영

16. 엄밀하게는 서버-서버간 차이가 아닌 서버-클라이언트간 차이지만 이해를 돕기 위해 가져옴 내가 움직임 ➔ 서버에서 처리해 준 결과

17. 장점 서버에 소속된 객체의 시야 외에는 관심이 없어 전체 세계의 크기와 상관 없는 구조 ➔ 이론적으로 무한한 크기의 세계를 표현 가능 특정 서버에 문제가 생겼을 때 재 접속하면 바로 그 위치에서 정상적인 플레이 가능 ➔ 안정성의 향상

18. 100 ㎢0.25 ㎢ 1 ㎢ 4 ㎢ 836개의 섬 2016년 4월 LBT 기준

19. 실시간 동기화

20. 동기화 • 동기화가 잦을 수록 DB에 부담이 된다 • 동기화가 잦을 수록 패킷량이 늘어난다 • 지나치게 잦은 동기화는 최적화의 대상 • 하지만 플레이가 불가능하진 않다

21. 분산 환경에서의 동기화 • 객체에서 환영으로 서버간 동기화가 이루어진다 • 같은 곳을 보는 서버가 많을 수록 N배 부담 • 동기화에서 느끼는 부담이 늘어났다

22. 2015년 12월 LBT 1일차 • 오픈 직후는 괜찮은 듯 보임 • 접속자가 늘어나자 급격히 서버 랙 증가 • 모니터링 결과 엄청난 양의 동기화 감지

23. 서버 지연의 원인 • 플레이어는 이동할 때마다 조금씩 에너지를 깎는다 • 깎을 때 마다 동기화가 발생한다 • 이동하는 모든 플레이어가 동기화를 유발 • 30명의 플레이어 기준으로 분당 약 10000회의 동기화를 시도

24. 최적화 • 동기화 당 부하를 줄여보자 • serialize, deserialize를 가볍게 하기 • 최소한의 정보만 동기화 • 게임 로직 레벨의 최적화는 아닌 것 같다 동기화 자체를 줄여보자

25. 회 회1 10 10초간 초당 -1일 때 동기화 횟수 1초마다 1씩 에너지를 감소시키는 방법 10초 동안 총 10의 에너지를 지속적으로 감소시키는 방법 ➔ 아래 방법이 훨씬 효율적이다. 그런데 왜 잘 안쓰게 될까? x N x N

26. 10 15 20 30 초 10초부터 10초간 초당 -10 15초부터 10초간 초당 +5 0초부터 ∞초간 초당 +1

27. 이걸 언제 다 계산하고 있어

28. what-studio/gauge https://github.com/what-studio/gauge 변화량을 입력하면 그래프 방식으로 데이터를 보여주는 라이브러리

29. 그래프 동기화 (since, until, velocity), (since, until, velocity), (since, until, velocity), … (광고) what-studio/gauge를 이용하면 당신도 쉽게 그래프 동기화를 ...

30. 그래프 동기화 • 추가적인 변화가 생기면 다시 동기화 해서 덮어 씌운다 • 현재 시각(at)을 넣으면 언제 어디서나 현재 값을 알 수 있다 10 15 20 30 초 15초부터 10초간 초당 +5

31. 그래프 동기화를 쓸 때 주의할 점 until이 미정인 경우가 있다 ➔ 움직이는 동안 에너지 소비 ➔ 접속 중일 때만 피로도가 오름 끝나는 이벤트를 잡는데 실패하면 영원히 지속된다

32. 변칙적 운용 until을 정해진 시간만큼 지정해 둔다 일정시간마다 until을 갱신한다 ➔ 실수로 이벤트를 놓쳤다면 until만큼만 동작 언제 끝날지 모르는 이동중 에너지 소비 문제 해결 접속 중일 때만 증가해야 하는 피로도 문제 해결

33. 가까운 미래의 예측 수치의 지속적인 증감 상태 효과로 인한 일시적인 변화 일정시간 동안 모션의 변화 • 언제부터(since) 언제까지(until) 변화가 지속될 지가 명확하다 • 변화를 매 순간 계산하지 말고 미리 예측하여 추이 자체를 동기화하자

34. 플레이어 30명의 분당 동기화 횟수 이동 중 에너지 감소 문제 수정 후 5약 배 절약 1차와 2차 LBT의 서버 비용 차이 물론 다른 개선 요소들도 반영된 결과긴 하지만… 약10000회 ➔ 1000회 이하

35. 농사와 날씨

36. 신기루 자연물과 건축물은 눈에만 보이고 실체가 없다

37. 신기루 그리드 사과나무 갈대 갈대 갈대 갈대물물 물 자연물은 위치와 종류만 저장 건축물은 외형 패킷을 패킹하여 저장

38. 신기루의 실체화 신기루와 인터랙션을 하는 순간 실체화 자연물은 아무도 건드리지 않았을 땐 DB에도 존재하지 않는다

39. 신기루의 장점 실체화 한 뒤에 일정 시간이 지나도록 인터랙션이 없으면 다시 신기루화 ➔ 메모리 사용량을 최소화 움직이지 않는 객체들도 주변 움직임에 관심을 가지고 있음 ➔ 메모리에 있지 않으면 관심이 없어지므로 동기화 비용 감소

40. 시간이 변하면 외형이 변하는 것들 외형이 전부 캐싱 되어있기 때문에 난감한 경우가 있다 • 불타버린 모닥불 • 내구도가 다된 건축물 • 다 자란 작물 • 외형 캐시에 만료 시간을 넣자 • 만료 시간이 지난 캐시는 버리고 DB에서 정보를 불러와 새로 생성한다

41. • 해당 객체를 보고 있는 모든 서버에서 각자 알아서 처리 • 외형 캐시가 교체되면 연결되어있는 클라이언트들에게 전송

42. 농사 70%토양 적합성

43. • 작물이 성공적으로 자랄 확률은 유저의 행동에 의해서 결정됨 • 하지만 각 처리를 서버에서 하기 때문에 서버마다 결과가 달라질 수 있다 70% 70% 70% 70% !?

44. 결정론적 작물 언제 어디서 결과를 확인하더라도 같은 결과가 나와야 한다 작물이 다 자라는 시각을 랜덤 시드로 하여 결과를 판별한다 Random(성장 완료 시각).random() = 0.751 0.751 ➔ 성공 70% 70% 70% 70% 0.751 ➔ 성공 0.751 ➔ 성공 0.751 ➔ 성공

45. 결정론적 날씨 같은 지역이면 어떤 서버에서도 같은 날씨여야 한다 다른 시간대면 랜덤하게 다른 날씨일 수 있다 Random(지리적 위치 + 현재 시각 / 날씨 변화 주기).random() ➔ 시기적으로 랜덤이지만 지리적으로는 언제나 같은 결과를 얻어온다

46. 협동 건설

47. 개척, 건설 건설은 개척의 핵심 요소 여럿이 모여 마을을 이루고 사회를 이룬다

48. 건설 현실 속에서 건설은 제작/채집보다 훨씬 오래 걸리는 일 빠른 건설 허용은 난개발을 가져온다 시간은 어느정도 길게 하지만 협동을 통해서 극복할 수 있게 하고 싶다

49. 원기옥의 프로토타입 누군가가 건설을 시작하면 동료들이 옆에서 같이 건설을 한다 여러 명의 건설력을 합하여서 완성하는 속도가 빨라진다

50. 원기옥 시스템에 숨어있는 피쳐들 건설할 때는 지속적으로 에너지가 감소 건설할 때는 지속적으로 도구의 내구도가 감소 오래 걸리는 작업이므로 잠시 접속을 끊어도 건설은 계속 진행되도록

51. 쉬운, 그러나 할 수 없는 방법 루프를 돌면서 ➔ 도구의 내구도를 깎고 ➔ 플레이어의 에너지를 소모한 후에 건설의 진행도를 올린다 ✘ 간단하지만 장시간 루프를 돌려줄 주체가 없다 ✘ 루프를 통해서 완성도를 올리는 방법은 지속적인 동기화를 유발하기 때문에 최적화면에서 좋지 않다 여러 개의 서버가 동시에 관여 중

52. 그래프 동기화의 활용 건설력 ➔ velocity 도구의 내구도 + 남은 에너지 ➔ until ✔ 진행을 처음부터 끝까지 그래프로 나타낼 수 있다 ✔ 참여자가 새로 참여할 때 마다 그래프를 새로 그리면 되...겠죠?

53. 참여자 중 한 명이 참여를 중단 ➔ 완성이 더 늦어짐 ➔ 남은 참여자의 에너지 소모와, 도구의 내구도 소모가 늘어남 ➔ 모두의 에너지 소비 그래프와 내구도 소모 그래프를 다시 그린다

54. 모든 참여자의 에너지 소비 그래프와 내구도 소비 그래프를 다시 그린다 ➔ 다시 그리는 중에 누가 또 나가면? ➔ 다시 그리던거 마무리 하고, 또 ... 다시 그린다... ➔ 근데 참여자 중 한명이 오프라인이라면?

55. 무엇이 혼란한가? 분산된 환경에서는 객체들이 다른 프로세스에 흩어져 있다 행동의 여파가 여러 객체에 동시에 영향을 주는 경우 적용에 시간이 걸린다 그 행동이 동시에 여러 곳에서 요청이 온다면? 심지어 메모리에 올라와 있지도 않은 객체가 포함되었다면?

56. 디자인 방향의 선회 ✘ 건설하는 동안 플레이어의 행동을 제한한다 ✘ 게임 진행의 흐름을 끊는다 ➔ 모바일 게임의 특성과 맞지 않다 앞에 붙어서 건설을 하는 시간 자체는 짧게 하지만 협동의 느낌은 나게

57. 개선된 원기옥 1명이 건설 (짧은 시간) ➔ 건축물이 완성되기를 기다림 (긴 시간) ➔ 친구가 ‘도와주기’를 하면 기다리는 시간 감소 ➔ 정해진 시간이 지나면 완성 ✔ 실제 앞에 붙어있어야 하는 시간이 짧다 ✔ 비 동기적인 액션으로 동료가 완성 시간을 줄여줄 수 있다

58. 동시에 여러 객체를 변조하는 일은 회피하자 2개 이상의 객체에 동시에 영향을 주는 작업은 구현 비용이 비싸다 비싸게 지불하고 구현했더라도 버그 가능성이 너무 높다 유지 보수도 복잡하다 디자이너와 충분한 협의를 통해 디자인 자체를 회피하는 방향으로 선회하자

59. 사유지

60. 사유지 @YoshiCoin 님의 만화

61. 사유지 권한 친구 / 외부인 / 부족원(추후 제공 예정) 에게 권한을 일부 혹은 전부 허용해줄 수 있다

62. 가족 간에도 범죄가 생기는 무서운 시대 내 사유지에서 무슨 일이 일어나는지 나는 알아야겠다!! ytn newsis 데일리한국 오마이뉴스

63. 사유지 이력 시스템

64. 실시간 알림의 필요성 • 이력 시스템은 문제를 발견하기 전까지 이용하지 않게 된다 • 문제를 발견한 이후에는 늦을 수 있다 • 내 사유지에서 일어나는 행동에 대한 빠른 피드백을 위해 실시간으로 알림이 필요하다

65. 오프라인인 캐릭터에게 알림 • 접속 중일 때는 해당 캐릭터에게 알림을 보내면 그만 • 접속 중이 아닐 때는 어떻게 해야 할까? • 해당 캐릭터의 DB 속 데이터를 직접 수정해야 한다 • 여러 명이 동시에 사유지에서 활동할 경우 동시에 알림을 보낼 수도 있다 • 여러 명의 요청을 안전하게 처리할 수 있어야 한다 요청자가 서로 다른 서버에 있을 수 있음

66. 낙관적 트랜잭션 니가 알고 있던 건 최신이 아니야 동작이 단순하고 가볍다 하나의 문서만을 대상으로 할 수 있다

67. 낙관적 트랜잭션의 어려움 트랜잭션 시 수행하는 코드는 언제나 재실행이 가능해야 한다 실행은 사이드 이펙트가 없어야 한다 객체는 복잡하고 다양한 로직을 가지고 있다 객체를 대상으로는 낙관적 트랜잭션을 금지 사이드 이펙트가 누적될 수 있다 계속해서 다시 시도해야 할 수 있다

68. 객체의 소유권 • 서버에게 객체의 담당 시킬 뿐 아니라 소유권한 까지 넘긴다 • 어떤 객체에게 영향을 주고 싶으면 소유한 서버에게 문의해야 한다 • 하지만 접속 중이 아닐 때에는?

69. DB에 태스크 큐 객체마다 태스크 큐를 DB에 만든다 작업을 큐잉해 둔다 owner.queue_task( Player.notify_estate_event, *args, **kwargs) 그 객체가 접속 중 이라면 rpc를 통해서 알려준다 접속 중이 아니었다면 접속할 때 내 큐를 확인해서 수행한다

70. 사유지 알림 • 행동을 하는 객체는 사유지의 주인에게 꼬박꼬박 보고를 한다 • 오프라인일 때 일어났던 일은 접속할 때 알려주고 • 온라인일 때 일어난 일은 바로 알려준다

71. 부족

72. 부족 시스템 아직 시스템에서 지원을 하고 있진 않음 기반은 작업해 두었지만 더 완성도를 높여서 보여드리고 싶은 마음에 아직 공개한 적은 없음

73. 부족과 플레이어의 관계는 서로 참조 가입이나 탈퇴는 양쪽 문서를 모두 수정해야 한다 d부족 A c a b

74. 가입과 탈퇴 시 양쪽 문서가 동시에 수정됨이 보장되지 않는다면 예상할 수 없는 문제들이 속출 d부족 A c a b

75. ACID 트랜잭션 • 안전한 트랜잭션을 위한 특징 Atomicity 부분적으로만 실행되지 않는다 Consistency 실행에 성공하면 언제나 일관된 상태로 유지된다 Isolation 수행 중 다른 트랜잭션이 끼어들 수 없다 Durability 성공한 트랜잭션은 영구히 반영된다 • 하지만 우리는 분산에 더 적합한 NoSQL을 사용 • NoSQL에서는 보장하기 힘들다

76. BASE 트랜잭션 • ACID를 NoSQL에서 근사하게 보장해 주기 위한 애플리케이션 레벨의 방법 Basically Available Soft state Eventual consistency • 트랜잭션에 내용을 따로 문서로 작성 • 애플리케이션 레벨에서 해당 문서를 참조하여 결과적으로 일관성을 보장함 • 애플리케이션 레벨의 처리이기 때문에 로직 자체에서 신경 써야 할 점이 많다

77. 가입과 탈퇴 가입과 탈퇴는 두개의 문서를 동시에 수정하는 작업 하지만 BASE 트랜잭션은 고민을 많이 해야하고 구현이 복잡하다 BASE 트랜잭션을 안쓰고 낙관적 트랜잭션만으로 해결할 순 없을까? 가볍지만 하나의 문서를 대상으로만 가능

78. 가입 신청 가입을 신청할 때 부족 문서에 기록하지 말자 ➔ 낙관적 트랜잭션만으로 가능 플레이어가 부족을 가리키는 단방향 관계 형성 DB에 쿼리를 통해서 부족은 가입하길 원하는 플레이어를 검색

79. 가입과 강제퇴출 부족장이 가입을 승인할 땐 부족이 플레이어를 가리키게 한다 ➔ 낙관적 트랜잭션만으로 가능 부족장이 부족이 플레이어를 가리키지 않게 하면 강제 퇴출 하지만 이럴 경우 가입 신청한 상황과 구분이 되지 않는다!

80. 토큰의 도입 가입 신청과 수락 시에 토큰을 같이 기록한다 토큰은 유니크한 값이 발급된다 A17D3 A17D3

81. 강제 퇴출 강제로 퇴출 시에는 토큰을 만료만 시킨다 양쪽 토큰이 일치하더라도 토큰이 만료되었을 경우는 인정하지 않는다 A17D3 A17D3:만료됨

82. 4F82K 탈퇴 자진 탈퇴할 때는 조용히 나의 가리킴만 삭제 기존의 부족 쪽 토큰은 데이터는 있지만 사실상 의미가 없다 재 가입신청을 할 때는 토큰이 바뀌어 있으므로 기존의 부족 쪽 토큰은 무효 A17D3

83. 초대 • 초대를 보낼 때에는 부족 쪽에서 발행하여 토큰을 초대장과 함께 보낸다 • 초대장을 보내는 순간 이미 부족은 플레이어를 가리키고 있다 • 내가 해당 토큰으로 부족을 가리키면 초대 수락 A17D3 A17D3

84. 낙관적 트랜잭션만으로 해결 가입 신청/ 탈퇴/ 초대 수락 ➔ 플레이어 데이터만 수정 가입 수락/ 강제 탈퇴 / 초대 ➔ 부족 데이터만 수정 일반적인 로그인 세션과 다르지 않다 간단한 구조 변경을 통해 가벼운 낙관적 트랜잭션으로 해결

85. 중앙 서버 없는 게임 로직

86. 중앙 서버가 없다는 것은? 원탁의 기사는 보기에는 좋지만 실제로는 일의 절차가 복잡하고 느릴 수 있다

87. 이미 활용되고 있는 서비스 형태 • 이미 웹 서비스 외 여러 분야에서 다양하게 활용되고 있다 • 서비스의 안정성과 가용성을 위해선 어쩌면 당연한 선택 • 단지 MMORPG에서 활용된 적은 많지 않은 것 같다 오늘 소개한 전략들도 상당수 여기서 힌트를 얻음

88. 분산 구조에 대응하는 전략 • 복잡한 계산은 최대한 한곳에서, 다른 서버에서는 결과만 받아보자 • 모든 서버에서 계산은 해야 한다면 어디에서 하든지 결과가 동일하게 • 동기화를 최대한 하지 않는다 • 다른 서버의 객체에 동시에 적용되어야 하는 작업을 최소화 한다

89. 시행착오 • 처음엔 별 생각 없이 익숙한 방식으로 작업하다가 재 작업을 많이 함 • 일반적인 멘탈 구조와 달라 작업할 때 조심을 많이 해야 함 하지만 오늘 살펴본 사례에서 볼 수 있듯이 생각보다 해결 방법은 간단하고 일반론 안에서 해결이 가능하다

90. 고비용 = 적응 비용 많은 사람이 시도하여 이미 다양한 경험이 공유되어 있었다면 우리도 시행착오를 줄일 수 있었을 것 같습니다 Q A

91. 감사합니다

92. Q&A

93. NDC16 <야생의 땅: 듀랑고>의 거친 환경에서 살아가는 동물 AI 세션에서 설명 드린 것을 참고하시면 좋을 것 같습니다. 저희는 PVE와 PVP 모두 콜로세움이라는 노드를 통해 해결합니다 모든 전투와 관련된 행동들이 해당 노드에서 결정, 수행되기 때문에 전투에 관해서 만큼은 다른 서버에 있다고 하여 시간차가 발생하지 않습니다 Q A 만약 PVP가 구현된다면, 예측 불가능한 인터랙션이 매우 많이 발생 하여 서로 다른 서버에 있는 유저들 사이에서 많은 부담이 발생할 것 같습니다. 혹시 구현 계획과 그 대책이 있나요? 여러 플레이어들과 공룡을 사냥할 때 신속한 동기화가 필요할텐데 이럴 경우 동기화의 퍼포먼스, 그리고 말씀하신 동기화로 인한 부하 가 커질텐데 그런 부분은 어떻게 해결하셨나요?Q

94. 객체는 서버에게 소유권이 이전 되어있기 때문에 다른 서버에 있는 객체 둘이 어느 목표 대상물에게 접근하려면 둘 다 목표 대상물을 소유한 서버에 rpc를 통해서 요청을 보내는 수 밖에 없습니다. 해당 서버 안에서는 객체 단위로 rpc 요청이 직렬화 되기 때문에 요청 받은 순서대로 처리하게 됩니다. Q A 동시에 다른 서버에 있는 유저가 같은 객체와 인터랙트하는 경우에 는 두 유저가 모두 인터랙트를 할 수 있는지? 동기화는 어떻게 처리 되는지요?

95. 병목이 생기는 부분을 분산할 예정입니다. Q A 서버간 동기화로 인해 패킷이 늘어나면, 물리적 네트워크 처리량이 병목이 되지 않나요? 패킷양으로 인해 물리적 네트워크 처리량에 병 목이 온다면, 어떻게 해결할 계획이신가요?

96. 인스턴트를 새로 만드는 비용은 언제나 최소한으로 맞추기 위해 노력을 했습니다. 기본적인 정보만 미리 세팅하고 상세한 정보들은 필요할 때 만들거나 읽어오도록 하였기 때문에 코스트가 크지 않습니다 Q A 신기루그리드를 누군가 터치했을 때 인스턴스를 새로만든다면 새로 만드는 연산에 비용코스트가 크지 않나요?

97. 서버는 지리적으로는 영향력이 없기 때문에 문제가 생긴 서버에게 속한 객체가 정상적으로 동기화 되지 않는다는 문제점 정도는 있을 것이지만, 그 지역 자체에는 아무런 영향이 없습니다. Q A 특정 서버만이 오류가 있을 때 게임지리적으로 같은 곳에 객체가 존 재하는 다른 서버도 같이 영향을 받을텐데 이는 어떻게 해결하실 생 각인가요?

98. 아직 글로벌 서비스에 대한 준비가 완벽하지 않아서 확실하게 답변 드릴 수 있는 부분이 아닌 것 같습니다. 모바일 통신 환경에서는 기본적으로 latency가 클 수 밖에 없기 때문에 항상 높은 latenc를 가정하고 게임을 디자인하고 있습니다. Q A 서로 다른 지역에서 플레이 하는 사람은 해당 지역의 서버에 접속을 하나요? 그렇다면 서버간 통신 latency가 큰 경우에 어떤 문제가 생 길 수 있나요?

99. 최초로 active 상태가 되는 것은 유저의 선택 (인터랙션)에 의해서 이루어 집니다. 단순히 내부적 상태가 변하는 것은 저희도 이 때 처리하고 있습니다만, 이 세션에서 설명드린 부분은 시간에 따라 외형이 변하는 객체들 입니다. 모닥불이 활활 타고 있는 것 같지만 실제로는 꺼져있는 상태는 유저에게 혼란을 줄 수 있어 그렇게 할 수 없었습니다. Q A 시간에 따라 상태가 변경되는 지형물은 스케줄러에 등록해놓고 매번 처리하지말고, 최초 로 active상태가 될때 누적된 처리를 한번에 해 주면 어떤 문제가 있나요?

100. 일단 분산된 서버라는 것 자체가 원래 있던 서버에 접속할 필요가 없게 만들어야 합니다. 재접속 할 때에는 원래 접속했던 서버에 접속할 확률이 낮기 때문에 언제나 관련된 정보는 DB에 저장해 두고 필요할 때마다 꺼내기 쉽게 해 놓았습니다. Q A 중앙서버가 없다면 비원활 네트워크 상황이 발생했을 경우, 원래 로 그인했던 게임서버에 재접속이 된다는 보장이 없을 텐데, 다른 게임 서버에 재접속 됐을 경우 예전 게임서버에 남아있는 유저의 정보와, 새로 로그인되는 유저의 정보는 어떻게 처리되는지 궁금합니다.

101. 유저의 이동은 BASE 트랜잭션으로 저장하지 않고 각 소유권이 인정된 서버에서 알아서 처리하기 때문에 Eventual consistency 로 처리하지 않습니다. 그리고 각 개체는 겹쳐있는 것을 허용하기 때문에 충돌이 일어나지 않습니다. Q A 서로 다른 서버에 있는 두 유저가 동시에 같은 장소로 이동할 경우 Eventual Consistency로 처리 되면 위치가 충돌하지 않을까요?

102. 쉽게 답변드릴 수 없는 부분인 것 같습니다. Q A 듀랑고 정도의 서버 프로그래밍의 예상 개발시간 소요는 어느정도일까요

103. iOS 노티피케이션은 큐를 통해서 처리하지 않습니다. 큐에 작업을 넣을 때 필요한 경우 푸쉬(노티피케이션)을 따로 보내고 있습니다. Q A 오프라인인 유저가 접속해야 있던 큐를 처리하면, 오프라인인 유저 는 iOS 노티피케이션을 받을 수 없나요?

104. 누군가가 해당 지역을 처음으로 목격했을 때 로드됩니다. 해당 서버에서 그 지역에 관심 있는 객체가 하나도 존재하지 않게 되면 다시 누군가 목격할 때 까지는 메모리에서 해제합니다. Q A 외형 캐시가 서버에 로드되는 시점이 언제인가요?

105. DB의 특정 노드에 장애가 난 상태에서 일부 DB 작업이 실패하는데 전체 서비스가 망가지진 않지만 일부 동작이 망가질 순 있습니다. DB 자체는 persistent 합니다. Q A 오프라인 유저에 대한 지연된 업데이트를 위해 DB큐를 둔다고 하셨 는데요. 해당 큐에 장애가 나는 경우에도 대비되어있나요? 오프라인 유저의 지연 업데이트를 위한 DB큐도 백업이 있나요? 해 당 DB큐에 장애가나면 데이터가 날아가버리지 않나요?Q

106. 게임 서버는 파이썬으로만 구성되어있습니다. 게임 서버 이외의 워커들엔 C#도 쓰고 있습니다. Q A 듀랑고 서버는 파이썬으로만 구성 되어 있나요?

107. 네 그렇습니다. 다만 3로 옮기는 것을 고려 중 입니다. Q A 파이썬 2.7에 gevent를 계속 사용하고 있나요?

108. 파이썬의 라이브러리 생태계가 아주 잘 이루어져 있기 때문이었습니다 Q A 서버 개발 언어로 분산에 최적화된 여러 언어가 아닌(얼랭이라던가) 파이썬을 고른 이유는 무엇인가요?

109. 저희는 NoSQL인 Couchbase를 사용하고 있습니다. Q A db는 awa의 rds를 쓰시나요? 다이나모를 쓰시나요 rds를 쓰신다 면 어떤 엔진을 쓰시고 그 엔진을 쓰신 이유가 있다면?

110. 네 그렇습니다. Q A 사용하는 파이썬 구현체는 무엇인가요? (only cpython?)

111. 아직 확정되지 않은 부분이라 답변 드리지 못함을 양해 부탁드립니다. Q A 랭킹시스템이 들어간다면 어떻게 구현을 하실 생각인가요?

중앙 서버 없는 게임 로직

중앙 서버 없는 게임 로직

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to 중앙 서버 없는 게임 로직

Similar to 중앙 서버 없는 게임 로직(20)

중앙 서버 없는 게임 로직