로그 한 줄 없이 서버가 멈췄다 - Virtual Thread와 커넥션 풀 Starvation

graph TB
    User[사용자]
    ALB[AWS ALB]
    WAS1[WAS 인스턴스 #1]
    WAS2[WAS 인스턴스 #2]
    Pool1[HikariCP Pool<br/>최대 50개]
    Pool2[HikariCP Pool<br/>최대 50개]
    DB[(RDS MySQL)]

    User --> ALB
    ALB --> WAS1
    ALB --> WAS2
    WAS1 --> Pool1
    WAS2 --> Pool2
    Pool1 --> DB
    Pool2 --> DB

    style User fill:#e1f5ff
    style ALB fill:#fff4e6
    style WAS1 fill:#e8f5e9
    style WAS2 fill:#e8f5e9
    style Pool1 fill:#fff9c4
    style Pool2 fill:#fff9c4
    style DB fill:#ffebee

# application-dev.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 50 # 인스턴스당 최대 커넥션
      connection-timeout: 30000 # 커넥션 획득 타임아웃 (30초)
      leak-detection-threshold: 0 # 리크 탐지 비활성화 (문제!)

사용자 행동: 관리자 페이지에서 "전체 검색" 버튼 클릭
시간: 14:23:15

나: "혹시 최근에 이 검색 API 손대신 거 있으세요?"
팀원: "아, 그거 너무 느려서 병렬로 바꿨습니다."
나: "...병렬로요?"
팀원: "네, Virtual Thread로 100개 테이블을 동시에 검색하게 했어요."
나: "100개요...?"

public SearchResult search(SearchRequest request) {
    // Virtual Thread로 병렬 검색
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        List<CompletableFuture<List<Item>>> futures = repositories.stream()
            .map(repo -> CompletableFuture.supplyAsync(
                () -> repo.search(request),  // 각각 DB 커넥션 필요!
                executor
            ))
            .toList();

        // 모든 결과 대기
        List<Item> allResults = futures.stream()
            .map(CompletableFuture::join)
            .flatMap(List::stream)
            .toList();

        return new SearchResult(allResults);
    }
}

sequenceDiagram
    participant User as 사용자
    participant API as SearchService
    participant VT as Virtual Threads
    participant Pool as HikariCP Pool<br/>(최대 50개)
    participant DB as MySQL

    User->>API: 검색 요청 (T=0초)
    API->>VT: 100개 Virtual Thread 생성

    Note over VT,Pool: T=0.1초: 동시에 커넥션 요청

    VT->>Pool: Thread 1~50: 커넥션 요청
    Pool->>DB: 50개 커넥션 연결 ✓
    Pool-->>VT: Thread 1~50: 커넥션 획득 성공

    VT->>Pool: Thread 51~100: 커넥션 요청
    Note over Pool: 풀 고갈! (0개 남음)
    Pool--xVT: Thread 51~100: 대기 큐 진입

    Note over VT,Pool: T=0.2초: Deadlock 상태

    rect rgb(255, 240, 240)
        Note over VT: Thread 1~50<br/>커넥션 보유 중<br/>51~100 완료 대기 (join)
        Note over Pool: Thread 51~100<br/>커넥션 대기 중<br/>1~50 반환 대기
    end

    Note over User,DB: 영원한 대기 (서버 멈춤)

graph LR
    A[Thread 1~50<br/>커넥션 보유] -->|join 대기| B[Thread 51~100<br/>완료 필요]
    B -->|커넥션 대기| C[HikariCP Pool<br/>0개 남음]
    C -->|반환 필요| A

    style A fill:#ffcdd2
    style B fill:#fff9c4
    style C fill:#b3e5fc

spring:
  datasource:
    hikari:
      maximum-pool-size: 255

spring:
  datasource:
    hikari:
      maximum-pool-size: 50

검색 요청 1회 = DB 커넥션 100개 동시 필요
WAS 인스턴스 2대
개발 환경 커넥션 풀: 인스턴스당 50개

검색 요청 1번만 해도 = 100개 커넥션 필요
하지만 인스턴스당 최대 50개밖에 없음
→ 50개는 획득 성공, 나머지 50개는 대기

대기 중인 50개는 영원히 커넥션을 받을 수 없음
→ 왜? 이미 획득한 50개가 반환되지 않기 때문
→ 전체 요청이 멈춤 (Deadlock)

// Platform Thread: OS 스레드와 1:1 매핑
Thread platformThread = new Thread(() -> {
    // 무거움, 개수 제한 있음
});

// Virtual Thread: JVM이 관리
Thread virtualThread = Thread.ofVirtual().start(() -> {
    // 가벼움, 수백만 개 생성 가능
});

graph TB
    subgraph VirtualThreads[Virtual Threads - 경량]
        VT1[Virtual Thread 1]
        VT2[Virtual Thread 2]
        VT3[Virtual Thread 3]
        VT4[Virtual Thread 4]
        VT5[Virtual Thread 5]
        VT6[Virtual Thread 6]
    end

    subgraph CarrierThreads[Carrier Threads - Platform Thread]
        CT1[Carrier Thread 1<br/>OS Thread]
        CT2[Carrier Thread 2<br/>OS Thread]
    end

    VT1 -.실행 중.- CT1
    VT2 -.실행 중.- CT1
    VT3 -.대기.- CT1

    VT4 -.실행 중.- CT2
    VT5 -.실행 중.- CT2
    VT6 -.대기.- CT2

    style VT1 fill:#c8e6c9
    style VT2 fill:#c8e6c9
    style VT4 fill:#c8e6c9
    style VT5 fill:#c8e6c9
    style VT3 fill:#ffecb3
    style VT6 fill:#ffecb3
    style CT1 fill:#bbdefb
    style CT2 fill:#bbdefb

stateDiagram-v2
    [*] --> Running: Mount
    Running --> Waiting: 블로킹 작업<br/>(DB 커넥션 대기)
    Running --> [*]: 작업 완료
    Waiting --> Running: 리소스 획득<br/>(Remount)

    note right of Running
        Carrier Thread 위에서 실행
        CPU 사용 중
    end note

    note right of Waiting
        Carrier Thread 양보 (Unmount)
        대기 큐에서 조용히 대기
    end note

ERROR c.z.h.p.HikariPool - Connection is not available, request timed out after 30000ms.
WARN  c.z.h.p.ProxyLeakTask - Connection leak detection triggered for connection...
ERROR o.s.w.s.m.m.a.ExceptionHandlerExceptionResolver - Resolved [SQLException]...

(아무것도 없음)

java.sql.SQLTransientConnectionException:
  HikariPool-1 - Connection is not available, request timed out after 30012ms.
    at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:696)
    at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:197)
    // ... 스택 트레이스

