입사 첫날에 36시간 점검 경험하기

이 글과 관련된 다른 글 보기

• 쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
• CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
• 쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
• CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
• 입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
• 쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기
• 쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기 - 쿠키런: 킹덤에 길드 기능이 추가된 이후 발생한 서비스 이슈 회고

---

들어가기에 앞서

안녕하세요, 저는 진저랩 데이터플랫폼셀에 재직 중인 2년 차 소프트웨어 엔지니어 김도현입니다.

데브시스터즈에 처음으로 출근한 날이 2021년 1월 25일인데, 글을 쓰는 지금 벌써 2년 가까운 시간이 지났다는 것이 아직도 실감이 잘 나지 않습니다. 오늘은, 입사 첫날에 36시간 점검을 경험한 이야기를 전해드리고자 합니다.

근 2년 동안 데브시스터즈에서 많은 일들이 있었지만, 제게 가장 강렬했던 기억은 역시 입사 첫날에 마주했던 36시간 점검입니다. 게임을 플레이하는 유저에서 하루 만에 유저 경험을 고려해야 하는 입사 1일 차 신입 엔지니어가 되었고, 또 그 점검의 규모 또한 상당히 컸습니다. 이런 특별한 상황이었다 보니 아직도 제 기억 속에 강렬하게 남아있습니다.

저 역시 입사 하루 전까지만 하더라도 일반 유저의 입장에서 게임을 즐기고 있었기 때문에, 아무래도 제 관점이 그 이전부터 팀 내부에 계셨던 엔지니어 분들의 관점보다는 친숙하게 느껴지실 것입니다. 이 글을 통해 당시의 제가 보았던 상황과 느꼈던 감정을 여러분께 공유 드림으로써 기술적인 맥락 없이도 점검 타임라인에 대해 보다 쉽게 이해하실 수 있었으면 좋겠습니다.

첫 출근: 점검 8시간 전

2021년 1월 25일, 데브시스터즈에 기념비적인 첫 출근을 했습니다. 신규입사자를 대상으로 진행해주신 간단한 OT를 듣고, 사무실로 이동하여 데이터플랫폼셀 팀원분들과 인사를 나눴습니다. 당시 팀에는 저를 제외하고 3분이 있으셨는데(지금은 훨씬 더 큰 팀이 되었습니다), 슬프게도 팀원분들 모두가 런칭 이후 과도한 업무에 시달리고 계셨습니다.

입사 4일 전인 1월 21일에 출시된 쿠키런: 킹덤은 역대급 이용자 수를 기록하며 많은 유저분의 관심과 사랑을 받고 있었고, 그만큼 큰 규모의 로그를 만들어내고 있었습니다. 킹덤은 제가 상상조차 해보지 못했던 크기의 로그를 매초 쏟아내고 있었고, 그로 인해 로그를 수집 및 적재하는 파이프라인의 부하가 커지고 있었습니다. 당연히 시급히 해결해야 할 문제들이 생겨났고, 팀원분들은 거의 밤을 새우다시피 파이프라인 관련 대응 작업을 하고 계셨습니다.

하지만 그렇게 바쁜 와중에도 멘토님을 비롯한 팀원분들 모두 온보딩 절차 및 가이드들을 잘 설명해주시고 전달해주셔서 긴장감이 많이 덜해졌습니다. 당시에 팀장님께서 우스갯소리로 “런칭 당일에 오셨어야 더 재밌는 일들이 많았을 텐데”라는 말씀을 해주셨는데, 정말로 한 달 정도 더 일찍 입사했다면 어땠을까 하는 생각을 해봤습니다. 게임 런칭이 그리 자주 있는 일도 아닌 데다가, 비록 아무것도 알지 못하더라도 런칭 과정을 지켜보면서 많이 성장할 수 있지 않았을까 하는 생각이었습니다.

그리고 그날 오후, 그 생각을 기억 속에서 날려버릴 일이 일어났습니다.

오후 4시 52분: 점검 시작

퇴근 시간을 1시간 정도 남겨두고 온보딩 가이드를 열심히 따라가던 중, 킹덤을 플레이하던 친구로부터 메시지를 하나 받았습니다.

