오늘은 Game4U 7월 2차, 횟수로는 두번째 정기점검이다.
회원수에 관계없이, 규모에 관계없이 정기점검은 지난 일년 반동안 정말 뛰고 싶었던 행사(?)였다.
정기점검이야말로 서비스가 나가고 있다는 증거이고 온라인 게임 회사만의 규칙이기 때문이다.
즉, 빨리 Game4U를 선보이고 싶었고 원래 피처폰 게임 조직어었던 이곳을 빨리 온라인 조직으로 이끌고 싶었다.
7월 2차 정기점검 공지
간단하게 "정책결정->기회서 제작->리소스 제작->코딩->QA->정기점검을 통한 배포"가 한 사이클로 돌아간다.
한 정기점검에 늦게 되면 당연히 다음 정기점검 때 패치를 해야 하는 것이고.
정기점검은 기획자, 디자이너, 프로그래머, 그리고 QA들만의 일이 아니다.
가장 중요한 것은 "개발환경->QA환경->배포환경->실서버 배포"까지
유기적으로 돌아가는 내부 프로세스가 수행되어야 하는데
이 프로세스를 만들고 확립하고 원할하게 만들고 정기점검동안 관장하는 팀이 필요하다.
그리고 빠뜨릴 수 없는게 각 서버에 있는 binary를 동기화 시켜 개발환경부터 실서버까지 배포시키는 SE팀의 능력이다.
(SE는 단순히 OS 업데이트하고 서버 설치하는 일만 있는 것이 아니다.)
잘 보이지 않지만 중요한 SE의 역활
온라인 게임 하나를 올리는지, 크고 작은 게임 여러 개를 올리는지에 따라 프로세스도 많이 바뀐다.
지금은 Game4U라는 플랫폼과 에픽하츠 하나 뿐이지만, 이 모습은 게임 포탈을 염두에 두고 만든 모습이다.
앞으로 꾸준히 게임이 늘어날 것이므로 여러 개의 게임을 올리는 방향으로 프로세스를 만들었다.
아쉽게도 현재는 온라인 게임을 운영해본 SE가 사내에 없고 지겹도록 정기점검을 뛰어본 사람은 나 혼자 뿐이다.
그래서... 정기점검 프로세스도 내가 만들었다. -_-;;;
(이 포스트를 통해 도움준 분당의 모 게임회사 기술센터 멤버들에게 무척 감사를 드린다.)
그러나 기존 온라인 게임의 정기점검과 다른 점은,
이를 위해, 우선 서버는 항상 클라이언트보다 먼저 배포되어야 한다는 규칙이 생기게 된다.
따라서 코딩 가이드도 일반적인 온라인 게임에서 좀 바뀌게 되었다.
언제 애플이나 T스토어에서 클라이언트가 오픈될지 모르고, 업데이트시 이전 버전과 업데이트 버전을 동시에 만족시켜야 한다.
모든 프로토콜은 이 조건을 만족해야 했다. 물론 지금도.
두번째 무선랜으로 변경되며 그동안 온라인 게임 회사들이 이용했던
proxy나 DNS를 변경한 서버 환경 전환을 할수 없다는 점이다.
문제는 너무 많은 AP가 설치하면 서로 주파수를 간섭하게 된다는게 현재 고민꺼리이다.
세번째는 게임 서버를 분산시켜주는 1차 서버에 점검중일때 서비스를 막는 기능을 추가하였다.
Game4U가 접속하는 첫번째 서버는 UDW(Uni-Destination WebServer)로
각 서비스별 해당 서버 NSAP을 알려주고 업데이트 여부를 통해 강제로 접속을 막거나, 점검 중일때를 막는 기능을 추가하였다.
이를 통해 각 서비스별로 전체를 막거나 다른 서버로 돌릴수 있도록 설정해두었다.
물론 국가별, 버전별 세부 기능도 제공되므로 언젠가 서버가 늘어가고 운영인력이 늘어나면
온라인 서비스의 꿈중 하나인 1년 내내 중단없는 서비스도 가능하게 되었다.
오늘 정기점검은 무엇이 바뀔까?그래서 달린다...
(이 포스트를 통해 도움준 분당의 모 게임회사 기술센터 멤버들에게 무척 감사를 드린다.)
그러나 기존 온라인 게임의 정기점검과 다른 점은,
1) 스마트폰으로 무대를 옮기며 클라이언트를 원하는 싯점에 배포할 수 없다.
2) PC기반의 유선랜이 아닌 스마트폰 무선랜이다.
3) 전체 서비스를 막을 웹페이지가 없다
라는 것이다.2) PC기반의 유선랜이 아닌 스마트폰 무선랜이다.
3) 전체 서비스를 막을 웹페이지가 없다
이를 위해, 우선 서버는 항상 클라이언트보다 먼저 배포되어야 한다는 규칙이 생기게 된다.
따라서 코딩 가이드도 일반적인 온라인 게임에서 좀 바뀌게 되었다.
언제 애플이나 T스토어에서 클라이언트가 오픈될지 모르고, 업데이트시 이전 버전과 업데이트 버전을 동시에 만족시켜야 한다.
모든 프로토콜은 이 조건을 만족해야 했다. 물론 지금도.
두번째 무선랜으로 변경되며 그동안 온라인 게임 회사들이 이용했던
proxy나 DNS를 변경한 서버 환경 전환을 할수 없다는 점이다.
(무경험자에게 설명할게 참 많은데, 가장 쉬운 사례는 이거다.
정기점검할때 보면 게임 사이트 웹페이지 막혀있잖아?
그렇지만 해당 회사 내부에서는 패치 작업해야 하므로 막혀있지 않음.
물론 실제 막혀진 실서버가 아니라 같은 주소를 가진 패치서버에서 하고 있는 것이고 <- 이거 나중에 적어야지.
당연히 클라이언트 소스 내에서 접속 주소를 바꾼다는건 말도 안된다.
따라서 내부에서는 같은 도메인으로 접속은 하되, proxy나 DNS를 변경해 다른 서버로 연결시킴. 우왕~ 존나 천쟄ㅋㅋ)
이를 위해서는 AP를 추가하고 각각 다른 DNS를 세팅하여 극복하였다.정기점검할때 보면 게임 사이트 웹페이지 막혀있잖아?
그렇지만 해당 회사 내부에서는 패치 작업해야 하므로 막혀있지 않음.
물론 실제 막혀진 실서버가 아니라 같은 주소를 가진 패치서버에서 하고 있는 것이고 <- 이거 나중에 적어야지.
당연히 클라이언트 소스 내에서 접속 주소를 바꾼다는건 말도 안된다.
따라서 내부에서는 같은 도메인으로 접속은 하되, proxy나 DNS를 변경해 다른 서버로 연결시킴. 우왕~ 존나 천쟄ㅋㅋ)
문제는 너무 많은 AP가 설치하면 서로 주파수를 간섭하게 된다는게 현재 고민꺼리이다.
세번째는 게임 서버를 분산시켜주는 1차 서버에 점검중일때 서비스를 막는 기능을 추가하였다.
Game4U가 접속하는 첫번째 서버는 UDW(Uni-Destination WebServer)로
각 서비스별 해당 서버 NSAP을 알려주고 업데이트 여부를 통해 강제로 접속을 막거나, 점검 중일때를 막는 기능을 추가하였다.
이를 통해 각 서비스별로 전체를 막거나 다른 서버로 돌릴수 있도록 설정해두었다.
물론 국가별, 버전별 세부 기능도 제공되므로 언젠가 서버가 늘어가고 운영인력이 늘어나면
온라인 서비스의 꿈중 하나인 1년 내내 중단없는 서비스도 가능하게 되었다.
그런데 UDW의 기능은 너무 잘 만들어 두었는지, UDW의 역활을 잘 이해하지 못하는 사람들이 많은 듯 하다.
아마 고전적으로 SE들의 할일을 서버 프로그램이 해줘서 그런가 보다.
(왜? 라고 묻는다면 회사 내에서 SE팀과 서버팀의 역할 충돌과 역학적인 충돌이 일어날수 있기 때문이다.)
하지만 UDW는 적은 인력으로 거대한 서비스를 돌리기위한 1차적인 구성요소이다. 무척 만족한다.
아마 고전적으로 SE들의 할일을 서버 프로그램이 해줘서 그런가 보다.
(왜? 라고 묻는다면 회사 내에서 SE팀과 서버팀의 역할 충돌과 역학적인 충돌이 일어날수 있기 때문이다.)
하지만 UDW는 적은 인력으로 거대한 서비스를 돌리기위한 1차적인 구성요소이다. 무척 만족한다.
빛나는 무대 뒤에서 배포를 대기하는 binary들.
우선 커뮤니케이션 서버의 유령사용자 현상을 없애고(채팅 좀 많이 해주세요~)
사용자 정보 변경 기능의 버그를 고쳤다.
가장 중요한 것은 7월중 배포한다고 약속했던 시크릿 박스를 위한 서버 프로토콜이 올라간다.
이제 일주일 정도 후면 우선 안드로이드에서 시크릿 박스란 앱을 볼수 있을 것이다.
게임은 아니지만 Game4U 커뮤니티를 더욱 강력하게 해줄 Base Platform 서비스로 무리가 없을 것이다.
시크릿 박스
그래서 나는 정기점검이 즐겁다.
