스레드 풀(Thread Pool) 고갈 시 요청 대기열의 무한 증가 위험

증상 확인: 서버가 갑자기 응답을 멈추나요?

서비스가 정상적으로 운영되다가 특정 시점 이후로 갑자기 응답 속도가 극도로 느려지거나, 아예 응답 자체가 없는 상태가 지속됩니다. 사용자 입장에서는 ‘로딩 중’ 화면만 보이거나 ‘연결 시간 초과’ 오류를 마주하게 됩니다. CPU와 메모리 사용률은 정상 범위에 있지만, 애플리케이션 로그에는 스레드 생성 관련 오류나 대기열이 가득 찼다는 경고 메시지가 빈번하게 기록됩니다. 이는 스레드 풀(Thread Pool)의 모든 작업 스레드가 고갈되고, 들어오는 요청들이 무한정 대기열(Queue)에만 쌓이는 위험한 상태입니다.

원인 분석: 왜 스레드 풀이 고갈되는가

스레드 풀은 서버가 효율적으로 동시 요청을 처리하기 위한 핵심 메커니즘입니다. 풀에 미리 생성해 둔 유한한 개수의 스레드(Worker Thread)가 작업(Task)을 할당받아 실행합니다. 문제는 이 작업이 끝나지 않고 장시간 블로킹(Blocking)될 때 발생합니다, 특히, 느린 외부 api 호출, 데드락(deadlock)에 걸린 데이터베이스 쿼리, 동기식(synchronous)으로 처리되는 대용량 파일 i/o 등이 원인입니다. 작업이 끝나지 않으면 스레드는 풀로 돌아가지 못하고, 결국 모든 스레드가 이런 ‘끝나지 않는 작업’에 점유됩니다. 이때 추가 요청은 대기열로 들어가는데, 대기열의 크기 나아가 제한되어 있지 않다면(Unbounded Queue) 메모리가 고갈될 때까지 요청이 쌓여 시스템 전체를 마비시킵니다.

해결 방법 1: 즉시 적용 가능한 긴급 조치 및 모니터링

현장에서 가장 먼저 시스템을 안정화시켜 서비스 중단을 막아야 합니다. 근본 원인을 찾기 전에 적용할 수 있는 실용적인 조치입니다.

1. 스레드 덤프(Thread Dump) 확보: 문제가 발생한 서버에서 즉시 스레드 덤프를 2-3회, 5초 간격으로 수집하십시오. Linux 기준 jstack [PID] > thread_dump.log 명령어를 사용합니다. 이 덤프는 나중에 원인 분석의 결정적 단서가 됩니다.
2. 서비스 재시작: 가장 직접적인 방법입니다. 모든 점유된 스레드를 강제로 해제하고 스레드 풀을 초기화합니다. 한편 이는 임시 조치일 뿐이며, 근본 원인이 해결되지 않으면 수시간 내로 동일 증상이 재발합니다.
3. 모니터링 체크포인트 설정: 재발 방지를 위해 스레드 풀 사용률에 대한 실시간 모니터링을 구성해야 합니다. 애플리케이션 메트릭(Micrometer, Prometheus)이나 APM 도구를 통해 thread_pool.active_threads, thread_pool.queue_size 지표를 대시보드에 배치하고, 임계치(예: 활성 스레드 수가 최대 스레드 수의 80% 초과) 초과 시 알람을 받도록 설정합니다.

해결 방법 2: 스레드 풀 구성 최적화 및 병목 제거

애플리케이션 설정 단계에서 방어적인 설계를 적용합니다. 이는 문제의 빈도와 영향을 줄이는 핵심 작업입니다.

스레드 풀 파라미터 조정 (Tomcat/Spring Boot 기준)

WAS(Web Application Server)의 스레드 풀 설정을 검토하고 조정합니다. application.yml 또는 server.xml에서 다음 값을 환경에 맞게 튜닝하십시오.

1. 최대 스레드 수(max-threads): 무작정 높이는 것은 컨텍스트 스위칭 오버헤드를 증가시킵니다. 성능 테스트를 통해 시스템이 안정적으로 처리할 수 있는 적정 수준을 찾아야 합니다, 일반적으로 cpu 코어 수 * 2 ~ 4를 시작점으로 합니다.
2. 대기열 크기(queue-capacity): 절대 무제한(unbounded)으로 두지 마십시오. 유한한 크기(예: 100~500)로 설정하여 요청이 폭주할 때 과도한 메모리 사용과 장애 전파를 방지합니다. 대기열이 가득 차면 적절한 HTTP 503(Service Unavailable) 오류를 클라이언트에 즉시 반환하여 실패를 빠르게 전달해야 합니다.
3. 스레드 유휴 시간(keep-alive-time): 불필요하게 장시간 유지되는 스레드를 정리하여 리소스를 확보합니다.

주의사항: 모든 설정 변경은 스테이징(Staging) 환경에서 충분한 부하 테스트를 거친 후 운영 환경에 적용해야 합니다. 설정값의 변경은 애플리케이션 재시작을 필요로 할 수 있습니다.

동기식 블로킹 호출 제거

스레드 풀 고갈의 가장 흔한 근본 원인입니다. 스레드를 점유하는 작업을 비동기(Non-blocking) 방식으로 전환합니다.

