Incident Library

IL-0567 Devsisters · 2023-09-05 (게시일)databaseaws

쿠키런: 오븐브레이크의 패키지 매출 랭킹 기능을 배포한 뒤 Aurora MySQL CPU가 100%에 이르러 유저가 게임에 접속하지 못했다

2022년 8월에 추가된 쿠키런: 오븐브레이크의 패키지 매출 랭킹은 판매 중인 패키지의 지난 N시간 매출을 집계해 순위를 보여주는 기능이다. 구매 기록을 담은 AWS Aurora MySQL 테이블에 구매 시점 정보가 없어 purchase_dt 칼럼과 인덱스를 추가해야 했다. 일반 ALTER TABLE은 table lock을 잡는다. 게다가 이 테이블은 서비스 시작 이후의 모든 구매 기록을 담은 큰 테이블이라 2시간 점검 안에 끝내기도 어려웠다. 그래서 팀은 online alter를 택했다. lock을 잡지 않는 inplace algorithm은 테스트 서버 Database 복제본에서 첫 시도에 ERROR 1062 (23000): Duplicate entry '73817' for key 'PRIMARY' 오류로 실패했다. MySQL 공식 문서가 이를 간헐적으로 생기는 한계라고 설명하고 있어, 팀은 이 방식을 쓰지 않기로 했다. 대신 Percona Toolkit의 pt-online-schema-change를 Staging 복제본, Production 복제본, Staging, Production 순서로 시험하고 적용했다. Production 복제본에서는 CPU를 45% 정도로 유지하는 chunk-size 250을 골랐고, Production 적용은 문제 없이 끝났다.

기능 배포 당일 CPU가 조금 오른 데 이어, 버그 픽스를 더 배포하고 유저를 재접속시키자 CPU가 100%에 이르러 Database 접속이 실패했다. 팀은 서버 점검을 걸고, 랭킹 기능을 끄고 켤 수 있는 설정을 급히 넣어 꺼 둔 뒤 서비스를 정상화했다. 원인은 두 가지였다. 첫째, 쿼리가 product_id와 purchase_dt를 함께 조건으로 쓰는데도 둘을 묶은 인덱스가 없었고, 매번 바뀌는 현재 시각이 조건에 있어 Database가 최적화하기 어려웠다. composite index는 개선 폭이 10% 정도에 그쳐 넣지 않았다. 대신 판매 시작 시간이 같은 상품의 조건을 묶고 현재 시각 조건을 지운 쿼리로 바꿨다. 둘째, AWS autoscaling group으로 수평 분산된 서버마다 게임데이터 버전별로 캐시를 따로 만들어, 쿼리가 분산 서버 수 곱하기 게임데이터 가짓수만큼 실행됐다. 서버를 업데이트하면 캐시가 빈 서버가 늘어 부하가 더 커졌다.

팀은 스케줄러 서버가 모든 서버의 요청을 모아 주기적으로 쿼리하고 결과를 원격 저장소에 캐싱하는 공용 캐시를 만들었다. 각 서버는 Database 대신 원격 저장소의 결과를 읽는다. 이후 랭킹 기능을 다시 켰을 때 CPU는 스케줄러 서버의 작은 피크 말고는 안정적으로 유지됐다.

심각도
–
영향 범위
Cookie Run: OvenBreak players could not log in to or play the game while database connections failed
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

패키지 매출 랭킹 기능을 배포한 뒤 버그 픽스를 몇 차례 더 배포하고 유저를 재접속시키자 Database 알람이 울렸고, Database CPU 그래프가 100%에서 내려오지 않았다. Database 접속에 문제가 생기면서 유저들이 게임에 정상적으로 접속하거나 플레이할 수 없었다.

배포 직후에는 평소 20% 정도이던 CPU가 10~20% 정도 올랐다. 개발자는 새 기능에 넣은 쿼리의 영향이라는 것을 알아챘지만, 아직 큰 문제는 아니라고 보고 함께 배포한 다른 기능의 문제부터 고쳤다.

각 서버는 게임데이터 버전마다 캐시를 따로 만들기 때문에, 서버를 업데이트하면 캐시가 빈 서버가 늘어 같은 집계 쿼리가 한꺼번에 많이 실행됐다. 개발 환경에서는 결제 데이터가 적어 쿼리가 빨랐고 분산 서버 수도 적어 이 문제가 드러나지 않았다.

증상 데이터베이스 과부하서비스 중단

원인

원인 배포 결함

구성 요소 데이터베이스
기여 요인 비효율적인 쿼리데워진 캐시에 기댄 구조스테이징 불일치
촉발
새 패키지 매출 랭킹 기능의 집계 쿼리가 들어간 배포 뒤 버그 픽스를 추가로 배포하고 유저를 재접속시키면서, 캐시가 빈 서버들이 이 쿼리를 한꺼번에 실행했다.

감지

버그 픽스를 추가로 배포하고 유저를 재접속시킨 뒤 Database 알람이 울려 CPU 그래프를 보고 알았다.

조치

후속 조치

–

교훈

무거운 쿼리와 분산 서버의 캐시 구조가 겹치면 예상하지 못한 문제가 생기므로, 문제가 될 만한 지점을 미리 파악해야 한다. 장애가 나면 원인 파악보다 서비스 정상화가 먼저다. 문제가 되는 기능을 끄고 켤 수 있는 안전장치를 미리 만들어 두면 서비스를 더 안정적으로 운영하는 데 도움이 된다. Production 환경의 online alter에는 Percona Toolkit 같은 유용한 툴을 잘 활용하는 것이 중요하다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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