CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기
(tech.devsisters.com)- 데브시스터즈 역사상 가장 길었던 쿠키런: 킹덤의 36시간 장애
- 메인 분산 DB로 CockroachDB를 사용 : 4대의 노드, 12TB의 스토리지, 7개의 복제본
- 데이터베이스 확장 작업중 노드 절반이 다운
- 이로 인해 서비스 전체 장애가 발생, CockroachDB쪽 서포트 엔지니어는 복구가 불가능하다고 판단
- 그래서 직접 스토리지에 저장된 데이터를 찾기 위한 노력들을 정리한 글
유저들 반응은 어땠을지 모르겠으나 백섭을 막기위해 노력했다는 점에서 유저로서는 칭찬한표 주고 싶은데.. 36시간동안 일어났을 유저이탈과 고객경험을 생각하면 손실이 더 클지 몰라도 개발자 입장에선 재미있는 도전이었다고 봅니다. 회사가 게임이 아니라 은행이었다면 어땠을까요?
포켓몬고는 GCP의 Spanner를 사용한다고 하는데 (https://cloud.google.com/blog/topics/…) AWS에는 마땅한 대안이 없기는 하네요
보니까 해당 블로그에 해당 장애 관련 내용을 연작으로 올려뒀습니다. 쭈욱 읽어보니 저거 수습하던 사람들이 느꼈을 멘붕이 참 인상깊더군요.
일부 사용자의 경험을 훼손하고 대다수를 지키는 롤백보다 36시간에 걸쳐서 모든 사용자 정보를 복구하는것이 비즈니스적으로 옳은 판단인지는 잘 모르겠네요. 개발자 관점에서는 흥미로운 내용들이고요.
본문 내용 중에 이런 내용이 있네요.
고객에게 최고의 경험을 선사하는 게 우리의 미션이고, 이를 진심으로 실천하기 위해 노력했습니다. 그 누구도 낙담하고 포기하지 않았습니다.
돈 때문에 일부 사용자는 버려도 된다는 이야기를 여기서도 듣게 되다니, 한국 게임계에서 유저들에 대한 취급을 또 한번 느끼고 갑니다.
그건 너무 꼬아서 본거 같고, 결과론적 봤을때 문제를 해결하지 못했으면 시간은 시간대로 낭비하고 백섭은 백섭대로 해서 원망을 들었겠죠.
그리고 서비스를 못하면 그 시간동안 사용자를 버리고 있다는 관점은 마찬가지구요.
개발자 관점에서는 너무 흥미롭게 읽었지만 (자극적인 제목 포함) 저도 비슷한 시각으로 바라보긴 했습니다. 좀 지난 기사에 언급된 내용이라 실제와는 차이가 있겠지만 쿠키런 킹덤 매출이 3천억 넘는 것 같은데 36시간 다운타임을 기대매출로 환산했을 때와 롤백 후 보상지급액을 비교하고 결정한 사안이었겠죠.
문제 해결을 중시하는 개발자 문화가 강한 조직이라는 점도 어느정도 영향이 있었을거라고 생각합니다.
저라면 어떤 결정을 했을지 아직도 잘 모르겠네요.
요즘 게임에서 (특히 랜덤 뽑기류 있는 게임에서) 롤백은.. 진짜 최악의 경우에만 쓸 수 있는 방법이라.. L모 게임처럼 이미지에 신경쓰지않는 이상 불가능해서 특히 이 사건은 오히려 롤백 안하고 이후에 보상을 크게 줘서 유저들도 재화가 부족하면 서버 한번 또 안터지나? 이런 농담을 주고 받았으니까요.. 저는 옳은 판단이었다고 봅니다.
의도치 않은 설정 미스 (이게 가장 크리티컬한 어처구니없는 휴먼 에러. 복제본 동작을 못하게 끔 만드는 엄청난 조작을 이런 식으로 저질러 버린 것, db 설계 개발자를 다 데려와도 이건 복구가 안됨)
그래서 데이터를 통째로 날릴수는 없으니... 최신 데이터 정합성은 포기 하고라도 최종 저장된 바이너리 형태의 DB 데이터를 직접 찾아서 (7 TB) 이걸 csv 로 변환하기 위해 go 프로그램을 작성... ?
이거 변환 go 프로그램 만드는 게 그거 아무리 잘 만들어도 뭔 의미가 있을까..
휴.. 참 생각만해도 답답하군요. 왜 이래야만 했을까..
이런 휴먼 에러 안나게 프로세스를 강화하는게 제일 중요하겠네요. 장애 처리하면서 바이너리 변환하느라 고생한 얘기는 하지 말고.
제가 보기엔, 진정 도움이 되는 글을 쓴다면 제목이 이렇게 되야 하지 않을까요 ?
"노드 설정 미스로 인해 클러스터 불가 에러 발생 원인 분석 및 교훈"
그런 글은 따로 쓰면 되는 이야기고, ”장애 원인 분석“ 과 ”장애 해결 과정“ 은 별도의 토픽이고 둘 다 중요한 이야기인데, ”장애원인 분석“ 이 없었다고 글의 가치를 까내리는 행동은 이해하기 힘드네요...
원인 분석 글 도 후속으로 써주면 더욱 좋을 것 같다고 말씀하시면 되는데, 그 전에 가치없다고 말씀하시는건 좋은 태도는 아니네요.
엄밀하게 말하자면 '장애 해결 과정' 아니고, "불완전한 데이터 복구 노가다" 과정입니다. 단지 손실 범위를 좀 줄였다? 이 정도.
위 글에 데이터 복구가 “불완전”하다는 내용이 어디 있습니까? 적어도 위 글 내용상으로는 완전 복구에 성공했다는데요. 그리고 날려먹은 DB를 복구한 게 장애 해결이 아니면 뭡니까? 저 사건 이후로 해당 서비스가 그대로 운영을 종료했나요?
결과적으로 뽑아낸 파일에 모든 사용자 데이터가 정확하게 담겨있음을 확인할 수 있었습니다.
- 기본적으로 그 이야기는 아예 다른 글에서 하고 있습니다. 제목을 붙일 글부터가 틀렸습니다.
- 그 다른 글을 읽어보면, 장애가 시작된 가장 근본적인 원인은 스크립트 파일에 들어간 경로가 잘못된 것과 그것을 피어 리뷰하지 않고 그냥 써먹은 게 문제였습니다. 제목에 딱히 그런 정보가 들어가 있지 않으니, 오히려 별로 도움이 안되는 제목 같습니다.
- 무엇보다도, 제목이 노잼입니다. 그런 제목을 가진 글을 원하시면 그냥 학술지 혹은 사고 보고서를 찾아보시기 바랍니다. 글을 발표하는 매체의 특성을 생각하지 않고 제목을 짓는 것은 좋은 생각이 아닙니다.
- 그래서 “장애 처리하면서 바이너리 변환하느라 고생한 얘기”를 하지 말아야 할 이유는 뭐죠?
"CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기" --> 제목이 너무 웃겨서요. 궁금한게 해소 됬습니까 ?
저렇게 거창하게 제목 달아서 할 얘기가 아닌듯 해서요. 그냥 오픈 소스 중 바이너리 포맷 알아서 변환해서 csv 로 저장해서 다시 읽었습니다. 한줄이면 끝. 근데 제목이 참... 아주 그냥 뿌듯한 듯... 거~~~~~~~창 하네 그려.