서버 개발자의 라이브 서비스 장애 해결기 - 1

얼마 전... 아직 3년차가 채 되지 않은 저는, 회사에 마지막 남은 서버 팀원이 되어버렸습니다.

선임분도, 후임분도, 팀장님도 아무도 계시지 않는 상황인거죠. 야호~! 내 세상이다! (는 무슨, 과거 릴 온라인 개발 막바지의 현 김대일 펄어비스 대표의 상황이 오버랩 됐습니다...)

한 두분씩 떠나시면서 미안하다는 말씀을 남기고 가셨지만, 사실 저를 포함한 모두가 그렇게 크게 걱정하지는 않았습니다. 

제가 아직 경력이 3년밖에 안되기는 했지만, 저희 게임에서 발생하는 별의별 장애는 다 경험해 보았고... 게임서버야 원래 혼자 하고 있었고.. 결국 플랫폼 서버와 Facebook API쪽 대응만 하면 됐기 때문입니다.

당연히 잘 서비스되고 있는 게임에서 갑작스럽게 크리티컬한 장애가 날 거라는 생각은 하지 않고 있었던 겁니다. (다만 휴가를 못 쓴다거나, 휴가를 못 쓴다거나, 휴가를 못 쓴다거나, 휴가를 가서도 서버 관리를 해야 한다거나, 휴가를 가서도 서버 관리를 해야 한다거나, 휴가를 가서도 서버 관리를 해야 한다거나 하는 부담감은 있었죠)

하지만 인생은 실전이라고 했습니다. 그리고 당연히 제 생각대로 흘러가는 법도 없습니다. 서비스중인 게임의 토너먼트(실시간 점수 경쟁 컨텐츠) 시스템에서 문제가 발생 했습니다.

사실 토너먼트 시스템 자체는 큰 비중을 차지하지 않아서 장애가 생겼으면, 잠깐 점검을 걸어놓던, 임시로 수를 써놓고 차근차근 찾던 크게 문제가 되지 않습니다. 하지만 진짜 문제는 이 토너먼트 서버가 다른 모든 서버들에 영향을 끼치고 있었다는 점 입니다.

어떻게 그럴수가 있을까요?

이유는 서버간 의존성 때문입니다. 저희 게임은 장애 피해 최소화를 위한 분산 서버 구조로 되어 있습니다. 그래서 분산된 여러 서버들과 통신하는 하나의 메인 서버가 있고, 클라이언트는 오직 메인 서버랑만 통신하며 패킷 통신을 하는거죠.

클라이언트가 메인 서버에 요청을 보내면, 메인 서버는 분산된 서버들 중 알맞는 서버에게 해당 요청을 보내서 처리 하고요.

당연히, 토너먼트 서버 역시 예외는 아니었습니다.

이 구조는 서버간 의존성이 심해지는 문제가 있지만, 현재 상황에서는 어쩔 수 없는 선택이었다고 생각됩니다.

분산된 서버의 갯수가 매우 많다보니(약 10개에 달합니다...) 클라이언트가 모든 서버와 Connection을 유지하면 매우 비효율적인 상황이 발생됩니다. 로드 밸런싱이 불편해지는것도 물론 있구요.

이 장애의 시작은 작년 12월로 거슬러 올라가게 됩니다. 토너먼트 시스템이 그때 오픈을 했거든요. 이 시스템의 개발은 제가 아닌 퇴사자분이 하셨었습니다. 저는 게임서버 담당이였고, 게임 플랫폼 서버 부분은 퇴사자분이 맡고 계셨었거든요.

이 시스템은 기존에 작업되어 있던 토너먼트를 리뉴얼 하는 것이였기에, 큰 어려움 없이 개발이 되었던것으로 기억합니다. 과부하 테스트도 가뿐하게 끝나고, 두근두근 설레는 신규 컨텐츠의 오픈만 남아있었죠.

그런데 웬걸? 오픈을 하자마자 장애가 발생했습니다. 처음 라운드는 잘 되다가, 다음 라운드부터는 아예 토너먼트가 안 되기 시작하는거죠. (담당자분이 이게 뭐야, F***! 을 외쳤던 기억이 나네요)

저희는 우선 토너먼트에 점검을 걸어놓고 다급하게 문제를 찾기 시작했습니다. 담당자분은 멘붕이 오신 상태라, 저도 버그 추적을 지원하며 불필요한 lock을 삭제하고, 부하가 걸릴만한 부분을 찾는 등의 작업을 했었죠.

어느정도 정리가 되었다 싶어 패치를 진행했습니다. 하지만? 그럼에도 상황은 나아지지 않았습니다.

그런데, 개발 서버에 돌고 있던 과부하 테스트용 봇은 여전히 잘 돌고 있었습니다. '대체 문제가 뭘까...' 하며 찾다보니, 토너먼트 서버에 봇이 절대 진입할 수 없는 로직이 있더군요! (봇이 아닌 실제 유저에게만 적용되는 로직)

그래서 해당 if 분기를 삭제하고, 봇도 그 로직을 타도록 해보았습니다. 그러자, 어떻게 됐을까요? 네. 토너먼트 서버가 시원하게 터졌습니다!

'어쨌든 재현을 했으니 문제는 금방 수정될거야!' 라고 생각한지 4일째 되는 일요일 저녁,

PD님이 4일째 클라이언트 분과 저의 충혈된 눈을 보시더니(클라이언트 분은 혹시 몰라서, 저는 봇 지원과 이슈를 함께 파악하기 위해서.. 그니까 한마디로 둘 다 이 장애와 아무런 관계 없는 사람들..) 결단을 내리셨습니다. 지금 당장 핸드폰을 꺼내서 퇴사하신 팀장님들께 전화를 드려 어떻게 해결해야 할 지 여쭤보라고 하시더군요!

사실 지금 생각해보면 여기부터가 잘못된 게 아니었을까 싶습니다. 코드를 같이 보며 의논할 수 있는 상황도 아니고, 그냥 대충 상황만 듣고 해결법을 달라고 하는거니까요. 더 큰 문제는, 장애 상황과 원인도 제대로 정립되지 않은 상태였구요!

그 후, 담당자분이 통화를 마치고 오셔서는 저에게 "쓰레드 풀을 많이 늘리면 될거래!" 라는 말을 하시더군요. 그 말을 들은 저는 뭐 한 10개정도 늘리면 되려나.. 싶었습니다.

그런데, 갑자기 쓰레드풀을 기존의 몇십배씩 늘리시더니 어떤 서버는 500개... 어떤 서버는 1000개... 심지어 2000개 까지도 늘리시더군요.

그렇게 많이 늘려도 되나? 컨텍스트 스위칭만 심해지지 않나? (※ 당연히 안됩니다)

처음엔 너무 과도한 숫자가 아닌가 싶어 여쭤봤지만 담당자분도 확신이 없긴 마찬가지셨습니다. 또, 웃긴건 쓰레드풀을 그렇게 무지막지하게 늘렸더니 장애가 해결되긴 하더라구요. (흑마법은 언제나 통한다...)

정말 매우 매우 찜찜했지만... 일단 제 파트도 아니고, 확실하게 아는것도 아니고 해서 더이상 말씀을 드리진 않았습니다. 하지만 그 때 부터였습니다... 지금까지 이어지는 이 재앙이 시작된건요.

쓰다보니 글이 매우 길어졌네요. 사실 원래는 심플하게 현상-원인-수정 방법 딱 이렇게 끝내려고 했는데 말이에요. 어쩔 수 없이 글을 나눠서 써야 할 것 같습니다(...)

그럼 2편에서 뵙겠습니다.