사례2건

2건 중 1~2번째

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

   CyberAgent2026

   증상

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

   오류율 상승메모리 압박

   촉발

   FreeableMemory 가 내려가기 시작한 날의 애플리케이션 릴리스에서 쿠버네티스 CronJob 으로 매분 도는 배치 처리가 더해졌다.

   원인

   용량 한계

   구성 요소

   데이터베이스잡과 크론잡

   기여 요인

   기본 설정 방치늦게 드러난 변경

   감지

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

   조치

   • Aurora MySQL 파라미터 그룹에서 Performance Schema 를 자동 관리를 뜻하는 0 에서 수동 관리를 뜻하는 1 로 바꾸고, 기본값 -1 로 무제한이던 관련 파라미터 두 개에 상한 100 을 두었다. 적용에는 RDS 인스턴스 재시작이 필요했고, 이 조치로 FreeableMemory 감소와 SwapUsage 발생이 멈췄다.

   교훈

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

   사례 보기
2. IL-0373 EU 리전의 Heroku Postgres Essential 등급 데이터베이스가 메모리가 바닥나 두 번에 걸쳐 연결을 받지 못했다

   Heroku2024

   증상

   EU/Dublin 리전에 있는 Heroku Postgres Essential 등급 고객 일부가 데이터베이스에 연결하지 못했다. 상태 페이지는 영향받은 고객이 데이터베이스에 접근하면 out of memory 오류를 받는다고 알렸다.

   메모리 압박서비스 중단

   촉발

   제3자 업체가 메모리 누수가 있는 모니터링 변경을 배포했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스텔레메트리 에이전트

   기여 요인

   모니터링 사각지대

   감지

   첫 장애는 고객 지원 티켓으로 알았다. Heroku Support 가 7월 28일 07:50 UTC 에 고객 티켓을 받고 기술 팀을 호출했는데, 장애가 시작되고 9시간 19분 뒤였다. 둘째 장애도 Heroku Support 의 에스컬레이션과 고객 지원 티켓으로 알았다.

   조치

   • 첫 장애 때 자원을 더 배정하고 Heroku Postgres 클러스터를 재시작해 7월 28일 14:16 UTC 에 문제를 일시적으로 풀었다.
   • 둘째 장애 때 문제가 없는 제3자 서비스의 이전 버전을 프로비저닝하는 우회책을 적용했다. Postgres 데이터베이스 클러스터를 이전 안정 버전으로 바꾸자 메모리가 회수되어 클러스터가 건강한 상태로 돌아왔다.
   • 제3자 업체가 임시 완화책을 적용했다.

   후속 조치

   • 제3자 모니터링의 지표 수집을 강화했다.
   • 제3자 업체가 메모리 누수를 고친 모니터링 소프트웨어 새 버전을 내면, 기술 팀이 그 버전을 평가하고 괜찮으면 Heroku 고객에게 내보낸다.

   사례 보기

원인별2