Tomcat 스레드 풀과 HikariCP 커넥션 풀의 병목 구조

부하 테스트를 진행한 이유

• 요청 처리량이 선형적으로 증가하는지

• p95 응답시간이 어느 시점부터 급격히 상승하는지

• 실패율 없이 처리되더라도, 내부 대기열이 쌓이기 시작하는 임계 구간은 어디인지

• 로그인(Login): 가장 빈번한 요청, 실패율 증가는 곧 서비스 장애로 직결

• 회원가입(Sign-up): 배포 초기·축제 기간 전후로 급증 가능 (INSERT, 중복 검사 등으로 상대적으로 DB 부하가 큼)

RPS 40 → 60 → 80 구간 테스트 지표

RPS 60부터 무너지는 응답 시간

• 어떤 지점에서 지연이 발생하는지

• 병목이 애플리케이션 레이어인지, DB 레이어인지

• DB 관점에서 어떤 쿼리와 자원이 한계에 도달하는지

첫번째 부하 테스트 (maxPool : 30)

스레드 풀 & HikariCP 커넥션 풀 자원 상태

• tomcat_threads_current가 200 (max-threads) 에 도달

• RPS는 40 수준이지만, 동시에 대기·실행 중인 요청 수가 급증하면서 스레드 풀이 먼저 포화

• 동일 시점에 hikaricp_connections_pending이 최대 150까지 증가

• Tomcat 스레드가 확보 되었으나, DB 커넥션 풀이 한계에 도달하여 커넥션 획득 대기 발생

트래픽 & 응답 지연 지표

• Response Time p95 (http_req_duration) : 클라이언트가 요청을 보내고 응답을 받을 때까지의 전체 시간

• HTTP Server p95 : 서버가 내부에서 요청을 처리하는데 걸린 시간

기능 단위 응답 지연

DB & 시스템 상태 (아직까지 병목 아님)

• Active Connections: 3~5 수준

• TPS: ~110

• PG Block I/O Time: ≈ 0

• Cache Hit Ratio: ≈ 1.0

예상되는 병목의 원인

[가설] HikariCP maxPool=30이 병목의 시작점이다.

• 커넥션을 즉시 확보하지 못한 요청은 Pending 상태로 전환

• 해당 요청을 처리 중인 Tomcat 스레드는 커넥션 반환을 기다리며 블로킹

[가설] DB 커넥션 대기가 Tomcat 스레드 풀 포화를 유발한다.

• Tomcat의 max-threads=200 이 모두 점유

• 이후 유입된 요청은 큐 대기 또는 타임아웃

2번째 부하 테스트 (maxPool : 30 → 50) : 커넥션 풀을 늘리면 Pending이 줄고, 스레드 반환이 빨라질 것이다.

• maxPool을 늘렸지만 Pending은 여전히 높음

• DB에서 커넥션 반환이 지연되며 Tomcat 스레드 포화가 해소되지 않음

3번째 부하 테스트(maxPool: 50 → 100) : Pending 자체를 충분히 처리할 수 있을 정도로 Pool 확장

• Pending은 줄었지만, 부하 구간에서는 여전히 Active + Pending이 함께 증가

• Tomcat 스레드와 HikariCP가 동시에 포화

• 이는 쿼리 처리 시간 또는 트랜잭션 점유 시간이 여전히 길다는 신호

4번째 부하 테스트 (max-threads: 200 → 350) : Pending 완화 → 스레드 수가 처리량 한계인지 검증

• 부하 시점에도 Tomcat max-threads(350)에 도달하지 않음

• 반면, HikariCP Active / Pending은 지속적으로 증가

• Idle 커넥션은 부하 시작 직후 거의 0으로 수렴

• 스레드는 병목이 아니였다. 스레드 풀을 늘렸음에도, 실제 사용 중인 스레드는 상한선에 도달하지 못하였다. DB I/O 대기로 인해 스레드가 오래 점유되고 있음을 알 수 있다.

• 커넥션 Pending이 재증가 하였고, 커넥션 점유 시간이 늘어났다.

• idle 커넥션이 0이라는 것은, 풀에 여유 커넥션이 없고 모든 커넥션이 장시간 점유 중이라는 의미

병목은 여전히 DB Connection Pool과 DB 처리량 이였다.

5번째 부하 테스트(스레드 수 유지, maxPool 100 → 200)

• Idle 커넥션이 부하 초반 즉시 소진

• Active + Pending이 동시에 크게 증가

