이 글과 관련된 다른 글 보기안녕하세요, 데브시스터즈 진저랩 플랫폼셀에서 소프트웨어 엔지니어로 일하고 있는 박새미, 인프라셀에서 일하고 있는 데브옵스 엔지니어 이창원입니다. 이 글에서는 2022년 NDC에서 함께 발표한 쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 - 그때 그 명검은 왜 뽑아야 했는가 세션에서도 다룬 바 있는, 2021년 2월 19일에 발생한 AWS 도쿄 리전 데이터센터 장애에 대해 공유해 드리고자 합니다. 만약 정보를 접할 때 글보다 영상을 선호하는 편이시라면, 해당 세션 영상을 보시는 것을 권해드립니다.CockroachDB? 분산 데이터베이스!어느 평화로운 봄날, 회식 자리에서 DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 나타났지만, 데브옵스 엔지니어들은 크게 당황하지 않았습니다. AWS 같은 거대한 클라우드 벤더사라고 해서 100% SLA를 보장하지는 못하기도 하고요. 무엇보다도 CockroachDB는 이러한 장애를 견딜 수 있게 설계된 분산 데이터베이스이기 때문입니다.[1] 는 레플리카들에 복사되어 저장됩니다. CockroachDB는 Raft 알고리즘을 채택하였고 이에 따라 DB가 N대 있다고 했을 때 (N/2) + 1 이상의 값, 즉 과반수를 정족수로 사용합니다. 결과적으로 정족수가 깨지지 않는 한 일부 노드가 죽어도 영향을 받지 않게 설계된 것이지요. 예를 들어 Replication을 5대로 설정한다면, (5/2)-1대 미만의 노드가 죽어도 DB를 이용하는 데는 문제가 없습니다. CockroachDB에 더 자세히 알고싶으시다면 진저랩 인프라셀 이준성 님이 쓰신 기본적으로 분산 DB는 일부 노드가 정상적으로 동작하지 않아도 견딜 수 있게끔 설계됩니다. CockroachDB는 기본적으로 3대의 레플리카를 두게 되어 있으며, 각 Range는 레플리카들에 복사되어 저장됩니다. CockroachDB는 Raft 알고리즘을 채택하였고 이에 따라 DB가 N대 있다고 했을 때 (N/2) + 1 이상의 값, 즉 과반수를 정족수로 사용합니다. 결과적으로 정족수가 깨지지 않는 한 일부 노드가 죽어도 영향을 받지 않게 설계된 것이지요. 예를 들어 Replication을 5대로 설정한다면, (5/2)-1대 미만의 노드가 죽어도 DB를 이용하는 데는 문제가 없습니다. CockroachDB에 더 자세히 알고싶으시다면 진저랩 인프라셀 이준성 님이 쓰신 CockroachDB in Production 을 읽어보시는 것을 추천드립니다.[2] 중 6대의 노드가 작동 불능이 되는 것은 조금 다른 이야기입니다. 엔지니어들은 빠르게 상황 파악 및 대응에 나섰습니다. 다만 분산 DB라 하더라도 3분 만에 또 2대, 6분 뒤에 2대, 20분 후에 2대… 22분 만에 총 60대중 6대의 노드가 작동 불능이 되는 것은 조금 다른 이야기입니다. 엔지니어들은 빠르게 상황 파악 및 대응에 나섰습니다.다시는 보고 싶지 않은 그 날의 Ops 채널 알람을 모사해보았습니다.무슨 일이 일어나고 있나요?애플리케이션 레벨에서 DB 호출과 관련된 치명적인 로직이 없고 DB

