NDC Replay

분산서버 구축의 ABC
이호규
넥슨코리아
현재 모바일 게임을 개발하고 있으며, 서버 프로그래밍을 담당하고 있음 과거 던전스트라이커, 스맥다운 vs 로우 온라인, 라이딩스타을 개발하였음 총 개발 경력은 10년 이상
대규모 게임 서비스를 위해 분산 서버는 선택이 아니라 필수이다. 이런 분산 서버를 구축하는 방식은 보통 서버 개발자 개인의 경험과 지식의 토대로 이루어지는 것이 많다. 이 세션에서는 이미 많이 알려진 분산 서버 구축 방법을 소개하고, 실제 게임내에 적용되었던 예외처리 및 장애 처리 방법, 그리고 운영에 대한 아이디어를 공유하여 분산서버를 구축하는 이론적 근거 토대 및 실제 적용할 수 있는 방법에 대해 제시한다.
[새 창에서 슬라이드 보기]
감사합니다. 반갑습니다. 안녕하세요. 진짜 NDC 운영국에서 얘기한 것처럼 사람들이 많이 왔네요. 지인들이 올 거라고 생각은 했는데 지인 분들은 좀 안보여서. 그러면… 멀리서 오신 분들도 있을 텐데 알차게 해보도록 하겠습니다. 제목은 ‘분산 서버 구축의 ABC’ 고요. 대규모 분산 시스템을 구축하기 위한 실용적 예와 그 원칙들이 되겠습니다. 그 내용을 적으면서 많은 거를 생각했는데요, 아무래도 NDC가 이제 좀 깊게 얘기하는 것도 좋을 것 같아서 나름 독립적인 역할을 할 수 있는 분들. 그래서 학생 분들한테는 죄송하지만 이게 최소 1년 이상의 서버 프로그래머 대상으로 강연을 준비했습니다. 제 약력은 던전 스트라이커를 최근에 개발했고요. 스맥다운 VS 로우 라고 THQ 콘솔 온라인 한 거 했었고, 라이딩 스타를 했었고요. 그 외 마음 아프지만 여러 MMO들, 보드게임들 했었는데 출시는 못했습니다. 대략 2003년도에 개발을 시작해서 지금은 대략 10년정도 넘은 개발자고요. 개요는 일단 첫 번째가 분산 서버는 왜 필요한 가에 대해서 간략히 다뤄볼 예정이고요. 2번이 어떻게 분산할 것인가. 이 부분이 많이들 글도 나와있고 다들 경험적으로 알고 있는 분들. 그거를 좀 이론화해서 양이 좀 많은데 how에 대해서 얘기를 할 거고요. 3번은 견고한 분산 서버 시스템. 이 부분은 저희 게임 개발자들이 많이 간과하는 것 같아요. 웹 서비스 아키텍처나 다른 쪽에서 보면 이 부분이 참 잘 되어있는데, 이 부분에 대해서 다루고 4번은 개발자로서의 넋두리에 대해서 얘기를 해볼 예정입니다. 1번 why. 분산 서버는 왜 필요한가? 에 대해서 할 거고요. 제가 근무를 하고 와서 목이 좀 많이 탑니다. 양해 좀 부탁 드릴게요. 분산 서버는 왜 필요한가? 던전 서버 하나만 있으면 안되나요? 이거 실제로 일어났던 일입니다. 이게 없었던 일이 아니고요. 유명 퍼블리셔의 사업부 분이셨는데, 기술 회의 들어가실 때 이렇게 물어보셨어요. 던전 서버가 너무 많으니까. 사실 그때 여러 가지 생각이 많았고 정확하게 얘기해드리고 싶었는데 기 비 개발자 분이셔 가지고. 아무튼 이런 좋은 계기를 저한테 주셨습니다. 그래서 좀 되게 많이 당황을 했었는데. 처음은 이렇죠? 왜 필요하게 됐을까요? 이걸 보려면 예전 서버부터 역사를 보면 될 것 같아요. 예전에는 단순하죠. 단일 서버에 DB하나 물려서 각 서버군 선택해서 들어가는. 이 때는 전혀 필요가 없었는데, 요즘에는 다 이렇게 많이들 쓰실 겁니다. 앞 단에 Front end 좀 달고 뒷단에는 요즘 NoSQL이라고 반응 속도 빠르게 하기 위해서 많이 달고. DB서버 있고, DB도 멤버쉽 DB, 게임 DB 이렇게 나눠서 많이들 쓰죠. 결국 이렇게 됐다는 거는 무엇이냐 하면 게임이 많이 바뀌었다는 겁니다. 많이 바뀌었죠. 10년이 지났으니까. 그래서 기획자들 만나거나 새로운 트렌드를 보면 다들 뭘 다 외치죠? 유저가 더 많았으면 좋겠다. 유저 인터렉션이 세상에 다 영향을 받았으면 좋겠다. 나의 하나의 포인트가 다른 사람의 퀘스트에 영향을 줬으면 좋겠습니다. 심지어 하나의 공통세상을 서버가 만들어주세요. 이렇게도 많이 얘기하고요. 결국에는 이렇게 이런 많은 것들을 단일 서버로 구성하면 서버가 못 버텨나갈 겁니다. 그래서 분산 서버가 필요하게 되었습니다. 그러면 무엇을 분산해야 할까요? 이게 가장 기초적인 질문인데, 결국 분산이란 사람마다 정의는 다를 수 있습니다. 그런데 제 나름대로 객관적으로 생각을 해보면 머신의 하드웨어 부하를 분산시키는 게 가장 큰 목적입니다. 그래서 머신의 부하는 뭐가 있을지 보면, 기타 자잘한 거 빼면, 크게 세 가지로 나눌 수 있는데요. 하나는 네트워크, 대역폭. 그리고 CPU. 그리고 메모리. 분산 서버를 하면 기본적으로 장점이 있습니다. 그거는 기능의 분산을 통해서 서비스 안정성이 확보되는 건데요. 간단히 던전 서버 10개가 있었을 때 던전 서버 하나만 죽는다고 서비스가 중지되지는 않습니다. 그냥 그 쪽 던전 분들만 게임 못 하게 되고, 역시나 커뮤니티 서버나 채팅 서버가 해도 게임 플레이는 가능하게 되는 거죠. 대신 단점은 개발자들한테 많이 왔는데, 어쩔 수 없이 서버가 분산되다 보니까 정보를 많이 분산을 시켜야 돼서 디버깅에 어려움이 있고요. 당연히 한 쪽에서만 해야 될 거를 여러 쪽을 해야 되고, 타이밍 이슈나 동시성에 의해서 나타날 수 있는 문제들도 파악을 해야 돼서 이런 쪽은 단점이 되겠죠. 제가 사실 강연이 되게 캐쥬얼하게 얘기를 하는데, 많이 웃으셨으면 좋겠어요. 1부는 금방 끝났고 계속 하도록 하겠습니다. 2부. How. 어떻게 분산할 것 인가. 이 부분에 대해서 많은 시간을 할애할 건데요. 천천히 보도록 하겠습니다. 분산 서버의 기본은 저도 그렇고 제가 2003년 병특으로 시작해서 2004년도에 처음으로 제가 서버 구조를 잡게 됐던 거 같아요. 그때 이제 큰 화두였던 것 같아요. 그때 여러 사람들이 서버 아키텍처 글도 내고. 결국 분산 서버의 기능은 뭐냐면, 분산을 해야 된다. 그래서 독립적으로 하나를 여러 개로 나눠야 된다. 이게 가장 기본이라 생각합니다. 그래서 결국 A+B해서 C를 내는 게 아니라 A역할을 할 수 있는 다수를 늘려서 하는 거고요. 이건 익히 다들 아시는 바와 같이 scale out 패턴이라고 불리고 있고요. 그래서 옛날에는 각각 아예 DB를 분립해서 유저들이 같이 게임을 못 했던걸 DB를 같이 해서 교환이 일어나게 하고. 그런데 DB만 하니까 DB가 아무래도 부하가 많이 걸리고, read/write가 I/O도 있으니까 DB 서버를 통해서 캐시를 하고. 대략 2004년도, 5년도 캐쥬얼 때 많이 했죠. 이걸 설명 드리면, 이제 게임 서버가 scale out 되다 보니까 다른 서버에 붙어있는 애들도 같이 게임을 해주게 해주자. 그래서 관리 서버, 매니저 서버가 대충 이럴 때 등장을 했고요. 그래서 붙어 있어도 같이 모아줄 수 있게. 그러다 보니까 관리 서버가 있으니까 채팅서버라든지 길드 서버라든지, 커뮤니티 쪽 서버들을 이렇게 넣어서 하게 됐고요. 이게 보통 만드신 분들마다 약간 다르긴 하지만 주로 캐쥬얼 서버 쪽에는 정형화된 구조라고 생각합니다. 그런데 이제 MMO나 MO가 들어가면서 약간 이슈가 달라졌던 게 캐쥬얼 같은 룸 게임 서버에서는 이미 시작했을 때 I/O가 발생하니까 그 전에만 애들을 같은 곳에 모아두고 실행을 해도 큰 문제가 없었어요. I/O 쪽 부하가 작아서요. 그런데 MMO 같은 경우에는 애들이 이동해야 되고, 이동하다 보면 broadcasting이 많이 발생하고. 그래서 I/O 단과 로직 단을 많이 나누게 됐죠. 그래서 우리가 익히 아는 Front/back 구조. 정확히는 앞에는 front end. 뒤에는 back end. 어떤 사람은 앞 단 서버, 뒷단 서버. 이렇게 말하는 구조가 됐고요. 그러면 여기서 대충 크게 서버가 이렇게 많이들 정형화 된 부분을 살펴봤고요. 그러면 서버를 분산 서버의 기준, 유닛을 만들 때 과연 주의해야 할 거는 없냐. 이 부분이 저는 제일 중요하다고 봅니다. 첫 번째 통합 독립적 로직. 즉 역할로 나눈 것. 던전 서버, 로비 서버. 이런 식이고요. 단순 기능 로직으로 나눈 것들 있죠? 아이템 서버, 퀘스트 서버. 그러니까 하나의 기능만을 감독하는 서버들. 과연 어느 게 좋냐하면 기능 로직 서버는 하면 아이템과 퀘스트. 사실 연관이 되어 있는데 분산이 되다 보니까 굉장히 로직 처리가 복잡합니다. 퀘스트를 완료하기 아이템을 줄 수 있냐? 물어봐서 맞다고 해야 되고, 퀘스트 완료했는데 아이템 줘라. 못 준다. 이러면 여러 번의 트랜잭션을 거쳐서 에러처리를 해야 되죠. 로그 분석도 되게 복잡한 게, 물론 파일 단위로 남길 때에는 서버가 다르니까 아예 불가능한데. 요즘은 DB로 검색을 용이하게 해서 남겼다고 하더라도 머신 시간이나 이런 것들에 의해서 분석하기가 참으로 어렵습니다. 그래서 제 개인적인 결론은, 양심을 걸고, 통합 쪽이 좋다고 생각합니다. 통합 쪽은 역할로 나누는 건데요. 얘가 어떤 로비 쪽. 로비라면 캐릭터도 만들어야 되고 커뮤니티 정보도 가져올 수도 있고. 이런 것들 한 쪽에 모아두면 동시성 제어라든지 버그 제현, 수정, 개발 유지보수에 상당히 좋습니다. 아까 퀘스트를 예를 들었는데 그 예를 또 들면, 당연히 퀘스트 쪽 관련하는 서브 시스템과 아이템 쪽 서브 시스템이 한 바이너리 안에서 자유롭게 왔다 갔다 할 수 있기 때문에 당연히 훨씬 좋고요. 결국 저는 role로 분산해야 된다고 생각합니다. 이 부분에 이견이 있을 수도 있겠는데… 그 다음에 scale up 인데요. Scale up 물론 다들 잘 아실 겁니다. 그런데 핵심은 성능과 비용의 타협이라고 생각을 합니다. 이 그림을 봤을 때 저 표시한 게 매니저 서버거든요. 그런데 보통 앞 단은 그럼 scale out 하니까 10만명, 20만명 받겠네. 뒤 단은 어떻게 하지? 그러면 매니저 서버는 어떻게 과연 scale out하냐? 일단 비용을 생각해 봐야 합니다. 왜냐면 주된 서버가 아니니까 애매한 거죠. 그닥 아주 빈번한 처리는 없고 한 번만 다른 애들한테 매치해 주면 그 앞단 서버가 알아서 다 해주는데, 굳이 이걸 해줘야 되나? 그래서 매니저 서버를 만약에 scale out 하게 되어도 사다리 형으로 매니저 서버가 필요하게 되고요. 그래서 성능보다 안정성이 필요할 때 이런 경우 scale up이 제일 좋고요. Scale up은 알다시피 장비의 성능을 늘리는 거고요. 일명, 좋아하시는 분도 있고 안 좋아하시는 분도 있는데, 장비빨이라고도 많이 불립니다. 그러면 이제 소셜 들어오면서 많이 화두가 됐던 데이터베이스. 이거는 그러면 어떻게 scale out하냐? 일단 이것도 이유를 짚어보도록 하겠습니다. 예전에는 DB 단 까지는 요구하지 않았어요. 기획자 분들도. 우리 한 월드가 만 명을 처리합니다. 2만 명을 처리합니다. 보통 DB 때문에 제한이 걸린 경우도 많았고요. 그러면 다들 그런가 보다. 그러고 넘어가는데 소셜 게임이 대두가 되다 보니까, 한 같이 월드를 구성하는 유저가 10만이 아니라 수백 만 명도 갈 수 있다. 이런 끔찍한 얘기들을 하게 되니까 이제 DB도 scale out을 해야겠다. 이게 나온 거죠. 그러면 DB는 scale out이 뭐냐 하면, 웹 쪽에서는 이미 sharding이라고 많이 불리고 있었더라고요. 결국 sharding은 데이터베이스의 scale out인데 shard. 즉 파편이라는 뜻인데, 하나하나 유닛을 샤드라고 말하고 그 샤드를 여러 개를 분산하는 겁니다. 그래서 소셜 게임 같은 경우를 보면 대충 대략 비슷한 구조를 많이 갖는다고 생각하는데요. 앞단에 웹 서버들이 있고, 뒤에 NoSQL 캐시 서버가 있고, sharding을 하는 방법 중에 맵핑 방법이라는 게 있는데 그거를 위해서 sharding 정보들을 구성할 수 있는 어떤 글로벌 DB, 멤버쉽 DB 같은 것들을 두고 각 유저들을 기준으로 데이터베이스를 따로따로 분리해서 두는 거죠. 이게 sharding 입니다. 그래서 이 sharding 구조를 쓰면 장점이 참 많습니다. 결국에는 프로그래머의 감으로써 이거는 확실히 알잖아요? 정보가 너무 많으니까 분산을 해야 된다. 그러면 분산의 기준을 뭘 두냐면 대략적으로 보통 유저단위로 두는 게 제일 좋죠. 그래서 A유저는 1번 게임DB서버, 2번 유저는 2번 게임 DB서버, 이렇게 나누는 거고요. 그러면 이런 sharding하는 방법에는 몇 가지가 있냐? 크게 두 가지인 것 같아요. 하나는 많이들 쓰시는 mapping table. 즉 1번 유저는 어디 게임DB와 어디 로그DB를 사용한다. 이런 mapping table을 유지해서 쓰는 거고요. 다른 하나는 dynamic share라고, 이 유저의 고유한 키를 가지고 계산해서 키 분열로 하는 방법이 있고요. 그러면 맵핑을 좀더 자세히 알아보면 shard한 정보를 테이블에 저장을 할 거고요. 그래서 sharding을 어떻게 구성할지에 대한 정보가 꼭 필요합니다. 당연히 그 DB는 많은 접속이 일어나고, 당연히 그 DB에는 부하가 굉장히 심하기 때문에 NoSQL 캐시를 통해서 성능을 최적화할 수 있고요. 당연히 이래야 된다고 생각합니다. 이렇게 하면 주의해야 할 점은 맵핑 정보를 많이 가져갈 수는 없습니다. 그래도 충분히 필요한 정보를 하다 보면 20byte 정도 되는 것 같아요. 100만명 기준으로 하면 20M 밖에 안 되고요. 더 많은 숫자 세 개를 더 붙여도 20G 정도 밖에 안됩니다. 그러니까 이게 수 만 명 되는 글로벌 DB를 scale out 해야 되느냐? 그럴 필요까지는 없다고 생각합니다. 그래서 글로벌 DB는 충분히 scale up으로 할 수 있고요. 물론 맵핑에 대한 정보는 가지고 있어야 됩니다. Dynamic 부분을 보면 기준 값을 키로 데이터를 분산하는 거고요. 이거는 굉장히 구현이 너무 쉽고요. 그러니까 %로 나눠서, 저 같은 경우는 redis를 경험해봤는데 redis 서버 10개 썼다. 그러면 % 10나눠가지고 해당하는 놈을 그때 맞추면 되는 거고요. 역시나 개발 구현이 제일 쉽고. 다들 너무 조용하시네요. 계속 하도록 하겠습니다. 개발 구현이 굉장히 쉽습니다. 그런데 단점이 하나 있습니다. 키 분해로 할 때는 dynamic sharding이 참으로 어렵습니다. 4대가 있어요. 부하가 심해. 그러면 보통 아까 맵핑 테이블 같은 경우는 DB를 추가하고 로드밸런서 하는 로직 쪽에 그쪽만 패치하면 dynamic sharding을 비슷하게 구현할 수 있는데, 이 키 분해 쪽은 dynamic으로 붙이면 그 키 값에 대한 정보가 다른 쪽에 이미 다 들어가있기 때문에 거의 불가능합니다. 하신 글을 읽었던 것 같기는 해요. 시도했다는 거는. 아무튼 그래서 static sharding으로 많이 하고요. 정적으로 처음에 몇 대를 세팅하고 이거대로 나눠서 키 분해를 하는 거죠. 결국 그러다 보니까 확장을 할 때 re-sharding 문제가 있습니다. 무슨 말이냐면 서버를 4대를 썼어요. 1번, 2번, 3번, 4번이 있는데, 2번 애들 정보들이 많이 있는 거죠. 그래서 5, 6, 7, 8을 넣을 때 이 2번에 해당하는 정보를 5, 6, 7, 8 중에 6번에 넘겨줘야 됩니다. 그래서 re-sharding, 정보를 넘기는 작업이 필요하고요. Sharding은 정말 좋습니다. 이게 있음으로 해서 DB 쪽도 scale out이라는 개념이 들어가기 때문에 우리 소셜이나 one world. 하나의 세상을 구현하는 데 있어서 문제가 많이 없어졌죠. 하지만 불편한 점은 생겼습니다. 하가 데이터베이스 트랜잭션인데요. 프로시저 안에서 다들 트랜잭션을 많이 썼을 겁니다. 코드 단에서 하다 보면 코드의 버그나 이런 것 때문에 트랜잭션이 꼬일 수도 있고 DB의 도움도 못 받기 때문에 가능한 DB 프로시저 안에서 모든 걸 해결한 거죠. 그런데 이거는 유저 만의 DB가 다 다릅니다. A DB가 있고, B DB가 있고. 그래서 A DB에 있는 아이템을 꺼내서 B DB에 줬을 때, 원격 트랜잭션을 어떻게 구성을 해야 되냐? 프로시저 단의 그 기능이 있는지는 정확히 모르겠습니다. MySQL에 원격 트랜잭션이 건재하더라도 부하가 엄청 심할 거라 예상이 되고요. 당연히 이거는 이 프로시저를 호출하는 쪽. 즉, 게임 서버 쪽에서 코드로 처리를 합니다. 이제 코드로 이걸 처리하다 보면 많은 노하우들이 있을 거에요. 왜냐면 한 쓰레드에서 여러 DB를 왔다 갔다 하기 때문에 이거에 대한 트랜잭션을 모아서 한꺼번에 롤백하는 경우도 있고요. 그래서 이쪽은 코딩 노하우가 경험적으로 들어가야 되는데, 그래서 약간의 불편한 점이 있지만 분명한 건 코드에서 처리를 해야 합니다. 그래서 소셜 게임 예를 보면, 앞 단의 서버들, 요청 받는 곳에서 트랜잭션을 처리할 거고요. 다들 이 표정을 예상했어요. 역시 다들 심각하신 것 같아요. 아직 좀 다뤄보실 게 많아서 힘을 내시라고 넣었는데요. 아무도 안 웃으시네요. 좋아하는 그림인데…. 그러면 보통 여기까지 대충 알겠네? 그런 게 아니라 더 무엇을 해야 합니다. 무엇이냐? 이 분산 서버 자체를 만들 때부터 병목을 걱정하셔야 되요. 병목은 크게 CPU, 메모리, I/O 이 세 부분으로 나눌 수 있는데, 일단 CPU. 절대 파이프라인으로 구성을 하면 안됩니다. 즉 A 서버를 통과했어. B 서버로 보내. C 서버가 응답을 줘. 그러면 이제 어떠한 하나의 처리가 완료 되. 이런 처리로 하시면 안되고 꼭 처리량을 늘릴 수 있게. 저희가 이미 멀티 코어에서는 많이 알려진 생성자, 소비자 패턴 있잖아요? 그래서 많은 생성자를 두고 병렬적으로, 독립적으로 처리가 돼서 처리량을 늘려야 됩니다. 메모리 부분은, 이제는 운영체계가 달라져서 이제는 거의 해당이 없을 것 같아요. 64bit의 머신, 클라이언트 쪽은 16g 이 정도 밖에 물리 메모리를 하지 못하지만 서버 머신, 제가 찾아봤는데 2008년도 같은 경우에 인식할 수 있는 물리 메모리. 그러니까 페이징 아웃/인 되는 가상 메모리가 아니고요, 2TB라고 합니다. 사실 수많은 정보를 올릴 수 있죠. 그래서 메모리 쪽은 별로 없을 것 같고요. 이제 I/O 쪽이 되게 중요한데, 분산 서버를 구현해서 할 때 로직컬한 적들은 많이 생각을 하고 하지만 I/O 쪽은 놓치는 부분이 많습니다. 일단 DB I/O 부분이 있는데요. 예전에 와우 보셨다시피, 초창기였던 걸로 기억하는데, 아이템을 줍다가 얘가 멈춰있는 경우. 이런 경우가 있죠. 이런 경우는 이제 게임 서버 쪽에서 ‘아이템을 줘라.’ 했더니 그거를 이제 바로 즉시 처리가 아니라 DB 쪽에 확인을 받고 와야 되니까 DB 쪽에 처리의 끝이 다 있다 보니까 DB가 병목이 생기면 전체 게임이 느려지는 그런 게 있었죠. 그래서 제가 적용하기도 했지만 그런 사항이 있으면 메모리를 먼저 만들어서 리턴하고 DB 쪽에 요청을 해도 충분히 게임 서비스하는 데 문제는 없었습니다. 단, DB쪽에 줬을 때 DB가 유효성 검사의 최종 검사 권한이 있어야 되고요. DB에서 만약에 에러를 리턴하게 되면 그 해당유저는 반드시 끊어줘야 됩니다. 왜냐면 데이터 유효성이 낮지 않으니까요. 그래서 반영성을 위해서 내가 어떤 DB같은 큰 I/O를 가져와야 되는 그런 경우에는 즉시 결과 값을 만들어서 리턴을 주고 후 처리로 넣어줘도 큰 문제는 없다고 생각합니다. 물론 데이터 validation은 DB쪽에서 꼭 확인을 해서 예외처리를 해야 되고요. 그리고 네트워크 I/O 부분이 있는데, 이 부분에 대해서 개발 자분들과 얘기를 하면 크게 두 그룹으로 나뉩니다. 하나는 열렬하게 반대하시는 부분이 있고요 하나는 되게 신선하게 받아들이시는 분들도 있는데, 소켓을 쓰는 데 두려워하지 말아야 된다. 라고 유명하신 분이 얘기를 했는데, 저도 동의하는 부분이고요. 여기 무슨 말이냐면 왜 채팅 패킷을 받는데 시뮬레이션 하는 네트워크 라인을 공유할까? 그게 맞는 질문인 것 같아요. 그럴 필요 없다고 생각합니다. 즉, 커뮤니티 쪽에 날라오는 네트워크 라인하고 시뮬레이션을 분리하면 커뮤니케이션은 아무래도 채팅에 의해서 부하가 되게 많잖아요? 그거에 의해서 네트워크 패키지 지원이 안 되게 분리를 해두면 당연히 상호 연관성이 없기 때문에 더욱 쾌적한 게임을 할 수 있는 거죠. 그런데 이거를 좀더 세부적으로 더 나눠서 할 수도 있는데, 그러니까 이동 관련, 시뮬레이션의 어떤 전투 관련, 그리고 그 외 관리나 채팅 같은 커뮤니티 쪽. 이걸 분리해 두면 독립적이 되니까 연관성, 병목에 대한 부분이 없어질 거라고 생각합니다. 그 다음에 broadcast인데요.  이 부분이 저희 서버 개발자가 주도적으로 해보고 서비스를 경험해볼 때 제일 많이 생각하는 부분인 것 같아요. 일단 인정을 하고 들어가야 됩니다. 이건 지불할 수 밖에 없다. 그럼 지불할 수 있는데 과연 어떻게 최적화를 할 거냐? 당연히 저는 알다시피 한 이벤트가 났을 때 broadcast 나가는 범위. 이 범위를 어떻게 grouping을 하느냐가 가장 최적화의 기본이고 이걸로 이제 서버들이 많이 나오기도 하죠. 이 broadcast를 할 때 가능한 각 컨텐츠가 역할적으로 분리가 될 수 있다면 네트워크 라인을 분리를 꼭 해야 됩니다. 되게 웃긴 건데, 로그인, 로그아웃을 엄청 했더니 게임의 전투가 느려졌어. 이런 것들. 보상 메일을 유저들한테 가 보냈더니 게임이 느려졌어. 이러면 안 된다고 생각하고요. Broadcast 부분에 있어서 이거를 최적화 하는 방법은 많이 있을 수 있어요. 물론 하나만 주고 유저를 선별해서 앞 단 서버에서 병행으로 쓰레드 둬서 돌릴 수도 있고요. 그런데 모든 소켓 버퍼라든지 이런 거까지 최적해서 다 할 수 있는데, 제 경험적으로는 완벽한 최적화를 위해서는 기획에 굉장히 밀접하게 붙어야 됩니다. 그런데 중요한 거는 서비스가 되다 보면 바뀌는 부분이고요. 결국에는 완벽한 최적화는 되게 많이 힘들어서 제 생각에는 90% 정도 해당 로직, 해당 기획에 맞게 최적화 부분을 하고 어쩔 수 없지만 장비 부분으로 대체하는 게 좋다고 생각합니다. 아직 하나 더 남았습니다. 2장이 참 길긴 한데, 한 2~3개 남았네요. 일단 테스트. 이걸 만들고 나서 ‘테스트를 뭘 하지?’ 이것보다는 테스트를 염두해두시고 만드는 게 좋습니다. 그러면 테스트는 어떤 걸 해야 되나? 일단 머신 지표가 있는데요. 이거는 다들 하시고, 커밋 시 요구도 하니까 일단 머신의 CPU, 메모리, 네트워크 바운드 In/Out. 로직 지표가 있을 수 있죠. 보통은 패킷 Queue를 쓰잖아요? 패킷 Queue의 길이가 있고요. 그 다음에 던전 서버나 이런 것 같이 시뮬레이션을 담당하는 거는 한 프레임, 로직의 처리속도. 이게 만약에 1초에 10번돈다. 그러면 1초에 1000명을 봤을 때, 이 1000명의 시뮬레이션을 통과할 때 100ms. 한 프레임을 만족할 수 있냐? 이런 부분이 되게 중요한 부분이 되겠죠. 그리고 네트워크 지표가 있는데, 당연히 이거는 사람마다 좀 다르긴 한데, 네트워크 latency를 로직 전까지 잡을 꺼냐. 그런 관계가 있는데, 하여튼 네트워크 latency가 있고, 보낼 때 send queue의 데이터 크기. 이거는 이제 네트워크가 지연 됐을 때 계속 Queue에 패킷이 쌓이는 거. 그렇게 되겠죠? 테스트는 분산 서버 테스트를 어떻게 하냐? 많은 부분들을 고민하고 지금도 고민한다고 생각합니다. 그렇지만 앞 단에서 설명들을 봤을 때 분산 서버에서 가장 큰 문제는 뭐냐? 결국 병목이고요. 사실 병목 이외의 문제는 개별 서버의 예외로 발생할 수 있는 거라서 그거는 해결할 수 있다고 봅니다. 즉, 병목은 뭐냐면 scale-out을 해도 개선이 안 되는 거. 분명히 A 서버 프로그래머 분께서 얘기했듯이 앞 단에 서버를 늘렸는데, 그래도 게임이 느립니다. 이런 경우가 되겠죠. 그래서 테스트는 병목을 꼭 테스트 해야 됩니다. 그 다음으로는 개별 서버의 성능이 있겠는데요. 좀 이따 보고. 그럼 테스트는 어떻게 해야 되냐? 이제 장비 스펙이 일단 제일 중요하고요. 왜냐면 broadcasting 같은 건 장비 스펙이 거의 90%이기 때문에 되게 중요하고, 그래서 장비 스펙이 결정이 되면 어떤 시나리오 테스트를 하는 게 좋냐? 역시 무조건 broadcast는 들어가야 되고요. 그 다음에 중요한 로직을 같이 해보면 됩니다. 즉, 수 많은 모든 게임의 그런 것들을 하는 게 아니라 제일 부하를 많이 주는 broadcast, 이동, 장비 획득에 대한 알림, 중요 커뮤니티 메시지. 이런 거와 실제 게임 로직을 같이 하다 보면 나오게 되는 거죠. 어디 DB가 병목이다. 이게 나오게 되는 거죠. 이제 서버 성능 부분에 대해서 얘기를 할 건데요. 로직 쓰레드 모델들을 만드실 때 많이들 논쟁이 되기도 하지만 보통 I/O 쓰레드는 여러 개, 로직 쓰레드 한 개로 캐쥬얼 서버 만들 때 많이 그렇게 하시는 분들도 있고, 멀티 코어를 더 확연하게 사용하기 위해서 I/O 쓰레드 여러 개, 로직 쓰레드 여러 개. 이렇게 해서 쓰시는 분들도 있는데. 아무튼 로직 쓰레드 그 안에서는 가능한 블록이 없어야 되기 때문에 당연히 비동이 I/O를 써야 되고요. 클라이언트에서 많이 쓰는 polling이라는 방법과 이벤트가 있는데, polling은 계속 매번 체크를 해야 되기 때문에 서버 쪽은 이벤트가 제일 낫고. 역시나 메모리 쪽이 여유가 있기 때문에 계산 값, 캐시를 많이 이용해야 됩니다. 그러면 여기서, 제가 제일 두려워하는 부분이기도 한데, 이 부분은 어떤 분은 성향 차이라고도 하고. 그러니까 이거는 이론 적으로 어느 정도 예측은 할 수 있으되, 그 기획서버에 멀티 프로세스를 돌리냐, 멀티 쓰레드를 돌리느냐, 어느 게 더 낫냐. 이거는 정말 바로 산술적으로 비교가 안되는 수치라서 일단 제 의견을 과감하게 얘기를 해드리겠습니다. 멀티 프로세스는 장점이 있습니다. 장점은 뭐냐 하면 당연히 I/O는 멀티 쓰레드고요. 그 다음에 싱글 로직 쓰레드를 두는 거니까 당연히 로직컬한 쪽에서는 concurrent에 대한 염려가 별로 없습니다. 즉 싱글톤도 마음대로 쓸 수 있고, 시작과 끝 점에 대한 것도 명확하고, 어떤 예외처리가 왔을 때 그거에 트랜잭션 처리도 굉장히 명확하게 할 수 있습니다. 즉, 관리, 개발이 굉장히 편리하고요. 이거는 신입이 누가 오든, 경력자 분이 누가 오든 명확하게 그 쓰레드 안에서 시작되는 것들은 머리를 크게 쓰지 않고도 추가 개발이 가능할 정도로 쉽죠. 이걸 하나 잡고 들어가면 멀티 쓰레드를 쓴다고 해서 성능이 속도가 빨라지는 건 아닙니다. 그건 많은 책에서 다들 나왔다시피 멀티 코어를 쓰는 거는 병행적으로 독립적인 애들이 돌기 때문에 당위 시간당 생산성이 드러날 수 있죠. 그래서 요즘은 16코어, 24코어… 코어가 많기 때문에 각 그 코어에 쓰레드를 올려서 생산량을 쓰는 게 하드웨어 머신의 성능을 더 쓰는 거니까 당연히 처리량이 좋고 많이 좋습니다. 그런데 문제점은 멀티코어를 쓰려면 A라는 유저가 멀티 코어 A, A필드 쪽 맵을 할당해서 이렇게 처리를 하게 되면 기타 얘가 접근할 수 있는 다른 서브시스템의 것들은 싱글톤이 될 수 없고, 멀티쓰레드 쪽에 가서 들어가야 되요. 이게 당연한 거 아냐? 이렇게 하시겠지만 개발하다 보면 굉장히 헷갈리게 됩니다. 클래스에 이 부분들이 이렇게 있는데, 이 때는 어떤 쓰레드에 접근하고, 어떤 쓰레드에 접근 안 하고. 보통 그래서 함수 위에 적죠. From, 로직 쓰레드 어디서 온다. From, 어디 쓰레드에서 온다. 이제 그 부분을 명확하게 이해해서 짜기가 되게 어렵다는 겁니다. 그래서 항상 concurrent 버그가 나고요. 이건 버그가 나면 아시다시피 메모리 같은 경우에는 랜덤하게 죽죠. 힙이 깨졌다고 저기서 죽고, 저기서 죽고. 문제는 이거는 장비, 코어가 많을수록 발생을 하기 때문에 절대적으로 내부가 가지고 있는 테스트 서버 단에서는 거의 발생을 안 하고 주로 퍼블리셔에 의해서 실제 머신, 16코어 이상인 거일 때 발생이 되니까 참 개발자 삶을 힘들게 합니다. 그래서 저는 제 개인적인 의견은 이런 멀티 코어 쓰레드는 시대의 트렌드라고 생각을 합니다. 이거는 꼭 개발자는 익혀야 된다고 생각하고요. 단 MO나 MMO 처럼 거대 성능을 요구할 때, 그런 던전 서버에는 되게 적합하다고 생각합니다. 그런데 그 외 캐쥬얼 서버나 소셜 서버나 또는 로비 서버 또는 기타서버 등등은 멀티 프로세스로 하셔도 충분히 좋다고 생각하고요. 그러니까 멀티 쓰레드라고 프로세스 하나를 띄우는 게 아니라 한 머신에 해당하는 프로세스를 여러 개를 띄우는 거죠. 당연히 알다시피 쓰레드가 프로세스 스위칭에 비해 훨씬 비용이 싸기 때문에 이론적으로 충분히 멀티 코어 쓰레드가 장비 성능을 더 잘 쓸 겁니다. 하지만 개발자의 단위 시간에 어떤 픽처를 구현함에 있어서 어떤 단가로 보자면 저는 멀티 프로세스가 더 좋다고 보고요. 이상입니다. 2부는 끝났습니다. 지금 시간이 아직 남았군요. 조금 빨리 할게요. 4시 5분에 끝나고 가능한 질문을 받도록 하겠습니다. 견고한 분산 서버 시스템이란 무엇이냐? 이거는 저도 소셜 쪽을 하면서 많이 배웠는데요. 과연 분산 서버는 만들었어요. 그런데 얘가 진짜 견고하다. 이런 표현을 쓸 수 있다. 그러면 그게 뭘까? 뭐냐면 첫 번째. 어떤 오류에 대해서 서비스가 중지되면 안 된다. 이게 Fault Tolerance고요. User trace. 해당 유저를 추적함에 있어서 불편함이 없어야 된다. 보통 서비스하면 많이들 나오잖아요? 그 다음에 server dashboard인데, 현재 분산서버 시스템의 서버 현황을 잘 봐야 됩니다. 장애라든지, 부하라든지. 일단은 fault에 대해서 애기를 드리면 exception handling하고 fallover, 장애복구로 나눌 수 있는데, exception handling에 대해서 좀더 자세히 보면, exception 처리를 하는 목적은 항상 가능하게. 예전에는 이렇게 개발도 많이 했어요. 던전 서버에서 메모리 exception이 났다. 그러면 얘 죽이고 다시 빨리 켰죠. 그런데 이런 게 아니라 예외가 나면 이 예외에 해당하는 놈들. 또는 예외가 발생한 룸. 그런 지역적인 놈들만 하고 이 서버는 살아있는 채 서비스를 하는 그런 개념입니다. Graceful exception handling이란 뭐냐면 이런 유저가 나타났을 때 보통은 끄는 데, 저도 예전에는 그렇게 많이 했습니다, 그런 게 아니라 유저를 로비나 안전구역으로 보내주면 유저가 다시 로그인할 필요 없이 게임을 지속적으로, 물론 불편을 하지만 다시 로그인하고 대기표 받고 이런 과정은 필요 없으니까 훨씬 좋고요. 그 다음에 error trace 부분은 exception이 났을 때 C++ 쪽은 보통 메모리 덤프를 떠서 하는데, 메모리 덤프만을 볼 때 부족한 경우가 있습니다. 왜냐하면 어떤 경우에 의해서 메모리가 잘못되는지 히스토리를 볼 필요가 있을 때. 그때 error trace를 어떻게 남기는 게 좋은지 얘기를 해보겠습니다. 일단 C++ 쪽은 SEH 요즘 다들 많이 쓰시니까 에러가 나면 덤프 뜨고 해당 유저만 로비로 보낸다든지 이런 걸 많이 하는 거고요. Graceful은 아까 말씀 드렸다시피 친절하게 ‘잠시 장애가 났습니다. 죄송합니다. 10초후 로비로 이동합니다.’ 이런 것들을 저희 서버 쪽에서 지원할 수 있는 거고요. Error trace는 뭐냐면, 보통 개발할 때는 많이들 하시잖아요? 유저의 full log를 남기죠. 뭘 리퀘스트했고, 어떤 이벤트가 났고. 이런 걸 쭉 남기는데, 실제 서비스는 거의 불가능합니다. 워낙 양이 많으니까요. 그럴 때 쓸 수 있는 게 이 해당 유저의 어떤 중요 액션에 대한 로그를 한 10개, 100개 정도를 유지하고 있다가 exception이 발생하면 그때 그 100개를 이걸 넣어주는 쪽 서브시스템에 의뢰를 해서 걔내가 넣어주면 얘가 exception나기 전에 어느 정도 휘발성 로그를 확보할 수 있습니다. Failover 쪽으로 하면 장애 복구인데요. Exception에 불구하게도 장애는 납니다. 그게 참 exception을 안 걸었는데도 안 건 쪽에서 나기도 하고 장비 쪽에서 나기도 하고. 그러면 이럴 때 서비스를 다 끄고 다시 시작할 거냐? 그건 아니고 그 해당 룸만 장애복구를 해야 됩니다. 제일 많이 쓰는 replication, 복제 방법은 마지막에 설명 드리고요. 일단 간단하게 할 수 있는 instant load랑 local DB, memory DB를 이용하는 방법에 대해서 알아보도록 하겠습니다. Instant는 필요할 때 정보를 복구하는 거죠. 메일 서버 같은 경우에 얘 메일 정보를 굳이 다시 켰을 때 가져올 필요 없어요. 그런데 얘가 다시 메일을 보낸다고 요청 받았을 때. 또는 어떤 유저의 메일 정보에 접근이 필요할 때. 그때 다시 DB를 가져와서 세팅하고 응답을 줄 수 있고요. 이럴 땐 중요하지 않은 정보를 할 때는 굉장히 유용합니다. DB에서 가져오는 경우는 매니저 서버 같은 경우를 예로 듭시다. 모든 유저가 매니저 서버에 정보를 가지고 있는, 보통 다 그렇게 하죠. 그런데 매니저 서버가 죽었어요. 서버 군은 보통 그럴 땐 다시 껐다 키는데 그런 게 아니라 메모리 서버를 킬 때, 메모리 서버가 자신이 중요하다는 정보를 받으면 DB 쪽이나 자신의 로컬 DB에다가 정보를 똑같이 writing을 합니다. 그래서 다시 켜질 때는 필요한 정보를 다시 load해서 가지고 있는 거죠. DB를 통하면 역시나 필요한 정보를 모두 load할 땐 복구 안정성이 굉장히 좋고요. 대신 서비스 시작하는 데 딜레이가 좀 필요하고, 복제 모델하고 똑같이 내가 어떤 중요 정보를 모르면 writing 부하가 들어 게 됩니다. 이제 복제 모델인데요. Master/slave 모델인데. DB쪽에서 많이 쓰고, back down 서버 쪽에서는 많이 쓰는 기술이죠. master라는 주요 서버가 있고 slave라는 보조 서버들이 있고. 그래서 내가 어떤 정보를 업데이트할 때는 master에도 쓰지만 slave에도 쓰는 거죠. 또는 master에 쓰면 master가 slave로 연결해 주기도 하고. 굉장히 안정적인 복구 모델이고요. 또는 reading 경우에는 다들 알다시피 slave쪽에만 가져와서 read 부하를 분산할 수도 있고요. 이거는 DB 쪽에서는 많이 쓰는데, 우리 게임 온라인 쪽이나 매니저 서버나 DB 서버 쪽에는 많이 안 쓰는데, 데이터베이스가 아니라 DB 서버입니다. 매니저 서버에 쓰면 상당히 안정적으로 구현할 수 있습니다. 물론 이거를 더 완벽히 하기 위해서는 내가 mater가 slave로 writing 하라고 전달 할 때 자신이 누구인지 까지 남기면 나중에 복구할 때 이 바이너리 로그까지 체크해서 복구하면 더 확실하게 장애복구를 할 수 있겠죠. 그림을 보면 뒤에 redis가 나올 건데요. NoSQL 같은 거를 두면, NoSQL이 쫙 올렸다가 필요할 때 NoSQL 받아도 되고, 저거는 이제 로컬DB 모양인데, 로컬DB했다가 로컬 DB 받아도 되고. Dashboard는 특정 유저의 추적이나 현재 분산 서버 모니터. 또 지표 수집할 때 필요하고요. 로그는 파일 로그도 있고 DB로그도 있습니다. 그런데 분산 서버할 때는 저는 무조건 DB 로그로 해야 된다고 생각합니다. 그 이유는 당연히 분산 서버에 있으니까 로그가 분산되어 있잖아요? 그러면 그 로그를 받아서 시간대 별로 그 유저를 추적하는 시간이 굉장히 많이 듭니다. 또 머신 시간 별로 약간씩 오차가 있기 때문에 정확한 타이밍 이슈를 찾는데 굉장히 어려움이 있죠. 그래서 DB 로그를 두면 좋은 거는 유저 ID에 쓸 하나, 유저 세션 키로 하나 하면 유저가 하는 것들을 쫙 볼 수 있습니다. 검색에 굉장히 용이하다. 단, 단점은 DB 테이블을 많이 먹습니다. 그래서 통짜 테이블을 만들면 어느 순간 한 달이 되면 너무 용량이 많아서 검색 부하가 되게 심하고요. 그래서 가능한 일일 테이블을 두면 검색에 굉장히 용이합니다. 그리고 모니터는 메모리 DB를 통해서 많은 걸 할 수 있는데, 특히 redis요. 정말 redis는 훌륭한 애인데. 각 서버가 예전에는 자신의 정보를 다른 외부 시스템에 주려면 보통 매니저 서버가 외부 서버시스템을 인터페이싱 하기 때문에 내가 수집한 정보를 매니저 서버로 올리고 매니저 서버가 어떤 인터페이스 API를 통해서 외부로 올리고. 이런 작업을 할 필요가 없이 바로 redis로 커넥트 해서 쏴주면 됩니다. 굉장히 성능이 우수한 아이라서. 그러면 다른 외부 시스템은 redis나 이런 NoSQL 서버에 들어와서 1초당 리프레시를 하든 이런 식으로 할 수가 있고요. 역시나 exception이 났던 것도 올려줘도 되고 그렇습니다. 그 다음에 지표 문제가 있는데요. 중요 지표 CS는 당연히 서버에서 하는 게 맞습니다. 중요하다는 건 뭐냐면 어떤 사업적인 비즈니스 지표. 매출관련. 또는 CS 적인 처리가 필요한 커스텀 서비스 쪽에 필요한 것들은 두는 게 맞고요. 그런데 그 외 유저의 성향을 파악하기 위한 거. 즉, 내가 파티를 맺어서 A던전에 들어갈 때 내 인벤토리에 뭘 두고 싶었는지. 또는 내가 레벨 10일 때 내 카드 덱은 어떻게 구성이 되어 있는지. 이런 거 다룰 때는 굳이 서버를 통해서 할 필요 없이 클라이언트 베이스 로그를 쓰면 좋습니다. 서버를 쓰면 서버는 DB 검증도 받아야 되고요, QA도 통해야 되고요. 그래서 시간이 많이 걸리고요. 그런 실시간 적으로 받고 싶은 걸 받는데 있어서 꽤 시간이 걸립니다. 정보 취합하는데도. 클라이언트 베이스라면 요즘은 많이 쓰잖아요? 인앱이라고 해서 앱 서버에서 바로 해주는 그런 솔루션도 있고, 오픈 소스도 있는데 그런 것들을 통해서 해주는 거죠. 그러다 보면 정말 많은 걸 분석할 수 있습니다. 던전 입장 시에 내 파티원들 정보는 뭔지. 내 파티원들이 장착한 것은 뭔지. 이걸 서버에서 하면 서버는 애들이 모여있기 때문에 천 명의 그 모든 것들을 처리하면 부하가 로그 때문에 더 들어나는 거죠. 그런데 이거를 클라이언트 베이스에서 하면 부하는 어느 정도 있는데 간지럽고요. 그러다 보면 아키텍처 단이 좀 나뉘게 되는 단점은 있습니다. 그래서 왼쪽은 실제 게임 서비스를 담당하는 부분이라고 하고, B쪽. 이거는 실제 구현을 한 다음에 이렇게 되는 거고요. 이런 걸 대신해 주는 솔루션들이 있습니다. 공짜인 것도 있고요. 그래서 B단에서는 외부로 쏴주면 앱이 어떤 Queue 오픈 소스나 이런 걸 통해서 실제 writing만 해주는 애들한테 인계를 해주면 쉽게 구현할 수 있는 부분이고요. 남은 게 있습니다. Redis. NoSQL 중에, 물론 제가 Mongo는 제가 경험을 못해봤어요. 못해봤는데, redis는 정말 훌륭합니다. 안정적이고요. 굉장히 빠르고요. 명확합니다. 그런데 이제 redis 쪽에는 저희가 push 알람 같은 기능도 있어요. 그래서 예전에는 매니저 서버를 통해서 각 앞 단에 front end 서버까지 갔는데 그럴 필요 없이 redis가 각 서버들이 자신의 redis 메시지를 받아 와서 실시간 적으로 바로 알릴 수도 있고요. 이거는 이제 단순한 관리 기능뿐만 아니라 이벤트 쪽에서 웹이나 이런 걸로 데이터화를 해서 redis에 올리면 redis는 SQL로 구현된 놈이 아니라 NoSQL로 맵이라든지 여러 가지 정보를 가지고 있을 수 있습니다. 그런 정보를 구성해서 올리면 그 정보를 실시간으로 받아와서 할 수도 있고요. 또는 관리기능 중에 상점 on/off도 손쉽게 할 수 있고요. 정말 좋은 거에요. Admin을 예로 들면 이렇게 된 거죠. 저 노트북 같은 데서 올리면 관련 된 애들이 관련 정보를 받아와서 해주는 겁니다. 3부가 끝났습니다. 엑스트라입니다. 분산 서버를 할 때 개발자로서 또 하나 약간 신경을 써야 할 부분이 배포방법인데, 배포를 그냥 ‘서버 5개네? 그냥 올리지 뭐.’ 하다 보면 서버간에 패킷 버전이 안 맞을 수도 있고, 여러 가지 데이터를 쓰는데 다를 수도 있고. 신경 쓸 게 많아요. 그래서 통합 서버 바이너리를 만들어 두시면, 그게 무슨 말이냐면 던전 서버, 로비 서버를 객체로 하고 하나의 메인에서 그 객체들을 생성해서 연결해 두는 거죠. 그러면 하나의 EXE안에 12개의 서버 역할을 하는 애가 들어가 있는 겁니다. 이거는 굉장히 편해서 배포하기가 너무 편합니다. 그래서 어디서 뭐 시연이 필요해? 그러면 얘 하나만 던져주면 되고, A라는 클라이언트 개발자가 ‘나 이거 필요한데, 이거만 좀 줘.’ 할 때, 다른 머신 필요 없이 EXE면 굉장히 편하고요. 원 바이너리 서버 같은 경우는 이곳도 비슷한 개념인데, 하나의 바이너리에 모든 서버의 그런 것들을 빌드해서 넣는 거고요. 대신 얘가 실행되면서 나는 던전 서버 역할을 하겠다. 나는 로비 서버 역할을 하겠다. 이렇게 뜨는 거고요. 그래서 EXE는 여러 개가 뜨는 그런 방법이 되겠죠. 그래서 통합 서버는 각 서버를 객체로 정말 수비고요. 정말 디버깅하기도 쉽습니다. 저 같은 경우는 레슬링 게임 그거 할 때 해봤는데 정말 편했고요. 바이너리 서버 같은 경우는 서버간 버전 불일치 절대 없고, 이것도 쉬운데 약간 복잡한 거는, 왜냐면 이 서버가 ‘나는 어떤 서버가 되겠어.’ 이런 종합 설정이 약간 들어가게 되요. 그런데 이것도 괜찮은 것 같아요. 그 다음에 스케쥴 부분인데, 분산 서버를 구축하겠다고 마음 먹는 순간 개발 비용이 한 순수 개발은 6이지만 분산 서버를 유지/보수하는데 한 4정도가 들어갑니다. 그래서 보통은 서비스 전에 ‘지금 잘 돌아가니까 바로 서비스 일정 잡자.’ 절대 그러시면 안되고, say no! 저도 잘 못하지만 절대 안 됩니다. 이렇게 얘기를 해야 되고요. 일정을 잡음에 있어도 아까 6대 4기 때문에 가능한 분산 서버 유지/보수 할 거에 대한 것도 잡아야 되고요, 제일 중요한 건 test driven development인데, 알다시피 아무리 내가 테스트 대형 레이어를 쓴다고 해도 완벽한 테스트는 나올 수 없어요. 왜냐면 DB를 공유하기도 하고, 또는 어떤 거는 이 한 서버에서 하는 게 아니라 다른 서버의 정보를 이용해야 되기 때문에. 그렇지만 가능한 던전 서버라면 그 서버 안에서만은 PDD를 써서 로직컬한 거 검증하는 거는 굉장히 큰 도움이 됩니다. 이상입니다. 감사합니다. 
질답을 하고 싶어서 후반에는 많이 달렸는데요. 첫 번째 질문이 “샤딩 방식을 사용한 프로젝트가 있었나요? 있었다면 곤란한 점은 없었습니까?”
예. 지금 하고 있습니다. 샤딩 프로젝트할 때 굉장히 편했어요. 어렵지도 않고요. 개념적으로 너무 간단합니다. 단점은 아까 트랜잭션 처리인데 어려웠어요. 어려운 게 한 쓰레드 안에서 유저가 여러 DB를 건들다 보니까 트랜잭션하고 롤백 처리하는 게 어려웠는데, 그 부분은 물론 코딩적 노하우로 해결하였습니다. 결국에는 DB 트랜잭션이었고요.
“클라우드 서버의 WS를 쓰는 경우의 분산 서버는 어떤 점이 다를지… 유의할 점이나 무시할 수 있는 변경 사항.” 
글쎄요. 이거는 이론적으로 일단 어떤 로직컬한 주제를, 피처를 받고 제가 로직적으로 이 놈을 어떻게 분산할지, 어떠한 패턴을 쓸지, 또는 얘의 어떤 운영을 쓰는 거라서 사실 이거는 클라우드 서버 군을 쓰든, 서버 저희 지원하시는 분이 있어서 서버 팀의 도움을 받든 큰 문제는 없다고 생각을 하고요. 그래서 죄송한데 이 부분은 제가 더는 모르겠네요.
다음 질문은 “분산 서버를 구축할 때 장애 환경에 대한 부분을 생각을 안 할 수가 없는데요. 분산 포인트마다 장애가 발생했을 때 어떠한 대처방법이나 혹은 꼭 고려해야 하는 상황이 있다면 어떤 것이 있을까요?” 
아까 말씀 드렸다시피 3장에 속해 있는 부분이에요. 그런데 가장 기본이 되는 거는 exception handler입니다. 사실 failover. 최악의 경우에는 다시 할 수도 있어요. 그런데 제일 기본적인 거, 많이 빼먹는 부분이 exception handling. 트라이 캐치라든지 SEH를 통해서 실제 이놈의 파티가 붕괴됐어. 그러면 가능한 이 던전 서버를 다 죽였다가 관리 툴에서 빨리 키는 게 아니라 이 해당하는 놈들의 exception을 잡아서 덤프 남기고 가는 거. 저는 그게 가장 큰 포인트라고 생각하고요.
“서버간 병목 확인은 어떻게 하셨나요?” 
증상은요, 무조건 클라가 느려집니다. 그 다음에 두 번째로 나타날 수 있는 건 다른 애들의 리소스가 놀고 있는데 느려지는 겁니다. 그래서 아까 지표 같은 거를 뒀는데, 그 지표를 추적해보면 어떤 한 애만 바빠요. DB라든지 또는 매니저 서버라든지. 던전 서버는 널널한데 front end, I/O쪽이 CPU 80이 넘어가고 이런 다든지. 그래서 아까 말씀 드린 지표를 충분히 보시면 병목 부분을 확인할 수 있고요.
그 다음에 이것도 같이 할게요. “게임 서버로부터 리퀘스트를 받은 서버가 다운됐을 때 대응은 어떻게 하셨나요? 리퀘스트는 그냥 누락되고 마는 건가요?” 
이건 기획자 분들하고 이견도 있고 그랬는데요. 할 수 없는 부분에는 할 수 없다고 하는 게 옳다고 생각을 해요. 리퀘스트를 받았는데 이게 처리에요. 그래서 DB쪽에 보내려고 하다가 죽은 거죠. 이제 다시 켰을 때 이 정보가 다행히도 리셋이 안 돼서 다시 요청했으면 좋은데, 리셋하는 부분까지는 날라가고 보상적인 부분이 빠졌다. 물론 이제 트랜잭션 묶어놓은 부분인데 버그가 있을 때 가능한 부분입니다. 그 때는 프로그램 쪽으로 어떤 자동화 시스템을 만들어서 얘가 들어왔을 때 자동으로 막하는 걸 만드는 건 굉장히 비용이 큽니다. 그 때는 이제 어쩔 수 없이 점검을 통해서 해당 관련된, 불일치 되는 애들을 추리고, 그 분이 어떤 항의를 하셨겠죠? 그 분의 그거를 관리 툴에 의해서 CS 보상 쪽으로 해결하는 게 맞다고 생각을 합니다.
한 개만 더 하면… “던전 종류마다 던전 서버를 나누시는 것 같은데 특정한 던전이 인기가 없으면 서버는 노는 건가요?” 
음… 제가 예전에 만든 게임은 그랬습니다. 던전이 물론 데이터를 가지고 있으니까 얘를 띄우고 어떤 특정 정보를 로딩해서 그때 그때 자신의 역할을 바꿀 수도 있는데, 모르겠어요. 기존에는 보통 레벨 10짜리 던전용 서버다. 그러면 레벨 10에 해당하는 데이터만 올려와서 썼어요. 그 때는 물론 메모리, 지금은 64bit가 되었지만 그 때는 메모리 장애도 많고, 그래서 모든 정보를 다 로딩해서 어떤 경우든 하지는 않았고요. 그런데 지금은 이 부분에 대해서 많이 고민해봐서 어떤 정형화된 그런 패턴들이 나오면 좋을 것 같네요.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
