2015년 11월 26일 (목) 09:20 판

중국서비스시 기술적 체크사항!!

중국 서비스시라고 명명을 하긴 했지만, 모든나라 게임을 런칭을 하면서 발생되는 문제다. 약간의 경중이 있을 뿐이고, 미리미리 준비한다면 그래도 어려움이 좀 적어지지 않을까 한다. 여기나온 글이 정답이 아닐수도 있다. 해결방안은 항상 다양하기 때문에 다양한 생각들이 공유되었으면 한다.

서버 사이드

네트워크 상태가 좋지 않는(끊겼다 붙었다라는 느낌) 유저에 대한 대처는 되어있는가?

중국은 내트워크 상황이 천차 만별이다. 회선이 좋은 사람, 회선이 좋지 않은사람 많은 사람들이 섞여서 게임을 진행하게 된다. 초반에 유저들이 한 맵에 몰려있는 상황에서 많은 패킷을 좋지 않은 유저에게 보내려고 패킷을 할당하고, 메모리가 증가되서(버퍼오버플로우 처리 미흡), 혹은 처리를 못해서 죽는 경우가 발생하게 된다.

http://blog.naver.com/cosphoto/150012140907

이 문제에 대해서 언급한 글이 있는데, 참고하자.

스위치, 방화벽은 적절한 장비를 사용했는가?

  위 문제에 대해서 동일한 증상은 스위치(D-Link 등) 가 패브릭이 버텨내지 못할때도 똑같이 발생하게된다. 현상적으로 게임서버가 죽게 되는데, 제휴사쪽에 이에 관련된 고급엔지니어가 없다면 케취해내기가 힘들고, 게임서버의 문제로 돌리는 경우가 생긴다. 프로그래머만 출장을 나갔다면 정말 당황스러운 상황이 연출된다. (예전에 이 문제 때문에 대만에 아침에 연락받고, 저녁에 날라간적이 있다. )  
  이 문제로 확인된다면! (이건 이 문제인지 꼭 확인해보고 움직여야한다.) 임시적으로 스위치에서 물려있는 서버 댓수를 줄이고, 예비스위치를 투입하고, 우선 상황을 버틴후, 서버쪽에 올라가있는 스위치를 검증된 스위치(cisco 3550, 2950 등등)로 모두 변경을 해야 한다.

DB 부하 문제

  DB의 부하도 고려해야 한다. GameDB는 서버단에서 거의 분산이 되기때문에 거의 문제가 되지 않는데, 공동된 DB(예를 들어서 accountDB 라던지, MemberDB라던지)가 있다면 프로팰러를 돌려서 꼭 인덱스 작업을 하자. 만약 인덱스 되어도 부하가 많다면 DB구조를 바꿔야한다.

네트워크 상태가 좋지 않는(그냥 느린느낌) 유저에 대한 대처는 되어있는가?

아... 참 애메한 문제이다. 위에 문제같이 끊겼다 붙었다 그러는 사람 같은 경우는 그냥 짤라버리면 되는데, 이거... 그냥 느린 사람에 대해선 어떻게 처리해야 하는가? 참으로 애매한 문제인데, 어째든 처리해야한다. 잘해보자.. 다만 클라이언트로 역할을 넘기는 방향으로는 결정되길 않길 바랄뿐이다.

서버프로그램 실행시 경로참고문제

서버 프로그램 실행시 절대경로에서 실행되게 프로그램 되어야 한다. 상대경로로 지정하게 되면, 원격에서 서버프로그램을 실행할때 엉뚱한 파일을 참고 할 수 있다.

서버 부하분산은 잘 되어있는가?

분산서버로 게임서버를 구축하게 되면 어떤곳에 부하가 몰릴 수 있는지 잘 체크해 보는것이 좋다. 만약 예상보다 많은 부하가 있는 서버가 있다면, 분산방향을 다시한번 고려해보는것도 좋다. 유일하게 존재해야 하는 서버가 있다면 이 서버의 한개를 명확히 해보는것도 좋고, 그 한계상황보다 더 많은 유저들이 들어왔을때 어떻게 대처할지 충분히 시뮬레이션을 돌려보자.

로그인 관련 처리는 잘 되어있는가?

로그인 관련 처리라고 총칭하기에는 항목이 너무 많다. 초반에 정의되는 값이긴 하지만, 급히 변경될 여지도 많은 상황이다. 1) 로그인 ID의 길이에 대한 값을 서버의 경우는 셋팅값으로 빼준다면, 유동적으로 셋팅할 수 있으므로 가급적이면 그렇게 해주는 것이 좋고, 클라이언트에서 보통 바이너리 안에 셋팅되는 값을 손쉽게 바꿀수 있도록 함수로 정의해 놓는 것이 좋을것이다.

2) 로그인 ID의 대소문자 구분, 특수문자 허용 관련 잇슈가 있다. 그냥 허용한다 안한다로 끝나지 않고, '일부 문자는 허용한다.' 로 끝날 수도 있다. 정확히 정의해놓지 않는다면 하나를 빼먹어서 고생한다던지하는 문제가 발생한다. 이문제에 관련된 부분은 꼭(!) 문서로 받고, 최종점검시에 다시한번 확인하자.