// Virtual Thread가 커넥션 획득 시도
Connection conn = dataSource.getConnection(); // 여기서 블로킹

// 이때 일어나는 일:
// 1. Virtual Thread가 Carrier Thread에서 Unmount됨
// 2. Virtual Thread는 대기 큐로 이동
// 3. Carrier Thread는 다른 Virtual Thread 실행
// 4. 하지만... 대기 큐에 있는 Virtual Thread는 조용히 기다림

Virtual Thread 1~50: 커넥션 획득, 하지만 join() 대기
Virtual Thread 51~100: 커넥션 획득 대기 (블로킹)
                       ↓
            조용히 멈춘 상태
        (로그 출력할 스레드 없음)

타임아웃 예외가 발생하려면:
1. poll(timeout) 대기
2. 타임아웃 시간 경과
3. null 반환
4. 예외 throw

하지만 우리 상황:
- Thread 1~50: 커넥션 보유, join() 대기 (51~100 완료 대기)
- Thread 51~100: poll() 대기 (1~50 반환 대기)
   ↓
순환 의존성으로 타임아웃이 발생해도
join()이 영원히 끝나지 않아 진행 불가

spring:
  datasource:
    hikari:
      leak-detection-threshold: 60000 # 60초

1. 커넥션을 획득함 ✓
2. 60초 동안 반환하지 않음 ✓
→ "커넥션 리크 경고" 출력

