외부 API 지연 시 스레드 풀 고갈을 방어하는 적응형 동시성 제한(Adaptive Concurrency Limits)과 서킷 브레이커 아키텍처

1. 외부 의존 서비스 지연이 촉발하는 스레드 풀 고갈과 연쇄 장애

마이크로서비스 아키텍처와 대규모 배치 파이프라인에서 원격 결제 게이트웨이, 공공데이터 오픈 API, 서드파티 웹훅과 같은 외부 의존 시스템은 통제 불가능한 장애 발생 지점입니다. 외부 API의 응답 지연(Latency)이 평소 50ms에서 수 초 단위로 급증할 때, 인입되는 요청을 처리하는 애플리케이션의 서블릿 워커 스레드(Tomcat, Jetty 등) 전체가 블로킹 대기 상태에 진입합니다.

스레드 풀이 고갈되면 외부 API와 무관한 정상 내부 서비스(회원 조회, 메인 페이지 렌더링 등)의 HTTP 요청까지 대기열에 쌓이다가 HTTP 503 Service Unavailable 및 게이트웨이 타임아웃을 유발하는 연쇄 장애(Cascading Failure)로 비화합니다.

2. 정적 동시성 제한(Static Limit)의 한계와 적응형 동시성 제어(Adaptive Limits)

Netflix 기술 블로그의 과부하 대응 연구에 명시된 바와 같이, 세마포어(Semaphore)나 고정 스레드 풀 크기를 이용한 정적 동시성 제한(Static Concurrency Limit)은 동적 트래픽 환경에서 다음과 같은 치명적 결함을 노출합니다.

• 과소 할당(Under-provisioning): 한도를 너무 낮게 잡으면 원격 서버가 충분한 용량을 처리할 수 있는 정상 상태에서도 불필요하게 클라이언트 요청을 거부하여 시스템 처리량(Throughput)을 낭비합니다.
• 과대 할당(Over-provisioning): 한도를 너무 높게 잡으면 원격 서버가 지연되는 순간 수백 개의 스레드가 동시에 락에 갇혀 로컬 애플리케이션의 메모리와 CPU 자원을 완전히 소진시킵니다.
• Little의 법칙과 적응형 제어: 대기열 이론의 기본인 Little의 법칙($L = \lambda W$, 동시성 = 처리량 $\times$ 지연시간)에 따라 지연시간($W$)이 변하면 최적 동시성($L$) 역시 실시간으로 재계산되어야 합니다.

3. TCP Vegas RTT 알고리즘 기반 적응형 동시성 계산 원리

Netflix Concurrency Limits 라이브러리의 핵심 알고리즘인 TCP Vegas는 패킷 손실이 발생하기 전에 왕복 지연시간(RTT)의 미세한 변화를 감지하여 큐 적체(Queueing Delay)를 사전 억제합니다.

• BaseRTT 추적: 시스템이 무부하 상태일 때 관측된 최소 RTT를 기준값($BaseRTT$)으로 기억합니다.
• 큐 크기 추정(Queue Size Estimation): 현재 관측된 샘플 RTT를 기반으로 원격 서버 버퍼에 적체된 큐 크기를 다음 수식으로 도출합니다.

Queue Size = Current Limit * (1 – BaseRTT / SampleRTT)

• 동적 윈도우 조절: 추정된 큐 크기가 임계치 $\alpha$(예: 3) 이하이면 한도를 증액($+1$)하고, $\beta$(예: 6) 이상으로 큐잉이 심화되면 한도를 즉시 선제 축소($-1$)하여 원격 서버의 과부하 붕괴를 사전에 차단합니다.

4. 실전 파이프라인 구현: Vegas 적응형 리미터와 서킷 브레이커 통합 엔진

Martin Fowler의 Circuit Breaker 패턴(CLOSED, OPEN, HALF_OPEN)과 TCP Vegas 적응형 동시성 제한을 유기적으로 결합한 파이썬 엔지니어링 구현체입니다.

import time
import math
import logging
from typing import Dict, Any, Optional, Tuple
from enum import Enum

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s [%(levelname)s] (%(name)s) %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S'
)
logger = logging.getLogger('AdaptiveResilienceEngine')

class CircuitState(str, Enum):
    CLOSED = 'CLOSED'
    OPEN = 'OPEN'
    HALF_OPEN = 'HALF_OPEN'