로그인 서버의 부하분산

  한국 같은 경우는 로그인 서버를 보통 하나의 서버로 구성을 한다. 중국같은 경우는 네트워크가 안좋은 유저는 계속 물고있는 경우가 생겨 죽을수도있다. 이에 대해서 고려가 되어있다면 한번 테스트삼아서 띄워보고, 죽는다면, 로그인서버도 부하분산을 하는것을 생각해야 한다. 셋팅값에 의해서 부하분산을 하게되고, 이때 대부분이 로드발랜싱을 어떻게 할것인가에 대해서 고민할텐데, 아주 간단한 방법은 로그인서버 IP를 셋팅하는 것이 아니라, 도메인을 셋팅하게 되고, 도메인에 여러 아이피를 넣어서 라운드로빈방식으로 부하를분산하면 된다. 만약 로그인서버에서 중복로그인에 대한 값들을 가지고 있다면 다른 서버(예. DB)에 그 기능을 분리해야 한다. 로그인은 순수히 로그인만 처리하도록 설계하자.

  중국업체중에서 샨다랑 계약하고 서비스하게 되는 경우, 이때 샨다에서는 로그인 시스템에 E-key(OTP)를 달도록 요구하게 된다. 이 시스템이 장착되게 되면, 원래 2번이면 끝나던작업이 4번으로 늘어나게 되고, Login Server에 주는 부하는 대략 8배로 늘어나게 된다. 그렇기 때문에 한국에서는 문제가 없더라도 중국에서는 문제가 발생할 수 있다. 꼭 로그인 서버를 분산할 수 있어야 한다.

썸머타임 적용에 따른 이상유무

미국, 유럽등은 썸머타임이 적용된다. 적용되는 사항을 서버에 체크해서, 시간이 항상 연동되믄 좋은데, 그러한것에 의지하기가 쉽지 않다. 그렇기 때문에 썸머타임에 따른 시스템을 구성해야 한다.

클라이언트 사이드

처음에 한 화면에 많은 유저가 모여있을때의 처리는 되어있는가?

  처음 게임이 시작하면 허용하는 모든 유저가 모두 한화면에 출현하게 될것이다. 이렇게 된다고 하면, 클라이언트와 서버의 부하도 매우 커지고, 네트워크 패킷도 늘어나고, 유저는 몬스터가 부족에서 몹잡기도 힘든 장중고에 시달리게 될것이다. 이에대해서 어떻게 대처를 해야 하는가? 정말 다양하게 대처해야 한다. 지금까지 최적화를 미루고 있다고 하면 최적화를 꼭! 해서 나가야 한다. 
  기획적으로 해결하는방법은 초보들이 움직이는 맵을 병렬로 분산하는것이다. 3D게임에서 리젠방식이라고 한다면 다양한곳에서 리젠이 되도록 조정하는 것이다.

번역은 잘 되어있는가?

  중국서비스를 하려고 로컬라이징 작업에 빠지지 않는 작업은 번역이다. 보통 중국쪽 번역은 여러사람이 하게 되는데, 동일한 아이템, 동일한 NPC이름을 다른이름으로 번역해서 오는 경우를 종종 볼 수 있다. 이부분에 대한 체크가 필요하다. 공통된 항목이 있다면 가이드라인을 제시해 주는 것이 두번 일하는 것을 막을 수 있다.

클라이언트 창모드

  클라이언트 창모드 관련 잇슈가 항상 발생한다. 만약 풀화면 모드만 사용한다면 문제가안되겠지만,한국에서는 창모드를 지원하는 것이 보편화되어있기 때문에 이부분을 막아달라는 요청이 오고, 이부분을 파라메터값으로 처리했었는데, 이부분만 그냥 버튼(?)만 없게 처리했다면, 한국 클라이언트를 확인해서 파라메터값을 케취해서 중국쪽에 적용해보고, 된다는 것을 바로 알아차릴것이다.(1시간도 안걸린다.)아이에 파라메터값을 없애벌는 방법으로 처리해야 하고, 제휴사 안에서만 지원하는 문제는 다른 방법을 고려해봐야한다. IP로 제한하는 방법도 좋고, 다양한 제한을 해야 한다.

P2P 홀펀칭 처리 문제

홀펀칭을 처리할때 모든 아이피에 대해서 동일한 방식으로 처리하기 보다는 네트워크 상황에 맞춰서 홀펀칭을 시도하는 것이 좋다. 동일한 사설망 네트워크안에 존재하는 사람들끼리 게임을 한다면 홀펀칭을 하지 않고 그냥 통신하게 해야 한다. 사설망과 공인망의 판단은 클라이언트에서 조사한 IP와 서버에서 접속한 IP가 같은지 틀린지에 대해서 판단하면 되고, 사설망이라고 판단되었을때 서버에 접속한 IP가 같다면 동일한 네트워크 안에 존재하는 두개의 클라이언트가 게임하는것으로 판단한다.

