33P by xguru 16일전 | favorite | 댓글 27개
  • 데브시스터즈 역사상 가장 길었던 쿠키런: 킹덤의 36시간 장애
  • 메인 분산 DB로 CockroachDB를 사용 : 4대의 노드, 12TB의 스토리지, 7개의 복제본
  • 데이터베이스 확장 작업중 노드 절반이 다운
  • 이로 인해 서비스 전체 장애가 발생, CockroachDB쪽 서포트 엔지니어는 복구가 불가능하다고 판단
  • 그래서 직접 스토리지에 저장된 데이터를 찾기 위한 노력들을 정리한 글

서비스에 따라 섬뜩할 수 있는 내용이네요.
잼있게 읽었습니다.

보니까 해당 블로그에 해당 장애 관련 내용을 연작으로 올려뒀습니다. 쭈욱 읽어보니 저거 수습하던 사람들이 느꼈을 멘붕이 참 인상깊더군요.

일부 사용자의 경험을 훼손하고 대다수를 지키는 롤백보다 36시간에 걸쳐서 모든 사용자 정보를 복구하는것이 비즈니스적으로 옳은 판단인지는 잘 모르겠네요. 개발자 관점에서는 흥미로운 내용들이고요.

돈 때문에 일부 사용자는 버려도 된다는 이야기를 여기서도 듣게 되다니, 한국 게임계에서 유저들에 대한 취급을 또 한번 느끼고 갑니다.

그건 너무 꼬아서 본거 같고, 결과론적 봤을때 문제를 해결하지 못했으면 시간은 시간대로 낭비하고 백섭은 백섭대로 해서 원망을 들었겠죠.
그리고 서비스를 못하면 그 시간동안 사용자를 버리고 있다는 관점은 마찬가지구요.

매우 매우 격하게 공감합니다...

요즘 게임에서 (특히 랜덤 뽑기류 있는 게임에서) 롤백은.. 진짜 최악의 경우에만 쓸 수 있는 방법이라.. L모 게임처럼 이미지에 신경쓰지않는 이상 불가능해서 특히 이 사건은 오히려 롤백 안하고 이후에 보상을 크게 줘서 유저들도 재화가 부족하면 서버 한번 또 안터지나? 이런 농담을 주고 받았으니까요.. 저는 옳은 판단이었다고 봅니다.

게임이다보니 36시간 전으로 롤백하면 캐쉬 관련으로 금전적 손해가 많았을 수도 있었을 것 같네요

비지니스적으로 옳은 판단은 아닌거 같다는데 한표.

본문 내용 중에 이런 내용이 있네요.

고객에게 최고의 경험을 선사하는 게 우리의 미션이고, 이를 진심으로 실천하기 위해 노력했습니다. 그 누구도 낙담하고 포기하지 않았습니다.

개발자 관점에서는 너무 흥미롭게 읽었지만 (자극적인 제목 포함) 저도 비슷한 시각으로 바라보긴 했습니다. 좀 지난 기사에 언급된 내용이라 실제와는 차이가 있겠지만 쿠키런 킹덤 매출이 3천억 넘는 것 같은데 36시간 다운타임을 기대매출로 환산했을 때와 롤백 후 보상지급액을 비교하고 결정한 사안이었겠죠.
문제 해결을 중시하는 개발자 문화가 강한 조직이라는 점도 어느정도 영향이 있었을거라고 생각합니다.

저라면 어떤 결정을 했을지 아직도 잘 모르겠네요.

유독 논란이 많은 글이네요..? 서비스 측면에선 어떨지 모르겠으나 작업했던 개발자들은 엄청 뿌듯했을거 같네요

유저들 반응은 어땠을지 모르겠으나 백섭을 막기위해 노력했다는 점에서 유저로서는 칭찬한표 주고 싶은데.. 36시간동안 일어났을 유저이탈과 고객경험을 생각하면 손실이 더 클지 몰라도 개발자 입장에선 재미있는 도전이었다고 봅니다. 회사가 게임이 아니라 은행이었다면 어땠을까요?