뭔가 싶어서 킹덤을 켜보니 실제로 접속이 되지 않았습니다. 사내 와이파이에 문제가 있나 싶어 셀룰러 모드로 다시 접속해보았지만, 똑같이 접속이 불가능하다는 팝업이 보였습니다. 싸한 느낌이 들어 팝업에서 눈을 떼니, 사색이 되어 움직이시는 그룹 분들과 모니터 속에서 시작되는 무수히 많은 화상회의가 보였습니다.

명백하게 문제로 보이는 상황에 저 역시 몹시 당황했습니다. 무슨 일이 벌어진 건가 여쭤보고 싶었지만, 당시 팀원분들이 다른 회의로 인해 자리를 비우신 상황이라 바로 맥락을 여쭤볼 순 없었습니다. 심상치 않은 분위기 속에서 당황한 채로 주변에서 들리는 이야기를 듣던 중, ‘데이터베이스’라는 단어가 들려왔습니다. 자연스럽게 ‘데이터베이스에 문제가 생겼나?’라는 의문이 머릿속에서 떠올랐고, 순간 오만가지 생각이 다 들기 시작했습니다.

당시 점검의 이유를 요약하자면, 데이터는 정상적으로 남아있으나 데이터베이스 클러스터에서 데이터를 인식할 수 없는 문제였습니다. 더욱 자세한 기술적 설명은 위 NDC 프레젠테이션과 데브시스터즈 기술 블로그의 이 글에서 확인하실 수 있습니다.

하지만 당시에는 이슈에 대한 자세한 상황을 몰랐고, 불안감은 잔뜩 커져만 갔습니다. 데이터가 날아갔다면 원본을 복구할 수 있는 것인지, 서버 롤백을 하게 될지, 만약 롤백을 한다면 후속 대응은 어떻게 진행될지 등등의 생각이 꼬리에 꼬리를 물며 떠올랐습니다. 저는 이제 막 신입 엔지니어로 입사한 데다가 아직 팀의 맥락은커녕 회사의 OT도 다 받지 못했던 상황이었고, 게다가 점검의 제대로 된 원인도 모르는 상황에서 혼자서 무언가를 할 수는 없었습니다. 그렇다 보니 팀원분들이 오실 때까지는 긴장한 채 주변의 상황을 지켜봤었습니다.

위의 NDC 프레젠테이션과 기술 블로그 게시글에서도 나온 내용이지만, 점검 시작 후 팀에서는 AWS 및 CockroachDB 엔지니어와 기술 지원을 위한 화상회의를 시작하였습니다. 많은 사람이 한꺼번에 대응하다 보니 회의는 스피커폰으로 진행되었는데, 전망이 좋지 않아 보이는 이야기들이 많이 들렸습니다. AWS 측에서는 마땅히 대응 방안을 제공해주지 못했다는 말과, CockroachDB 측에서는 롤백(백섭)이 최선의 방법일 것이라고 답변해주었다는 얘기도 들렸습니다.

1일차 종료: 점검 1시간 30분 경과

그렇게 절망적인 이야기들을 듣던 중 자리를 비우셨던 팀원분들이 돌아오셨습니다. 회의 도중에 대응을 진행하시다 자리로 돌아오셨다고 말씀해주셨는데, 아침에 뵀던 것보다 더욱 수척해지신 모습이셨습니다. 혹여나 제가 자리에 남는다면 조금이나마 도와드릴 수 있는 일이 있지 않을까 하는 마음이었지만, 팀원분들은 강력하게 저를 퇴근길에 올려보내셨습니다.

걱정 반 불안 반의 마음으로 집에 가는 와중에도 몇 번씩 킹덤을 실행해봤지만, 여전히 점검 안내 팝업이 저를 반겨주었습니다. 집에 도착하고서도, 저녁을 먹고서도, 씻고 잘 준비를 하면서도 계속해서 킹덤을 실행해봤지만, 점검은 계속되고 있었고 제 불안감도 커져만 갔습니다.

결국 오늘 막 입사한 제가 딱히 집에서 할 수 있는 일도 없었고(재택근무를 위한 노트북 VPN 설정조차 끝내지 못했었습니다), 깨어있다면 계속해서 불안한 생각만 들 것 같았기에 이른 잠자리에 들기로 하였습니다.