• I/O 작업: 동기식 파일/네트워크 읽기/쓰기를 CompletableFuture 또는 Reactive Stack(WebFlux)을 이용한 비동기 방식으로 변경합니다.
• 외부 API 호출: RestTemplate 대신 비동기 클라이언트인 AsyncRestTemplate 또는 WebClient를 사용합니다. 호출 시 타임아웃(connectionTimeout, readTimeout)을 반드시 설정합니다.
• 장시간 작업: 리포트 생성, 대용량 메일 발송 등은 메인 스레드 풀이 아닌 별도의 작업자 풀(ExecutorService)로 분리하여 실행합니다.

해결 방법 3: 회로 차단기(Circuit Breaker) 및 벌크헤드 패턴 도입

분산 시스템 환경에서 장애가 전파되는 것을 차단하는 아키텍처 패턴을 적용합니다. 이는 시스템의 회복 탄력성(Resilience)을 높이는 고급 기법입니다.

회로 차단기(Circuit Breaker) 구현: Hystrix, Resilience4j 같은 라이브러리를 사용합니다. 솔루션 비교 검토서에 명시된 바와 같이, 느리거나 실패하는 외부 서비스 호출에 대해 실패 임계치를 설정하고 임계치를 초과하면 일정 시간 동안 모든 호출을 즉시 차단(OPEN 상태)하여 스레드 점유를 막습니다. 주기적으로 건강 검사를 수행하여 서비스가 복구되면 호출을 다시 허용(CLOSED/HALF-OPEN 상태)합니다.

벌크헤드(Bulkhead) 패턴 적용: 하나의 거대한 스레드 풀을 사용하는 대신, 업무 기능별 또는 중요도별로 스레드 풀을 격리합니다. 예를 들어, ‘결제 서비스 호출 풀’과 ‘알림 발송 풀’을 분리하면, 알림 서비스의 장애가 결제 업무의 스레드를 모두 점유하지 못하게 막을 수 있습니다. 주목할 만한 것은 resilience4j의 Bulkhead나 별도의 ExecutorService를 생성하여 구현합니다.

폴백(Fallback) 메커니즘 제공: 회로 차단기가 발동했거나 요청이 거부되었을 때 사용자에게 제공할 대체 응답을 설계합니다. 예를 들어, 개인화 추천 API가 실패하면 정적 인기 상품 목록을 반환하는 방식입니다. 이는 사용자 경험을 유지하면서 시스템 부하를 줄입니다.

주의사항 및 최종 점검 리스트

위 해결책을 적용하기 전후에 반드시 확인해야 할 사항입니다. 누락된 체크포인트는 새로운 장애를 유발할 수 있습니다.

• 데드락(Deadlock) 검증은 필수 단계입니다. 수집한 스레드 덤프를 분석해 데드락이 실제로 존재하는지 확인해야 하며, 이는 두 개 이상의 스레드가 서로 상대방이 점유한 리소스를 무한정 기다리는 상태에서 발생할 수 있습니다. 이러한 상황은 IOPS 포화 상태에서의 디스크 쓰기 지연과 데이터 유실 가능성처럼, 특정 자원에 대한 병목이 연쇄적으로 확산되며 시스템 전반의 응답성을 급격히 떨어뜨리는 문제와도 구조적으로 닮아 있습니다.
• 커넥션 풀(Connection Pool) 연동 확인: 데이터베이스 커넥션 풀 크기가 스레드 풀 크기보다 현저히 작다면, 스레드가 커넥션을 얻기 위해 대기하면서 블로킹 상태에 빠질 수 있습니다. DB 커넥션 풀 크기를 적절히 조정하십시오.
• 타임아웃 설정은 모든 외부 호출에 적용: 네트워크 호출, 데이터베이스 쿼리, 캐시 조회 등 모든 I/O 작업에는 합리적인 타임아웃을 설정해야 합니다. 무한 대기를 방지하는 최소한의 안전장치입니다.
• 모니터링 없이는 운영 불가: 스레드 풀 상태, 대기열 크기, 회로 차단기 상태, 시스템 리소스 사용률을 실시간으로 볼 수 있는 모니터링 체계가 구축되지 않았다면, 당신은 눈가리개를 하고 시스템을 운영하는 것과 같습니다.

전문가 팁: 장애 조치(Failover) 시나리오 시뮬레이션 정기적인 장애 훈련(Chaos Engineering)을 도입하십시오, 의도적으로 외부 api 응답을 지연시키거나 실패하게 만들어, 회로 차단기가 정상 작동하는지, 폴백 로직이 실행되는지, 대기열이 폭주하지 않는지 직접 확인합니다. 설정한 모든 안전장치(타임아웃, 차단기, 벌크헤드)는 평소에는 보이지 않지만, 실제 장애 시에만 빛을 발합니다. 이 시뮬레이션을 통해 그 효과를 검증해야 합니다. 또한, 스레드 풀 고갈은 단일 서버의 문제를 넘어 전체 클러스터를 순차적으로 마비시킬 수 있는 ‘연쇄 장애’의 시발점이 됩니다. 로드 밸런서의 상태 확인(Health Check) 로직이 응답 지연을 감지하고 해당 인스턴스를 서비스 대상에서 빠르게 제외시키도록 구성되어 있는지 반드시 점검하십시오.