이 글과 관련된 다른 글 보기
- 쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
- CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
- 쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
- CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
- 입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
- 쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기
안녕하세요, 데브시스터즈 진저랩 인프라셀에서 데브옵스 엔지니어로 일하고 있는 이상유입니다.
지난 NDC22의 쿠키런 킹덤: 총 56시간의 긴급 점검 회고를 보셨던 분이라면, 그 당시 시간 관계로 미처 이야기하지 못했던 주제가 하나 있었다는 것을 기억하실 것이라고 생각합니다.
이 글에서는 바로 그 주제, 21년 3월 길드 업데이트 이후 발생했던 서비스 이슈에 관해 다루고자 합니 다.
Hot Range(혹은 Hot Spot)
이전에 게시된 글을 읽어보신 분들이라면,
- 쿠키런: 킹덤은 CockroachDB라는 데이터베이스를 사용하고 있다
- CockroachDB는 SQL 인터페이스를 제공하는 분산 데이터베이스이다
- 분산 처리와 고가용성을 위해, CockroachDB는 데이터를 쪼개 ‘Range’라는 단위로 저장한다
는 부분을 이미 알고 계실 것입니다.
혹 이전 게시글을 읽어보지 않으셨더라도, 위 3개 내용을 알고 계신다면 이 글을 무리없이 이해하실 수 있도록 구성했습니다. CockroachDB에 대해 더 깊게 알아보고 싶으시거나, 데브시스터즈에서 어째서 CockroachDB를 사용하도록 결정했는지 궁금하신 분은 CockroachDB in Production을 읽어보시기를 추천합니다.
CockroachDB는 Range별 용량과 초당 쿼리수를 종합해 자율적으로 Range를 병합하거나 분리합니다. 초기 설정에서 Range 용량은 128MB에서 512MB 사이를 유지하도록[1], 그리고 Range에 초당 2500쿼리 미만의 요청이 가해지도록[2] 설정되어 있습니다. 때문에 CockroachDB 클러스터를 관리하다 보면, 쿼리가 자주 일어나는 Range는 알아서 잘 분산되어 여러 노드에서 작업을 처리하고, 쿼리가 자주 일어나지 않는 Range는 합쳐지는 동작을 관측할 수 있습니다.
이러한 동작 덕분에, 부하가 장기간에 걸쳐 점진적으로 늘어나는 경우에는 관리자가 CockroachDB 클러스터에 대해서 해주어야 할 동작은 많지 않습니다. CPU나 메모리, 스토리지와 같은 리소스가 부족한 경우, 이에 맞춰 새 노드를 추가해주면 CockroachDB 클러스터에서 우아하게 Range를 분산하여, 모든 노드가 비슷한 양의 데이터와 부하를 처리하도록 조절합니다.
하지만 이런 아름다운 그림이 모든 상황에서 그려지는 것은 아닙니다. CockroachDB에서는 Primary Key를 go의 빌트인 인코딩/디코딩 메소드를 사용하여 정렬한 뒤 일정 간격으로 나누어 Range를 만들어냅니다[3]. 이러한 알고리즘에 따라 유사한 키 값은 동일하거나 인접한 Range에서의 작업이 될 가능성이 높으며, 이렇게 대부분의 워크로드가 몰린 Range를 Hot Range 또는 Hot Spot이라고 합니다.
Hot Range는 결과적으로 해당 Range를 관할하는 노드들에서만 전체 부하를 처리하는 결과를 초래해, 클러스터가 제 성능을 낼 수 없도록 만들게 됩니다.
이러한 배경 지식을 가지고, 장애가 발생한 날로 떠나 보겠습니다.
[05:00] 길드 업데이트
길드 기능 업데이트 점검에서, 쿠키런: 킹덤의 데이터베이스 클러스터에는 2가지 작업이 진행되었습니다.
첫째로 길드 기능에서 사용하는 테이블을 추가하고, 사전에 부하를 분산하도록 설정하였습니다. 길드 기능에서 사용하는 테이블들은 아직 CockroachDB가 부하를 분산할 수 있는 정보를 가지고 있지 않기 때문에, 서비스 오픈 직후 길드 기능에서 사용하는 테이블에서 Hot Range가 발생할 가능성이 높습니다. 이를 미연에 방지하기 위해, 길드 관련 테이블들의 Range를 강제로 분할하고, 이를 클러스터 전체에 나누어주도록 작업하였습니다.
둘째로 당시 점검 며칠 전 데이터베이스 노드 한 대가 물리 장비 이슈로 제거된 상태였는데, 새 노드를 추가하여 데이터베이스 규모를 원래 의도한 규모로 복원하였습니다. 길드 업데이트를 위해 점검이 필요했고, 이를 위해 데이터베이스 백업 등 안전한 작업에 필요한 제반 준비가 되어야 하는 상황이었기에, 이 기회를 틈타 함께 작업을 진행하였습니다.
점검 중 인프라 외적인 사유로 점검이 2시간가량 연장되었으나, 2021년 3월 6일 11시, 모든 문제를 해결하고 점검이 마무리되었습니다. 이후 모니터링 중, 데이터베이스의 CPU 사용량이 예상보다 조금 높다는 것을 확인했으나 당시 접속중인 유저가 평시보다 많은 점, 그리고 새롭게 상호작용하는 기능이 추가되었다는 것을 고려했을 때 우려하지 않아도 될 것으로 판단했습니다.
[11:30] 불길한 신호는 항상 현실이 되고
그렇지만 우려하지 않아도 된다는 것이 특별한 조치를 취하지 않아도 된다는 것이지, 마음을 놓을 수 있다는 의미는 아니죠. 많은 유저분들이 새 업데이트를 즐겨주시고 있다는 것에 기뻐하며 서버 상태를 지켜보던 중, 굉장히 슬픈 소식이 들려오고 맙니다.
그것은 바로 한 노드의 CPU 사용량이 천장을 찍었다는 소식이었습니다. 이와 동시에 서버 지표에서도 유의미한 양의 에러가 관측되기 시작했습니다. 모두가 탄식하며 일시적인 현상이기를 기도하던 그때, 야속하게도 다른 두 노드에서도 CPU 사용량 이상이 확인되었습니다.
모종의 이유로 로드가 고르게 분배되지 않고 있으며, 이 때문에 특정 노드가 과도한 로드로 데이터베이스 클러스터 안정성에 악영향을 주고 있다는 사실을 받아들여야 하는 순간이었습니다.
저희가 무엇을 잘못했나요
이야기를 더 진행하기 앞서, 무엇이 이런 상황을 만들었는지 정리해 봅시다.
근본적인 원인은 저희가 사전에 인지하지 못한 인덱스의 prefix 구조 추가와 변경이었습니다.
쿠키런: 킹덤의 게임 서버는 실제 플레이 데이터 이외에도, 더 나은 플레이 경험을 위한 데이터 분석을 위해 여러 가지 정보를 DB에 기록합니다. 이 때 사용되는 테이블은 용도에 따라 <feature>-<uuid> 형식의 Primary Key를 가집니다. 이 테이블은 런칭 초기에도 Split을 하지 않았었고, 그 상태로도 문제가 발생하지 않았기 때문에 명시적인 Split이 필요없는 테이블로 여겨졌습니다.
나중에 알고 보니, 런칭 초기에는 모든 유저들이 게임 시작 후 거치는 튜토리얼이 거대한 Funnel로 작용해 유저들이 이 테이블에 쓰기를 하는 시점이 제각각 달랐고, 이 덕분에 Hot Range 없이 자동적인 Split이 자연스럽게 수행될 수 있었습니다. 이와 달리 길드 업데이트의 경우 모든 킹덤 유저가 기다려오던 기능이었고 초기 Funnel 또한 거의 없도록 설계되었습니다. 따라서 업데이트 직후 모든 유저들이 이 테이블에 쓰기 활동을 하게 되어 아주 많은 수의 guild-<uuid> 형식의 Primary Key가 매우 빠르게 쓰여졌고, 결과적으로 시스템에 의한 Split이 미처 수행되지 못해 Hot Range가 발생한 것이 첫번째 원인이었습니다.
두번째로, 신규 기능이 추가되며 코드 리팩토링이 진행되었고, 겸사겸사 Primary Key의 형태가 변경된 경우도 있었습니다. 이 테이블의 경우 기존에 활발하게 쓰이고 있었고 Split도 잘 되어있었지만, PK의 포맷이 달라지면서 Split되어 있던 Range의 극히 일부만 실제로 사용되도록 변경되었고, 이 또한 마찬가지로 Hot Range를 발생시켰습니다.
종합적으로 이 테이블들은 1. 기존에 이미 존재하던 테이블이고, 스키마 변경이 없었기 때문에 잘 눈에 띄지 않았고, 2. 플레이에 직접적인 트래픽을 받지 않기 때문에 Hot Range 가 발생할 것이라고 미처 판단하지 못했습니다.
그러나 여기까지만 해도 상황이 심각해지지는 않았을 수도 있습니다. CockroachDB에는 자체적인 부하 기반 Range 분산 로직이 있기 때문에, 시간이 지남에 따라 클러스터가 자가 회복하기를 기대해볼 수 있기 때문입니다.
이 문제를 더욱 키운 것은 새 DB 노드를 추가한 것이었습니다. CockroachDB는 새 노드를 클러스터에 추가하는 경우 기존 노드들이 가지고 있던 Range를 자동으로 분산하여, 모든 노드들이 비슷한 양의 작업을 할 수 있도록 만들고자 시도합니다. 이 때 Range가 이동하는 작업은 기존 Range를 분할하여 이동시키는 작업과 같은 큐를 사용합니다. 점검 중에 새 노드가 추가되며 발생한 Replication Queue가 오픈 때까지 충분히 해소되지 않았고, 새 노드에 Range들이 모두 분산된 뒤에야 Hot Range가 분산될 수 있었습니다.
정리하면, 사전에 부하를 분산하지 않은 테이블에서 Hot Range가 발생하여, CockroachDB에서 부하 분산을 시도했으나 노드 추가로 트리거된 Range 분할로 인해 해당 부하를 분산하지 못하였고, 이로 인해 DB가 과부하되어 발생한 문제였습니다.
[11:55] 점검만은 안 돼
하지만 이번 문제는 앞서 게시된 두 번의 이슈[4]와는 조금 달랐습니다. 이전의 상황은 데이터베이스가 데이터 로드를 거부했거나 데이터를 검증해줄 수 있는 서버 자체가 사라져 데이터의 정합성을 검증하지 못한 문제로, 이를 복구하기 위해 데이터베이스를 종료하고 storage layer에서 데이터를 조각모음 하는 등의 액션이 필요했습니다. 하지만 지금은 단순히 데이터베이스의 일부 노드에 일시적으로 과도한 부하가 가해져 CockroachDB 내부 로직이 동작할 시간이 부족한 것이어서 이 부하만 해결되면 상황이 호전될 것으로 기대되었습니다.
이러한 기대를 안고, 저희는 이제 점검 없이 서버에 가해지는 부하를 줄일 수 있는 방법을 찾기 시작했습니다.
다만 문제는, 저희가 선택할 수 있는 방법이 많지 않다는 점이 었습니다. 순간적인 부하를 줄이기 위해서 사용하는 가장 일반적인 방법은 접속 대기열을 운영하는 것인데, 쿠키런: 킹덤의 서버 아키텍처는 수평적인 확장이 가능하도록 특히 많은 고민과 노력을 기울인 만큼 접속 대기열이 필요할 상황 자체가 존재하지 않아야 했기에 대기열이 마련되어 있지 않았습니다. 그렇다면 유저 접근을 제한할 수 있는 방법은 점검뿐인데, 점검 없이 서버에 가해지는 부하를 줄인다는 고민과는 공존할 수 없는 방법이었습니다.
이러지도 저러지도 못하고 시간이 지나가던 중, ‘점검이 아닌 점검을 하자’라는 의견이 나왔습니다.
[13:00] 점검 아닌 점검
쿠키런: 킹덤의 점검은 새로 접속하는 유저의 접속을 거부하는 부분과, 이미 게임을 플레이중인 유저를 강제로 접속 종료시키는 부분이 완전히 분리되어 존재합니다. 이 아래부터는 전자를 ‘로그인 블록’, 후자를 ‘유저 킥’으로 표현하겠습니다.
일반적인 점검 때에는 로그인을 블록한 뒤 기존 유저를 킥하는 동작을 함께 진행하지만, 두 동작은 앞서 언급한 대로 분리되어 존재하기 때문에 따로 실행하는 것 또한 가능합니다.
접속 대기열은 기본적으로 유저의 접속을 인위적으로 제한하면서, 동시에 원하는 만큼만 유저가 접속할 수 있도록 만드는 기능입니다. 킹덤의 점검에도 로그인하는 유저만 블록할 수 있는 방법이 존재합니다. 그럼 점검을 대기열처럼 사 용할 수 있지 않을까요?
기존 유저를 킥하지 않고 로그인을 블록하는 것으로, 입장 인원을 0명으로 설정한 대기열과 같은 효과를 낼 수 있습니다. 이렇게 되면 이미 게임에 접속해 플레이하던 유저는 아무런 영향을 받지 않으면서, 서버에 가해지는 부하를 적절한 수준으로 관리할 수 있습니다. 접속에 성공한 유저가 게임에 접속하여 하려던 행동을 모두 완료하면 게임을 종료할 것이므로, 새로 게임에 접속하려는 유저를 제어하면 동시 접속자는 자연적으로 감소할 수밖에 없기 때문입니다.
그렇다고 계속 로그인을 블록하면 안 됩니다. 우리가 원하는 것은 대기열 기능으로, 유저분들이 기다리다 보면 어느 순간 게임에 접속되어 플레이하는 경험을 기대하기 때문입니다. 걸어둔 점검을 종료하면, 기다리시던 유저 분들께서 게임에 접속할 것이고, 지표를 참고하며 이를 반복하면 결국 동시에 원하는 만큼만 유저가 접속할 수 있도록 하는 대기열의 역할을 수행할 수 있게 됩니다. 점검이라는 방법을 사용하여 서비스 점검을 피한, ‘점검 아닌 점검’인 셈입니다.
이렇게 임시로 만든 대기열을 가지고 동시 접속자 수를 조절한 결과, 데이터베이스 클러스터가 상당히 안정되는 것을 확인할 수 있었습니다. 우아한 방법은 아니지만, 아무도 쿠키런: 킹덤에 접속하지 못하는 상황을 만들지 않고도 장애 상황을 해결할 수 있을 것이라는 희망이 보이기 시작했고, 이대로 지켜보며 클러스터 상황이 정상으로 돌아오기를 기다리자고 결정하게 되었습니다.
[14:50] 진짜 긴급점검
그렇게 안정화 작업을 진행하던 중, 오후 2시 50분, 클러스터를 구성하는 노드 여러 대가 갑자기 health check를 통과하지 못하기 시작했습니다. 이 때는 점검 직후 상황과 비교했을 때 더 많은 노드들이 영향을 받았고, 때문에 이 이상 문제가 전파된다면 데이터 안정성에도 영향이 갈 수 있다고 보여졌습니다. 때문에 클러스터가 불안정해진 직후, 긴급히 아무도 게임을 플레이할 수 없는 진짜 긴급점검을 수행하기로 결정했습니다.
점검을 시작한 직후부터 클러스터 상태가 눈에 띄게 좋아지는 것을 확인할 수 있었습니다. 당연한 결과이기도 했는데, 문제의 원인이 Hot Range에 있다고 예상된 이상 더 이상 유저 요청을 받지 않는다면 문제가 되는 Range를 사용하지도 않을 것이기 때문입니다. 다만 이를 실제로 확인함으로서 저희가 정의한 문제 상황과 해결 방법이 맞을 것이라는 확신을 가질 수 있었습니다.
하지만 그렇다고 이 클러스터를 그대로 계속 쓸 수 있다는 확신은 없는 상태였습니다. 클러스터가 불안정해지며 CockroachDB에서 데이터 정합성을 보증할 수 없어 접근 자체를 막은 Unavailable Range가 발생했고, 클러스터가 안정되며 해당 Range가 다시 접근 가능하다고 표시되었지만 이 클러스터에 문제가 발생하지 않을 것이라고 확답할 수 없었기 때문입니다. 여전히 데이터베이스의 여러 지표들은 클러스터가 아직 완전히 정상으로 되돌아오지 않았다고 말하고 있었고, 이전의 경험을 바탕으로 더욱 더 신중히 의사결정을 하고자 하였습니다.
일련의 데이터베이스 연관 장애를 겪으면서 저희 팀의 목표는 늘 유저 분들이 정성들여 키우신 소중한 왕국의 데이터를 지키는 것이었습니다. 언제 무너질지 모르는 데이터베이스 클러스터를 지켜보며, 저희는 우선 클러스터가 조금이라도 안정적일 때 데이터를 백업해 두기로 결정했습니다. 정기적으로 백업이 진행되고 있지만 실시간 백업이 아닌 이상 이는 최후의 수단이고, 점검 이후 데이터를 백업해 두면 클러스터가 돌아올 수 없는 강을 건너더라도 유저 임팩트는 없을 것이니까요. 백업 이후에 클러스터가 완벽히 정상화되어 백업한 데이터를 쓸 필요가 없으면 더 좋고요.
[15:05] 미션: 데이터 백업하기
그렇지만 저희의 간절한 마음을 아는지 모르는지, CockroachDB 클러스터는 데이터 백업을 거부했습니다. CockroahchDB의 BACKUP statement를 사용해 전체 데이터베이스 백업을 시도했으나, 백업이 진행되다 어느 시점에 멈춰버리는 것을 볼 수 있었습니다. 혹시나 알 수 없는 문제 때문에 BACKUP 구문이 동작하지 않는 것일까 싶어 CSV 파일로 export도 시도해 보았으나, 지표상으로 클러스터가 불안정해지는 것을 확인해 중단했습니다.
이때 점검 시간이 길어진 주 원인이 바로 이 백업이 진행되지 않는 문제 때문이었습니다. 클러스터 상태가 불안정한 것이 눈에 보이는데 백업을 안 하고 방치하는 것은 선택지가 되지 않습니다. 그렇다고 백업을 하니 백업이 과연 완료되기는 할지, 된다면 얼마나 기다려야 할지 알 수 없는 상황이었습니다.
어떤 방법을 사용해야 안전하게 데이터를 백업할 수 있을지 찾아내던 중, 전체 데이터베이스가 아닌 테이블 단위 백업을 시도해 보자는 의견이 나왔습니다. 높은 부하가 걸린 것은 특정 테이블의 일부 Range였기 때문에, 이와 관련없는 다른 테이블은 문제없이 백업이 될 것이라는 가설으로부터 도출된 의견이었습니다. 또한 이때 문제가 되는 테이블은 다른 테이블의 정보를 바탕으로 복구 가능한 테이블이었기에, 다른 더 중요한 테이블을 백업할 수 있다면 이 테이블 또한 자연적으로 백업되었다고 볼 수 있는 점도 이러한 결정에 힘을 실어 주었습니다.
정말 다행히도 이 방법을 통해 킹덤 게임 데이터의 백업에 성공했습니다. 이 방법이 동작한다는 것을 확인한 뒤에는, 일단 필요한 모든 테이블을 테이블 단위로 백업한 뒤 클러스터 안정을 기다린 다음 서비스를 오픈하고, 서버에 일정 수준 이상의 부하가 가해질 경우 킥 없는 점검을 통해 부하를 조절하는 것으로 서비스 오픈 계획을 세울 수 있었습니다.
백업 중 진행도가 우려스러울 정도로 올라가지 않는 경우도 몇 번 있었으나, CockroachDB 서포트 팀의 도움으로 무사히 백업을 마칠 수 있었습니다.
이제 손에 데이터를 들고 있기 때문에, 클러스터에 조금 더 도전적인 작업을 시켜볼 수 있게 되었습니다. 이제는 클러스터가 완전히 사용 불능이 되더라도 백업 데이터에서 복원하면 데이터 손실은 없을 것이니까요.
[18:35] 오픈 준비하기
서비스 오픈을 준비하며, 플레이 기록을 남기는 것은 일시 중지하기로 결정했습니다. 문제가 발생하는 원인은 규명되었고, 오픈 전 해당 테이블의 split을 진행하기로 했으나, 이와 별개로 최대한 데이터베이스에 부하를 가하지 않기 위해 진행한 조치였습니다.
하지만 예측되는 부하를 줄인다고 해도 쿠키런: 킹덤을 플레이해주시는 유저분들이 많다면 Range 분리는 다시 발생합니다. 그리고 앞선 경험을 기반으로, 우리는 이것이 일어나야 하는, 방해받으면 안 되는 작업임을 잘 알고 있습니다.
때문에 이 이후 오픈 준비는
- 문제가 되었던 테이블이 모두 잘 Split되어 모든 노드에 골고루 로드가 분산되며
- CockroachDB의 Range Replication Queue가 0이 되어, 오픈 후 Range Split이 발생하더라도 방해받지 않도록
만드는 것에 초점을 맞추게 되었습니다.
그렇게 오후 6시 반 경, 문제가 되었던 테이블에 대해 Split 액션을 수행하기 시작했습니다[5].
[19:20] 좋은 노드, 기다리는 노드, 떠나간 노드
메트릭을 지켜보며 Split이 완료되기를 기다리고 있던 중, 오후 7시 20분 경 슬랙 알림이 한 건 날아옵니다.
바로 데이터베이스 노드 한 대가 Host Status Check를 통과하지 못했다는 알림이었습니다. 이 알림이 발생했을 때 운이 정말 좋지 않은 경우 EC2 인스턴스 자체가 대응할 시간 없이 셧다운되는 상황까지 가는 경우가 있지만, 이 때는 인스턴스가 셧다운되는 상황은 아니었습니다.
동시에 서버들의 이상 로그를 감지하는 채널에 한 메시지가 날아왔는데요, 해당 인스턴스에서 filemap_fdatawait_range_keep_errors라는 로그가 감지되었다는 알림이었습니다.
리눅스 커널에서 filemap_fdatawait은 Write-back Page를 다시 디스크에 작성하는 계통의 메소드인데요, 지금 Range를 옮기고 분리하는 것과 같이 디스크 Write 작업이 많은 상황에서 이러한 로그가 보인다는 것은 좋은 징조는 아니었습니다. Host Status Check이 실패했으니 이 인스턴스 자체도 신뢰할 수 없어졌다는 것 또한 문제가 되었습니다.
때문에 저희는 이 노드를 클러스터에서 제거하기로 결정하고, Range 분리와 이 노드의 Decommission을 함께 진행했습니다. 이 노드의 Decommission이 완료되면서 복제되지 않은 Range는 0이 되었고, 클러스터의 각종 지표 또한 안정적인 상태로 돌아왔습니다.
[22:00] 대망의 오픈
데이터베이스 클러스터가 정상으로 돌아온 것처럼 보였어도 마음을 놓기에는 넘어야 할 산이 조금 더 있었습니다. 우선 점검이 끝나기만을 기다리던 유저 분들이 한꺼번에 게임에 접속하실 것이 자명했고, 로그인 보너스를 수령하기 위해 12시경 접속하는 유저 분들이 매우 많을 것인데다, 이렇게 많은 트래픽이 흘러들어갔을 때 데이터베이스가 안정적일지는 지켜보아야만 알 수 있었습니다.
모든 엔지니어들이 숨죽여 지켜보는 가운데 점검이 종료되었고, 서버는 트래픽을 잘 받아내는 것처럼 보였습니다. 그냥 그렇게 트래픽을 잘 받아내서 처리해줬으면 더할 나위 없이 좋았겠으나, 현실은 그렇지 않았습니다. 또 한 데이터베이스 노드에서 CPU를 100% 사용하는 것이 확인되었고, 다시 대기열을 통해 노드의 CPU 사용량을 안정시켰습니다.
이 때까지는 한 두 노드가 상태 회복을 위해 이럴 수 있다고 판단할 수 있는 내용이었는데, 이 뒤 얼마 지나지 않아 정확히 해당 노드가 다시 CPU를 100% 사용하기 시작했습니다. 몇 차례 대기열을 활용해 트래픽을 제어했으나, 문제가 발생하는 노드가 같다는 점에서 노드 자체의 문제일 가능성이 높아졌고, 결국 이 노드를 종료시킴으로서 문제 상황이 모두 해결되었습니다.
몸으로 체득한 경험
일반적으로 RDBMS에서 Primary Key의 Prefix의 변경은 큰 문제가 되지 않습니다. 작업이 한 대의 서버에서만 처리되기 때문에 애초에 분산 처리를 상정하지 않는 이유도 있지만, RDBMS의 인덱스 자료형이 Prefix의 구조 변화에 크게 영향을 받지 않기 때문이기도 합니다.
하지만 CockroachDB의 분산 처리 특성상, 프로덕션 클러스터에서 이러한 변경이 가해지는 것은 상당한 주의가 필요한 작업임을 체득할 수 있었습니다. 팀 내에서 CockroachDB 스터디를 진행하며, 문서와 관련 자료들을 리뷰하며 충분히 알고 있던 내용이었지만, 실제 체험은 글로 얻은 정보에 비해 훨씬 큰 사건이었습니다.
마무리하며
이렇게 킹덤 런칭 초창기의 점검 이야기는 모두 마무리됩니다.
이 당시 상황을 돌아보면, 많은 유저분들이 쿠키런: 킹덤을 사랑해주신 덕분에 전사적으로 처음 맞이해보는 규모의 트래픽을 다루게 되었고, 이 큰 트래픽을 잘 다루기 위해 끊임없이 노력을 기울이던 때였던 것 같습니다. 저희 예상보다 훨씬 더 많은 분들께서 쿠키런: 킹덤을 좋아해주셨고, 때문에 이에 맞추어 정말 많은 것을 개선하고 보수해야 했던, 정말 쏜살같이 빠르게 지나간 시간이기도 했습니다.
하지만 그런 환경 속에서도, 어떤 챌린지가 닥쳐왔을 때 타협하는 대신 최고의 고객 경험을 위해 끊임없이 다양한 방법을 시도하고 길을 찾아내는 것은, 데브시스터즈의 모든 구성원이 각자의 분야에서 이러한 노력을 뒷받침할 수 있는 경험과 스킬을 가지고 있기 때문에 가능했던 일이 아닐까 싶습니다.
긴 이야기의 끝까지 함께해 주셔서 감사합니다.
[1]: https://www.cockroachlabs.com/docs/v22.2/configure-replication-zones#replication-zone-variables
[2]: https://www.cockroachlabs.com/docs/v22.1/load-based-splitting
[3]: https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-table-data-to-key-value-storage/
[4]: 쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기, 쿠키런: 킹덤 AWS AZ 장애 아웃라인
[5]: 이 오퍼레이션에 관해 더 자세히 알고 싶으시다면 CockroachDB in Production의 Production 배포시 고려해야 할 사항 > Range Split을 참고해주세요