• maxPool을 200으로 늘렸음에도 Pending 다수 유지

왜 Max Connections 값을 올렸음에도 처리량이 내려갔을까?

• 동시에 더 많은 쿼리가 DB로 유입

• DB CPU / Lock / 내부 리소스 경합 증가

• DB 처리량은 늘지 않았는데 부하만 증가

6번째 부하 테스트(스레드 수 유지, maxPool 200 → 150)

• DB 과부화 완화

• 쿼리 응답 속도 개선

• 전체 p95 및 실패율 감소

마지막 테스트(스레드 수 유지, maxPool 150 → 130)

• Idle → Active 전환 후 Pending(파랑)이 급격히 치솟음 → 커넥션 풀 부족으로 요청이 대기

• DB 처리 대기시간이 길어지면서 전체 응답 지연 및 실패율 상승

• 150 → 130으로 줄였을 때 Pending 대기열 급증

왜 maxPool 150에서는 괜찮았고, 130에서는 무너졌을까?

그러면, 아까 maxPool=200에서는 왜 처리량이 낮았을까?

결론 및 테스트를 통해 알게된 점

• 130은 과도한 큐 대기 때문에 지연과 실패율 모두 악화

• 150 커넥션 풀이 현재 RPS에서의 안정성과 성능의 균형점

• 200은 오히려 DB 부하를 높였고, 150이 가장 효율적인 선택으로 보임

HikariCP 커넥션 풀의 역할

요청 → (대기열) → DB 커넥션 → 쿼리 실행 → 커넥션 반환
// 커넥션 = 동시에 DB에 접근할 수 있는 티켓
// maxPool = 동시에 실행 가능한 DB 작업 수의 상한

스레드풀과 커넥션풀의 관계

DB 커넥션 풀이 먼저 병목이 된 이유

• 커넥션 풀이 작으면 → 요청 큐 대기 증가 → 요청 스레드 점유(Blocking)

• 커넥션 풀이 너무 크면 → DB 과부하 및 처리 속도 저하 → 커넥션 반환 늦어짐 → 요청 스레드 점유(Blocking)

• Thread Pool ≥ Connection Pool

• 그러나 Thread Pool ≫ Connection Pool은 의미 없음

개선 방향을 어떻게 잡으면 좋을까 ?

1. Fail-Fast 전략 — Connection Timeout 최적화 (큐 대기 시간 제어)

spring:
  datasource:
    hikari:
      maximum-pool-size: 150    
      connection-timeout: 5000 
  // 30초 -> 5초 (Fail-Fast)
  // 5초 이내에 커넥션을 획득하지 못하면 즉시 SQLTransientConnectionException 발생

2. 커넥션 점유 시간 최소화 — Pool을 늘리지 않으면서 처리량 올리기

3. 유입량 제어 — Backpressure / Rate Limiting 도입

// Controller나 Filter에서 적용
public Response handleRequest() {
    if (bucket.tryConsume(1)) { // 토큰이 있을 때만 통과
        return service.process();
    } else {
        // DB가 비명을 지르기 전에 여기서 쳐냄
        throw new RateLimitException("시스템 부하가 많습니다. 잠시 후 시도해주세요.");
    }
}

요청 → [유입 제어] → DB
        ↑
     초과 요청 즉시 차단 

location / {
    # 요청 수 제한 적용 (버스트 20개까지 허용, 노딜레이)
    limit_req zone=api_limit burst=20 nodelay;
    
    # 동시 연결 수 제한 적용 (IP당 10개)
    limit_conn addr_limit 10;
		...

• limit_req: IP당 초당 10회 요청(10r/s)으로 제한하며, 순간적인 버스트는 20개까지 허용

• limit_conn: IP당 동시 연결 수를 10개로 제한하여 커넥션 점유를 방지

resilience4j:
  bulkhead:
    instances:
      paymentBulkhead:
        maxConcurrentCalls: 140
        maxWaitDuration: 0  //  대기 없이 즉시 429 에러 반환 (Backpressure)

@ExceptionHandler(io.github.resilience4j.bulkhead.BulkheadFullException.class)
public ResponseEntity<Response<Void>> handleBulkheadFullException(
        io.github.resilience4j.bulkhead.BulkheadFullException ex) {
    log.warn("Bulkhead is full: {}", ex.getMessage());
    return ResponseEntity
            .status(HttpStatus.TOO_MANY_REQUESTS)
            .body(Response.fail(Code.TOO_MANY_REQUESTS));
}