포켓몬고는 GCP의 Spanner를 사용한다고 하는데 (https://cloud.google.com/blog/topics/…) AWS에는 마땅한 대안이 없기는 하네요

해당 문서를 기반으로 개발팀의 의도를 파악했을때 해당 프로젝트에서는 CockroachDB를 사용하지 말았어야 했네요.

어떤 DB를 사용했어야 했을까요?

의도치 않은 설정 미스 (이게 가장 크리티컬한 어처구니없는 휴먼 에러. 복제본 동작을 못하게 끔 만드는 엄청난 조작을 이런 식으로 저질러 버린 것, db 설계 개발자를 다 데려와도 이건 복구가 안됨)

그래서 데이터를 통째로 날릴수는 없으니... 최신 데이터 정합성은 포기 하고라도 최종 저장된 바이너리 형태의 DB 데이터를 직접 찾아서 (7 TB) 이걸 csv 로 변환하기 위해 go 프로그램을 작성... ?

이거 변환 go 프로그램 만드는 게 그거 아무리 잘 만들어도 뭔 의미가 있을까..
휴.. 참 생각만해도 답답하군요. 왜 이래야만 했을까..
이런 휴먼 에러 안나게 프로세스를 강화하는게 제일 중요하겠네요. 장애 처리하면서 바이너리 변환하느라 고생한 얘기는 하지 말고.

참 꼬였으면 꼬인대로 어디 안보이는 곳에 박혀 계실 것이지 인터넷이라고 아무 데나 튀어나와서는 눈살찌푸리게 하시네

이런 이야기를 하지 말아야 이유가 또 따로 있습니까? 포스트모템을 공개하는 것 자체가 의미가 있는데 말입니다.

제가 보기엔, 진정 도움이 되는 글을 쓴다면 제목이 이렇게 되야 하지 않을까요 ?

"노드 설정 미스로 인해 클러스터 불가 에러 발생 원인 분석 및 교훈"

그런 글은 따로 쓰면 되는 이야기고, ”장애 원인 분석“ 과 ”장애 해결 과정“ 은 별도의 토픽이고 둘 다 중요한 이야기인데, ”장애원인 분석“ 이 없었다고 글의 가치를 까내리는 행동은 이해하기 힘드네요...

원인 분석 글 도 후속으로 써주면 더욱 좋을 것 같다고 말씀하시면 되는데, 그 전에 가치없다고 말씀하시는건 좋은 태도는 아니네요.

엄밀하게 말하자면 '장애 해결 과정' 아니고, "불완전한 데이터 복구 노가다" 과정입니다. 단지 손실 범위를 좀 줄였다? 이 정도.

위 글에 데이터 복구가 “불완전”하다는 내용이 어디 있습니까? 적어도 위 글 내용상으로는 완전 복구에 성공했다는데요. 그리고 날려먹은 DB를 복구한 게 장애 해결이 아니면 뭡니까? 저 사건 이후로 해당 서비스가 그대로 운영을 종료했나요?

결과적으로 뽑아낸 파일에 모든 사용자 데이터가 정확하게 담겨있음을 확인할 수 있었습니다.

  1. 기본적으로 그 이야기는 아예 다른 글에서 하고 있습니다. 제목을 붙일 글부터가 틀렸습니다.
  2. 그 다른 글을 읽어보면, 장애가 시작된 가장 근본적인 원인은 스크립트 파일에 들어간 경로가 잘못된 것과 그것을 피어 리뷰하지 않고 그냥 써먹은 게 문제였습니다. 제목에 딱히 그런 정보가 들어가 있지 않으니, 오히려 별로 도움이 안되는 제목 같습니다.
  3. 무엇보다도, 제목이 노잼입니다. 그런 제목을 가진 글을 원하시면 그냥 학술지 혹은 사고 보고서를 찾아보시기 바랍니다. 글을 발표하는 매체의 특성을 생각하지 않고 제목을 짓는 것은 좋은 생각이 아닙니다.
  4. 그래서 “장애 처리하면서 바이너리 변환하느라 고생한 얘기”를 하지 말아야 할 이유는 뭐죠?

"CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기" --> 제목이 너무 웃겨서요. 궁금한게 해소 됬습니까 ?

그건 이 이야기를 하지말아야할 이유가 아닌데요?

세상 참 힘들게 사시네요

저렇게 거창하게 제목 달아서 할 얘기가 아닌듯 해서요. 그냥 오픈 소스 중 바이너리 포맷 알아서 변환해서 csv 로 저장해서 다시 읽었습니다. 한줄이면 끝. 근데 제목이 참... 아주 그냥 뿌듯한 듯... 거~~~~~~~창 하네 그려.