Aurora MySQL Signal 11 Crash 분석과 Spring Boot 커넥션 오류 대응 전략

개요

2025년 3월 26일, AWS Aurora MySQL 환경에서 Signal 11로 인해 데이터베이스가 비정상 종료되는 장애가 발생했습니다. 이와 동시에 Spring Boot 기반의 배치 애플리케이션에서는 커넥션 풀 오류로 애플리케이션 구동 실패가 발생했으며, 이 글에서는 그 원인과 해결 방안을 상세히 정리합니다.

장애 타임라인 요약

시각 자료 1 – RDS 커넥션 수 변화 그래프

설명: 장애 직전 커넥션 수가 급증하면서 3,000에 근접했고, 비정상 종료 이후 재시작 완료까지 커넥션 수가 0으로 떨어졌다가 회복되는 모습을 시각화한 그래프입니다.

문제 쿼리 (샘플 변환)

WITH past_order AS (
  SELECT ord.user_id,
         IFNULL(SUM(ord.order_count), 0) > 0 AS has_past_orders
    FROM (
      SELECT u.user_id, o.order_count
        FROM user_table u
   LEFT JOIN LATERAL (
          SELECT COUNT(*) AS order_count
            FROM order_table o
           WHERE o.user_id = u.user_id AND o.status = 'COMPLETED'
           ORDER BY o.created_at
           LIMIT 1
        ) o ON u.user_id = o.user_id
    ) ord
GROUP BY ord.user_id
)
SELECT COUNT(*) FROM past_order;

시각 자료 2 – 쿼리 흐름도

LATERAL JOIN, LIMIT, JSON 기반 계산이 포함된 복합 쿼리 흐름을 시각적으로 정리

Spring Boot 에러 요약

Failed to obtain JDBC Connection
SQLTransientConnectionException: Connection is not available
Communications link failure

• RDS가 종료되면서 기존 커넥션이 모두 끊김
• HikariCP는 죽은 커넥션을 재사용하려다 실패
• 이에 따라 Spring Batch는 JobRepository 초기화 실패 → 애플리케이션 기동 불가

대응 전략

Spring Boot 측 설정 개선

spring:
  datasource:
    hikari:
      maximum-pool-size: 10
      connection-timeout: 30000
      validation-timeout: 5000
      keepalive-time: 300000
      connection-test-query: SELECT 1

• keepalive-time과 connection-test-query는 상황에 맞게 병행 설정 가능
• 비정상 커넥션 탐지 및 제거를 위한 필수 설정

시각 자료 3 – Spring Boot + HikariCP 구조도

Spring Boot 내에서 HikariConfig → HikariDataSource → 커넥션 풀로 이어지는 흐름을 설명

Aurora 측 점검 포인트

• DB 인스턴스 스펙 대비 커넥션 수 과다 여부
• max_connections, Threads_connected 실시간 모니터링
• 엔진 버전 버그 여부 확인 (특히 LATERAL JOIN 관련 Known Issue)

결론

필요 시 AWS Support를 통한 core dump 분석 또는 RDS Proxy 도입 고려

복잡한 JSON 기반 조건 + LATERAL JOIN 조합은 일부 Aurora 버전에서 Optimizer 오류 또는 메모리 풀 충돌을 유발할 수 있음

Spring Boot에서는 DB 비정상 종료에 대비해 Hikari 설정을 보완하고, DB 재접속 복원 전략을 명확히 해야 함