1. 커넥션 획득 시도 중 ✗ (대기만 하고 있음)
2. 아직 획득하지 못함 ✗
→ 리크 탐지 조건에 해당 안 됨
→ 경고 없음

HikariCP 리크 탐지 = "빌려간 물건을 안 돌려줄 때" 경고
우리 상황 = "빌리지도 못하고 대기만 하는 중"
→ 경고할 조건이 아님

✗ Connection Timeout: Virtual Thread가 대기 큐에서 멈춤
✗ Leak Detection: 커넥션을 획득하지 못해서 리크가 아님
✗ Health Check: 모든 Carrier Thread가 블로킹 상태

# application-dev.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 100 # 50 → 100

public SearchResult search(SearchRequest request) {
    // 100개 Repository를 모두 병렬로
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        List<CompletableFuture<List<Item>>> futures = repositories.stream()
            .map(repo -> CompletableFuture.supplyAsync(
                () -> repo.search(request),
                executor
            ))
            .toList();

        return new SearchResult(futures.stream()
            .map(CompletableFuture::join)
            .flatMap(List::stream)
            .toList());
    }
}

private static final int MAX_PARALLEL_SEARCHES = 10; // 동시 검색 제한

public SearchResult search(SearchRequest request) {
    List<Item> allResults = new ArrayList<>();

    // 10개씩 묶어서 순차적으로 처리
    for (int i = 0; i < repositories.size(); i += MAX_PARALLEL_SEARCHES) {
        List<SearchRepository> batch = repositories.subList(
            i,
            Math.min(i + MAX_PARALLEL_SEARCHES, repositories.size())
        );

        // 배치 단위로 병렬 처리
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            List<CompletableFuture<List<Item>>> futures = batch.stream()
                .map(repo -> CompletableFuture.supplyAsync(
                    () -> repo.search(request),
                    executor
                ))
                .toList();

            List<Item> batchResults = futures.stream()
                .map(CompletableFuture::join)
                .flatMap(List::stream)
                .toList();

            allResults.addAll(batchResults);
        }
    }

    return new SearchResult(allResults);
}

# application.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 100
      connection-timeout: 10000 # 30초 → 10초로 단축
      leak-detection-threshold: 30000 # 리크 탐지 활성화 (30초)

management:
  metrics:
    enable:
      hikari: true # HikariCP 메트릭 활성화

# application.yml
spring:
  datasource:
    hikari:
      # 1. 커넥션 풀 크기 설정
      maximum-pool-size: 100 # 환경별로 조정 필요
      minimum-idle: 10 # 최소 유휴 커넥션

      # 2. 타임아웃 설정
      connection-timeout: 10000 # 10초 (기본 30초는 너무 길다)
      validation-timeout: 5000 # 커넥션 검증 타임아웃

      # 3. 리크 탐지 활성화
      leak-detection-threshold: 30000 # 30초 이상 점유 시 경고

      # 4. 커넥션 수명 관리
      max-lifetime: 1800000 # 30분 (DB wait_timeout보다 짧게)
      idle-timeout: 600000 # 10분

// 커넥션 풀 크기의 60~70% 정도로 설정
private static final int MAX_CONCURRENT = 30;
private final Semaphore semaphore = new Semaphore(MAX_CONCURRENT);

public SearchResult search(SearchRequest request) {
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        List<CompletableFuture<List<Item>>> futures = repositories.stream()
            .map(repo -> CompletableFuture.supplyAsync(() -> {
                try {
                    semaphore.acquire();  // 최대 30개까지만 동시 실행
                    try {
                        return repo.search(request);
                    } finally {
                        semaphore.release();
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    throw new RuntimeException(e);
                }
            }, executor))
            .toList();

        return new SearchResult(futures.stream()
            .map(CompletableFuture::join)
            .flatMap(List::stream)
            .toList());
    }
}

