{"id":"IL-0435","org":"CyberAgent","date":"2026-04-02","docs":["https://tech.andpad.co.jp/entry/2025/12/24/100000"],"title":{"en":"Error rates rose as Aurora MySQL killed connections and declined queries to avoid OOM while load metrics stayed flat","ko":"Aurora MySQL 이 OOM 을 피하려고 커넥션을 끊고 쿼리를 거부해 애플리케이션 오류율이 올랐다"},"domain":["database","aws","kubernetes"],"impact":{"scope":"Application requests failed and slowed while Aurora MySQL killed connections and declined queries","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When system alerts fire but the database's load metrics look calm, Performance Schema growth is worth suspecting. The two parameters that were capped are unlimited by default, so connections from ever-changing source addresses keep adding to the records. Capping them has a cost: once the cap is exceeded, per-host figures in Performance Insights are missing. Putting RDS Proxy between the application and Aurora MySQL to keep source hosts stable is another possible measure.","ko":"시스템 알림이 울렸는데 DB 부하 지표가 조용하면 Performance Schema 가 불어난 것도 의심해야 한다. 상한을 둔 두 파라미터는 기본값이 무제한이라 이번처럼 기록이 계속 쌓였다. 상한을 두면 퍼포먼스 인사이트의 호스트별 집계에서 상한을 넘은 호스트의 정보가 빠지는 단점이 있다. 애플리케이션과 Aurora MySQL 사이에 RDS Proxy 를 두어 DB 에 접속하는 HOST 를 일정하게 유지하는 방법도 있다."},"related":[],"sources":[{"url":"https://ca-srg.dev/3354358b43f780758296fd51b761968f","kind":"blog","archived":"https://web.archive.org/web/20260625090240/https://ca-srg.dev/3354358b43f780758296fd51b761968f"}],"summary":{"en":"CyberAgent's Service Reliability Group traced an error rate alert to Aurora MySQL 3.04 avoiding OOM by killing connections and declining queries. FreeableMemory had been falling since a feature release while CPU, active sessions, slow queries, query counts and connection counts were unchanged. An ANDPAD article described Performance Schema lowering FreeableMemory after an upgrade from Aurora MySQL 3.04 (MySQL 8.0.28) to 3.10 (MySQL 8.0.42) changed default behaviour on some instances. This environment was on 3.04, so the case was not the same, but it pointed at Performance Schema.\n\nPerformance Schema as a whole was using about 5.2GB, with current use equal to the peak, so it was still growing. The largest consumers were the per-host and per-account summaries. There were about 16,000 hosts and about 16,000 accounts, and the accounts were filled with distinct source hosts recorded under different IP addresses. The release had added a per-minute Kubernetes CronJob whose short-lived pods connected from a new pod IP each time, so hosts and accounts, and the summaries kept for each, grew without end. FreeableMemory kept falling, SwapUsage rose, and finally Aurora's OOM avoidance killed queries.\n\nThe fix was in the Aurora MySQL parameter group: performance_schema changed from 0 (automatic management) to 1 (manual management), and two related parameters whose default is -1 (unlimited) were capped at 100. The new values take effect only after the RDS instance is restarted. After the change FreeableMemory stopped falling and swap use stopped.","ko":"CyberAgent 의 Service Reliability Group 이 지원하는 서비스에서 애플리케이션 오류율 알림이 울렸다. Aurora MySQL 3.04 의 오류 로그를 보니 Aurora MySQL 이 OOM 을 피하려고 커넥션을 끊고 쿼리를 거부하고 있었다. FreeableMemory 는 어느 날부터 계속 내려갔고 SwapUsage 도 뒤따라 올랐지만, CPU 사용률, AAS, 쿼리 수, 커넥션 수에는 변화가 없었다.\n\n팀은 ANDPAD 기술 블로그에서 Performance Schema 때문에 FreeableMemory 가 줄어든 사례를 보고 Performance Schema 를 조사했다. Performance Schema 전체가 약 5.2GB 를 쓰고 있었고, 현재 값이 최대 사용량과 같아 아직도 늘고 있었다. 내역을 보면 host 별, account 별 요약이 대부분이었고, host 와 account 가 각각 약 16,000건이었다. 서로 다른 IP 주소에서 접속한 HOST 가 대량으로 기록되어 있었다.\n\n원인은 그 릴리스에서 더해진 쿠버네티스 CronJob 의 매분 배치였다. 수명이 짧은 파드가 매번 새 파드 IP 로 DB 에 접속하면서 host 와 account 기록과 그 요약이 계속 쌓였고, Performance Schema 의 메모리 사용이 불어났다. FreeableMemory 가 줄고 SwapUsage 가 늘다가 결국 Aurora 가 OOM 을 피하는 동작으로 쿼리를 강제 종료했고, 애플리케이션 지연 시간이 나빠졌다. 팀은 파라미터 그룹에서 Performance Schema 를 수동 관리로 바꾸고 기본값이 무제한인 두 파라미터에 상한을 두어 문제를 풀었다."},"trigger":{"en":"An application release added a batch job run every minute by a Kubernetes CronJob. Each run's short-lived pod connected to the database from a new pod IP.","ko":"FreeableMemory 가 내려가기 시작한 날의 애플리케이션 릴리스에서 쿠버네티스 CronJob 으로 매분 도는 배치 처리가 더해졌다."},"severity":"unknown","symptoms":["high-error-rate","memory-pressure"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"An alert fired on the application's error rate.","ko":"애플리케이션 오류율이 나빠졌다는 알림이 울렸다."},"components":["database","job-controller"],"root_cause":"capacity","remediation":[{"text":{"en":"Set performance_schema to manual management and capped two related Performance Schema parameters, unlimited by default, at 100 in the parameter group, then restarted the RDS instance","ko":"Aurora MySQL 파라미터 그룹에서 Performance Schema 를 자동 관리를 뜻하는 0 에서 수동 관리를 뜻하는 1 로 바꾸고, 기본값 -1 로 무제한이던 관련 파라미터 두 개에 상한 100 을 두었다. 적용에는 RDS 인스턴스 재시작이 필요했고, 이 조치로 FreeableMemory 감소와 SwapUsage 발생이 멈췄다."}}],"action_items":[],"contributing":["default-config-unchanged","delayed-effect-change"],"recurrence_of":null,"symptoms_text":{"en":"An alert fired one day because an application's error rate had suddenly risen. The error log of the Aurora MySQL RDS instance for that time showed Aurora killing connections and declining queries to avoid running out of memory. The killed queries also made application latency worse.\n\nFreeableMemory had been falling steadily since one particular day, and SwapUsage rose some time later. Nothing else pointed at database load: CPU utilisation showed no large change over a month, average active sessions in Database Insight had not worsened over the last week, there were no slow query log entries, and query counts and connection counts showed no change in trend. The day FreeableMemory started to fall was the day of a new application feature release.","ko":"어느 날 갑자기 애플리케이션 오류율이 나빠졌다는 알림이 울렸다. 그 시간대 Aurora MySQL RDS 인스턴스의 오류 로그에는, Aurora MySQL 이 메모리 부족으로 OOM 이 나는 것을 피하려고 커넥션을 끊고 쿼리를 거부한 기록이 남아 있었다.\n\n메트릭을 보니 어느 날을 경계로 FreeableMemory 가 꾸준히 내려가고 있었고, 시간차를 두고 SwapUsage 도 올라갔다.\n\nDB 부하와 관련된 다른 지표에는 변화가 없었다. CPU 사용률은 한 달 범위로 봐도 크게 바뀌지 않았고, Database Insight 에서 본 최근 1주일의 평균 활성 세션 수 AAS 도 나빠지지 않았다. 슬로 쿼리 로그는 없었고, 쿼리 수와 커넥션 수의 추세도 그대로였다.\n\nFreeableMemory 가 내려가기 시작한 날 애플리케이션 신기능 릴리스가 있었다는 것까지는 알았지만, 메모리 압박 말고는 오른 지표가 없어 원인을 좁히지 못했다."},"updated_at":"2026-11-14T12:34:08.488344Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0435","org_slug":"cyberagent"}