JDBC 커넥션 풀 고갈 문제 해결기

 

🚨 문제 상황

• 증상: 레거시로 프로그램에 JDBC 커넥션을 못 잡아서 애플리케이션이 간헐적으로 터짐
• 환경: HikariCP 사용 중, MySQL max_connections = 10,000
• 의문: 커넥션 풀도 있고 MySQL 설정도 충분한데 왜?

🔍 원인 분석

1. 스레드 수 vs 커넥션 풀 크기 불균형

애플리케이션 스레드 구성:
├─ 스케줄러 스레드: 15개
├─ 비동기 스레드: 5-20개  
├─ SMS 워커 스레드: 3개
└─ LED 스레드: 3-10개
총 최대 48개 스레드

HikariCP 커넥션 풀: 15개 ❌
→ 스레드 수가 커넥션 풀보다 3배 많음!

2. 1분 스케줄러의 대량 개별 UPDATE

// 매 1분마다 2개 스케줄러 동시 실행
@Scheduled(cron = "0 0/1 * * * *")
public void startMethod2() { /* 자동퇴실, 스터디룸 관리 */ }

@Scheduled(cron = "0 0/1 * * * *") 
public void startMethod3() { /* 자습실 시간 스케줄 */ }

커넥션 폭증 시나리오:

매 1분 정각:
├─ 자동퇴실 50명 × 개별 UPDATE = 50개 커넥션
├─ 스터디룸 20개 × 개별 UPDATE = 20개 커넥션
├─ 기타 조회/업데이트 = 30개 커넥션
└─ 일반 웹 요청 = 10개 커넥션
총 110개 커넥션 동시 사용! (풀 크기: 15개)

3. 불필요한 SMS DB 설정

<!-- 사용하지 않는 SMS DB (커넥션 풀 없음) -->
<bean id="dataSource2" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <!-- 매번 새 커넥션 생성/해제 → 성능 저하 -->
</bean>

🚀 해결 방안

1. HikariCP 커넥션 풀 최적화

<!-- 기존 설정 -->
<property name="minimumIdle" value="3"/>
<property name="maximumPoolSize" value="15"/>
<property name="idleTimeout" value="30000"/>      <!-- 30초 -->
<property name="maxLifetime" value="1200000"/>    <!-- 20분 -->

<!-- 개선된 설정 -->
<property name="minimumIdle" value="10"/>         <!-- 안정적 기본 연결 -->
<property name="maximumPoolSize" value="50"/>     <!-- 스레드 48개 대응 -->
<property name="idleTimeout" value="600000"/>     <!-- 10분 -->
<property name="maxLifetime" value="1800000"/>    <!-- 30분 -->
<property name="leakDetectionThreshold" value="60000"/> <!-- 1분, 빠른 감지 -->

2. 배치 업데이트 도입

기존 방식 (N+1 문제):

for(int i=0; i<list.size(); i++) {
    // 개별 UPDATE (매번 커넥션 사용)
    params.put("querykey", "seat_power_state_update");
    params.put("power_number", powerNumber);
    params.put("power_state", "0");
    comService.simpleUpdate(params);  // 커넥션 1개 사용
}

개선된 방식 (배치 처리):

List<String> powerNumbers = new ArrayList<String>();

for(int i=0; i<list.size(); i++) {
    // 데이터만 수집 (커넥션 사용 안 함)
    powerNumbers.add(powerNumber);
}

// 한 번에 배치 업데이트 (커넥션 1개만 사용)
comService.batchUpdateSeatPowerState(powerNumbers, "0");

배치 UPDATE 쿼리:

<update id="seat_power_state_batch_update">
    UPDATE xe_tbl_seat 
    SET power_state = #{power_state}
    WHERE power_number IN 
    <foreach collection="power_numbers" item="power_number" open="(" close=")" separator=",">
        #{power_number}
    </foreach>
</update>

3. 사용하지 않는 SMS DB 설정 제거

<!-- 제거된 설정들 -->
<bean id="dataSource2">...</bean>
<bean id="sqlSessionFactory2">...</bean>
<bean id="transactionManager2">...</bean>
<bean id="sqlSession2">...</bean>

📊 성능 개선 결과

커넥션 사용량 비교

시나리오	기존	개선 후	개선율
자동 퇴실 50명	50개 UPDATE	1개 UPDATE	98% 감소
스터디룸 20개	20개 UPDATE	1개 UPDATE	95% 감소
업무 마감 100좌석	100개 UPDATE	1개 UPDATE	99% 감소
1분 스케줄러 전체	170개 커넥션	20개 커넥션	88% 감소

실제 SQL 실행 비교

-- 기존: 100개 좌석 처리 시
UPDATE xe_tbl_seat SET power_state = '0' WHERE power_number = '1';
UPDATE xe_tbl_seat SET power_state = '0' WHERE power_number = '2';
-- ... 100번 반복

-- 개선: 100개 좌석 처리 시  
UPDATE xe_tbl_seat SET power_state = '0' 
WHERE power_number IN ('1','2','3',...,'100');

🛡️ 안전한 적용 전략

배치 적용 기준

✅ 적용 가능

• 상태값이 명확하게 동일한 경우
• 로직이 단순한 경우
• 안전성이 보장되는 경우

❌ 적용 제외

• 상태값이 동적으로 계산되는 경우
• 복잡한 조건문이 있는 경우
• 기존 로직 변경 위험이 있는 경우

적용된 4가지 케이스

1. 자동 퇴실: 시간 만료 → 모두 OFF
2. 스터디룸 퇴실: 예약 종료 → 모두 OFF
3. 스터디룸 입실: 예약 시작 → 모두 ON ⭐
4. 업무 마감: 운영 종료 → 모두 OFF

🎯 핵심 교훈

1. 스레드 수와 커넥션 풀 크기의 관계

• 동시 실행 가능한 스레드 수 ≤ 커넥션 풀 크기
• 스케줄러, 비동기 작업 등 모든 스레드 고려 필요

2. 배치 처리의 위력

• N+1 문제 해결로 극적인 성능 향상
• 안전한 부분만 선별 적용해도 큰 효과

3. 모니터링의 중요성

• 커넥션 누수 감지 시간 단축 (5분 → 1분)
• 배치 처리 결과 로깅으로 효과 측정

💡 결론

"스레드 수를 고려한 커넥션 풀 크기 조정 + 선별적 배치 업데이트 적용"

• 스케줄러 실행 횟수는 그대로 유지
• 커넥션 사용량만 88% 감소
• 기존 기능 완전 보존
• 안정성과 성능 두 마리 토끼 모두 확보

결과: 커넥션 풀 고갈 문제 해결된거같으나 경과를 지켜봐야할꺼같다..