Incident Library

IL-0574 Safie · 2026-10-27 (게시일)awsdatabase

운영 환경의 DB 접속 경로를 Amazon RDS Proxy로 바꾼 지 몇 분 만에 Aurora MySQL writer CPU가 100%에 이르고 에러가 났다

Safie의 플랫폼은 여러 마이크로서비스가 같은 Aurora MySQL에 읽고 쓰는 구조이고 쓰기 트랜잭션 비중이 크다. max_connections를 최대치인 16,000까지 쓸 수 있는 인스턴스 클래스로 이미 올렸는데도, 이용자가 늘며 커넥션 수가 계속 늘었다. 팀은 많은 클라이언트 커넥션을 적은 수의 DB 커넥션으로 묶는 RDS Proxy를 넣기로 했다. SHOW PROCESSLIST로 커넥션 출처를 집계해 MaxConnectionsPercent 21%, MaxIdleConnectionsPercent 10%, ConnectionBorrowTimeout 7초로 정했다. 스테이징에서 1주일쯤 돌렸을 때 커넥션 수 감소 같은 기대한 변화는 보이지 않았지만, 애플리케이션 동작에 문제가 없어 운영 환경에 배포했다.

엔드포인트를 바꾸고 몇 분 뒤 에러 알림이 울렸고, 팀은 바로 ECS Fargate 태스크를 이전 버전으로 되돌렸다. 실제 커넥션 수요는 약 7,600개였는데 Proxy가 Aurora에 열 수 있는 상한은 16,000의 21%인 약 3,360개였다. 나머지 약 4,200개는 Proxy에서 커넥션을 빌리려고 기다렸다. 대기 시간과 애플리케이션 소켓 타임아웃이 같은 7초여서, 대기가 풀리기 전에 애플리케이션이 먼저 접속을 끊고 새로 접속했다. MySQL은 새 커넥션을 처리할 때마다 CPU를 썼다. CPU가 포화되자 접속이 더 늦어지고 타임아웃이 더 늘어나는 악순환이 이어졌다.

팀은 스테이징 스냅샷으로 만든 검증용 Aurora에 Locust로 부하를 걸어 같은 장애를 재현했고, MaxConnectionsPercent를 62%로 올리자 사라지는 것을 확인했다. 이후 Flipt 피처 플래그로 조회 요청부터 비율을 나눠 옮겼다. 그 과정에서 두 문제를 고쳤다. 하나는 애플리케이션의 커넥션 풀이 커넥션을 반납할 때마다 세션을 리셋해 Proxy가 커넥션을 재사용하지 못하던 문제였다. 다른 하나는 Aurora의 wait_timeout 120초가 Proxy가 빌려준 커넥션을 끊던 문제였다. 그러나 Proxy가 한 번 연 커넥션을 유휴 예비 커넥션으로 계속 쥐고 있어 Aurora writer의 커넥션 수는 오히려 약 5,000개 늘었다. 매시 정해진 시각에 커넥션이 급증하는 탓에 예비 커넥션을 줄일 수도 없어, 팀은 RDS Proxy 도입을 접었다.

심각도
–
영향 범위
The platform services that use the main Aurora MySQL database returned errors until the rollback
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

운영 환경의 엔드포인트를 RDS Proxy로 바꾸고 몇 분 뒤 사내 알림 모니터링 시스템에서 에러 알림이 울렸다. Aurora writer의 CPU 사용률은 거의 100%에서 내려오지 않았다.

CloudWatch 지표에서 새 접속 시도 수인 ConnectionAttempts는 평소 1만 미만이던 것이 최대 264,000까지 올랐고, 끊긴 클라이언트 수인 AbortedClients는 258,000이었다.

팀은 처음에 RDS Proxy에서 커넥션이 pinning되는 현상을 의심했다. 그러나 실제로 pinning된 커넥션은 전체의 1% 정도여서 원인으로 보기 어려웠다.

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

원인

원인 설정 변경

구성 요소 데이터베이스 프록시와 커넥션 풀러데이터베이스
기여 요인 재시도 폭주스테이징 불일치단계적 배포 부재
촉발
운영 환경의 Aurora MySQL 접속 엔드포인트를 RDS Proxy로 바꿨다. Proxy는 MaxConnectionsPercent 21%로 Aurora에 커넥션을 약 3,360개만 열 수 있었고, ConnectionBorrowTimeout은 애플리케이션 소켓 타임아웃과 같은 7초였다.

감지

운영 환경의 엔드포인트를 RDS Proxy로 바꾸고 몇 분 뒤 사내 알림 모니터링 시스템이 에러 알림을 냈다.

조치

후속 조치

교훈

이번 장애와 이후의 문제는 RDS Proxy의 버그가 아니었고, Proxy를 끼우면서 애플리케이션 커넥션 풀의 구현과 설정에 있던 문제가 드러난 것이었다. Proxy를 끼우면 백엔드 커넥션을 여러 클라이언트가 나눠 쓰므로, 세션 상태가 같은지, 트랜잭션이 닫혔는지, 커넥션이 DB 쪽 수명 안에 있는지가 모두 재사용 조건이 된다. 도입 전에는 Proxy 설정 값보다 애플리케이션 커넥션 풀이 커넥션을 반납할 때 무엇을 실행하는지, 커넥션 수명을 어떻게 정하는지, 접속할 때 무엇을 보내는지를 확인했어야 했다. 타임아웃과 상한은 애플리케이션, Proxy, 데이터베이스 순으로 아래 계층일수록 같거나 길게 맞춘다. 엔드포인트만 바꾸는 한 번의 전환은 실패하면 모든 서비스에 한꺼번에 번지므로 단계적으로 옮겨야 한다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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