Incident Library

IL-0566 Devsisters · 2021-03-06databaseaws

쿠키런: 킹덤 길드 업데이트 직후 CockroachDB 노드 몇 대에 부하가 몰려 CPU가 100%에 이르고 게임에 에러가 났다

CockroachDB는 Primary Key를 정렬해 일정 간격으로 나눈 Range 단위로 데이터를 저장하고, 쿼리가 몰리는 Range는 스스로 나눠 여러 노드에 분산한다. 비슷한 키에 작업이 몰려 한 Range를 맡은 노드만 부하를 지는 것을 Hot Range라고 한다. 2021년 3월 6일 쿠키런: 킹덤 길드 업데이트 점검에서 팀은 새 길드 테이블의 Range를 미리 강제로 나눠 클러스터 전체에 분산했다. 며칠 전 물리 장비 문제로 빠진 데이터베이스 노드를 대신할 새 노드도 함께 추가했다. 점검은 11시에 끝났다.

근본 원인은 팀이 미리 알지 못한 인덱스 prefix 구조의 추가와 변경이었다. 분석용 데이터를 쓰는 테이블은 <feature>-<uuid> 형식의 Primary Key를 쓰는데, 출시 초기에는 튜토리얼 때문에 유저마다 쓰기 시점이 달라 미리 나누지 않아도 문제가 없었다. 길드 기능은 모든 유저가 기다리던 기능이라 업데이트 직후 guild-<uuid> 키가 한꺼번에 쓰였고, 자동 Split이 따라가지 못해 Hot Range가 생겼다. 리팩토링으로 Primary Key 형식이 바뀐 다른 테이블은 이미 나뉘어 있던 Range 중 극히 일부만 쓰게 돼 역시 Hot Range가 생겼다. 이 테이블들은 스키마 변경이 없어 눈에 띄지 않았고, 플레이 트래픽을 직접 받지 않아 Hot Range를 예상하지 못했다. 게다가 새 노드를 추가하며 생긴 Range 이동 작업이 Range 분할과 같은 Replication Queue를 썼고, 이 큐가 서비스를 열 때까지 비지 않아 Hot Range가 분산되지 못했다.

접속 대기열이 없었던 팀은 기존 유저를 내보내지 않고 새 로그인만 막는 방식으로 접속자 수를 조절했다. 오후 2시 50분 노드 여러 대가 health check를 통과하지 못하자 전체 긴급 점검에 들어갔고, 점검 직후 클러스터 상태가 눈에 띄게 좋아졌다. 전체 데이터베이스 백업이 멈추자 테이블 단위로 백업해 게임 데이터를 지켰다. 플레이 기록 저장을 멈추고 오후 6시 반쯤 문제 테이블을 Split했으며, 오후 7시 20분에 Host Status Check에 실패한 노드를 Decommission해 복제되지 않은 Range를 0으로 만들었다. 22시에 다시 연 뒤에도 노드 하나가 거듭 CPU 100%에 이르렀다. 팀은 노드 자체의 문제로 보고 그 노드를 종료해 문제를 끝냈다.

심각도
–
영향 범위
Cookie Run: Kingdom returned errors after the guild update, new logins were blocked for periods, and the game was in emergency maintenance from 14:50 until it reopened in the evening
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2021년 3월 6일 11시 길드 업데이트 점검을 마친 뒤 데이터베이스 CPU 사용량이 예상보다 조금 높았다. 11시 30분쯤 24코어 머신인 데이터베이스 노드 하나가 24코어를 모두 쓰며 CPU 사용량이 최대치에 이르렀고, 같은 시각 서버 지표에서 상당한 양의 에러가 보이기 시작했다. 곧 다른 두 노드에서도 CPU 사용량 이상이 나타났다.

점검 직후 CPU가 높았을 때 팀은 접속자가 평소보다 많고 유저끼리 상호작용하는 새 기능이 들어온 탓으로 보고 걱정할 일이 아니라고 판단했다. 노드 세 대가 과부하에 걸리자 팀은 부하가 노드에 고르게 나뉘지 않고 있다는 사실을 인정해야 했다.

로그인만 막아 접속자 수를 조절하자 클러스터가 꽤 안정됐지만, 오후 2시 50분 클러스터 노드 여러 대가 갑자기 health check를 통과하지 못했다. 점검 직후보다 더 많은 노드가 영향을 받았다. 클러스터가 불안정해지면서 CockroachDB가 데이터 정합성을 보증할 수 없어 접근을 막은 Unavailable Range도 생겼다.

전체 점검에 들어간 뒤 BACKUP statement로 전체 데이터베이스를 백업하려 했지만 백업이 어느 시점에서 멈췄다. CSV 파일로 export를 시도하자 지표상 클러스터가 불안정해져 중단했다.

오후 7시 20분쯤 데이터베이스 노드 한 대가 Host Status Check를 통과하지 못했다는 슬랙 알림이 왔다. 이상 로그를 감지하는 채널에는 같은 인스턴스에서 filemap_fdatawait_range_keep_errors 로그가 감지됐다는 알림이 왔다.

22시에 서비스를 다시 연 뒤에도 데이터베이스 노드 하나가 CPU를 100% 썼다. 대기열로 안정시켜도 같은 노드가 다시 CPU 100%에 이르기를 되풀이했다.

증상 부하 불균형데이터베이스 과부하오류율 상승

원인

원인 배포 결함

구성 요소 데이터베이스
기여 요인 미검증 가정장애 중첩
촉발
길드 업데이트 점검 뒤 서비스를 열자 모든 유저가 곧바로 새 기능을 썼고, 분석용 테이블에 guild-<uuid> 형식의 Primary Key가 매우 빠르게 쓰였다. 리팩토링으로 Primary Key 형식이 바뀐 테이블도 있었다.

감지

모니터링 중 한 노드의 CPU 사용량이 최대치에 이르렀다는 소식과 함께 서버 지표에서 에러가 관측돼 알았다. 이후 노드 문제는 Host Status Check 실패 슬랙 알림과 이상 로그 감지 채널의 알림으로 알았다.

조치

후속 조치

–

교훈

일반 RDBMS에서는 Primary Key prefix를 바꿔도 큰 문제가 되지 않지만, 분산 처리를 하는 CockroachDB의 프로덕션 클러스터에서는 이런 변경에 상당한 주의가 필요하다. 팀은 CockroachDB 스터디에서 문서와 자료를 읽어 이 내용을 알고 있었다. 그러나 직접 겪어 보니 글로 읽어 알던 것보다 훨씬 큰 일이었다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.