지난해 출시되어 결과적으로는 '역대급'으로 흥행에 성공한 데브시스터즈의 <쿠키런: 킹덤>. 하지만 이 게임은 오픈 직후에 소위 한 사건으로 인해 초반 분위기는 그렇게 좋지만은 않았습니다. 바로 오픈 4일 후인 1월 25일 터진 이른바 '36시간 서버 점검' 사태로 인해 유저들의 불만이 하늘을 찔렀던 것이죠. 이걸로 끝이 아니라 약 3주후인 2월 중순에는 추가로 '20시간 서버 점검' 사태가 벌어지면서 더더욱 많은 논란을 야기했습니다.
이 당시 게이머들 사이에서는 'DB가 날아가서 복구가 불가능 하다더라' 부터 시작해서 온갖 추측이 난무하기도 했습니다. 그렇다면 실제로는 과연 그 '총합 56시간의 서버 점검' 시간 동안 대체 <쿠키런: 킹덤>에는 무슨 일이 있었던 것일까요? 데브시스터즈 서버기술그룹에서 활동중인 이창원 데브옵스 엔지니어, 박새미 서버 프로그래머가 당시에 무슨일이 있었는지 약 1년 6개월이 지나서 돌아봤습니다.
강연자: 이창원
소속: 데브시스터즈 서비스기술그룹 인프라셀에서 데브옵스 엔지니어
강연자: 박새미
소속: 데브시스터즈 서비스기술그룹 플랫폼셀 서버 프로그래머
<쿠키런: 킹덤>은 '안정적인 서비스'를 목표로 데브시스터즈에서 나름 철저한 준비와 조치를 취하고 오픈까지 진행했던 게임이었다. 개발사에서는 사용자들의 데이터를 7중으로 보관하고, 통신망 장애에 대한 대책을 세우고, IDC 서버 인프라를 강화해서 여러 곳으로 데이터를 분산했다. 여기에 서버 오픈 전 70회가 넘는 스트레스 테스트를 진행해 유저들이 갑자기 몰릴 때의 대책 또한 준비해뒀다.
그 결과 <쿠키런: 킹덤>은 1월 21일 론칭 후 가장 많은 트래픽이 몰리는 첫 주말(23~24일)까지 별다른 서버 문제를 일으키지 않고 굉장히 안정적으로 서비스를 진행하는 데 성공했다. 오죽하면 당시 서버 팀은 "이만하면 됐다" 라고 자축할 정도였고, 장기간 계속된 크런치를 풀고 이제 일상(?)으로 돌아갈 준비를 할 정도였다.
하지만 딱 하나. 예측하지 못했던 문제가 있었다. 바로 유저들이 상상을 초월할 정도로 많이 계정을 생성하고 게임을 즐기다 보니 유저들의 데이터를 저장하는 데이터베이스(DB)의 저장소 용량이 엄청나게 빠르게 차오르는 것이었다. 하지만 그래도 아직 용량에 여유가 있었다고 봤기 때문에 서버팀은 첫 주말을 넘기고 "월요일에 출근하면 그때부터 대응한다" 라고 방침을 세운 상태에서 평온한(?) 월요일을 맞이했다. 주말을 넘겨 평일에 들어서면 이제 DB가 쌓이는 속도가 좀 떨어질 것이라는 안일한 계산도 있었다.
하지만 서버팀의 바람은 보기좋게 깨졌고, 오히려 데이터가 차오르는 속도는 월요일이 되어도 꺾일 기미가 보이질 않았다. 결국 긴급하게 계산을 해보니 "약 36시간이 지나면 용량이 꽉차고, 치명적인 오류가 발생한다"는 결론이 나왔다. 결국 서버팀은 긴급하게 대책을 수립하기 시작했다.
그런데 대책을 수립하는 와중에 사고가 터지기 시작했다. 알기 쉽게 설명하자면, 유저들의 DB를 저장한 클러스터가 분명 데이터가 있음에도 불구하고 읽기를 거부하는 오류를 내기 시작한 것이다. 이로 인해 개발팀에서는 긴급하게 서버를 내리기로 결정하고 그렇게 25일 오후 4시 52분, 긴급 점검이 시작되었다.
개발팀이 세운 대책은 바로 새로운 클러스터를 만들어서 데이터를 모두 옮긴다는 것이었다. 그러니까 저장소를 바꾼다는 것. 문제는 데이터의 양이 자그만치 7,577 '기가 바이트' 였다는 것이고, 이를 읽을 수 있는 CSV파일로 변환(포팅) 하는데 기존의 방식대로라면 '변환하는 것에만' 24시간이 넘게 걸린다는 것이었다. 그래서 개발팀은 기존의 방식이 아니라, CSV파일을 변환하는 최적화된 새로운 커맨드를 '직접 만들기로' 결정한다.
결국 다음날 오전 10시 30분, 서버 점검 약 18시간이 지나서 유저들의 데이터가 CSV로 변환을 시작했고 작업한 보람이 있어서 1시간 30분만에 유저들의 데이터는 모두 안전하게 포팅이 완료되었다. 그렇게 포팅이 완료된 데이터가 기존 데이터와 100% 일치한다는 것을 검증 완료한 후, 새로운 클러스터에 모든 데이터를 옮기고 최초 점검 시작후 약 31시간이 지난 후에 드디어 서버 점검이 끝나게 된다.
하지만 이번에는 30시간이 넘게 기다린 유저들이 한꺼번에 몰리면서 서버에 과부하가 발생한다. 결국 오픈 이후 채 3시간이 지나지 않아 임계치를 넘어서게 되고 새벽 2시 40분 경, 2차 점검을 시작한다. 결국 서버팀은 데이터의 최적화 및 여러 작업을 거쳐서 최초 서버 점검 시작후 약 36시간 30분이 지난 27일 오전 8시 30분 경 점검을 완료하게 된다.
36시간 서버 점검은 사실 엄밀히 따지자면 <쿠키런: 킹덤> 개발팀의 실수, 혹은 잘못이라고 볼 수 있는 사건이었다. 하지만 약 3주후에 벌어진 소위 '20시간 점검' 사태는 개발팀 입장에서는 굉장히 억울할 수도 있는 일이었다. 왜냐하면 개발실 내부 이슈가 아니라 'AWS' 데이터 센터가 있는 도쿄 리전의 냉각 유닛. 그러니까 에어콘이 정전으로 꺼져서 발생한 이슈기 때문이다.
일본의 AWS 센터는 <쿠키런: 킹덤> 외에도 수많은 게임이나 서버의 데이터들이 보관된다. 그런데 하필이면 이 사태로 서버의 온도가 급격하게 올라가면서 여러 서버의 데이터가 파손되었고, 그 중에서도 상당수는 <쿠키런: 킹덤>의 데이터가 보관된 서버였다. 심지어 다중 보관을 위해 여러 곳에 분산 배치한 데이터들이 한꺼번에 '하필이면' 문제가 생긴 유닛안에 있었고 결국 어쩔 수 없이 유저 DB가 보관된 2개의 서버가 파손된 게임사는 서버 점검을 안 할 수가 없게 되었다.
정말 다행인 것은 서버 점검 이후 파손된 서버에서 유저들의 데이터를 무사히 꺼낼 수 있었다는 사실이었다. 문제는 이렇게 건진 백업 데이터가 '문제가 없는지' 검증하고 그걸 다시 적용하는 데 시간이 너무 오래 걸린다는 것이었지만... 이미 이 사실을 알았을 때 서버 점검은 8시간을 넘겨 9시간을 향해 달려가고 있었고, 결국 개발팀은 극약중에 극약처방을 내린다.
바로 DB의 소스코드를 확인하던 중에 메뉴얼에도 없는 'unsafe-remove-dead-replica'라는 명령어를 발견한 것이다. 알기 쉽게 설명하자면, 이 명령어는 메뉴얼에도 없는 정말 '권장되지 않는' 최후의 명령어이며, 일단 데이터를 빠르게 복구할 수는 있지만 그 데이터가 '100% 멀쩡하다는' 보장이 전혀 없다. 오죽하면 이 명령어를 남긴 엔지니어들 조차 주석에서 "진짜 다른 수단이 없을 때 최후의 수단으로 사용해야 하며, 전문 엔지니어들이 보는 앞에서 신중하게 사용해야 한다" 같은 설명을 남겼을 정도다.
이창원 엔지니어와 박새미 프로그래머의 표현에 따르면 '흑마법'과도 같은 명령어였던 것. 그런데 더이상 개발팀 입장에서는 방법이 없었다. 이미 서버 점검은 12시간을 넘겼기 때문이었다.
결국 <쿠키런: 킹덤> 개발팀은 이 명령어를 사용할 수밖에 없었고, 결과는 정말 다행히도 성공했다. 다만 파손된 2개의 서버 중 하나는 이 명령어로도 살릴 수 없었기 때문에 1차 36시간 서버 점검때 사용했던 방법을 함께 병행해서 DB를 복구하는 데 성공했다.
결국 2차 서버 점검은 점검 시작 약 20시간이 지나서 무사히 완료할 수 있었다. 이번에도 1차 때와 마찬가지로 서버가 오픈하자 마자 유저들의 트래픽이 폭증했지만, 이미 1차 때 한 번 경험해봤기 때문에 이번에는 오픈 이후 트래픽 폭증으로 인한 추가 점검은 발생하지 않았다.
이런 1, 2차 56시간 점검에 대해 이창원 엔지니어는 "의도치 않은 이슈가 발생함으로 인해 유저들에게 많은 불편함을 끼쳤고, 작은 이슈라고 생각했던 것에 너무 안일하게 대처하는 바람에 문제가 커졌다. 그래도 사용자 데이터를 100% 사수할 수 있었고, 이후 클러스터 증설 및 접속자 대기열 서버 등의 추가 대책을 거치면서 이와 같은 이슈가 두 번다시 발생하지 않은 것은 다행" 이라고 말했다.
실제로 <쿠키런: 킹덤>은 두 번의 초창기 점검을 통해 수많은 노하우를 쌓았고, 이는 그대로 서버 안정으로 이어지고 있다.
