Incident Library

IL-0435 CyberAgent · 2026-04-02 (게시일)databaseawskubernetes

Aurora MySQL 이 OOM 을 피하려고 커넥션을 끊고 쿼리를 거부해 애플리케이션 오류율이 올랐다

CyberAgent 의 Service Reliability Group 이 지원하는 서비스에서 애플리케이션 오류율 알림이 울렸다. Aurora MySQL 3.04 의 오류 로그를 보니 Aurora MySQL 이 OOM 을 피하려고 커넥션을 끊고 쿼리를 거부하고 있었다. FreeableMemory 는 어느 날부터 계속 내려갔고 SwapUsage 도 뒤따라 올랐지만, CPU 사용률, AAS, 쿼리 수, 커넥션 수에는 변화가 없었다.

팀은 ANDPAD 기술 블로그에서 Performance Schema 때문에 FreeableMemory 가 줄어든 사례를 보고 Performance Schema 를 조사했다. Performance Schema 전체가 약 5.2GB 를 쓰고 있었고, 현재 값이 최대 사용량과 같아 아직도 늘고 있었다. 내역을 보면 host 별, account 별 요약이 대부분이었고, host 와 account 가 각각 약 16,000건이었다. 서로 다른 IP 주소에서 접속한 HOST 가 대량으로 기록되어 있었다.

원인은 그 릴리스에서 더해진 쿠버네티스 CronJob 의 매분 배치였다. 수명이 짧은 파드가 매번 새 파드 IP 로 DB 에 접속하면서 host 와 account 기록과 그 요약이 계속 쌓였고, Performance Schema 의 메모리 사용이 불어났다. FreeableMemory 가 줄고 SwapUsage 가 늘다가 결국 Aurora 가 OOM 을 피하는 동작으로 쿼리를 강제 종료했고, 애플리케이션 지연 시간이 나빠졌다. 팀은 파라미터 그룹에서 Performance Schema 를 수동 관리로 바꾸고 기본값이 무제한인 두 파라미터에 상한을 두어 문제를 풀었다.

심각도
–
영향 범위
Application requests failed and slowed while Aurora MySQL killed connections and declined queries
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

어느 날 갑자기 애플리케이션 오류율이 나빠졌다는 알림이 울렸다. 그 시간대 Aurora MySQL RDS 인스턴스의 오류 로그에는, Aurora MySQL 이 메모리 부족으로 OOM 이 나는 것을 피하려고 커넥션을 끊고 쿼리를 거부한 기록이 남아 있었다.

메트릭을 보니 어느 날을 경계로 FreeableMemory 가 꾸준히 내려가고 있었고, 시간차를 두고 SwapUsage 도 올라갔다.

DB 부하와 관련된 다른 지표에는 변화가 없었다. CPU 사용률은 한 달 범위로 봐도 크게 바뀌지 않았고, Database Insight 에서 본 최근 1주일의 평균 활성 세션 수 AAS 도 나빠지지 않았다. 슬로 쿼리 로그는 없었고, 쿼리 수와 커넥션 수의 추세도 그대로였다.

FreeableMemory 가 내려가기 시작한 날 애플리케이션 신기능 릴리스가 있었다는 것까지는 알았지만, 메모리 압박 말고는 오른 지표가 없어 원인을 좁히지 못했다.

증상 오류율 상승메모리 압박

원인

원인 용량 한계

구성 요소 데이터베이스잡과 크론잡
기여 요인 기본 설정 방치늦게 드러난 변경
촉발
FreeableMemory 가 내려가기 시작한 날의 애플리케이션 릴리스에서 쿠버네티스 CronJob 으로 매분 도는 배치 처리가 더해졌다.

감지

애플리케이션 오류율이 나빠졌다는 알림이 울렸다.

조치

후속 조치

–

교훈

시스템 알림이 울렸는데 DB 부하 지표가 조용하면 Performance Schema 가 불어난 것도 의심해야 한다. 상한을 둔 두 파라미터는 기본값이 무제한이라 이번처럼 기록이 계속 쌓였다. 상한을 두면 퍼포먼스 인사이트의 호스트별 집계에서 상한을 넘은 호스트의 정보가 빠지는 단점이 있다. 애플리케이션과 Aurora MySQL 사이에 RDS Proxy 를 두어 DB 에 접속하는 HOST 를 일정하게 유지하는 방법도 있다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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