@Value("${search.batch-size:10}")
private int batchSize;

public SearchResult search(SearchRequest request) {
    List<Item> allResults = new ArrayList<>();

    // Batch 단위로 순차 처리
    for (int i = 0; i < repositories.size(); i += batchSize) {
        List<SearchRepository> batch = repositories.subList(
            i,
            Math.min(i + batchSize, repositories.size())
        );

        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            List<CompletableFuture<List<Item>>> futures = batch.stream()
                .map(repo -> CompletableFuture.supplyAsync(
                    () -> repo.search(request),
                    executor
                ))
                .toList();

            List<Item> batchResults = futures.stream()
                .map(CompletableFuture::join)
                .flatMap(List::stream)
                .toList();

            allResults.addAll(batchResults);
        }
    }

    return new SearchResult(allResults);
}

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health,metrics,prometheus
  endpoint:
    health:
      show-details: always
  metrics:
    tags:
      application: ${spring.application.name}

@Override
public Health health() {
    HikariPoolMXBean poolMXBean = dataSource.getHikariPoolMXBean();
    int activeConnections = poolMXBean.getActiveConnections();
    int maxPoolSize = dataSource.getMaximumPoolSize();
    double usage = (double) activeConnections / maxPoolSize * 100;

    Health.Builder builder = Health.up()
        .withDetail("active", activeConnections)
        .withDetail("max", maxPoolSize)
        .withDetail("usage", String.format("%.1f%%", usage));

    if (usage >= 95) {
        return builder.down()
            .withDetail("message", "Connection pool is nearly exhausted")
            .build();
    }

    if (usage >= 80) {
        return builder.status("WARNING")
            .withDetail("message", "Connection pool usage is high")
            .build();
    }

    return builder.build();
}

// Bad: 리소스 제약 무시
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    futures = repositories.stream()  // 100개
        .map(repo -> CompletableFuture.supplyAsync(...))
        .toList();
    // → 커넥션 풀 고갈
}

// Good: 리소스 제약 고려
Semaphore semaphore = new Semaphore(10);  // 최대 10개로 제한
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    futures = repositories.stream()
        .map(repo -> CompletableFuture.supplyAsync(() -> {
            semaphore.acquire();
            try {
                return repo.search(request);
            } finally {
                semaphore.release();
            }
        }))
        .toList();
}

Virtual Thread 개수는 무한대에 가깝다
하지만 DB 커넥션, 파일 디스크립터, 메모리는 여전히 유한하다
→ 병목은 항상 외부 리소스에서 발생한다

1. 사전 예방
   - 병렬 처리에 Semaphore/배치 제한 걸기
   - 커넥션 풀 크기 충분히 확보하기

2. 빠른 감지
   - HikariCP 메트릭 모니터링
   - 커넥션 풀 사용률 80% 경보
   - Pending connections 경보

3. 디버깅 대비
   - leak-detection-threshold 활성화
   - connection-timeout 짧게 (10초 이하)
   - Thread Dump 수집 자동화

운영 환경: 커넥션 풀 255개 → 100개 병렬 처리 OK
개발 환경: 커넥션 풀 50개 → 100개 병렬 처리

개발 환경 = 운영 환경의 30~50% 리소스 (최소한)

예시 (우리 경우):
- 운영 환경: 커넥션 풀 255개
- 현재 개발 환경: 50개 (약 20% - 너무 작음!)
- 권장 개발 환경: 최소 75~125개 (30~50%)

→ 커넥션 풀만이 아니라 메모리, CPU도 비슷한 비율로 유지

왜 30~50%인가?
- 개발에서 발견 → 수정 비용 낮음 + 빠른 피드백
- 운영에서 발견 → 수정 비용 높음 + 장애 발생
- 너무 작으면 문제를 숨기고, 너무 크면 비용 낭비

나: "왜 100개를 동시에 검색하신 거예요?"
팀원: "Virtual Thread니까 괜찮은 줄 알았습니다..."
나: "..."