Incident Library

IL-0488 Kit · 2022-12-24databaseaws

EBS 성능 저하 뒤 Kit의 RDS MySQL 쓰기 지연이 100배 넘게 늘어 Sidekiq 작업 처리가 느려졌다

Kit은 AWS us-east-2 리전의 RDS에서 MySQL을 Multi-AZ 고가용성 구성으로 운영한다. 2023년 7월 기준으로 크기는 13.75TB, 인스턴스는 db.r6g.16xlarge다. 2022-12-23 오후 9시 50분 EST에 AWS RSS 피드가 use2-az1 가용 영역의 EC2와 EBS 성능 저하를 알렸고, MySQL 프라이머리가 그 가용 영역에 있었다. AWS가 24분 만에 해결됐다고 표시했고 서버를 여러 가용 영역에 두고 있어 팀은 크게 신경 쓰지 않았다.

다음 날 오전 5시 20분 EST에 MySQL 실행 중 스레드가 9에서 900으로 뛰었다는 호출이 왔다. 당번 엔지니어는 먼저 가장 많이 밀린 Sidekiq 큐를 살폈지만 원인을 찾지 못했고, 더 파고들어 RDS 쓰기 지연이 약 1.5ms에서 150~300ms로 늘어난 것을 찾았다. 쓰기가 느려 Sidekiq 작업 처리가 늦어졌고, 큐가 밀리면서 redis 메모리가 빠르게 차올랐다. 오전 8시 33분 EST의 장애 조치 시도는 세컨더리가 동기화되지 않은 상태여서 타임아웃으로 실패했다.

팀은 RDS가 EBS 위에서 돈다는 점에서 전날의 EBS 성능 저하가 원인이라고 판단했다. AWS가 보낸 포스트모템에 따르면 2022-12-24 02:12:47 UTC에 LSE라고 적힌 사건이 일어나 replaceSecondaryHostAndVolumesTask가 돌았고, 이 작업이 스탠바이 볼륨을 프라이머리 스냅숏으로 다시 만들었다. 새 볼륨의 first touch penalty 때문에 쓰기 I/O 지연이 1~2ms에서 140ms로 늘었다. 스토리지를 12.5TB에서 13.75TB로 10% 늘리자 RDS가 optimizing storage 상태를 거치며 쓰기 지연이 1~2ms로 돌아왔고, AWS 기록으로는 15:05 UTC 무렵 안정됐다. 그 뒤 큐가 비고 redis 메모리도 안전한 수준으로 돌아왔다. 서비스는 느려졌지만 멈추지는 않았다.

심각도
–
영향 범위
Kit's RDS MySQL primary and the Sidekiq job processing that depends on it slowed for several hours; the service never stopped
영향 사용자
–
지역
us-east-2 (use2-az1)
감지까지
46m
복구까지
5h 22m

증상

2022-12-24 오전 5시 20분 EST에 MySQL 실행 중 스레드 수가 9에서 900으로 100배 뛰었다는 첫 호출이 왔다. 크리스마스이브 새벽이라 트래픽이 아주 적은 시간이었다.

Sidekiq 큐가 밀리기 시작했고, 그중 한 큐가 다른 큐보다 훨씬 많이 밀려 있었다. Kit은 한 달에 Sidekiq 작업을 약 50억 개, 초당 약 2,000개 처리하고, 대부분의 작업이 MySQL을 쓴다.

RDS MySQL의 쓰기 지연이 약 1.5ms에서 약 150ms로, 많게는 300ms까지 100배 넘게 늘어 있었다. AWS 내부 조사로는 WriteLatency가 2022-12-24 09:34 UTC부터 14:56 UTC까지 높았다.

큐에 쌓인 작업이 Sidekiq이 쓰는 redis의 메모리를 빠르게 채웠다. 작업을 넣는 속도가 처리 속도보다 빠르면 redis가 메모리 부족으로 죽고 쌓인 작업을 잃게 되는 상황이었다.

처음에는 새로 배포한 코드가 큐 하나에 나쁜 영향을 줬다고 보고 가장 많이 밀린 큐를 살폈지만, 그 큐에서는 원인이 될 만한 것을 찾지 못했다. 전날 밤 9시 50분 EST에 AWS RSS 피드가 use2-az1 가용 영역의 EC2 인스턴스와 EBS 볼륨 성능 저하를 Slack으로 알렸고 MySQL 프라이머리가 그 가용 영역에 있었지만, AWS가 24분 만에 해결됐다고 표시해 팀은 넘어갔다.

오전 8시 33분 EST에 스탠바이로 장애 조치를 시도했지만 실패해 데이터베이스는 원래 인스턴스에 그대로 남았고, 쓰기 지연은 수백 ms에 머물렀다. AWS 조사에 따르면 세컨더리가 프라이머리와 동기화되지 않은 상태여서 장애 조치가 타임아웃됐다.

증상 데이터베이스 과부하처리량 저하

원인

원인 클라우드 제공자 장애

구성 요소 데이터베이스클라우드 블록 스토리지데이터베이스 복제
기여 요인 초기 신호 무시
촉발
스탠바이 서버의 EBS 중단으로 RDS가 replaceSecondaryHostAndVolumesTask를 실행해 스탠바이의 호스트와 볼륨을 교체했다. 새 볼륨은 프라이머리 볼륨의 스냅숏으로 다시 만들어져 AWS가 first touch penalty라고 부른 쓰기 지연이 있었고, 동기 복제 때문에 프라이머리의 쓰기 지연이 함께 늘었다.

감지

2022-12-24 오전 5시 20분 EST에 MySQL 실행 중 스레드 수 급증 알림이 당번 엔지니어를 호출했다. 원인이 된 EBS 성능 저하는 전날 밤 AWS RSS 피드 알림으로 Slack에 들어왔지만 그때는 넘어갔다.

조치

후속 조치

–

교훈

AWS Multi-AZ는 동기 복제로 데이터 정합성과 내구성을 지키지만, 모든 트랜잭션을 스탠바이에도 커밋해야 하므로 스탠바이의 EBS 볼륨이 나빠지면 쓰기 지연도 나빠진다. 데이터베이스가 클수록 이런 일에서 회복이 오래 걸린다. 단일 AZ였다면 이번 일은 영향이 없었겠지만, 영향을 받은 가용 영역에 서버가 있었다면 몇 시간 동안 멈췄을 것이다. 운영 RDS의 배치 방식을 정할 때는 이런 득실을 따져야 한다. RDS와 EBS가 어떻게 동작하고 Kit에 어떤 영향을 주는지 이해하는 것이 중요했다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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