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

WAS 인스턴스: 2대
CPU: 20% (정상)
메모리: 40% (정상)
네트워크 I/O: 정상
디스크: 정상
        
        복사
      

# 14:23:15 이후
- Request Count: 0
- ALB Health Check: 0 (찍히지 않음)
- JVM Metrics: 정상 (GC, Heap 모두 정상)
        
        복사
      

-- MySQL processlist 확인
mysql> show processlist;

+-----+------+-----------+------+---------+------+----------+------------------+
| Id  | User | Host      | db   | Command | Time | State    | Info             |
+-----+------+-----------+------+---------+------+----------+------------------+
| 123 | app  | 10.0.1.5  | mydb | Sleep   | 45   | (none)   | NULL             |
| 124 | app  | 10.0.1.6  | mydb | Sleep   | 42   | (none)   | NULL             |
...
+-----+------+-----------+------+---------+------+----------+------------------+
        
        복사
      

# 컨테이너 접속
$ docker exec -it <container_id> bash

# 자바 프로세스 확인
$ ps aux | grep java
app      1  2.1 12.3  4567890  1234567 ?  Ssl  14:00  0:35 java -jar app.jar

# 프로세스는 떠 있음
# 하지만 curl로 헬스체크 요청 시도
$ curl http://localhost:8080/actuator/health
(응답 없음, 타임아웃)
        
        복사
      

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

@Service
public class SearchService {

    @Autowired
    private List<SearchRepository> repositories; // 100개의 Repository

    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),
                    executor
                ))
                .toList();

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

            return new SearchResult(allResults);
        }
    }
}
        
        복사
      

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(() -> {
    // 가벼움, 수백만 개 생성 가능
});
        
        복사
      

Virtual Thread 1 ──┐
Virtual Thread 2 ──┼── Carrier Thread 1 (Platform Thread)
Virtual Thread 3 ──┘

Virtual Thread 4 ──┐
Virtual Thread 5 ──┼── Carrier Thread 2 (Platform Thread)
Virtual Thread 6 ──┘
        
        복사
      

Virtual Thread가 블로킹 작업을 만나면?
1. Carrier Thread를 양보 (Unmount)
2. 대기 큐로 이동
3. 다른 Virtual Thread가 Carrier Thread 사용
4. 블로킹이 끝나면 다시 Carrier Thread에 탑승 (Mount)
        
        복사
      

spring:
  datasource:
    hikari:
      connection-timeout: 30000 # 30초 (기본값)
        
        복사
      

SQLTransientConnectionException:
HikariPool - Connection is not available, request timed out after 30000ms.
        
        복사
      

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

// Carrier Thread는 양보되고,
// Virtual Thread는 대기 큐에서 조용히 기다림
        
        복사
      

Virtual Thread 1~50: 커넥션 획득 대기 (블로킹)
Virtual Thread 51~60: 커넥션 획득 대기 (블로킹)
...
        
        복사
      

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

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

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

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

# 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());
    }
}
        
        복사
      

@Service
public class SearchService {

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

    @Autowired
    private List<SearchRepository> repositories;

    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 메트릭 활성화
        
        복사
      

// 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();
}
        
        복사
      

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

100개 병렬 → 응답 빠름, 리소스 고갈 위험
10개 배치 → 응답 느림, 안정성 확보
        
        복사