1편. Spring Boot 성능 튜닝 — 운영 서버에서 실제로 효과 본 방법

 

Spring Boot 성능 튜닝

🟦 1편. Spring Boot 성능 튜닝 — 운영 서버에서 실제로 효과 본 방법

운영 서비스에서 성능 문제는 보통 예고 없이 찾아온다.
어느 날, 특정 시간대에 API 응답이 갑자기 평균 100ms → 2~3초까지 치솟는 이슈가 발생했다.

단순 트래픽 증가로 보기엔 수치가 너무 컸다. 이상 징후를 확인하기 위해 APM을 열어보니, 가장 먼저 눈에 띈 것은 DB Connection Pool 대기 시간 증가였다. HikariCP 모니터링 그래프가 정확히 피크 시간대에 급격히 상승하고 있었고, 그 순간 전체 API의 응답 시간이 함께 늘어났다.

이런 문제는 개발·테스트 환경에서는 잘 드러나지 않기 때문에 운영 환경에서만 재현되는 케이스가 많다. 오늘은 실제 운영에서 겪은 이 이슈를 기준으로 Spring Boot 성능 튜닝 과정을 자세히 정리해본다.

---

■ 문제 1: HikariCP 커넥션 풀 고갈

✔ 어떤 현상이 발생했나?

• 연결을 빌려오는 데만 500ms 이상 걸림
• maxPoolSize 는 충분해 보이는데도 계속 풀 부족이 발생
• 특정 시간대에만 반복적으로 발생

HikariCP 로그를 DEBUG 수준으로 열어보니, 트래픽이 몰리는 순간마다 다음 메시지가 반복적으로 출력되고 있었다.

HikariPool-1 - Pool stats (total=40, active=40, idle=0)
HikariPool-1 - Timeout failure waiting for a connection.

즉 모든 커넥션이 사용 중(active=40) 이고, 반환이 늦어지면서 대기열이 쌓인 것이다.

---

● 원인 분석

1) DB 설정과 HikariCP maxLifetime 불일치

운영 DB(MySQL, MariaDB 등)는 보통 wait_timeout, interactive_timeout 설정 값이 있다.
이 값보다 더 오래 살아 있는 커넥션은 DB가 먼저 끊어버린다.
그런데 HikariCP는 DB가 커넥션을 끊은 줄 모르고 계속 사용하려다 Dead Connection 을 받게 되고, 이로 인해 재시도 및 대기가 발생한다.

테스트 결과:

• DB wait_timeout: 1800초(30분)
• Hikari maxLifetime: 1800000ms(30분) (기본값)

즉 둘이 정확히 같은 값이라 DB가 끊어버리는 타이밍과 거의 동일했다.

2) 트래픽 폭주 구간에서 세션이 오래 유지됨

특정 API는 다소 무거운 조회 쿼리를 수행하고 있었고, 이 API가 동시 다발적으로 호출되면서 커넥션 점유 시간이 길어졌다.

결과적으로:

• 평상시엔 문제 없음
• 피크 타임에만 접속 대기 증가 → 전체 API 지연

---

● 해결 방법

DB 설정을 먼저 확인하고, 이를 기준으로 HikariCP 설정을 조정했다.

spring:
  datasource:
    hikari:
      maximum-pool-size: 40
      minimum-idle: 10
      max-lifetime: 1700000   # DB wait_timeout 의 약 90%로 맞춤
      connection-timeout: 3000

✔ 설정 적용 후 효과

• 불규칙했던 dead connection 이 사라짐
• active pool 그래프가 안정적으로 유지됨
• 트래픽 피크 시간대 API 응답 2~3초 → 110~140ms로 회복
• APM DB 대기 구간 지연이 거의 0에 가깝게 감소

즉 HikariCP가 커넥션을 먼저 정리하고 재생성하도록 만드는 것만으로도 큰 효과를 보았다.

---

● 실전 팁 3개 (운영 환경 기준)

1. maxLifetime 은 반드시 DB wait_timeout 의 90%로 설정한다

• DB가 먼저 연결을 끊어버리면 애플리케이션이 장애를 맞는다.
• 커넥션은 “DB가 끊기기 전에” HikariCP가 먼저 제거해야 한다.

2. idleTimeout 은 maxLifetime 보다 항상 작아야 한다

• idle 상태의 커넥션도 적절히 재생성되도록 해야 한다.
• 일반적으로 idleTimeout ≈ maxLifetime 의 50~60% 수준이 안정적이다.

3. 풀 부족이라고 무조건 maximum-pool-size 를 늘리지 마라

대부분의 경우 root cause 는 다음 중 하나다:

• 느린 SQL
• 대량 JOIN
• 불필요한 쿼리 호출
• 트랜잭션 범위 과도하게 큼

즉 풀을 늘리는 것은 최후의 수단이고, SQL 튜닝이 오히려 더 큰 효과를 만든다.

---

🧩 마무리

Spring Boot 성능 튜닝은 단순히 설정 값을 바꾸는 것이 아니라
환경 전체(DB 설정 → Hikari 설정 → SQL → API 설계) 를 함께 고려해야 한다.

이번 글은 그중에서도 가장 많고 실제 운영에서 자주 발생하는 “HikariCP 커넥션 풀 고갈” 문제를 다뤘다. 다음 글에서는 Jackson 직렬화 튜닝, ThreadPool 조정 등 또 다른 실전 경험을 기반으로 더 깊은 내용을 다룰 예정이다.

---

🔖 TAGS

Java, SpringBoot, PerformanceTuning, HikariCP, DatabaseOptimization, ProductionIssue, BackendEngineering, RealWorldTips

🍃 Spring Boot 성능 튜닝 시리즈 (전 5편)

1. 1편 — 운영 서버에서 실제로 효과 본 방법 (현재 글)
2. 2편 — Jackson 직렬화 튜닝: 숨은 CPU 병목 해결
3. 3편 — ThreadPool & Tomcat 튜닝: 트래픽 폭주 대응
4. 4편 — DB 성능 모니터링과 SQL 튜닝 사례
5. 5편 — 운영 장애 사례 10선 + 장애 복구 플레이북