TL;DR — 제출의 테스트케이스마다 새 JVM 프로세스를 띄우던 Java 채점 워커를, 단일 JVM이 전체 케이스를 순차 실행(Multi-Runner)하도록 바꾸고 CDS 아카이브·GraalVM 베이스로 보강했다. 운영 DB 기준 테스트케이스당 평균 실행 시간이 0.844s → 0.060s(약 14배), ≥1.0s 꼬리(JVM 콜드 스타트)가 완전히 사라졌다.

배경

• 프로젝트/기능: CodeQuest — 언어별 채점 워커 중 Java 워커(Docker 컨테이너, Kafka 소비 기반, KEDA 오토스케일)
• 환경: JDK 17, Docker, Kubernetes
• 왜 문제였나: 채점은 제출×테스트케이스 단위로 코드를 실행한다. 실행 단가가 곧 채점 지연과 워커 비용

문제 (증상)

• 기존: 케이스마다 java 프로세스를 새로 띄움(ThreadPool 최대 4 병렬)
• JVM 콜드 스타트(클래스 로딩 + 초기화) 비용이 케이스 수만큼 반복
• 케이스가 많을수록 실제 사용자 코드 실행보다 JVM 기동에 쓰는 시간이 커짐

원인 분석

• 채점 1건 = numCases개의 짧은 프로그램 실행. 각 실행을 독립 JVM으로 격리하니 안전하지만, 기동 오버헤드가 지배적
• 병렬화(ThreadPool 4)로 가려졌을 뿐, 프로세스 생성·JVM 워밍업 비용 자체는 그대로

해결 (방향별)

Phase 1 — CDS 아카이브로 클래스 로딩 단축 (docker/java/Dockerfile)

# 빌드 시 표준 클래스 메타데이터를 미리 덤프
RUN java -XX:+UseSerialGC -Xshare:dump \
    -XX:SharedArchiveFile=/app/classes.jsa 2>/dev/null; exit 0

• 런타임 JVM이 클래스를 매번 파싱하지 않고 공유 아카이브에서 매핑 → 기동 단축
• 런타임도 -XX:+UseSerialGC로 맞춰 아카이브 유효성 보장

Phase 2 — Single JVM Multi-Runner (핵심)

• 케이스별 JVM을 띄우던 구조를 폐기하고, TestCaseRunner 단일 JVM이 전체 케이스를 순차 실행

// 이전: 케이스마다 ProcessBuilder("java", ...) 를 ThreadPool로 병렬 기동
// 이후: 단일 러너 프로세스 1회 기동
Process runner = new ProcessBuilder(
    "java", "-XX:SharedArchiveFile=/app/classes.jsa", "-XX:+UseSerialGC",
    "-cp", workDir + ":/app", "TestCaseRunner", ...).start();