두 번째 출근: 점검 16시간 경과

1월 26일, 잠을 설치고 새벽에 눈을 떴습니다. 일어나자마자 킹덤을 실행해봤으나 야속한 점검 팝업만 보였습니다.

출근 준비를 마치고 회사에 도착하니 멘토님이 어제와 똑같은 옷차림으로 퇴근할 때 뵌 모습과 똑같이 자리에 앉아계셨습니다. 밤새 이슈 대응을 진행하고 계셨다고 말씀해주셨고, 멘토님뿐만 아니라 저희 팀을 포함한 전사의 수많은 분이 대응을 위해 밤을 새우신 상태였습니다.

멘토님께서 간단하게 상황 정리를 해주셔서 현재 점검의 원인에 대한 자세한 설명과 진행 중인 대응의 기조를 들을 수 있었습니다. 롤백(백섭)을 하는 것이 단순하게 타협해볼 수 있는 선택이긴 하지만, 런칭하자마자 많은 분께서 게임을 즐겨주고 계셨던 상황에서 롤백으로 인한 데이터 손실이 몇 시간, 몇 분이라도 발생한다면 많은 유저분이 상실감을 느끼실 것을 우려하고 계셨습니다. 그 때문에 완벽한 복구를 계획하고 있다고 하셨고, 이를 위해 데이터베이스 클러스터 간 데이터 이동 작업을 밤새 준비하셨다고 알려주셨습니다.

덕분에 회사 차원에서 어떤 기조로 현 상황에 대처하고 있는지 알게 되어 무지에 대한 불안감은 어느 정도 줄어들었습니다. 다만 여전히 점검이 계속 길어지는 것에 대한 불안은 남아있었는데, 팀장님의 배려로 실제로 대응을 진행하시는 것을 가까이서 지켜볼 수 있었습니다.

처음으로 봤던 작업은 CockroachDB의 스토리지 레이어에서 사용하는 sst 파일을 csv 파일로 변환하는 과정이었습니다. Spark를 통해서 약 7TB나 되는 분량의 데이터를 병합하는 작업이었는데, 대략 11,200코어의 CPU와 89,600GB의 메모리를 가지는 클러스터임에도 불구하고 워낙에 데이터의 규모가 크다 보니 작업이 오래 걸릴 수밖에 없었습니다. 시간은 시간대로 흘러가고 Spark job 프로그레스 바는 너무나도 느리게 차오르다 보니, 계속 마음속으로 제발 잘 좀 옮겨지라고 기도하고 있었습니다.

다행히도 CSV 파일로의 변환은 잘 마무리되었고, 이어서 새로운 CockroachDB 클러스터에 변환된 데이터를 옮겨주기 시작했습니다. 하지만 추가로 한 가지 생겼던 문제가 더 생겼었는데, 바로 EC2 인스턴스 부족이었습니다. 데이터 전처리를 위해서 Spark 노드를 최대한 많이 띄웠었는데, AWS 도쿄 리전의 가용 가능한 모든 R계열 인스턴스를 끌어다 사용하다 보니 인스턴스가 부족해서 새 노드를 띄울 수 없었습니다.

결국 적재 및 분석에 사용하던 다른 인스턴스들까지 끌어와 데이터 이주 작업에 동원되었고, 오후 5시 반쯤이 되어서 데이터 이주가 모두 완료되었습니다. 다만 데이터베이스 클러스터 간의 데이터 정합성 역시 확인해야 했었기에, 최종적으로 오후 8시 정도가 되어서야 서비스 오픈을 위한 데이터베이스 준비가 완료되었습니다. 이때 작업을 지켜보면서도 시간이 이렇게 많이 흐른 줄 몰랐는데, 어느새 창밖이 어두워진 것을 보고 놀랐던 기억이 납니다.

첫 야근: 점검 27시간 경과

그리고 또다시 퇴근 시간이 되었습니다. 팀원분들은 오늘도 저를 집으로 보내려 하셨지만, 무지에서 오는 불안감도 있었고, 남아서 도와드릴 수 있는 일들이 하나쯤은 있지 않을까 싶었기에 잠깐의 논의 끝에 회사에 남아 자잘한 작업을 더 도와드리기로 하였습니다.

