3편. ThreadPool & Tomcat 튜닝 — 트래픽 폭주 시 서버가 버티지 못하는 진짜 이유

 

ThreadPool & Tomcat 튜닝

🟦 3편. ThreadPool & Tomcat 튜닝 — 트래픽 폭주 시 서버가 버티지 못하는 진짜 이유

운영 서비스에서 트래픽이 갑자기 몰리면 가장 먼저 문제가 터지는 곳이 바로 ThreadPool이다.
DB나 캐시가 아무리 빨라도, Tomcat 스레드가 바닥나면 전체 서비스가 멈춰 버린다.

특히 금융권처럼 특정 시간(오전 9시, 점심 직전)에 트래픽이 폭발하는 서비스에서는
ThreadPool 튜닝이 장애 예방의 핵심이다.

이번 편에서는 실제 운영 환경에서 겪었던 Tomcat 스레드 풀 고갈 → API 전반 타임아웃 문제를 기준으로
어떻게 안정화 했는지 자세히 정리해본다.

---

■ 문제 3: Tomcat 스레드 풀 고갈로 전체 API 지연

특정 일자 오전 9시, 모든 API 응답이 갑자기 5~10초로 치솟는 현상이 발생했다.
APM과 서버 로그를 확인해보니 공통적인 원인은 다음과 같았다.

• Tomcat max-threads 고갈
• 요청이 큐에 쌓이며 대기 시간만 4초 이상 발생
• 일부 요청은 결국 503 Service Unavailable 발생
• 내부 API 호출까지 줄줄이 타임아웃

문제의 원인을 추적하기 위해 Thread Dump를 살펴보니
대부분의 Request Thread가 외부 API 응답을 기다리며 BLOCKED 상태에 있었다.

즉, “CPU가 부족한 게 아니라 스레드가 부족한 상황”이었다.

---

● 원인 분석

1) Tomcat 기본 스레드 수가 절대적으로 부족

Spring Boot 내장 Tomcat 기본값:

max-threads = 200

대량 트래픽이 몰리면 200은 금방 바닥난다.

2) slow API 하나가 전체 시스템을 멈춤

N개의 요청 중 단 1개의 API가 3초만 걸려도
그 스레드를 사용하는 모든 요청이 지연된다.

3) 비동기 처리 가능한 로직도 동기적으로 처리

예:

• 외부 알림 전송 API
• 로그 적재 API
• 등록/수정 이후 백오피스 알림

이런 것들이 모두 Request Thread를 통과하면 고갈이 빨라진다.

---

● 해결 방법

운영 환경에서 효과가 컸던 조치들을 순서대로 정리하면 다음과 같다.

---

✔ 1) Tomcat max-threads 튜닝

server:
  tomcat:
    max-threads: 400
    accept-count: 200
    min-spare-threads: 20

효과

• 동시 접속 요청 증가 구간에서도 스레드 고갈 방지
• 대기 요청(accept-count) 증가로 순간적인 트래픽 폭주에도 안정적으로 처리

---

✔ 2) 외부 API 호출은 반드시 별도 ThreadPool 사용

비즈니스 로직에서 외부 API를 호출하는 경우 다음과 같이 분리한다.

@Configuration
public class AsyncConfig {

    @Bean(name = "externalApiExecutor")
    public Executor externalApiExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(20);
        executor.setMaxPoolSize(50);
        executor.setQueueCapacity(200);
        executor.setThreadNamePrefix("api-executor-");
        executor.initialize();
        return executor;
    }
}

사용:

@Async("externalApiExecutor")
public void callExternalApi() {
    // 외부 알림, 웹훅 호출 등
}

효과

• 외부 API 응답 지연이 Tomcat Request Thread에 영향을 주지 않음
• 전체 API 응답 속도 안정화

---

✔ 3) CompletableFuture 로 병렬 처리

대량 조회 후 여러 부가 정보를 조합해야 할 때,
동기 호출을 병렬로 전환하면 응답 시간이 절반 이하로 줄어든다.

CompletableFuture<DataA> a = serviceA.getData();
CompletableFuture<DataB> b = serviceB.getData();

CompletableFuture.allOf(a, b).join();

return new Response(a.get(), b.get());

효과

• 스레드를 효율적으로 사용 → TPS 15~30% 증가
• 외부 API 조합형 응답의 성능 개선

---

✔ 4) Slow Request Trace 로 오래 걸리는 API 선제 파악

스레드가 “왜 오래 점유되는지”를 모르면 튜닝은 의미가 없다.
운영에서는 300~400ms 이상 걸리는 요청만 필터링하는 것이 효과적이다.

Spring Boot Filter 등록:

@Component
public class SlowRequestFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        long start = System.currentTimeMillis();
        chain.doFilter(request, response);
        long end = System.currentTimeMillis();

        if (end - start > 300) {
            log.warn("[SLOW] {}ms | URI={}", (end - start),
                    ((HttpServletRequest) request).getRequestURI());
        }
    }
}

효과

• “스레드를 잡아먹는 API”를 정확히 찾아 즉시 튜닝 가능

---

● 적용 후 성능 개선 효과

운영 서버 기준:

항목 개선 전 개선 후

Tomcat 스레드 고갈	자주 발생	거의 없음
순간 TPS	2,000 이하	4,000 이상
최대 응답 시간	10초 이상	300ms 이내
Error Rate	4%↑	0.1% 이하

특히 피크 시간(오전 9시)에 API가 전부 멈추던 장애가 완전히 사라졌다.

---

● 실전 팁 3개

1. max-threads 를 늘린다고 모든 문제가 해결되는 건 아니다

스레드를 잠가버리는 근본 원인(외부 API·DB 지연)을 먼저 해결해야 한다.

2. 외부 API 호출은 반드시 별도 ThreadPool 로 분리하라

가장 큰 체감 성능 향상을 주는 튜닝이다.

3. “300ms 이상 걸리는 요청”만 계속 추적하라

slow request 를 추적하면 대부분의 병목이 눈에 보인다.

---

🧩 마무리

ThreadPool 튜닝은 단순히 서버 스펙을 강화하는 작업이 아니다.
운영 환경에서는 작은 지연이 전체 시스템을 멈추게 만들 수 있다.

이번 편에서는 실제로 운영 장애를 해결했던
Tomcat 스레드 튜닝 + 비동기 분리 + 병렬 처리 구조 개편을 다뤘다.

다음 편에서는 DB 성능 모니터링 방식,
그리고 실제 운영에서 효과가 컸던 SQL 튜닝 사례를 다룰 예정이다.

---

🔖 TAGS

Java, SpringBoot, Tomcat, ThreadPool, Async, PerformanceTuning, BackendOptimization, HighTraffic, ProductionIssue, RealWorldTips

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

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