class VegasAdaptiveConcurrencyLimiter:
    def __init__(self, initial_limit: int = 20, min_limit: int = 5, max_limit: int = 200, alpha: float = 3.0, beta: float = 6.0):
        self.estimated_limit = float(initial_limit)
        self.min_limit = min_limit
        self.max_limit = max_limit
        self.alpha = alpha
        self.beta = beta
        self.base_rtt_sec = float('inf')
        self.in_flight = 0

    def acquire(self) -> bool:
        if self.in_flight >= int(self.estimated_limit):
            logger.warning(f'동시성 상한 초과(In-flight: {self.in_flight} >= Limit: {int(self.estimated_limit)}): 요청 즉각 탈락')
            return False
        self.in_flight += 1
        return True

    def release(self, sample_rtt_sec: float):
        self.in_flight = max(0, self.in_flight - 1)
        if sample_rtt_sec <= 0:
            return

        # 최소 RTT(무부하 기준 지연시간) 추적
        if sample_rtt_sec < self.base_rtt_sec:
            self.base_rtt_sec = sample_rtt_sec

        # TCP Vegas 큐 크기 추정 수식: Queue Size = Current Limit * (1 - BaseRTT / SampleRTT)
        queue_size = self.estimated_limit * (1.0 - (self.base_rtt_sec / sample_rtt_sec))

        if queue_size <= self.alpha:
            self.estimated_limit += 1.0  # 지연시간 안정적: 동시성 한도 점진 증액
        elif queue_size >= self.beta:
            self.estimated_limit -= 1.0  # 지연시간 급증: 큐잉 발생 감지, 한도 선제 축소

        self.estimated_limit = max(self.min_limit, min(self.max_limit, self.estimated_limit))
        logger.debug(f'Vegas 한도 동적 갱신: Limit={int(self.estimated_limit)}, QueueSize={queue_size:.2f}')

class AdaptiveCircuitBreaker:
    def __init__(self, failure_threshold: float = 0.5, recovery_timeout_sec: float = 10.0):
        self.state = CircuitState.CLOSED
        self.failure_threshold = failure_threshold
        self.recovery_timeout_sec = recovery_timeout_sec
        self.last_state_change = time.time()
        self.limiter = VegasAdaptiveConcurrencyLimiter()
        self.total_requests = 0
        self.failed_requests = 0

    def can_execute(self) -> bool:
        now = time.time()
        if self.state == CircuitState.OPEN:
            if now - self.last_state_change >= self.recovery_timeout_sec:
                self.state = CircuitState.HALF_OPEN
                self.last_state_change = now
                logger.info('[서킷브레이커] HALF_OPEN 상태 진입: 탐침 트래픽 인가 허용')
                return True
            return False
        return self.limiter.acquire()

    def record_result(self, is_success: bool, elapsed_rtt: float):
        self.limiter.release(elapsed_rtt)
        self.total_requests += 1
        if not is_success:
            self.failed_requests += 1

        if self.state == CircuitState.HALF_OPEN:
            if is_success:
                self.state = CircuitState.CLOSED
                self.last_state_change = time.time()
                self.total_requests, self.failed_requests = 0, 0
                logger.info('[서킷브레이커] 탐침 트래픽 성공 -> CLOSED 정상 복구')
            else:
                self.state = CircuitState.OPEN
                self.last_state_change = time.time()
                logger.warning('[서킷브레이커] 탐침 트래픽 실패 -> OPEN 재차단')

        elif self.state == CircuitState.CLOSED and self.total_requests >= 20:
            rate = self.failed_requests / self.total_requests
            if rate >= self.failure_threshold:
                self.state = CircuitState.OPEN
                self.last_state_change = time.time()
                logger.error(f'[서킷브레이커] 실패율({rate*100:.1f}%) 임계 초과 -> OPEN 회로 차단 발동')

if __name__ == '__main__':
    cb = AdaptiveCircuitBreaker(failure_threshold=0.4, recovery_timeout_sec=5.0)
    for i in range(10):
        if cb.can_execute():
            # 모의 API 호출 (지연시간 0.05초)
            cb.record_result(is_success=True, elapsed_rtt=0.05)

5. 성능 실측 벤치마크 및 프로덕션 운영 가이드

외부 API의 응답 지연이 50ms에서 3,000ms로 급증하는 장애 상황에서 무제한 호출, 정적 세마포어(50개), 적응형 Vegas 리미터 적용 시 시스템 지표를 비교 측정한 결과는 다음과 같습니다.

프로덕션 분산 시스템에 본 아키텍처를 도입할 때는 다음 사항을 반드시 설계에 반영해야 합니다.

• 최소 한도(min_limit) 안전장치: 네트워크 스파이크로 인해 동시성 한도가 0으로 수렴하지 않도록 최소 3~5개의 탐침 슬롯을 항상 열어두어야 지연시간 회복을 감지할 수 있습니다.
• Fallback 전략 사전 정의: 동시성 한도 초과 또는 서킷 오픈으로 인해 즉각 탈락(Fail-Fast)된 요청에 대해 캐시된 이전 데이터 반환, 비동기 큐 이관, 사용자 친화적 대체 응답 등 비즈니스 폴백을 완비해야 합니다.
• 메트릭 및 알람 연계: 동시성 한도가 급격히 축소되거나 서킷 상태가 OPEN으로 전이될 때 Prometheus 및 Grafana 대시보드에 즉시 이벤트를 기록하고 온콜(On-Call) 엔지니어에게 알람을 발송해야 합니다.