소프트웨어 엔지니어들은 수많은 추상화 속에서 살아갑니다. 하위 레벨에서 제공하는 추상화는 공기처럼 당연한 것으로 여겨지고, 그 위에 무엇을 어떻게 쌓아 올릴지 고민하는 게 소프트웨어 엔지니어링이라 할 수 있습니다. 오늘은 이렇게 당연하게 여겼던 추상화를 하나하나 파고들어간 이야기를 소개해 볼까 합니다. 수십 명의 개발자들이 만들었던 게임. 36시간 장애 속에서 수백만 명이 서비스 오픈만을 기다리고 있고, DB를 만든 회사에서 복구는 불가능하다고 얘기하는 극한의 상황 속에서 CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기를 소개합니다.이야기를 시작하기에 앞서 해커 문화(Hacker Culture)를 알고 갑시다. 대중적으로 ‘해킹’이라는 단어는 시스템을 불법적으로 침입하는 행위로 알려져 있습니다. 원래 ‘해킹’의 개념은 MIT에서 시작되었는데, 소프트웨어 시스템이나 하드웨어의 제약사항을 창조적으로 함께 극복해 내는 행위를 뜻합니다. 문제를 해결하거나 시스템의 한계를 극복하기 위해 시스템의 밑바닥까지 파고들고, 그 시스템에 대한 완벽한 이해를 추구합니다. 이러한 해커 문화를 이끌어간 리더들로는 GNU 창시자 RMS, C 언어를 개발한 Dennis Ritchie, Go 언어를 개발한 Ken Thompson, 리눅스를 개발한 Linus Torvalds 등이 있습니다. 보시면 아시겠지만 해커 문화와 오픈소스와는 밀접한 연관이 있습니다.데브시스터즈의 엔지니어링 조직은 뛰어난 엔지니어링을 지향함과 동시에 해커 문화와 오픈소스를 좋아합니다. 사용하는 오픈소스 제품의 코드 레벨까지 뛰어드는 걸 주저하지 않습니다. 여기서 소개되는 이야기는 이러한 문화가 얼마나 극한까지 갈 수 있는지 보여주며, 극한의 데이터베이스 해킹을 통해 장애를 극복하는 기술적 이야기를 다룹니다.이야기의 시작은 데브시스터즈 역사상 가장 길었던 쿠키런: 킹덤의 36시간 장애에서 시작합니다. 쿠키런: 킹덤은 메인 데이터베이스로 CockroachDB를 사용합니다. CockroachDB는 우리가 익숙한 전통적인 RDBMS처럼 ACID 특성을 가지고 있으며, SQL 기반의 트랜잭션 처리가 완벽하게 작동하는 분산 데이터베이스입니다. 런칭 전부터 대규모 사용자 유입을 대비하여 데이터베이스는 24대의 노드, 12TB의 스토리지, 7개의 복제본을 두는 설정으로 만반의 준비를 했는데요. 실제로 오픈 직후 어마어마한 사용자 유입이 있었고, 한 주가 채 지나기도 전에 스토리지가 약 8TB 정도로 꽉꽉 차기 시작합니다.일반적으로 공휴일이 가장 큰 허들인데요. DevOps 조직인 인프라셀은 런칭 첫 주 주말을 장애 없이 넘어갑니다. 이후 월요일부터 스토리지가 차는 문제를 대응하기 위한 작업에 들어갑니다. 여기서 문제의 발단이 시작됩니다. 데이터베이스 확장 작업 전에 안전장치를 설정하기 위한 작업을 하던 중 의도치 않은 설정 미스로 인해 데이터베이스 노드 중 절반 이상이 다운되게 됩니다.앞서 CockroachDB는 트랜잭션을 지원한다고 했는데요. CockroachDB 클러스터는 기본적으로

들어가기에 앞서안녕하세요, 저는 진저랩 데이터플랫폼셀에 재직 중인 2년 차 소프트웨어 엔지니어 김도현입니다.데브시스터즈에 처음으로 출근한 날이 2021년 1월 25일인데, 글을 쓰는 지금 벌써 2년 가까운 시간이 지났다는 것이 아직도 실감이 잘 나지 않습니다. 오늘은, 입사 첫날에 36시간 점검을 경험한 이야기를 전해드리고자 합니다.근 2년 동안 데브시스터즈에서 많은 일들이 있었지만, 제게 가장 강렬했던 기억은 역시 입사 첫날에 마주했던 36시간 점검입니다. 게임을 플레이하는 유저에서 하루 만에 유저 경험을 고려해야 하는 입사 1일 차 신입 엔지니어가 되었고, 또 그 점검의 규모 또한 상당히 컸습니다. 이런 특별한 상황이었다 보니 아직도 제 기억 속에 강렬하게 남아있습니다.저 역시 입사 하루 전까지만 하더라도 일반 유저의 입장에서 게임을 즐기고 있었기 때문에, 아무래도 제 관점이 그 이전부터 팀 내부에 계셨던 엔지니어 분들의 관점보다는 친숙하게 느껴지실 것입니다. 이 글을 통해 당시의 제가 보았던 상황과 느꼈던 감정을 여러분께 공유 드림으로써 기술적인 맥락 없이도 점검 타임라인에 대해 보다 쉽게 이해하실 수 있었으면 좋겠습니다.첫 출근: 점검 8시간 전2021년 1월 25일, 데브시스터즈에 기념비적인 첫 출근을 했습니다. 신규입사자를 대상으로 진행해주신 간단한 OT를 듣고, 사무실로 이동하여 데이터플랫폼셀 팀원분들과 인사를 나눴습니다. 당시 팀에는 저를 제외하고 3분이 있으셨는데(지금은 훨씬 더 큰 팀이 되었습니다), 슬프게도 팀원분들 모두가 런칭 이후 과도한 업무에 시달리고 계셨습니다.2021년 1월 21일에 쿠키런: 킹덤이 출시되었습니다.입사 4일 전인 1월 21일에 출시된 쿠키런: 킹덤은 역대급 이용자 수를 기록하며 많은 유저분의 관심과 사랑을 받고 있었고, 그만큼 큰 규모의 로그를 만들어내고 있었습니다. 킹덤은 제가 상상조차 해보지 못했던 크기의 로그를 매초 쏟아내고 있었고, 그로 인해 로그를 수집 및 적재하는 파이프라인의 부하가 커지고 있었습니다. 당연히 시급히 해결해야 할 문제들이 생겨났고, 팀원분들은 거의 밤을 새우다시피 파이프라인 관련 대응 작업을 하고 계셨습니다.하지만 그렇게 바쁜 와중에도 멘토님을 비롯한 팀원분들 모두 온보딩 절차 및 가이드들을 잘 설명해주시고 전달해주셔서 긴장감이 많이 덜해졌습니다. 당시에 팀장님께서 우스갯소리로 “런칭 당일에 오셨어야 더 재밌는 일들이 많았을 텐데”라는 말씀을 해주셨는데, 정말로 한 달 정도 더 일찍 입사했다면 어땠을까 하는 생각을 해봤습니다. 게임 런칭이 그리 자주 있는 일도 아닌 데다가, 비록 아무것도 알지 못하더라도 런칭 과정을 지켜보면서 많이 성장할 수 있지 않았을까 하는 생각이었습니다.그리고 그날 오후, 그 생각을 기억 속에서 날려버릴 일이 일어났습니다.오후 4시 52분: 점검 시작퇴근 시간을 1시간 정도 남겨두고 온보딩 가이드를 열심히 따라가던 중, 킹덤을 플레이하던 친구로부터 메시지를 하나 받았습니다.아직도 이 메시지를 받을 때의 기억이 생생합니다.뭔가 싶어서 킹덤을 켜보