오후 8시부터는 실제 유저 중 일부를 샘플링하여 데이터 정합성을 다시 한번 확인하였고, 이후 오후 10시경 전사 대상 내부 테스트가 시작되었습니다. 저도 아직 퇴근하지 않아서 내부 테스트에 참여했었는데, 다행히도 점검 시작 전까지의 제 킹덤 계정이 잘 보존된 것을 확인했습니다. 정말 안도의 한숨을 푹 쉬었던 기억이 아직도 생생합니다.

내부 테스트가 진행되는 동안 잠시 숨을 돌릴 틈이 있었고, 이 기회에 입사 첫날에 뵙지 못한 데이터 직군의 다른 분들과 안면을 트는 등 잠깐이지만 평범한(이미 오후 10시가 넘은 시점에서 사실 평범하지 않긴 했습니다) 온보딩을 진행했었습니다 🙃

테스트가 끝난 후, 오후 11시 30분경 점검 해제를 대비하여 데이터플랫폼의 로깅 인프라 모니터링을 준비하기로 하였습니다. 저는 Kafka와 Elastic Stack 메트릭을 모니터링하며 저희의 데이터플랫폼에 이상이 없는지 지켜보았습니다.

그리고 대망의 오후 11시 37분, 점검 시작 후 약 31시간 만에 서비스가 오픈되었습니다.

대략 1시간 정도 모니터링을 진행하였고, 정말 다행히도 Kafka와 Elastic Stack 모두 부하가 조금 걸리긴 했으나 서서히 줄어들고 마침내 다시 정상 범주 안으로 복귀하는 것을 확인하였습니다. 데이터플랫폼셀 뿐만 아니라 전사적으로도 어느 정도 복구가 완료된 것 같아 마음이 조금 놓였고, 새벽 1시경 모니터링을 마치고 퇴근하게 되었습니다.

다만 제가 퇴근하고 잠든 사이 점검이 한 차례 더 있었다는 이야기를 일어난 후에 듣게 되었습니다 😢

점검 이후: 후일담

서버가 오픈된 새벽 1시에 느꼈던 기분은 안도감과 경외감이었습니다. 팀뿐만 아니라 그룹 전체가 나서서 완벽한 사용자 경험을 복구하기 위해서 최선의 노력을 다하였고, 비록 시간은 오래 걸렸지만 CockroachDB 엔지니어도 불가능하다고 말했던 “온전한 유저 경험”을 되살릴 수 있었다는 점이 너무나도 경이로웠습니다.

대응과 복구를 지켜보고 또 맥락을 이해하면서 팀에서 내렸던 결정 및 선택의 이유 역시 알 수 있었고, 데이터플랫폼의 인프라를 이렇게도 활용할 수 있구나라는 생각이 들었습니다. CockroachDB 클러스터의 데이터를 살리는 것과 로그 기반으로 데이터의 정합성을 확인하는 것 모두 데이터플랫폼셀에서 Spark를 사용해 모든 로그를 적재하지 않고 있었더라면 불가능했을 것입니다.

마지막으로, 외부에서 점검을 구경하던 것과 내부에서 점검을 마주했을 때의 느낌은 완전히 다르다는 것을 알았습니다. 많은 분이 치열하게 서비스 재개를 위해 노력하셨고, 대응이라는 것이 얼마나 바쁜 작업의 연속인지를 알게 되었습니다. 저 역시 이러한 과정의 한 부분을 맡을 수 있도록 더욱 노력해야겠다는 생각도 들었습니다.

이 글에서는 간략하게 다루었지만, 더욱 자세한 대응에 관한 기록과 이야기는 아래의 글에서 더 자세하게 확인하실 수 있습니다.

• 쿠키런: 킹덤 런칭 회고
• 쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기

특히, 36시간 점검 당시 비트 레벨까지 내려가서 CockroachDB를 해킹한 CTO님의 이야기도 조만간 공개될 예정이니, 많은 관심을 부탁드리겠습니다.

읽어주셔서 감사합니다.