NDC Replay

쿠키런 1년, 서버 개발 분투기
홍성진
데브시스터즈
현재 쿠키란 for Kakao, LINE COOKIE RUN 프로젝트에서 근무하고 있으며, 서버 개발 총괄을 담당하고 있음. 과거 오븐브레이크2 개발에도 참여하였으며, 총 개발 경력은 8년 정도
쿠키런 서버를 1년동안 개발 및 운영해온 개발자의 이야기. 출시 전의 준비사항부터 출시 후 게임이 성공적인 궤도에 도달할 때 까지 주말을 반납하며 분투했던 개발자의 솔직한 심정과 후기를 들어본다. 클라우드 환경에 맞는 확장성있는 서버 구조를 만들어간 이야기, NoSQL 데이터베이스로의 마이그레이션 분투기, 게임 로그 분석과 운영툴에 대한 이야기 등을 들어보는 시간이다.
[새 창에서 슬라이드 보기]
예, 안녕하세요. 이 세션에 참석해 주셔서 대단히 감사합니다. 저는 데브시스터즈에서 서버 개발을 맡고 있는 홍성진이라고 합니다. 오늘 세션에서는 제가 1년 넘게 쿠키런 서버를 개발해 오고, 운영해 온 서버 개발자의 이야기를 좀 들려 드리고자 합니다. 우선 저에 대해 간단하게 소개를 해 드리겠습니다. 사실 저는 게임 서버 개발과는 별로 인연이 없었는데요. 데브시스터즈에 오기 전에는 자연어 처리이나 검색 엔진 등에 관심이 많았고, 그리고 그 이후에 co-founder로 참여한 회사에서는 영상통화 앱을 만드는 등 게임과는 전혀 다른 필드에서 활동을 했었는데요. 경력이 이렇다 보니까 다른 게임 회사에서 서버를 운영하는 방식도 모르고, 어떻게 보면 굉장히 근본 없는 상태에서 모바일 게임 서버 개발과 운영을 시작했다고 할 수 있습니다. 하지만 덕분에 새로운 접근을 많이 할 수 있게 된 것도 사실인 것 같은데요. 특히 쿠키런을 출시하고 반년 동안 사내 유일한 서버 개발자로 있었습니다. 이와 같은 환경 속에서 서버를 어떻게 개발했고 어떤 방식으로 서버를 운영했는지 그 이야기를 들려드리도록 하겠습니다. 우선 쿠키런에 대해 간단하게 소개 해드리겠습니다. 쿠키런은 스마트폰용 모바일 게임으로, 횡 스크롤 러닝 액션 게임입니다. 현재까지 국내외를 포함하여 5천만 누적 다운로드, 현재 천만에 가까운 DAU를 유지하고 있고요. 한국을 포함해 약 10여개 국에서 다운로드 1위를 기록한 적이 있는 게임입니다. 적극적으로 지금도 해외 진출을 지속하고 있고, 전 세계 다양한 사람들이 쿠키런을 즐길 수 있도록 열심히 노력하고 있습니다. 이 세션에서는 쿠키런 서버 구성이 어떻게 되어있는지, 그리고 1년간의 삽질을 통해 얻은 회고를 공유해 드릴 예정입니다. 출시를 준비할 때 가졌던 여러 가지 질문들에 대한 제 자신의 대답들도 포함되어 있는데요. 그 질문은 무엇일까요? 앞서 말씀 드렸다시피 저는 쿠키런 출시 이후 반년 가량 사내 유일한 서버 개발자였습니다. 이러한 상황 속에서 당연히 게임이 흥행했을 때 혼자서 서버를 개발하고 구축하고 관리, 운영까지 모두 도맡아서 해야 되는 게 가능할지에 대한 여러 가지 걱정들에 직면하고 있었습니다. 완벽하게 준비를 하기 위해서는 정말 한도 끝도 없는 시간이 필요한데, 이런 타이트한 스케줄 속에서 서버의 어떤 요소들을 어느 정도 수준으로 준비를 해야 하는지, 새로운 기술의 도입이 가능한지, 이러한 질문들이 저를 압박하기 시작했습니다. 정말 궁금한데 막상 삽질을 해 보지 못하면 해답을 얻을 수가 없는 질문들이 많았는데요. 1년이 지난 지금 시점에서는 이러한 질문들에 대해서 어느 정도 대답을 하 수 있을 것 같습니다. 비슷한 의문을 가지고 계셨다면 한번 흥미롭게 지켜봐 주시기 바랍니다. 우선 1년이 지난 현재, 최신의 쿠키런 서버를 소개를 해 드리겠습니다. 지금은 저를 포함해 서버 팀이 8명입니다. 당연히 할 수 있는 일도, 하게 되는 일도 늘어났고요. 제대로 된 서버 팀이라면 응당 갖추어야 되는 많은 시스템과 기능을 가질 수 있게 되었습니다. 다른 게임사와는 다르게 데브시스터즈의 경우에는 서버 팀이 서버 개발과 운영을 동시에 합니다. 따라서 개발과 운영을 개발자가 모두 다 수행하고 있고요. 서버 개발이나 프로덕션 서버 업데이트 모두 개발자가 다 수행을 하고 있습니다. 이와 같은 환경 속에서 쿠키런 서버팀의 궁극적인 목표는 무엇일까요? 당연하겠지만 업데이트를 쉽게 할 수 있어야 되고, 개발한 기능을 프로덕션 서버에 빨리 올릴 수 있는, 또 쉽게 올릴 수 있는, 그 다음에 어떠한 부화나 자연재해나 장애가 발생하더라도 최대한 빠르게 대처할 수 있고 자동적으로 대처할 수 있는, 요약하면 휴일에 서버 개발자가 쉴 수 있는 그런 서버가 서버 팀의 목표라고 할 수 있습니다. 이러한 서버를 구축하기 위해서는 사실 소스 코드, 코딩하는 레벨부터 인프라 레벨까지 참 많은 노력과 삽질이 필요했는데요. 우선 소프트웨어 스택에 대해서 설명을 해 드리겠습니다. 별로 흥미로운 스택은 아닌데, 자바와 스프링 기반입니다. 주 데이터베이스로 couchbase랑 NoSQL 데이터베이스를 사용하고 있고, MySQL도 사용하고 있습니다. 사용자 데이터는 couchbase에서 8노드, 총 2테라바이트 정도를 사용을 해서 서비스를 하고 있고요. 나머지 게임 운영을 위한 메타 데이터 등을 MySQL에 저장하고, 기타 특수한 역할을 맡고 있는 redis 데이터베이스가 있습니다. 로드밸런싱 같은 경우에는 아마존에서 제공하는 route 53에 있는 지오로케이션 부화분산기능과 아마존 ELB라는 로드 밸런서, 그 다음에 엔진 X를 결합해서 사용하고 있습니다. 메인 서버는 스케일 아웃이 가능하도록 Stateless하고 공유되는 데이터가 없는 구조로 설계가 되어 있습니다. 소스 코드의 품질 유지를 위해 소프트웨어 형상 관리 시스템도 적극적으로 도입했는데요. 외부 컴포넌트 종속성을 관리해주는 Maven과 소스 코드 관리를 위한 github 등을 적극적으로 활용하고 있습니다. 모두 대단위 개발은 topic branch라고, 예를 들어 기능 A를 만든 다음에 A라는 브랜치를 만들어서 작업을 하고요. 머지 하기 전에 코드 리뷰를 통해서 여러 개발자의 피드백을 받은 후에 develop branch라는 개발 브랜치로 머지가 됩니다. 이 기능들이 모이고 모여서 업데이트 준비가 완료가 되면 QA팀과 협의를 해서 develop branch를 테스트를 하고요. 테스트가 완료된 게 마스터로 올라가서 프로덕션 서버로 올라가는 구조로 되어 있습니다. 서클 CI라는 continuous integration 서비스도 도입을 했는데요. 브랜치마다 이 CI 툴이 MySQL과 couchbase를 즉석에서 생성을 해서 통합하여 검증을 하고, 테스트를 깨질 경우 사용자에게 알림 메일을 넣어주게 됩니다. 성공적으로 빌드 된 바이너리 같은 경우도 여기에서 관리가 되고 있는데요. 마스터 브랜치가 이 서비스를 사용해서 성공적으로 빌드가 되면 그 빌드를 사용한 서버 업데이트가 가능하게 되는 것입니다. 빌드를 가끔 깨 먹을 때가 있습니다. 저도 가끔 깨 먹을 때가 있는데, 이제 서버 팀원들이 엄청나게 갈굼을 주거든요. 하다 보면은 되게 코드를 좀 그나마 깨끗하게 짜도록 노력하게 되는 것 같습니다. 또 소스 코드를 형상 관리를 하다 보니까 서버에 대한 형상 관리를 할 수 없나, 저는 개발자다 보니까 서버를 어떤 설치해야 되는 기계 개념으로 보기 보다는 어떤 설정해야 되는 소프트웨어로 보고 싶어 하는 그런 성향이 있었던 것 같아요. 마침 chef라는 아주 유용한 서버 형상 관리 툴이 있었는데요. 오른쪽에 보시면 JSON의 루비 코드 형태로 서버에 대한 설정을 소스 코드처럼 관리할 수 있게 해줍니다. 생소하신 분들을 위해서 좀 준비를 해 봤는데요. 오른쪽에 보이는 코드는 홈 디렉토리를 생성하고 계정의 리미트를 해제해주고, H-top, D-step, C-step 같은 서버의 성능을 모니터링 할 수 있는 패키지를 설치해주는 그런 부분에 대한 chef 설정 파일입니다. 이렇게 코드 몇 줄로 서버에서 설정해야 되는 내용을 정의할 수 있는데요. 예를 들어 tomcat을 설치하고 설정을 잡아준다든지, 시스템 모니터링을 위한 패키지를 설치한다든지, 다양한 종류의 설정이 가능합니다. 서버가 한 대, 두 대, 열 대까지 손으로 어떻게든 관리할 수 있는데, 20대, 50대, 100대까지 가게 되면 더 이상 손으로 관리할 수 없는 수준에 이르게 됩니다. 이럴 때 필수적인 게 이러한 서버 형상 관리 툴이라고 할 수 있는데요. 이와 같이 chef를 사용하면 아마존과 같은 클라우드 환경에서 쿠키런 서버를 5분 이내에 원하는 개수만큼 얼마든지 생성을 할 수 있습니다. 100대든, 200대든 원하는 만큼 지금 당장 여기서도 생성을 할 수가 있습니다. 이 툴의 장점은 또 문서화가 있는데요. 새로운 개발자가 들어왔을 때 서버 설정을 어떻게 하냐, 라고 물어보면 이 소스코드를 봐라, 이 소스 코드에 설정이 다 있다, 어느 정도 문서화도 같이 할 수 있는 장점이 있습니다. chef 덕분에 서버 구성에 대해 반복적으로 설정해야 되는 수고도 줄이고 설정을 빼먹고 서비스에 문제가 생기는 경우도 적어졌습니다. 물론 인수인계 할 때도 많이 편한 점도 있고요. 또 서버만 형상 관리 해서는 뭔가 아쉬움이 있습니다. 서버 한 대를 설정하는 것을 넘어서서 인프라를 형상 관리 하고 싶다는 요구사항이 있는데요. 아마존 같은 경우는 CloudFormation이라는 소프트웨어를 제공을 합니다. 인프라 형상관리라는 건데요. 예를 들어서 서버 한 대를 어떻게 띄울 것인가, 어떤 종류로 띄울 것인가, 그 서버들이 어떤 로드 밸런스와 아래에 묶여 있는지, 그 로드 밸런스 아래 묶여 있는 서버들은 어떠한 오토스케일링 설정을 사용하는지 등을 JSON 파일로 관리할 수 있게 됩니다. 오른쪽에 코드를 보시면 1분 동안 오토 스케일링 그룹의 CPU 평균 사용량이 60% 이상이면 알람을 울려라, 라는 일종의 트리거를 설명해 놓은 것입니다. 이 트리거를 만들어 놓고, 서버를 네 대 추가로 띄워라, 라는 설정과 연결을 시켜 놓으면 서버가 자동적으로 평균 CPU사용량의 60%가 넘어가게 되면 용량을 확장하게 되는 것입니다. 이 탬플릿도 앞서 설명 드린 것과 마찬가지로 깃을 통해서 관리하고 있고 서버에 대한, 혹은 인프라에 대한 수정이 있을 때 이를 깃을 통해서 커밋을 함으로서 서버나 인프라에 대한 변경사항에 대해 이력 관리를 지속적으로 하고 있습니다. CloudFormation과 앞서 말씀 드린 chef를 함께 하면 언제 어디서든 쿠키런 서버 인프라를 재구축 할 수가 있는데요. 예를 들어서 제가 북미에 쿠키런을 출시한다고 했을 때, 북미 아마존 서버에 접속을 한 다음에 CloudFormation 탬플릿을 올리면 서버가 30분 안에 구축이 완료가 됩니다. 이와 같은 장점들을 가지고 있는 굉장히 강력한 도구라고 할 수 있습니다. 오토스케일에 대해서 얘기를 하겠습니다. 오토스케일을 통해서 자동으로 용량 확장을 할 수 있는 것은 다들 아실 겁니다. chef를 사용함으로써 서버를 완전 자동으로 구동할 수 있고, 따라서 오토스케일 구성도 쉽습니다. 이를 오토스케일과 조합하면 쿠키런 서버는 부화에 따라서 동적으로 서버 용량을 늘렸다 줄였다 할 수 있는 기능을 갖게 됩니다. 오른쪽은 순위결정전이 있는 일요일 트래픽인데요. 저렇게 확 튄 핑크가 일요일 저녁 9시입니다. 서버는 이렇게 부화에 따라서 네 대씩, 지금 같은 경우는 톱니바퀴로 되어있는 형태가 네 대씩 서버가 증가하는 건데요. 새벽 시간 때는 4 대에서 피크 시간 대에는 30대에서 50대까지 서버가 기동됩니다. 연휴 때는 배 이상의 서버를 기동하기도 하는데요. 예를 들어서 크리스마스나 설날 같은 때가 가장 큰 피크라고 할 수 있습니다. 부가적이지만 되게 저는 중요하다고 생각하는데 오토스케일을 사용하게 되면 로드에 대한 장애발생대처도 편합니다. 로드가 모두 다 오토스케일링 그룹의 감시 아래 있기 때문에, 예를 들어서, 서비스가 중단 되거나, 갑자기 실제 물리적 머신이 다운되거나 했을 때 그 로드를 제거하고 그 로드를 대체하는 새로운 로드를 자동으로 띄워줍니다. 따라서 장애도 대응이 잘 되는데요. 보시면 최저점에 새벽 시간대를 보시면 더 이상 서버를 대수를 줄이지 않고 네 대를 유지하는 것을 보실 수 있습니다. 네 대 중에 한 대가 장애가 나도 자동으로 대처할 수 있도록 설계를 한 것입니다. 오토 스케일을 사용하면 업데이트도 쉬운데요. 앞서 설명 드렸던 시스템을 통해서 개발자가 개발한 코드가 마스터를 통해서 올라가게 되면 github와 CI 툴을 거쳐서 빌드 된 테스트가 완료된 빌드 파일이 S3라는 스토리지 서버로 올라가게 됩니다. 그렇게 되면 이 올라간 시점부터 새로 뜨게 되는 서버들은 새 버전의 소스 코드를 가진 채로 서버가 기동이 되는데요. 이와 같은 방법을 반복하면서 새 서버를 띄우고, 옛날 서버를 퇴역시키면서 자연스럽게 무중단 업데이트가 가능하게 됩니다. 사용자에게 영향을 전혀 미치지 않고 롤링 업데이트를 공짜로 얻을 수 있습니다. 또 이제 중요한 서버 모니터링인데요. 서버 모니터링은 CloudWatch나 Zabbix, Statesd 같은 소프트웨어 조합으로 사용하고 있습니다. 특히 오른쪽 그래프에서 보시는 건 Statsd Graphite 매트릭 수집 기능인데요. 원하는 매트릭을 어떠한 형태에도 상관 없이 손쉽게 추가해서 구축을 할 수 있습니다. 왼쪽 아래에 보시면 자바 코드에 제가 annotation으로 이 함수를 호출한 시간과 초당 호출 회수 등을 모두 알고 싶다, 라고 선언을 하게 되면 그 설정에 따라서 레이턴시나 호출 정도 같은 것들을 다 기록하게 됩니다. 또한 어떤 성능 모니터링 말고도 예를 들어 매출, 맨 아랫줄을 보시면 사용자가 게임 플레이를 한 판 했을 때 버는 코인량, 코인량의 총량을, 초당 게임 서버가 사용자들에게 코인을 얼마나 찍어내고 있는지를 알고 싶을 때 아래와 같이 매트릭을 추가하면 바로 그 시점부터 실시간으로 그 매트릭을 추적할 수 있습니다. 굉장히 사용법이 단순해서요. 다른 매트릭 관리하는 툴보다 적극적으로 추천할만하다고 할 수 있습니다. 쿠키런 서버 인프라를 설명해드리겠습니다. 쿠키런 서버 인프라는 현재 아마존 웹서비스를 중심으로 두 개의 클라우드와 한 개의 IDC에 분산되어있고 재복구가 가능하도록 설계되어있습니다. 게임 데이터를 서비스하기 위해서 여러 클라우드와 IDC를 전부 합해서 24기가 정도의 대역폭을 확보하고 있고, 장애 모니터링이나 장애 복구는 전자동화 되어있어서 사용자 수요나 부화에 따라서 자동으로 서버 확장이 되도록 설계가 되어있습니다. 그래서 앞서 말씀 드렸던 저희 서버 팀의 목표, 결론적으로 휴일에 서버 개발자가 쉴 수 있는 서버를 제 생각에는 1년이 지난 이 시점에 그래도 조금은 자신감 있게 구현되어있다고 설명을 드릴 수 있을 것 같습니다. 최근에 발생하는 대부분의 장애는 인프라나 시스템의 장애라기 보다는 새로 추가된 기능들이 문제를 일으켜서 난 장애가 대부분으로 최근 3개월 간에는 인프라 관련 장애는 없었던 것으로 기억합니다. 따라서 요즘에는 서버 인프라는 신경을 끄고, 서버 소스코드, 어떻게 하면 더 좋은 품질의 코드를 만들 수 있는지, 어떻게 이 코드를 더 리팩토링 할 수 있을지, 어떻게 하면 테스트를 더 완전하게 할 수 있을지, 이런 부분으로 이제 시스템을 강화하는 방향으로 진행하고 있습니다. 하지만 처음부터 쿠키런 서버팀이 이런 강력한 인프라를 보유하게 되었을까요? 당연히 아닙니다. 아까 설명해드렸다시피 저는 거의 반년 동안 쿠키런 유일한 서버 개발자였는데요. 사실 회사의 유일한 서버 개발자였습니다. 따라서 이러한 기능들은 1년동안 차곡차곡 쌓아왔다고 볼 수 있는데 그러면 쿠키런 출시에는 어떠한 준비 과정이 있었고, 어떠한 삽질들을 했는지 한번 제가 준비과정을 이야기 해드리겠습니다. 2013년 초, 데브시스터즈를 입사했던 당시 상황은 다음과 같습니다. 서버 개발자는 한 명이고, 시스템 엔지니어는 얼마 전 퇴직해서 없답니다. 그나마 계시는 서버 개발자 한 분도 곧 이직 예정이라고 하시더라고요. 그 당시 오븐 브레이크 2를 북미에 출시를 해서 어느 정도 소기의 성과를 거두고 있던 상황이었고, 그 성과를 바탕으로 쿠키런 국내 출시라는 목표를 위해 개발을 막 시작하던 참이었습니다. 서버 관련 인프라는 전무하고 개발 관련 인프라가 전혀 어떻게 구축이 된 게 없었어요. 결정적으로 누구한테 물어볼 사람도 없고, 기존 서버가 구축이 되어있는데 이게 어떻게 설정이 되어있는 건가요? 라고 물어보면 시스템 엔지니어 분이 나가셔서 모릅니다, 라고 대답을 들었어요. 굉장히 어려운 상황이었죠. 게다가 쿠키런 서버를 개발하는데 대표이사님들이 물어보십니다. 지금 서버가 얼마나 버틸 수 있는지. 대답할 수 있는 사람도 없고, 그럼 서버를 어디다 IDC에 놔야 되는지, 아마존을 써야 되는지 결정해 달라, 제가 결정해야 되는 그런 상황이 오게 된 거죠. 오븐 브레이크 2 서버 구조를 먼저 보여드리겠습니다. L4 로드밸런스 아래 두 대의 웹 서버와 마스터-슬레이브, 데이터 베이스를 가지고 있다. 어디서 많이 들어 본 말 같지 않으신가요? 정말 가장 전형적인 하드웨어 기반 서버 구조를 가지고 있는데요. 이게 아마존 클라우드에 올라가 있습니다. 하드웨어 서버를 계획하듯이 서버 각각의 사양은 미래 수요를 예측해서 미리미리 큰 서버를 사용하고 있었고요. MySQL 데이터베이스는 하나여서 앞으로 만약 게임이 흥행했을 때 그 부하를 제대로 따라갈 수 없는 한계가 많은 구조였습니다. 문제는 새로운 서버를 만들 수가 없었어요. 쿠키런 서버 개발 기간이 한 한달 정도가 있었는데 당연하겠지만 오븐 브레이크2와 거의 유사한 게임인데 서버도 같이 가져가자, 재사용하자. 근데 이제 한계들이 너무 명확한 거에요. 당연히 서버 설치 매뉴얼도 없고, 서버가 어떻게 설정되어야 하는지도 잘 모르겠고, 사용자 증가 했을 때 서버를 손으로 다 계속 띄워줘야 되나, MySQL은 어떻게 하지, 이게 한계가 있다는 것은 너무나 분명한 사실이잖아요. 이 말은 돈을 아무리 쏟아 부어도 사용자 부화에 대응할 수 없는 그런 시스템의 한계를 적극적으로 보여주는 사례입니다. 지금 오븐 브레이크2 같은 경우는 지금도 서버가 올라가 있는데요. 로드가 장애가 나면 굉장히 스트레스를 받아요. 쿠키런의 100분의 1밖에 안 되는 서버 규모인데 문제가 터지면 어디서 문제가 터졌는지 알 수가 없어요. 서버를 막 재설치를 한다고 하면 정말, 너무 스트레스 많이 받을 것 같습니다. 앞서 설명 드렸다시피 이 오븐 브레이크2 서버를 재사용해서 쿠키런 서버를 만들어야 되는 상황이었습니다. 근데 이제 오븐 브레이크2 서버도 개발자 한 명이 한달 만에 급조한 서버에요. 사실 벤처 회사들이 다 어느 정도 비슷한 상황일 거라고 생각을 하는데요. 그럼 이 서버를 가지고 혼자서 개발하고 구축하고 관리하고 운영해야 되는 그런 상황이 참 암담했죠. 그리고 제가 어떤 모바일 게임 서버를 운영해 본 경험이 당시에는 되게 부족한, 사실상 없었죠. 없었던 상황이었기 때문에 삽질이 굉장히 필연적이라고 할 수 있습니다. 그래서 공부를 했습니다. 일단은 서버를 계속 제가 설치하고 운영할 자신이 없었어요. 만약 출시를 하게 되면 기능 개발과 버그 픽스, 성능 개선, 리팩토링, 할 일이 참 많은데 서버 설치까지 할 수는 없었으니까요. 서버를 자동으로 구성할 수 있다는 이 chef라는 도구를 알게 되었고, 한 번 써보자. 다양한 도구들이 있는데 그래도 가장 많은 사람들이 현재 사용하고, 가장 많은 자료가 있는 chef를 골라서 열심히 공부해서 도입을 해 봤습니다. 또 오토스케일을 사용하고 싶었습니다. 아마존을 사용하는데 오토스케일을 사용 안 하면 좀 뭔가 아쉽잖아요 사용자 부화가 늘어나는 데 자동으로 대응할 수 있다니, 굉장히 매력적이잖아요. 근데 이것을 사용하려면 서버가 자동으로 구축이 되어야 하고, 그러기 위해서는 서버 형상 관리 툴을 사용하는 게 거의 필수적입니다. 초기에는 참 배우는 게 쉽지가 않아요, 굉장히 생소한 개념들이기 때문에. 하지만 한 번 배워놓고 이것으로 관리를 하기 시작하면 서버 관리가 굉장히 쉬워지고 굉장히 수월해집니다. 또 계속 열심히 공부를 했습니다. 정말 열심히 공부를 했습니다. 우선 서버 모니터링 시스템부터 구축을 하기 시작했습니다. 아까 말씀 드렸던 Zabbix를 한국 SMS 서비스에 붙여가지고 장애가 날 경우에는 문자가 날아오도록, 1분만에 문자가 날아오도록 설계를 하고, 성능 모니터링을 붙이고, 그래도 매트릭을 제가 다 수집할 수가 없으니까 일단 클라이언트의 flurry 같은 클라이언트 사이드 애널리틱스 툴을 붙이자고 얘기를 하고, 서버 사이드에서는 그래도 매출 데이터 같은 핵심 매트릭들은 수집을 할 수 있도록 설정을 했습니다. 또 MySQL을 빼고 NoSQL을 붙이는 작업이 불가능한 시점이었기 때문에, 또 MySQL을 제가 직접 관리하기도 벅차니까 아마존에서 제공하는 MySQL 서비스가 있습니다. RDS라는 서비스를 사용해서 MySQL을 구축을 하고요. 오토스케일을 겨우겨우 적용했습니다. 출시 전에. 수평적으로 확장할 수 있도록 웹 서버를 최대한 구성을 바꿨고요. 그 다음에 게임 로그는 JSON 형태로 저장하게 수정을 했고요. 이런 상태로 그나마 제가 알고 있는 선에서 최선을 다해서 준비를 해서 출시를 했는데요. 출시 직후 서버의 상황입니다. 마케팅 비를 한 푼도 쓰지 않고 쿠키런을 출시를 했었는데요. 카카오톡 테마가 거의 유일한 마케팅 수단이었습니다. 그러니까 게임을 설치하면 쿠키런 카카오톡 테마를 준다. 귀여운 테마를 줄 테니 받아라, 이 정도의 마케팅이었고요. 첫날 가입자가 9만명이었습니다. 오토 스케일은 발동 하지도 않았고요. 서버가 그 때 네 대인가 떠 있었는데 그냥 네 대로 쭉 운영했습니다, 하루 종일. 열심히 준비를 했는데 내일도 한 이만큼, 9만명, 10만명이면 좋겠다, 라는 바램으로 하루를 보냈는데요. 참 소박한 바램이었죠. 그 소박한 바램은 끝없는 절망의 시작이었습니다. 신규 가입자가 산술적으로 증가하는 것이 아니라 기하급수적으로 증가하기 시작했고요. 4일부터 주기적인 피크 시간의 장애가 일어나기 시작했습니다. 정말 다양한 원인으로 장애가 났는데요. 6일만에 120만명을 돌파하고, 오토스케일로 최대 100대까지 서버가 늘어나기 시작했습니다. 이때부터 쿠키런 서버는 주말이나 연휴 때, 주기적으로 장애를 약 반년간 지속적으로 겪게 됩니다. 제가 반년 동안 연휴에 쉬지를 못하고 서버 장애 대응을 했어요. 성장 패턴을 한 번 설명해 드리겠습니다. 출시 11일차에 신규 사용자 유입이 피크가 쳤습니다. 이 피크가 카카오 플랫폼의 사용자 채널링 효과라고 할 수 있겠는데요. 그 이후에 누적된 사용자를 통해서 2,3일 후에 DAU가 피크에 도달하게 되고요. 신규 사용자는 그 이후로 급격하게 하락하게 됩니다. 하지만 DAU같은 경우네는 쿠키런이 생각보다 리텐션이 참 좋아서 완만하게 떨어지는 곡선을 보실 수가 있는데요. 오랜 기간 지속적으로 유지를 했습니다. 이 당시 굉장히 어려웠던 점이 공휴일만 되면 서버가 버텨내지를 못합니다. 노동절에도 장애가 났었는데 그 당시 네이버 실시간 검색어 1위가 되고, 기사로 쿠키들도 쉬어야 되는 거 아니냐, 뭐 이런 기사가 날 정도였으니까요. 그 이후로 어쨌든 DAU가 계속 떨어지니까 서버가 잠시 숨을 돌리는 듯 하다가 시즌2 업데이트 직전에 상당히 떨어지는 속도가 급격해졌죠. 업데이트 이후 모두 회복이 되었습니다. 신규 사용자 유입은 그닥 많지 않았는데요. DAU가 거의 다 복구가 되고, 그 이후에 큰 이벤트, 연휴 때 큰 이벤트를 준비했을 때 오히려 이전 신규 출시했을 때 이상의 DAU를 가질 수 있게 되었습니다. 전 이 그래프가 상당히 큰 게임 운영의 중요성을 잘 보여준다고 생각합니다. 쿠키런 게임에 지속적으로 집중하고 사용자들의 목소리를 듣고 모니터링 하면서 지속적으로 미친 듯이 업데이트를 준비했습니다. 정말 클라이언트 서버 개발자, 데브시스터즈 내의 모든 사람들이 밤낮없이 계속 일을 해서 시즌2 업데이트를 만들어서 출시를 했고요. 그 결과가 참 좋아서 굉장히 보람찬 것 같습니다. 이러한 쿠키런 서버 개발에 대한 회고를 하고자 합니다. 새로운 게임 서버를 준비한다면 어떻게 할까에 대한 개인적인 정리이기도 한데요. 개발자의 가장 중요한 도구, 언어와 프레임 워크, 그리고 데이터 베이스. 이와 같은 기술들을 선택할 때 어떠한 질문들을 하면 좋을까요? 전 이렇게 생각합니다. 회사의 사운을 걸고 서버를 개발한다면 본인에게 가장 익숙한 도구를 선택하지 않겠습니까? 물론 예를 들어 실시간성이 굉장히 요구되는 게임이어서 요즘 뜨고 있는 로드JS나 고, 스칼라 이런 것들이 개발에 효과적이니까 충분히 써 볼만 하다. 그런 경우에는 제 생각에는 배우더라도 리스크를 어느 정도 감수 하더라도 배워볼 수는 있겠죠. 이 해당 기술 X가 그 게임에 굉장히 특화 되어서 큰 장점을 발휘한다면 도전해 볼 만 하다고 생각합니다. 하지만 가능하면 문제가 터졌을 때 그 프레임워크나 언어, 런타임에 소스 코드까지 봐 가면서 디버깅을 하고, 고칠 수 있는 정도 수준이 되지 않으면 감당이 되지 않습니다. 실제 천만 명 단위의 사용자를 감당하는 서버는 정말 생각지도 못한 다양한 종류의 버그를 직면하게 마련인데요. 이러한 환경 속에서 내가 감당할 수 있는 기술을 선택하는 것은 소프트웨어 엔지니어의 기본 덕목이 아닐까 생각합니다. 저도 신기술 참 좋아하는데요. 저는 그래서 이러한 신기술들을 미니 프로젝트로 게임 메인 서버가 아니라 서브로 작은 서버들을 프로토타입으로 개발해보면서 평가를 해 보고 괜찮다 싶으면 조금씩 중요도가 높은 프로젝트에 적용을 해서 사용을 해 보고 있습니다. 테스트를 꼭 해보시고 결정을 하시기 바랍니다. 한가지 더 말씀 드릴 게, 모바일 게임 서버에서 PHP도 참 많이 쓰입니다. PHP 익숙하신 분들 많으실 텐데요. 서버로 쓰셔도 괜찮습니다. 익숙한 게 최고입니다. 서버 비용하고 생산성에 대한 얘기를 해보고 싶은데요. 저희 메인 서버가 자바와 스프링으로 되어있다 보니까 100만 DAU를 처리하는 데 월 2000만원 정도를 잡으면 적정한 평균일 것 같습니다. 실제 서비스에서는 데이터베이스나 CBN 유무, 트래픽이 얼마나 되나, 이런 여러 가지 다양한 차이점으로 굉장히 많은 변동성을 가지는데요. 그냥 참고자료 정도로만 생각해 주셨으면 좋겠습니다. 그런데 동일한 기능이 파이성과 장고 같은 고수준의 스크립팅 언어로 사용된다면 월 비용이 네 배. 8000~1억 정도 소비 될 것을 각오하셔야 됩니다. 하지만 100만 DAU 게임의 월 매출은 어느 정도가 될까요? 사실 이렇게 보면 와, 네 배나 비용이 상승되네, 쓰면 안 되겠네. 이러실 수도 있는데 게임의 매출 대비 서버 비용으로 생각한다면 생각보다 그렇게 비싸지 않을 수도 있습니다. 언어에 따른 생산성의 차이는 어떨까요? 전 그래서 여기서도 비슷한 기준을 적용하고 싶습니다. 내가 익숙한 언어, 내가 잘 쓸 수 있는 언어로 개발하면 상관없지 않을까, 스크립팅 언어도 괜찮을 것 같습니다. 결국에는 운영 비용이 많이 드는 대신에 초기 개발 시간을 절약하고 더 많은 것을 개발할 수 있는 Trade-off가 아닌가 라는 생각이 듭니다. 결정은 여러분들의 몫입니다. 저는 여기 나온 파이선, PHP, 여러 가지 언어들, 충분히 고려 대상에 들어갈 수 있다고 생각합니다. MySQL, 따른 RDBMS도 마찬가지고요. 익숙하다면 쓰는 것 좋습니다. 게임 흥행 후에 NoSQL이나 더 큰 데이터베이스로 마이그레이션 해도 괜찮습니다. 제 기준은 테이블 당 1억 로우 이하, 쓰기가 너무 많지 않은 테이블 같은 경우는 MySQL로 충분히 서비스를 할 수가 있습니다. 하지만 게임이 흥행을 한다면 아쉽게도 모든 사용자 테이블은 이 기준을 넘어가 버릴 겁니다. 당장 카카오 게임들에 많이 들어가 있는 생명 보내기 기능을 생각해봐도 사용자 n명이 또 다른 사용자 n명한테 매 시간마다 하트를 하나씩 보낼 수가 있습니다. 생명을 보낼 수가 있습니다. 어마어마하게 쌓이게 되죠. 저희 쿠키런 같은 경우도 원래 아까 말씀 드렸다시피 모든 게 MySQL에 다 저장이 되어있기 때문에 생명 보내는 것도 다 MySQL에 저장을 했습니다. 가장 먼저 터져 나간 테이블 중 하나입니다. 가장 많이 장애를 일으켰고요. 그렇다고 MySQL을 직접 샤딩해서 여러 대로 확장해서 쓰자니 차라리 NoSQL을 쓰는 게 더 편하고 더 괜찮은 선택이 아닐까 생각이 듭니다. 자동으로 샤딩해주고 확장할 수 있는 데이터베이스가 많기 때문이죠. 하지만 결제 정보는 꼭 이런 제대로 된 데이터베이스를 사용하시는 것을 권장해 드립니다. 이건 좀 이따 더 설명해 드리겠습니다. MySQL이 불안하고 NoSQL을 도입하고 싶으면 결국에는 어떤 모바일 게임 서버를 위한 조건들을 만족하는 NoSQL을 찾아야 되는데요. 저는 이렇게 생각합니다. 관리가 쉽고, 설치가 쉽고, 구성이 쉬워야 되고, 상용 서포트가 필요하면 구입을 할 수 있고, Auto Sharding, Auto Rebalancing, Failover가 지원이 되고, 무엇보다 어느 정도 안정된 NoSQL 서버가 필요한데요. 생각보다 이 조건을 만족하는 서버가 그렇게 많지 않습니다. 쿠키런의 경우는 couchbase라는 데이터베이스를 사용했는데요. 게임마다, 혹은 서버마다 사용 패턴에 최적화된 데이터베이스는 각각 다르므로 충분한 리서치를 통해서 최적화된 데이터베이스를 선택하시면 좋을 것 같습니다. 쿠키런은 반년 동안 장애로 고통 받은 후에 한달 동안 couchbase로 데이터를 이전하면서 큰 장애는 대부분 해소가 되었습니다. NoSQL 잘 적용하면 굉장히 큰 이득을 얻을 수 있습니다. 또 인앱 결제를 RDB에 저장하라고 강조를 해 드렸는데요. 결제 코드는 서버 구현 중에서 제 생각에는 가장 큰 공을 들여야 되는 부분이라고 생각을 합니다. 매뉴얼대로 정확하게 구현을 하시고, RDBM에 있는 기능, 예를 들어서 unique constraint나 트랜잭션 같은 기능들은 적극적으로 사용해서 안전하게 구현을 하시기 바랍니다. 가장 많은 해킹 시도가 있는 부분이고요. 하루에도 수만 건, 수십만 건씩 공격 패킷이 들어옵니다. 사소한 실수로도 결제가 뚫릴 수 있습니다. 정말 조심해야 되는 부분이고요. 결제 뚫리면 게임 정말 망할 수 있습니다. 정말 제가 생각할 때는 서버 개발에서 가장 중요한 부분이 아닌가 싶습니다. 게임 로그 보관하는 방법. 뭐 아까 설명 드렸다시피 JSON으로 저장하면 좋을 것 같고요. 최대한 심플하게 저장하는 것을 권장해드리고 싶습니다. 제가 출시 전에 간단한 로그 수집 시스템도 구현하고, MySQL 테이블도 만들어서 코인은 어디에 썼고, 크리스탈은 어디에 썼고, 무슨 아이템 구입했고, 여러 로그 테이블을 만들었었는데요. 게임이 흥행하면 대부분 고장 납니다. MySQL에 남기던 로그 테이블은 크리스탈 사용 기록 빼고 전부 다 삭제가 되었습니다. DB가 따라오지를 못해요. 이것 때문에 장애가 나요. 쿠키런 1일 로그가 600GB 정도가 되는데 첫 두 달 로그가 그래서 대부분 손실 되었거나 쓸 수 없는 상태가 되었습니다. 심플하게 보관하는 게 가장 효과적인데요. JSON으로 저장을 하고, 파일로 저장을 하고, 주기적으로 매일 중앙 서버, 스토리지 서버에 전송하는 정도로 가장 심플하게 구현하는 게 가장 게임이 부화를 많이 받을 때 살아남을 가능성이 높습니다. 추후에 모아놓은 파일로 언제든 핫업 같은 것을 구축을 해서 분석할 수 있으니까요. 일단 보관만 잘 하시면 나중에 분석하실 때 용이할 겁니다. 쿠키런은 그 귀중한 초기 로그 두 달 어치가 거의 쓸모가 없는 상태입니다. 다만 크리스탈 같은 경우는 그렇게 사용 빈도가 많지 않기 때문에 아직까지 MySQL에서 기록해서 사용하고 있습니다. 로그 분석 같은 경우에는 게임 런칭 전에 준비하는 것은 별로 추천해드리고 싶지 않은데요. 일단 로그 분석을 도입을 한다면 두 가지 경우가 있습니다. 실시간 로그 분석하고 일괄 배치 로그 분석이 있는데요. 쿠키런 같은 경우에는 ElasticSearch, Logstash, Kibana 라는 소프트웨어 스택을 사용하는데 대안의 상용서비스로는 splunk 같은 서비스가 있습니다. 정말 이런저런 곳에 유용하게 사용이 될 수 있는데 어뷰저를 찾는다든지, CS 응대, 고객이 언제 뭘 했는지 기록을 찾아야 될 때, 한달 어치의 데이터를 저장하고 있는데요. 간단한 데이터 분석, 통계, 구입통계 같은 것들은 다 실시간 로그 분석으로 충분히 낼 수 있습니다. 일괄 로그 분석은 Hadoop, Pig, Hive 이런 것들이 있고, 사용하고 있는데요. 일단 이 클러스터 구축하는 것도 어렵지만 구축을 하고, EPL도 구축을 해서 데이터도 다 끌어 오면 정말 다양한 분석이 가능해 집니다. 로그 분석은 흥행 이후에 구축해도 저는 충분하다고 생각합니다. 그전에 구축하는 건 좀 효용성이 떨어진다고 봐요. 서버 형상 관리의 경우에는 출시 전에 도입해서 프로덕션 서버를 모두 형상 관리 하에 두는 것을 추천해 드립니다. 오토스케일 같은 것을 사용하려면 필수적이기도 하고요. chef라는 소프트 웨어가 사용자도 많고 제품도 많습니다. ansible이라는 것도 뜨고 있고, 대안으로 조금 컨셉은 다르지만 docker도 요즘 잘 안정화 되어가고 있습니다. 내부적으로 계속 테스트를 하고 있는데요. 좀 긍정적이고 만족스러운데 좀 잔 버그가 많이 있고, 안정화 되려면 조금 더 시간이 필요하지 않나 싶습니다. 그러면 오토스케일 같은 경우에는 어떻게 접근해야 될까요? 처음에 쿠키런의 두 달치 로그가 날아갔던 이유 중 하나가 오토스케일로 서버를 증가하고 서버를 줄이는 양쪽 다를 수행을 했기 때문에 결국에는 서버가 하루살이가 됩니다. 무슨 말이냐 하면 서버가 떴다가 새벽 시간대에 다시 다 죽어야 되기 때문에 그 사이에 있는 사인 로그를 어딘가로 백업을 미리 해야 돼요, 서버가 꺼지기 전에. 그런데 이것을 이제 실시간으로 대충 만들었는데 중앙에 로그 수집하는 서버가 이 부화를 감당하지 못하니까 로그가 계속 손실이 된 겁니다. 그런데 이제 장애가 나니까 로그 시스템 고장 난 것 신경 쓸 겨를이 없잖아요. 두 달 동안 손도 못 쓰고 로그를 다 날린 거죠. 따라서 저는 서버 대수를 줄이는 어떤 코스 최적화보다는 오토 스케일을 사용자 증가에 따른 서버 대수를 자연스럽게 증가시킬 수 있는 일종의 보험이라고 생각해주셨으면 좋겠습니다. 자동으로 서버 대수를 늘리되, 줄이지 않게 할 수가 있거든요. 그렇게 되면 로그 관리나 여러 관리적인 이점이 많을 것입니다. 특히 서버 대수를 줄이는 것을 잘못 설정하게 되면 장애가 납니다. 서버 대수를 줄이는 설정 때문에 장애가 나는 경우가 많이 있는데요. 이 부분도 리스크를 줄일 수 있는 부분이기도 하고요. 그렇다면 어떤 출시 전에 안정적인 서버를 구축하기 위한 최소한의 요건은 뭐가 될까요? 저는 좀 정리를 해 봤는데요. 일단 소스 코드가 품질이 좋아야 되겠죠. 충분히 테스트가 구현된, 형상관리가 잘 되고 있는 품질 높은 빌드를 확보를 해야 됩니다. 소스 품질을 최대한 좋게 할 수 있도록 다양한 테스트와 형상관리 도입을 적극적으로 추진하셔야 되고, 리팩토링도 계속 하셔야 됩니다. 그리고 근본적인 소프트웨어 아키텍처도 수평적 확장이 가능하도록 설계를 해야 됩니다. 특히 서버 같은 경우 앞서 설명 드렸다시피 어떤 공유하는 데이터가 없는 서버를 구축하시면 좋고요. 그리고 웹 서버, 이제 API 서버가 확장성 있게 되면 데이터베이스가 문제가 됩니다. 따라서 데이터베이스도 확장 가능한 서버를 선택하시는 게 좋을 것 같고요. 앞서 말씀 드렸던 couchbase 같은 그런 예이고, 요즘 유명한 redis 같은 경우는 아직까지 클러스터링이 알파 단계 개발 중입니다. 그리고 클러스터링을 사용하면 기능 셋이 줄어들고요. 이런 데이터베이스 같은 경우에는 아직까지 도입이 시기상조이다, 라고 볼 수가 있고요. 또 서버 형상관리가 되어있어서 자동으로 서버가 설정이 되고, 자동으로 확장도 가능해져야 되지 않을까 싶습니다. 이건 이제 클라우드에 서버를 올렸을 경우의 얘기인데요. 아마 게임 신작을 준비하시는 벤처 회사 같은 경우는 대부분 클라우드를 타겟으로 하실 거라 생각이 됩니다. 그리고 서버의 장애 모니터링, 서버의 성능 모니터링, 서버의 주요 매트릭 모니터링 기능은 출시 전에 넣으시면 추후에 발생하는 장애나 혹은 장애를 예견하여서 미리 예방할 수 있는 좋은 눈이 될 겁니다. 서버가 2,30대, 100대씩 돌아가게 되면 더 이상 서버에 대한 어떤 가시적인 인사이트를 놓치게 됩니다. 서버 100대의 성능 매트릭들을 다 한 화면으로 합쳐서 그래프로 시각적으로 볼 수 있어야만 서버의 건강상태를 효과적으로 확인할 수 있는데요. 그런 의미에서 이러한 시스템 구축하는 건 굉장히 중요하다고 할 수 있습니다. 그리고 게임 로그. 최대한 단순한 방법으로 JSON과 같이 파싱하기 좋은 포맷으로 보관해놓으시고 추후에 처리하시면 좋을 것 같습니다. 이상으로 제가 다시 서버를 구현한다면 어떻게 할지, 제가 만약에 1년반 전으로 돌아가서 쿠키런 서버를 다시 준비할 기회가 있다면 어떻게 다르게 했을까 에 대한 생각을 공유해 드렸습니다. 결국에는 게임 출시를 앞두고 서버 개발자들은 최단시간에 최고의 효용성이 있는 아이템들을 개발해 나가면서 서버를 개발을 해야 될 것 같습니다. 게임이 흥행했을 때 부화를 견디고 사용자를 잘 처리할 수 있는 서버를 구축하는 건 어려운 일입니다. 저렴하고 성능 좋은 서버보다 성공하는 게임을 만드는 게 사실은 훨씬 더 어려운 일입니다. 결국에는 서버 개발자도 재미있는 게임을 만드는 게 목표 아닐까요? 그런 시각으로 바라본다면 사실 나머지는 모두 trade-off라고 할 수가 있겠습니다. 재미있는 게임을 만드는, 그 궁극적인 목표를 잊어서는 안되겠죠. 나머지는 모두 trade-off입니다. 그것을 명심합시다. 이상으로 발표는 마치겠고요. 질문 답변 시간을 갖겠습니다.
“자바8이 릴리즈 된지 얼마 안 되었는데 어떤 기능이 필요해서 8을 사용하는지요?”
라는 질문을 받았습니다. 자바8, 저희 같은 경우도 얼마 전에 적용을 했고요. 람다식이라든지 여러 가지 컬렉션에 대한 API들을 사용하기 위해서 지금 준비 중에 있습니다. 아직까지 저희 모든 글로벌 서버들이 자바8 레디 된 상태가 아니기 때문에 아직까지 언어 피쳐들은 사용하지 못하지만 저희 쿠키런 카카오 서버 같은 경우는 모두 자바8 JRE를 사용해서 서비스 중에 있고, 아직까지 특별한 문제를 발견하지 못했습니다. 추후에 새로 생겨난 언어 피쳐들을 사용해서 좀 더 효과적으로 서버 개발에 사용할 예정입니다.
두 번째 질문이네요. “각 플랫폼마다(라인, 카카오) 지원되는 서버나 관련 스펙이 다를 텐데 그 부분도 형상 관리를 통해 작업을 하신 건가요?”
이 부분이 참 어려운 부분 중 하나였는데요. 저희가 카카오 같은 경우는 직접 게임을 출시를 했기 때문에 저희가 서버 관리를 하지만 라인 같은 경우는 라인이 퍼블리셔 형태로 같이 하기 때문에 서버 관리 주체가 라인입니다. 그런데 라인에서는 라인의 서버 관리 팀 나름의 서버 관리 형태가 있기 때문에 저희가 그 부분을 chef를 써달라, 이렇게 요청할 수 없는 어려움이 있었는데요. 덕분에 저희가 라인 같은 경우는 서버 설치 매뉴얼을 PDF로 다 일일이 한땀한땀 만들어가지고 제공을 해야 되는 큰 어려움이 있었습니다. 그렇기 때문에 앞서 말씀 드렸던 docker 같은 새로운 컨셉의 서버 형상 관리가 주목 받을 만 하다고 생각이 됩니다. 이 부분은 좀 차이가 있는데, docker 같은 경우는 어떤 가상 이미지 위에서 VM보다 가벼운 형태로 서버를 올릴 수 있어서 이 세션에서는 적합하지 않지만 이런 부분에 있어서 보다 효과적으로 대응할 수 있다고 생각이 되고요. 저희도 내부적으로 굉장히 많은 evaluation을 하고 있습니다.
세 번째 질문입니다. “펫 뽑기를 하면서 넷이 끊어졌을 경우, 재 접속 시 소모된 크리스탈이나 무료 뽑기권이 복구가 되지 않을 경우에는 어떻게 합니까?” 
실제로 겪었던 일이라서 질문 드립니다. 이 부분 같은 경우는 이렇게 설명 드릴 수 있을 것 같아요. 클라이언트 버그로 인해서 보물 뽑기권이 하나만 지급됐는데 두 개가 지급된 것처럼 잘못 나와서 그렇게 착각되는 경우도 있었고, 실제로 크리스탈이 소모되는 경우도 있었는데, 모두 다 고객센터로 문의가 들어오는 부분에 있어서는 다 응대를 해 드려서, 크리스탈이나 이런 부분에 있어서 환급 조치를 해 드렸고요. 장애 날 때 주로 이런 현상이 벌어질 가능성이 있는데 게임을 참 많이 즐겨 주신 것 같습니다. 감사합니다.
네 번째 질문이네요. “반년간 혼자 버틸 수 있던 원동력은 무엇이었나요?” 
라는 질문인데요. 저는 이렇게 대답해 드릴 수 있을 것 같아요. 게임이 성공을 하고 흥행을 하면 굉장히 즐거워집니다. 그 사람들이 굉장히 즐겁게 게임을 하는 모습을 바라보고, 또 여러 가지 일화들이 굉장히 많이 들려 와요. 회사에. 굉장히 아팠던 아이가 수술을 앞두고 쿠키런을 하면서 참 많은 즐거움과 희망을 얻었다, 이런 편지가 실제로 회사에 오기도 하고요. 그런 것을 보면서 힘을 얻기도 하고. 무엇보다 재미있게 서버 관리, 서버 개발을 하도록 열심히 노력했던 것 같습니다. 
마지막 질문 하나 받겠습니다. “인프라나 서버에 장애가 발생했을 때 복구도 중요하지만 자동적으로 fail-over되어 사용자가 장애 자체를 못 느끼게 하는 게 더 중요할 것 같은데 이 부분은 어떻게 구성되어 있나요?” 
이 부분 같은 경우는 여러 단계의 fail-over가 구성이 되어 있는데요. router 13 DNS 서비스 단계에서 fail-over를 하는 경우도 있고, 로드밸런서 단에서 fail-over를 하는 경우도 있습니다. 이 부분은 다 구축이 되어 있고요. 지금까지 쿠키런 장애가 났던 건 클러스터 전체가 뻗어서 장애가 나는 경우, 혹은 데이터베이스가 과부화가 걸려서 장애가 나는 경우가 대부분이었고요. API 서버 자체에서 이 시스템이 구축된 상태에서 큰 문제가 되었던 점은 새벽 시간대, 원래 저희가 서버를 두 대까지 줄였는데 서버 두 대 중에 한 대가 장애가 났어요. 그러면 다른 쪽으로, 예를 들어 양쪽이 CPU 사용량이 50%였는데 하나가 뻗어버리면 나머지 하나도 자동적으로 뻗어 버립니다. 부화를 견딜 수가 없거든요. 그래서 앞서 그래프를 보셨을 때 아시겠지만 서버를 네 대로 유지하고 있습니다. 네 대가 된다면 서버 한 대가 장애가 나도 나머지 세 대가 받아줄 수 있거든요. 뭐 이런 사소한, 여러 가지 튜닝이 필요했습니다.
마지막 질문. “기억 나는 서버 장애의 원인 한 가지만 알려주세요.” 
라는 질문인데요. 워낙 장애가 많이 나서. 초창기 얘기인데, 서버가 밤 시간 되면 장애가 일어나고 그래서 저희가 MySQL로 이것 저것 구입 관련 로그 기능을 많이 남겨 놨다고 말씀 드렸잖아요. 그 부분을 다 싹 지우고 로그 안 남기게 만들고 서버를 다시 올려서 서버 용량을 10~20% 향상을 시킨 거죠. 그래서 새벽 다섯 시까지 일을 하고, 금요일이었어요. 패치를 하고 돌아가서 이제 괜찮겠구나, 하고 아는 친척 동생이 놀러 와서 같이 CGV에 영화를 보러 갔어요. 아침 시간에 아이언맨2를 보러 갔나 그랬는데 영화가 시작될 때 SMS가 딱 온 거에요. 장애 문자가. 그래서 갔는데 이번에 MySQL이 아예 완전히 다 뻗어 버렸더라고요. 그래서 사촌 동생은 영화 보게 하고 저는 그 길로 바로 택시 타고 회사로 가면서 노트북 펼쳐서 핸드폰 꽂아서 테더링으로 막 장애 복구하고 그랬던 기억이 나네요. 제일 힘들었던 기억 중 하나인데. 예, 그렇습니다.
한 가지 더 질문. “couchbase 이외 메인 DB 후보로 생각했던 것이 있는지요?” 
couchbase 사용하기 이전에 redis를 사용을 했었고요. 제가 앞서서 자동으로 스케일아웃할 수 있는 데이터베이스가 중요하다고 말씀 드린 이유는 redis 같은 경우는 자동으로 확장이 안됩니다. 메모리를 50기가 할당하면 50기가 넘어가는 순간 서버는 그냥 터져 버립니다. 그런 부분들을 계속 모니터링을 하다가 한 3개월 정도 사용을 했어요. 포기를 하고 couchbase로 완전 이전을 했었고요. 위약이라는 couchbase와 약간 비슷한, 자동 확장되는 데이터베이스 같은 경우는 옛날에 사용해 본 경험이 있고 굉장히 안정적인데 모바일 게임서버에 맞는 스루풋이 나오지가 않아요. 그런 문제로 배제가 되었고요. 카산드라나 H베이스. H베이스 같은 경우도 예전에 써본 경험이 있었는데 설치, 관리가 용이하지가 않습니다. 카산드라 같은 경우는 스키마 구성이 귀찮아요. couchbase는 그냥 JSON 문서 읽고 쓰면 되는데 카산드라는 스키마를 정해줘야 돼서 그런 부분들이 좀 번거로웠고요. evaluation에서 여러 가지 생각해 봤던 제품들은 이 정도 제품인 것 같고요. 그 중에서 couchbase가 제일 괜찮은 조건이 아니었나 싶습니다. 
네, 이 정도로 질문답변 시간 마치도록 하겠습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