안녕하세요, 저는 데브시스터즈 진저랩 인프라셀에서 데브옵스 엔지니어로 일하고 있는 이창원입니다. 지난 글인 쿠키런: 킹덤 런칭 회고에 이어 이번에는 런칭 후 4일 만에 기술적인 문제로 인해 발생했던 약 36시간 동안의 서비스 장애에 대해 전해드리려고 합니다. 여러 편의 글을 통해 다각도에서 이야기를 풀어드리고자 하는데, 이번 글에서는 서비스 장애의 원인과 해결 과정, 그리고 회고를 다루려고 합니다.Disclaimer이 이야기는 박새미님과 NDC22에서 공동 발표한 쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 - 그때 그 명검은 왜 뽑아야 했는가와 CockroachDB 고객사 컨퍼런스 행사인 Roachfest 세션에서 발표되기도 하였습니다. 보다 생동감 있게 혹은 짧은(?) 버전으로 일련의 이야기를 접하고자 하는 분들은 발표 영상을 보시는 것을 권해드립니다.데브시스터즈에서 어째서 CockroachDB라는 다소 생소한 데이터베이스를 사용하기로 결정했는지 이유나, 이 글을 읽으면서 CockroachDB의 내부 동작이나 설계가 궁금하신 분들은 CockroachDB in Production을 읽으시는 것을 추천합니다.지난 글에서…지난 글에서 여러 장치를 두어 <쿠키런: 킹덤>을 런칭했고, 첫 주말을 안정적으로 넘겼지만 모니터링 중에 사용자 수가 단조증가하여 스토리지 사용량이 크게 늘고 있었다는 이야기로 마무리되었는데요. <쿠키런: 킹덤>에서 사용한 CockroachDB가 배포되어 있는 리눅스 운영체제의 특성 상 디스크 공간이 가득 차게 되면 더 이상의 쓰기 작업이 불가능하게 됩니다. 이렇게 되면 당연하게도 사용자 상태의 변경사항을 기록하는 데이터베이스 본연의 기능을 할 수 없을 뿐더러, 분산 데이터베이스로써 변경사항을 여러 노드 간에 항시 복제, 전파하는 안전장치가 동작할 수 없게 됩니다. CockroachDB는 CP 시스템이므로 이런 경우 가용성, 즉 문제가 발생한 노드를 희생하여 데이터 일관성을 보존하도록 설계되어 있으며, <쿠키런: 킹덤>의 경우 7개의 복제본을 저장하도록 설정되어 가용성이 보장되지 않는 상태에서도 데이터 영향도가 가장 적도록 의도하였습니다.런칭 후 첫 주말을 보내고 월요일 오전 출근하여 클러스터 상태를 확인하니 사용자 인입이 현재 상태를 유지할 경우 위에서 묘사한 상황이 닥치기까지 약 36시간이 남은 것으로 계산할 수 있었습니다. 오픈 이후 유저 수는 단조증가하고 있었지만 마케팅은 서버 안정성이 확보된 이후에 집행하기로 결정되어 있던 상황이었습니다. 따라서 마케팅 집행이 시작되면 지금보다 더 가파른 규모로 유저가 증가할 수 있다는 사실을 인지하고 있었기 때문에 팀 내 위기감이 더욱 고조되었습니다. 당장 발등에 불이 떨어진 상황이기 때문에 저희는 여러 지표들을 따져보며 클러스터 규모를 얼마나 더 크게 키워야할지를 계산을 하는 동시에 공식 가이드를 따라 모든 노드에 Ballast 파일을 생성해두기로 결정했습니다.당시 사용 중이던 19.1.11 버전 공식 가이드에 적힌 내용.사실 파일 시스템이 가득 찰 경우 데이터베이스 쓰기