NDC Replay

게임 서버 디자인 가이드
임태현
넥슨코리아
현재, 마비노기2 프로젝트에서 서버개발을 담당하고 있습니다. 과거, 마비노기, 허스키익스프레스에서 서버개발을 담당하였고, 넥슨에서 10년간 게임서버를 전문으로 개발에 참여하였습니다.
누구든 특정 분야에 오랫동안 몸을 담그고 있으면 남들에게 보이지 않는 것이 보이기 시작합니다. 우리는 그것을 노하우라고 부릅니다. 이런 노하우는 수식이나 아니면 구체적인 코드 형태로 전달되게 되는데, 서버개발에 있어서 노하우를 실제 코드로 수차례 전파해본 결과, 서로 다른 게임에 적용되기 힘든 점을 발견 하였습니다. 그런 이유로 , 사용하는 언어와 플랫폼이 다른 게임들에게도 공통적으로 적용가능한 노하우를 공유하고자 디자인 패턴의 형식으로 게임서버의 핵심 아키텍쳐를 설명하려고 합니다. 멀티 스레드와 네트워크, 그리고 클라우드 환경으로 쉽게 확장가능한 패턴들을 5-6 가지 선별하여 샘플 코드와 주요 특징을 설명하는 식으로 진행할 계획입니다. 몇가지 얘기하면 서버간에 통신을 직접 하는 모델과 릴레이 서버를 통해하는 모델의 차이와 거기서 나타나는 주요패턴을 비교하면서 진행하게 될 것이고, 서버샤딩 확장에 따른 기본 요구사항과 그를 만족하는 패턴을 설명하게 됩니다.
[새 창에서 슬라이드 보기]
Play
Current Time 0:00
Duration Time 0:00
Remaining Time -0:00
Stream TypeLIVE
Loaded: 0%
Progress: 0%
0:00
Fullscreen
00:00
Mute
안녕하세요. 게임서버 디자이너 임태현입니다. 제목이 조금 바뀌었는데 원래 내용을 가지고 발표를 하려니 미흡하여 기본은 같지만 실무 내용을 조금 더 붙여서 작업을 했습니다. 그래서 몇 개 안 되게 만들었는데 덕분에 난이도가 조금 올라가서 학생 분들에게 약간 어렵지 않을까 생각이 드는데 최대한 잘 해보겠습니다. 제 소개는 이렇습니다. 벌써 넥슨에 온지 10년이 넘었는데 11년동안 제가 서버만 만들었습니다. 그런데 이 11년동안 한 가지 일만 하다 보면 온갖 생각을 하게 됩니다. 그 중에서 가장 드는 생각은 “과연 내가 일을 잘 하고 있나? 다른 사람들은 어떻게 일을 하나?” 하는 생각들이 많이 들었습니다. 그래서 이야기를 해보려 합니다. 그런데 그냥 이야기를 하면 이야기가 잘 안됩니다. .우선 제 이야기를 풀어놓고 다른 사람들이 어떻게 생각하는지 또 어떻게 이야기를 하는지 기대하는 마음으로 시작을 합니다. 목차는 이렇고요. 우선 몸풀기입니다. 늘 생각하는 주제인데 “왜 나는 서버를 직접 항상 만들어야 하나? 왜 10년이 지났는데 여전히 같은 일을 하고 있지?” 라는 생각을 하게 됩니다. 이유는 간단합니다. 팔지를 않습니다. 열심히 찾아봤는데 일부는 있지만 제가 원하는 스케일의 서버는 팔지 않습니다. 그 이유가 뭘까? 왜 구할 수 없을까? 대부분의 미들웨어들이 많은 와중에 내가 원하는 게 없을까? 라고 생각하면 이게 어떻게 보면 게임의 특징 중에 하나라고 생각합니다. 우선 이중에서 이 부분이 제일 문제가 됩니다. Massive한 문제를 해결하기 위해서 여러 기술들이 나와있습니다. 세 가지를 보여드리겠습니다. 어느 것이 더 기술적으로 발전했다고 판단하기는 어렵습니다. 문제는 같은 방법을 많이 썼다는 것이죠. 최초의 카트라이더만 해도 플레이를 8명이서 한다고 해도 같은 방이 수 천 개가 존재합니다. 그렇다면 동접이 몇 백 명으로 한 서버를 이루는 게임에 비해 기술적을 떨어지는가? 중요한 것은 같은 방식으로 말씀드릴 수 없다는 것입니다. 이게 포인트입니다. 핵심은 이것입니다. 게임의 유니크함. 게임의 유니크함은 게임 고유의 강점이라고 생각합니다. 그리고 코드들은 그것을 뒷받침해주는 겁니다. 그렇다면 여러 개를 만들어서 쓸 때 그 중에 굉장히 독특한 부품이 필요하다면 이것을 직접 만들 수 없으면 만족할 만한 결과가 나올 수 있을까요? 그것을 만들기 위해서 공부해야 할 것은 매우 많습니다. 제가 이번에 발표하려고 하는 내용은 그 부분입니다. 저희는 게임을 만들고 있으니까요. 이제부터 몸풀기는 끝났고 난이도가 확 올라갑니다. 제가 서버를 처음 만들면 이런 생각의 흐름으로 작업을 합니다. 우선 저는 무조건 이렇게 만듭니다. 오랜 경험에 의해 나눈 것인데 입력 실행 로직 이 세 부분으로 서버를 구분합니다. 모든 서버의 부품들은 이 안에서 고려를 해야 합니다. 각각은 무엇이냐? 작은 글씨들은 나중에 ppt를 읽는 사람을 위해서 만들었습니다. 우선 설명을 하면 네트워크가 들어가고 이쪽은 쓰레딩 쪽 관련, 마지막은 게임 플레이가 들어갑니다. 그러면 쓰레드 쪽이 항상 문제가 되는데 그러니까 설계할 때 이 부분이 핵심 부분으로 다가오는데 왜냐하면 네트워크 입력부분과 쓰레드는 사실상 거의 한 가족이나 다름 없습니다. 그러면 우선 제가 사용하는 네가지 모델을 가져왔습니다. 싱글 쓰레드는 쉽죠. 설명을 할게 없습니다. 우선 네트워크에서 들어옵니다. 그러면 메인 루프에서 풀링해서 처리를 합니다. 마지막으로 같은 메인루프에서 로직을 처리합니다. 이게 다입니다. 구조가 간단하고 락 문제가 발생하지 않는데 멀티코어를 사용할 수 없습니다. 하지만 멀티코어를 사용하지 못한다고 이게 꼭 나쁘지 않은게 대충 만든 멀티 쓰레드 모델보다 몇몇 싱글 쓰레드 모델들이 훨씬 고성능을 보일 때가 있습니다. 그래서 자주 사용합니다. 인풋 쓰레드입니다. 다른 모델 비슷한 것을 찾지 못해서 이름은 제가 임의로 붙였는데 비동기 io에서 주로 사용하는 방법이고 쓰레드 관리를 직접 안 한다는 점에서 이점이 있습니다. 인풋이 있습니다. 아까와 다른 점은 비동기이기 때문에 onreceive가 있습니다. 보통은 거기서 패킷이 들어오고 여기서 패킷을 해석합니다. 그런데 패킷을 해석하고 다른 것을 하지 않습니다. Onreceive 쓰레드에서 그대로 로직까지 넘어갑니다.  6분 10초)하는 것은 그냥 onreceive 수만큼 로직수가 존재한다는 이야기고 그 수 관리를 시스템에 전적을 맡긴다는 것입니다. 이게 언뜻 보면 이상한데 쓰레드를 관리하지 않는다라는 게 굉장히 장점입니다. 쓰레드 잠김에 대해서 내성이 좋습니다. 이 부분은 나중에 동기화 모델에서 설명하겠습니다. 커스텀 쓰레드. 이게 가장 일반적인 쓰레드 모델인데, 마찬가지고 온리시브에서 만들고 해석합니다. 해석하는데 여기서 작업을 큐잉해놨다가 각각의 쓰레드들이 자기가 노는 타이밍이 되면 가져갑니다. 쓰레드 수를 조절해, 성능을 최적화 할 수 있습니다. 이게 이론상 가장 빠릅니다. 그 다음에 여러 개를 통한 수치계산은 보통 이 모델을 사용합니다. 그런데 게임에 쓰기에는 문제가 하나 있습니다. 쉽게 말하자면 패킷이 역전됩니다. 즉 패킷이 들어오는 경우와 실행되는 경우가 역전이 되는 경우가 있습니다. 이게 어느 정도 심각 하냐면 게임에서 내가 이동하고 공격했는데 이게 역전이되면 제자리에서 공격하고 이동을 하잖아요? 이게 보통 시스템이 써버리는 경우가 되는데 굉장히 위험합니다. 이 문제를 해결하기 위해서 제가 하나 고친 것은 오브젝트 바운드 쓰레드인데 순서가 꼬일 수 있는 그 문제를 해결한 것입니다. 마구잡이로 가져가기 때문에 a, b, c 작업이 있고 쓰레드가 1, 2가 있다고 한다면 a를 1번이 가져가고 b가 2번을 가져가는데 b가 먼저 끝납니다. 그렇게 되면 2번이 a가 끝나지 않은 채로 c를 가져가게 되고 c가 먼저 끝납니다. 쓰레드 자체의 시간은 시스템 슬라이스하기 때문에 이러한 문제가 쓰레드에서 충분히 발생될 수 있는 일입니다. b->c->a 순으로 리졸브 되기 때문에 유저의 입장에서는 황당할 수 밖에 없습니다. 그렇다면 그걸 어떻게 막는가 하면 방금 그 부분에서 이 부분만 다른 것입니다. 큐잉을 이곳과 이곳에 합니다. 각각의 쓰레드에 큐잉을 시킵니다. 그렇다면 무슨 규칙으로 큐잉을 하는가? 저 같은 경우에는 보보통 객체 즉 플레이어 앞의 태그를 붙여서 그 플레이어가 실행하는 모든 명령들을 한 쪽으로 몹니다. 쓰레드 1번에는 플레이어 a가 쓰레드 2번에는 플레이어 b가 가는 식으로 해서 a가 하는 것일은 이쪽으로 b가 하는 일은 이쪽으로 하지만 이게 완벽한 해결법은 안 되는게 문제가 하나 있습니다. 가령 평균적으로 월드에 사람들이 일정한 간격을 서있으면 문제가 없는데 이벤트를 하게 될 경우 광장에 몇 백명이 모입니다. 그면 이 사람들은 인터렉션 레벨이 높기 때문에 즉 주변사람들이 같은 곳에서 작업하기 때문에 한 쓰레드에 몰 수 밖에 없습니다. 만약에 한 쓰레드에 작업에 몰리게 된다면 싱글 쓰레드보다도 작업이 경우가 생기기도 합니다. 그래서 만약에 우리게 임이 그런 일이 생길 수 있다면 쓰기 어려운 모델입니다. 이 모델이 사실 한 서버에 여러 개의 방을 돌리는 디아블로 같은 스타일의 게임에서는 괜찮은 모델입니다. 복습해보겠습니다. 이게 월래 내부 교육용 ppt를 개조한 것이라서 복습하는 부분이 있는데 싱글 쓰레드는 이렇습니다. 인풋 쓰레드는 어떤 모양이냐 하면 이렇습니다. 그 다음에 가장 일반적인 쓰레드는 여기서 큐를 합니다. 마지막은 문제를 어떻게 해결했는가. 큐를 이곳에 놓습니다. 장단점이 다 있습니다. 결정적으로 누가 더 빠르다? 케이스마다 다릅니다. 그렇기 때문에 게임의 특성에 따라 결정을 하면 되는데 나중에 바꾸는 것이 매우 어렵습니다. 달리는 차에 바퀴를 갈아 끼는 격이기 때문에 웬만하면 안 바꾸는게 좋은데 처음부터 케이스를 정하는 경우도 적고 유지되는 경우도 적기 때문에 일단은 싱글 쓰레드로 가장 작게 만들어놓고 나중에 고치는 게 낫습니다. 개발자들 사이에서는 흔히 나오는 경우고 저 같은 경우에 마비노기에서는 싱글 쓰레드로 만들었는데 중반에 멀티 쓰레드로 갈아탈 타이밍을 놓쳐서 직접 고치지는 못했습니다. 허스키 익스프레스 같은 경우에는 3번 모델을 썼습니다. 가장 일반적인 쓰레드 풀을 썼는데 역전 문제라던가 이런 저런 문제를 해결하기 위해 계속 추가장치를 달다 보니 ‘이건 아닌데’ 하는 생각이 들었습니다. 이번에 마비노기2를 준비하면서 업그레이드 모델을 썼는데 문제는 잠금처리문제 때문에 지금은 두 번째 인풋 쓰레드 모델을 쓰고 있습니다. 전 네 개의 모델로 만들어봤습니다. 잠깐 확장하여 개념을 갖겠습니다. 인터랙션은 왜 중요하냐 하면 인터랙션 자체가 리소스 잠금과 연결이 되어있습니다. 내가 옆 사람과 악수를 하려면 서버상에서는 상대와 내가 같은 락으로 잠겨있어야 합니다. 내가 악수하는 동안에 상대가 어디로 가버리면 안됩니다. 그러니까 제자리에서 서있어야 합니다. 둘이 동시에 합하여 악수를 해야 합니다. 그런데 mmo같은 경우에는 안그런 게임도 많지만 mmo는 월드기반으로 이루어져있습니다. 눈에 보이지 않는 상대와 인터랙션 할 일이 별로 없습니다. 눈에 보이는 상대가 굉장히 중요하죠. 그래서 보통 대부분의 리소스 잠금이 월드기반으로 되어있습니다. 그리고 이 리소스 잠금은 아까 말한 쓰레드 모델과 밀접합니다. 월드에 몇 명이 있는가? 월드가 몇 개인가? 월드가 심리스 인가에 따라 계속 바뀝니다. 여기서 인터렉션 레벨이 높다는 것은 둘은 잠금 처리가 되어야 하고 나머지는 잠금 처리가 없어도 상관없다는 것입니다. 저는 보통 이것을 게임 월드라고 부릅니다. 저는 계속 mmo였기 때문에 만들다 보면 항상 월드 기반으로 초반에 디자인 합니다. 기본적으로는 이렇게 됩니다. 플레이어가 있고 월드가 있고 지형도 있고 몬스터도 있고 다른 사람도 있고… 플레이어는 자기 정보를 클라이언트에서 받게 됩니다. 이것이 기본적인 모델이고 기본적인 동작은 어떠한가 보면 제가 만드는 시스템에서는 크게 이렇게 있는데 끝에 파란색이 시야 안으로 들어오면 객체가 생성되었다고 서버가 알려줍니다. 빨간 것이 나가면 객체가 파괴되었다고 알려주죠. 그리고 나머지는 이 바운더리 안에 있는 애들에게 정보를 주는 작업을 합니다. 그 다음에 범위 안에 있는 애들을 줘봐 라는 명령들이 부가적으로 붙게 됩니다. 결국에 이것들을 다 모아놓으면 시야 범위 즉 일정 범위 안에 일어나는 이벤트들이 있어요. 그래서 공간 분할이 필수적인 요소가 들어갑니다. 월드는 두 가지가 중요합니다. 하나는 인터렉션 레벨 즉 그룹의 크기 또 하나는 공간분할입니다. 공간분할은 알고리즘적인 것이기 때문에 깊게 설명하지 않겠습니다. 이런 것이 있는데 저는 주로 타일 분할을 씁니다. 왜냐하면 만들기가 제일 쉽고 가장 안정적인 속도가 나옵니다. 평균적인 속도가 나온다는 것은 그만큼 튜닝이 편한 다는 것입니다. 장점도 있고 단점도 있습니다. 사람이 적다고 빠르지도 않고 사람이 많다고 느리지도 않고. 이것은 아까 그것의 확장판입니다. 저 위에 빨간색을 보면 시야에 들어오면 이벤트가 발생하고 나가면 디스트로이가 발생하고 이것들 같은 경우에는 안에서 같이 네트워크 정보를 주고 받습니다. 이 안쪽이 보이는 부분 바깥쪽이 보이지 않는 부분입니다. 시스템상으로는 이렇습니다. 자 그러면 이제 잠시 쉬어가는 페이지인데… 심리스 월드. 여기서 전에 것을 잠시 정리를 해보자면 머리가 복잡하기 때문에 재미있는 요소를 넣어봤습니다. 심리스 월드를 바라보는 관점이 사람마다 다 다른데, 특히 게임 개발자중에서도 디자이너라고 하는 것은 이제 기획자인데 게임 기획자들이 말하는 심리스 월드는 그저 넓은 세계입니다. 클라이언트 엔지니어 쪽에서는 심리스 월드를 만들어야 한다면 절차적인 움직임을 만들어야 합니다. 이게 가장 문제가 되는데, 최종 고민이 무엇인가 하면 앞으로 갈수록 저 끝에 있는 것들을 조금씩 로딩을 하고 뒤에 버려지는 것들은 조금씩 내리는 그런 거죠. 제가 심리스 월드를 만들어라 하면 그 월드를 하나의 데이터 컨테이너에 담아야 합니다. 사실 가장 큰 고민은 심리스 월드가 얼마나 클 것인가 입니다. 왜냐하면 아까 인터랙션을 이야기 했는데, 결국 서버에서의 인터랙션은 무엇으로 귀화되냐면 내가 이 사람의 값을 읽거나 쓸 수 있는가? 객체가 읽거나 쓸 수 있으면 굉장히 인터랙션이 좋은 것입니다. 그런데 이게 같은 메모리 상에 없다면 방법은 있는데 상당히 복잡해 집니다. 깨지기도 쉽고… 그렇기 때문에 심리스 월드가 있으면 한 서버에 몰아버릴 수 밖에 없는 게 현실입니다. 심리스 월드를 하다 보면 제약이 생깁니다. 너무 커도 곤란하고… 심리스인데 원월드다. 게다가 채널링도 하지 않는다. 동접 3만을 한 서버에 몰아서 한다. 그렇다면 못하는 것입니다. 또한 눈에 보이지 않는 요소들도 많은데, 제가 마지막으로 측정했을 때에 플레이어 백 명당 객체가 오천에서 육천 개 정도 들어갑니다. 아마 요즘 나오는 게임들은 더 많을 것입니다. 만 개가 넘어가지 않을까 라는 생각이 듭니다. 이런 상황에서 어떻게 해야 하는가? 사실 쉬어가는 페이지이기 때문에 제가 원하는 방법으로 임의로 썼습니다. 우선 이런 것인데 실제로 많이 쓰는 방법입니다. 예를 들어 대륙이 두 개가 있고 바다가 있습니다. 이 바다를 심리스로 해야하는가? 안 하는 것이 낫습니다. 이 바다에서 얼마나 많은 사람들이 서로 인터렉션을 하겠습니까. 배 위에서 워프나 로딩을 하는 식으로 넘어갈 수 있습니다. 가령 달나라를 만들어야 한다면 지구에서 달까지 심리스는 불가능 합니다. 워프시키는 것이 낫죠. 실제로 고립된 마을 같은 경우에는 심리스 월드로 만들 필요가 없습니다. 제 경우에 고립된 마을의 가장 대표적인 예로 초보자, 레벨 1에 시작하는 마을. 여기에 심리스를 쓸 필요가 없는 게 튜토리얼과 이런 것 들이 복잡하게 엉켜있어서 외부세계와 단절이 심합니다. 심지어 어떤 게임은 편지도 못 주고 받게 되어있습니다. 그런 것들이 사실은 초보자들이 대량으로 유입될 때 심리스 월드 안에서 부하를 받는 것을 피하기 위해서 많이 그렇게 디자인을 합니다. 그 다음에 서버 분산. 방금 전에도 말했지만 하고 싶지 않은 방법. proxy를 써 갖고 하는게 디자인에 있긴 합니다. 이게 보이지는 않지만 ‘다른 서버에 있는 것이 우리 서버에 반쯤 투영되어 있어서 프록시를 이용해 통신을 한다.’ 내용은 이런 것인데, 안정화 시키기 매우 어렵죠. 실제로 만들려면 코드가 너무 많이 필요합니다. 버그도 너무 많아지고… 그래서 저도 보통 심리스 월드 이야기를 할 때 마음속으로는 거의 이 생각을 합니다. 그렇다면 이 서버는 굉장히 좋은 서버를 사야겠다. 여러가지 방법들이 있는 와중에 경험적으로 좋은 것은 기술을 하는 것이 아니라 역시 돈이 최고다. 쉬어가는 페이지에서 제가 이야기를 한 것이고. 이제 이번 챕터를 정리하겠습니다. 우선 지리적인 기준으로 게임이 갈라진다. 이것은 mmo의 특징이죠. 다음에 공간 분할된다. 심리스를 할 수 있는 것과 해야만 하는 것을 구분한다. 사실 이 부분은 이 앞에 것을 위한 포석인데, 아까 두 가지 일을 기억하시면 됩니다. 하나는 쓰레드 모델이 있고 이것을 결정하기 위해서는 게임의 특성을 봐야 하는데 그 게임의 특성에 가장 높은 것은 리소스 관리고 리소스 중 최고는 월드입니다. 이 두 개를 이야기 하기 위해서…… 서버 프로그램을 하면 대부분 이 부분이 문제가 됩니다. 이곳은 조금 천천히 이야기를 하려고 했는데, 서비스 속도를 떨어뜨리는 것은 공회전이라고 되어 있는데, 이 공회전이 무엇이냐? 쉽게 말해서 아무것도 안 하는 것입니다. 서버가 이런 상황이 언제 생기지? 의외로 많습니다. DB가 제가 볼 때는 1번이라고 생각하고 물론 DB를 비동기로 만들 수 는 있지만, 진짜 하고 싶지 않습니다. 그 다음에 lock issue. dead lock이 발생하는 경우도 심심치 않게 있습니다. 그 다음에 이것은 발생할 것 같지 않지만 많습니다. 명시적으로 슬립을 요청하는 경우가 굉장히 많아요. 정말 이런 것으로 싸우다 보면 우리가 왜 이러고 있는지 라는 생각이 듭니다. 해결법. 사실 이 문제에 대한 해결법은 몇 십 년 전에 나왔습니다. 이것을 다시 말하는 것도 참 부끄러운데, 비동기로 하면 됩니다. 그런데 이 주제로 한 이유는 천천히 설명하겠습니다. 편지를 읽는다. 내가 편지를 받았으면 읽고 싶잖아요? 편지 내용 자체가 DB에 있다면 편지를 DB에 읽고 요청을 하고 이것을 리턴합니다. 잠겨있습니다. 이 시간이 얼마가 걸릴지는 아무도 모릅니다. 제 경험상 가장 길었을 때가 18초 정도 걸린 적이 있었습니다. 그것은 DB 자체에 락이라던가 복잡하게 엉겨서 생긴 일이지만 실제로 발생을 합니다. 그렇다면 비동기로 만듭니다. 비동기로 갑니다. 끝납니다. 무언가를 하겠죠? 다음에 DB에서 다 끝나면 옵니다. 여기까지는 굉장히 좋은데 문제가 무엇이냐. 문제는 이것입니다. 이것을 리턴 할 길이 없기 때문에… 왜냐면 리턴하는 부분을 잊어버린 상태에서 콜백을 쓰면 됩니다. 이게 무엇이 문제냐? 되는 것 아니냐? 제가 만들었던 비동기 모델의 가장 최악의 경우는… 이게 일단 사이즈가 작아서 안 됬습니다. 콜백이 12개나 들어갔는데, 기기뿐만이 아니라 외부 인증 서버, 방음서버, 서버들이 참 많아요. 게임 서버에 필요한 것들이… 거기다가 pc방도 서버에 들어가야 하고. 요즘엔 많이 통합되어있는데 예전에는 다 케이스로 들었습니다. 그 다음에 이것저것 한 다음에 게임 안에서도 중복 로그인 아니냐 묻는 것 포함해서 쿼리가 엄청 많습니다. 이것을 다 비동기로 만들었는데 12개까지 만들고 여기서 더 늘어나면 유지, 보수 못한다고 했지만 늘어났습니다. 그래서 이 부분을 완전히 없애고 동기화 모드로 다시 만들었습니다. 사실은 조절할 수 있습니다. 게임 프로그래머가 조절 할 수 있는 게 동기화 코드 같은 경우에는 코드 작성에 유리합니다. 그 다음에 아까 말했지만 성능에 생각지도 못한 이슈가 생기고, 비 동기 코드는 반대. 사실 결론은 뻔합니다. 잘하자. 그런데 이런 이야기를 왜 했냐면 그냥 잘 하자면 의미가 없기 때문에 제가 적당히 제가 쓰는 방법으로 하겠습니다. 아까도 말했지만 비동기 콜백을 굉장히 싫어합니다. 그 이유는 한번 쓰기 시작하면 멈출 수가 없습니다. 동기화 비 동기화를 같이 쓴다는 것은 굉장히 위험하기 때문에 한번 비 동기 모델로 빠지면 돌아오기 힘듭니다. 그렇기 때문에 어쩔 수 없이 늘어나는 피쳐에 대해서 전부 비동기로 대응을 하게 되는데 그러다 보면 아까 저처럼 더 이상 못 만들겠어 라고 보이콧해버리고 해버리게 됩니다. 그래서 저는 비동기로 된 것을 동기화 코드로 만드는 것을 굉장히 좋아합니다. 어떻게 만들었는가? 이것을 예로 들겠습니다. 아까 인풋 쓰레드 시스템 기억나세요? 어떤 것이냐 하면 인풋 쓰레드에서 그대로 로직까지 이어지는 겁니다. 온리시브가 멈추지 않고 계속 연결되어 있습니다. 예를 들어 클라이언트에서 온 것이 리시브되고 로직까지 가고 그러면 마지막 플레이어가 패킷을 보냅니다. 그런데 그게 잠금을 유발하면 플레이어에게는 렉으로 다가옵니다. 여기까지는 좋은 것이 없어 보입니다. 그런데 실제로 놓고 보면 이런 차이가 있습니다. 이것이 반응이 분명히 느리지만 다른 플레이어들은 굉장히 영향을 적게 받습니다. 물론 안에서 락이 걸리고 한다면 문제가 되겠지만 영향을 최소화 할 수 있는 기반이 됩니다. 그렇다면 그것을 저는 어떤 식으로 표현을 하는가 하면 이런 식의 내용이 있고, 사실은 이것이 이번에 여러 가지 주제를 처음에 썼다가 하나를 고른 것이 바로 부분입니다. 저는 이것을 내성이라고 부르는데 서버가 얼마나 빨리 자동 복구가 되는가가 제 내성의 기준입니다. 싱글쓰레드를 예를 들어 보겠습니다. 싱글쓰레드에서 렉이 생깁니다. 우선 이것은 쉬지 않고 돌 때 100명을 처리할 수 있습니다. 여기까지는 문제가 없습니다. 그런데 어쩌다 보니 0.1초 딜레이가 생깁니다. 나중에는 1초의 딜레이가 생깁니다. 이 100명은 이제부터 1초씩 딜레이가 생기는 겁니다. 풀 수가 없습니다. 이를 해결할 유일한 방법은 나가는 것입니다. 유저 수가 줄어드는 것이 유일한 해법입니다. 그래서 싱글쓰레드는 이 내성이 굉장히 약합니다. 그래서 제가 싱글쓰레드 를 충분에도 빠름에도 불구하고 게임 서버로는 부적합하다고 이야기한 근거는 그 내성에 있습니다. 그러면 아까 이야기 했던 오브젝트 풀 같은 경우에는 어떻게 되는가. 이것들은 몰리면 대책이 없습니다. 이 쓰레드에 몰리는 것을 막을만한 장치가 없습니다. 그러니까 중앙에서 적절히 분배를 해줘야 하는데, 그래서 가장 빠른 방법은 이 분배가 유일하게 가능한 모델입니다. 바쁜 녀석에게는 안 주면 됩니다. 대신 유저가 느끼기에는 스타베이션이 발생합니다. “내껀 왜 처리가 안돼?” 라는 경우가 생길 수도 있지만 시스템적으로는 가장 최적화 되어있습니다. 하지만 쓰기 불편한 단점이 있습니다. 이런 여러가지 문제 때문에 제가 지금 가장 내성이 좋다고 생각하는 것이 인풋쓰레드인데, 인풋쓰레드는 스펙트럼이 넓습니다. 락을 어디로 잡는가에 따라 락 안에서 슬립이 일어나면 전체가 잠길 수도 있지만 락 위치를 옴기면 충분히 최소화 할 수 있는 여지가 생깁니다. 저는 가능성을 보고 이 방법을 쓰고 있는데, 실제로 로직 모델에서 얼만큼의 여파가 생길지는 지금 계속 실험을 하고 있습니다. 비동기 이야기를 왜 잘 안하느냐? 아까도 이야기 했지만 비동기 모델을 쓰는 경우는 굉장히 국한되어있고 네트워크에서 쓰고, 일부 모델에서 다른 서버와 통신할 때 씁니다. 게임 플레이와 연결되는 부분에서 비동기는 저는 경험상 쓰지 않습니다. 마지막은 좋은 말로 썼습니다. 그냥 안 쓰려고 했는데, 그렇게 할 수는 없으니까 써봤습니다. 어쨌든 제가 만약 고르라면 동기화 비동기화를 가르는 극단적인 기준이 아니라 코드가 단순해 지는 것이 결국 마지막에 가면 이기기 때문에 그쪽을 선호합니다. 저는 이것들을 작업하면서 제가 여러분들에게 많은 새로운 지식을 가르쳐 드릴 수 있다고 생각하고 만든 것이 아니라 저와 이런 이야기들을 하면서 ‘누군가는 시작했으니 나도 해봐야지’라고 생각한다면 저는 오늘 발표에 의미가 있다고 생각합니다. 
(질문자)_비동기모델을안쓰는이유가메인의코드가복잡해져서유지보수가어렵다고말씀하셨는데실제로비동기모델을쓰더라도포르틴이나이라든지코드자체는싱글처럼보이게할수도있고그러면서도비동기를실행을가능하게할수있는데이런것을안쓰시고굳이동기체제로가신이유가무엇이신지궁금합니다
(발표자)_좋은 질문입니다. 제가 피티가 너무 어려워질 까봐 하이딩 처리한 것이 있는데 그 부분이 바로 어싱크랑 코드처리 문제인데 그게 왜 안 쓰냐 라고 한다면 어싱크는 너무 최근에 나왔고 어싱크가 갖는 이번 최신버전에 나와 아직 재대로 사용하려면 훈련이 필요할 거 같아 보류를 하였고 코드티를 왜 안쓰냐 코드티는 너무 언어적 제한이 많습니다. 코드티 자체에 한계가 있는데 그게 뭐냐 하면 스테이터스가 코드티일들 앞뒤로 바뀌어요. 그런데 그것을 예전에 코드티를 써서 그 일들의 앞뒤로 스테이터스가 바뀐 것 추적을 하는데 어떤 식이냐 하면 분명히 내가 이 전까지 나랑 거래하고 있던 사람이 코드티를 통과하고 나면 로그아웃한 경우가 있습니다. 그러면 이것은 케이스를 해야 하나 어떻게 해야 하나 난감하죠. 물론 방법이 있는데 로직 프로그래머가 이런 말도 안되는 상황을 상정하고 코드를 짜려니 빌딩이 되지 못하고 터지더라고요. 그래서 과감하게 코드티는 저는 기본 설계에서 제외합니다.
(질문자2)_혹시 프로그래밍 언어로 어떤 것을 사용하는 것을 권장하시는 가요
(발표자)_저는 개인적으로 지금은 개발하기에는 C#이 제일 편한 것 같습니다. 그런데 남한테도 권하기는 힘든 게 메모리 관리가 너무 힘들어서… 만약에 C#의 메모리 관리가 영 마음에 안 든다고 하면 C++이 현재는 최고로 좋은 것 같습니다. 그런데 저는 어쨌든 그냥 메모리를 늘려서 해결하려고요.
(질문자3)_아까 질문의 연장인데, 저희 같은 경우는 모바일 게임이라는 다른 점이 있는데 동기화를 썼다는 건 서버의 대부분의 시간이 DB호출이나 이런 거에서 보내버리기 때문에. 낭비인 것 같아서. 어떻게 consistency를 고려하려고 해보거든요? 사실 말씀 하신 대로 디버그나 이런 게 힘들기 때문에 어려운 부분인데…… 어느 쪽이 더 나은지 궁금합니다.
(발표자)_성능은 확실히 코드티 좋죠. 그런데 아까 얘기 했듯이 그게 라이브 들어가기 전까지 코드티가 터질 줄 몰랐는데, 그 상황이 정말 말도 안 되는 상황들이 너무 많은 게 일단 글로벌한 뭔가가 있다 아니면 숫자 1~10을 넣은 글로벌 컨테이너가 있는데 이게 코드티 전이랑 후랑 같을 것을 보장할 수가 없다라고 로직 프로그래머들이 얘기를 하고 훈련을 시켰더니 멘붕을 하더라고요. 왜냐하면 글로벌 컨테이너가 당신 작업할 때 못 해도 40~50개 인데 이 40~50개를 일일이 테스트 할 수가 없습니다. 그래서 포기했습니다. 만약에 충분히 제한 할 수 있다면 가능하죠. 저도 그걸 제한하고 싶은데 그 쪽은 또 로직 프로그래머들의 편의와 개발 속도 때문에 제가 제한할 수 있는 부분이 아니라서 저는 그래서 안 쓰는 것이지 싫어해서 안 쓰는 것이 아닙니다. 정말로 쓰고 싶어 합니다. 성능 이야기를 안 했네요. 성능에 불만족이냐 그래서 인풋 쓰레드에서 쓰레드가 굉장히 많습니다. 제가 보통 한 100개 정도 유용한 쓰레드를 100개정도 쓰려고 해요. 너무 떨어지지 않겠냐 라고 하는데 충분히 상태 슬립 같은 것을 고려하면 100개정도 해야지 대충 속도가 나오는 것 같고 시스템 쓰레드에서 100개 만드는 거야 어렵지 않기 때문에 그래서 이 모델을 쓰는 겁니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