클라이언트 PATCH 관련 문제

보통 클라이언트 패치를 위해서 구성되는 서버는 보통 분산서버로 구성하게 된다. 그런데 분산서버로 구성하게 되면 서버마다 동기화시간이 다르다는 문제가 발생하게 된다. 한국같은경우 동기화 시간이 매우 짧아서 문제가 발생하지 않으나 해외 같은경우 1시간 심할때는 하루정도까지(심정적으로) 걸릴 때도 있다. 이런경우에 대한 대비책을 마련하는 것이 좋다.

보안 사이드

해킹, 메크로 문제

중국 사람들은 정말 해킹(?)을 좋아한다. 패킷을 캡춰해서 보는것은 기본이고, 동일한 패턴이 보인다면 꼭 메크로를 만들것이다. 항상 동일한 패킷이 가고, 서버쪽에서 패킷을 검증하지 않는다면, 이 패킷은 꼭 조작될 것이다. 잘 이해가 안될수도 있으니까 이부분은 예를 들어 설명을 하도록 하겠다.

  1) 포탈 이동을 하는데, 이 포탈이동에 대해서 검증(포탈을 쓰는 유저의 위치체크)을 안한다면? 
  2) 웨이포인트등 위치를 저장하는 장소가 있는데 이에 대한 검증(유저의 위치체크)을 안한다면?
  3) 퀘스트를 깨는 조건이 맵끝까지 가는조건인데, 역시 위치체크를 안한다면?
  4) 전체 외치기(보통 쿨타임으로 제한사항을 두는) 있는데, 이 쿨타임 체크를 클라이언트에서만 한다면?
  5) 몬스터가 항상 동일한 위치, 일정한 범위안에서 그리고 동일한 시간에 리젠된다면?
  6) 유저의 공격범위에는 포함되고, 몬스터의 공격범위는 미치지 않는 안전한 장소가 있다면?
  7) 동일한 키입력이 들어왔을때, 이에대한 처리(1분이상 동일한 키입력금지)를 해놓지 않는다면?
  8) 스피드 핵 관련 문제에 대해서 어떻게 대처하고 있는가?
  9) 패킷암호화는 잘 되었는가? 동일한 내용에 대해서 항상 같은 패킷을 보내지는 않는가?

다음은 클라이언트 안정성을 테스트 하는 항목들이다. 참고해볼만한 사항이다.

각각의 항목에 대해서 안전도를 1점 만점으로 테스트를 한다.

서버 해킹문제

서버 해킹에 대해서 누구도 장담할 수 없다. 이문제에 대해서 제휴사를 믿는 방향으로 가닥을 잡는다면 정말 큰 오판을 한것이다. (실제로 제휴사 직원이 프로그램을 빼돌리는경우도 봤다.) 서버 인증에 대한 것은 적용되어있는건지, 방화벽은 적용되어있는지, 어디 취약점은 존재하고 있는지 빠짐없이 체크해야 한다.

소스코드의 유출

해외 서비스 제공시에는 소스코드 유출은 가급적 하지 않아야 하며, 컴파일 된 형태의 서버 버전 및 클라이언트 버전의 제공이 필요하다. 협력사의 현지화 요구로 인하여 제출해야 할 경우에는 핵심적인 부분을 제외한 나머지 부분에 대해서 협력을 하여야 하며, 핵심부분의 경우에는 본사에서 직접 처리하거나 본사 인력을 통해서 처리하여야만 한다. 소스코드의 관리는 접근제어 및 권한에 따른 분명한 접근이 가능하여야 한다. 암호화된 매개체에 저장이 되어야 하며, 외부 유출시에도 암호화 되어 보호가 가능해야 한다.

게임 내의 아이템 등에 대한 내부 유출 문제

제휴사에는 게임DB를 조작할 수 있는 adminTool혹은 GMTool(이후 GMTool)등이 제공되게 된다. 이를 받은 제휴사 직원이 이를 남용, 아이템을 생성하여 팔아먹는다던지 하는 문제를 발생시킬 수 있다. 그렇기 때문에 이러한 툴들은 직접 DB에 접근하여 DB를 조작하는 방식이 아닌 서버-클라이언트 방식으로 제작하고, 서버에서 로그를 남길 수 있도록 하여야 한다. 또한 이와 병행되어야 하는 것은 직원에 대한 교육이다. GMTool은 외부로 반출을 금지해야하며, (서버에서 accessList를 걸어서 외부에 프로그램을 가지고 나가더라도 사용하지 못하도록 조치해야한다.) 직원이 게임내 수치를 조작였을때, 생기는 파장에 대해서 각인시켜야 한다.

참고 사항

  DB Character Set : Chinese_PRC_CI_AS
  중국 커피는 맛이 없다.
  기름진 음식이 많다.
  중국사람들이 모두 술을 잘마신다는 거는 편견이다. 싫어하는 사람도 있다.