Java의 GC 튜닝 실전 사례: Throughput vs Latency 중심

 

Java의 GC 튜닝 실전 사례: Throughput vs Latency 중심

 

Java 애플리케이션의 성능을 좌우하는 핵심 요소 중 하나는 바로 Garbage Collection(GC) 최적화입니다.

특히 대용량 트래픽을 처리하는 웹 애플리케이션이나 실시간 데이터 처리 시스템에서는 GC 튜닝이 애플리케이션의 전반적인 성능을 결정짓는 중요한 요소가 됩니다.

본 포스팅에서는 실제 운영 환경에서 마주할 수 있는 GC 성능 문제와 해결 방안을 Throughput과 Latency 관점에서 상세히 다루겠습니다.

GC 성능 지표의 이해: Throughput과 Latency 개념 정리

Throughput 중심의 GC 최적화

Throughput은 전체 실행 시간 대비 실제 애플리케이션 코드가 실행되는 시간의 비율을 의미합니다.

예를 들어, 100초 동안 애플리케이션이 실행되었을 때 GC에 소요된 시간이 2초라면 Throughput은 98%가 됩니다.

// Throughput 측정을 위한 간단한 예제
public class ThroughputTest {
    private static final int ALLOCATION_SIZE = 1024 * 1024; // 1MB
    private static final int ITERATIONS = 1000;
    
    public static void main(String[] args) {
        long startTime = System.currentTimeMillis();
        
        for (int i = 0; i < ITERATIONS; i++) {
            // 대량의 객체 생성으로 GC 유발
            byte[] data = new byte[ALLOCATION_SIZE];
            processData(data);
        }
        
        long endTime = System.currentTimeMillis();
        System.out.println("Total execution time: " + (endTime - startTime) + "ms");
    }
    
    private static void processData(byte[] data) {
        // 실제 비즈니스 로직 시뮬레이션
        Arrays.fill(data, (byte) 1);
    }
}

배치 처리나 데이터 분석 작업처럼 전체 처리 시간이 중요한 애플리케이션에서는 Throughput 최적화가 우선시됩니다.

Latency 중심의 GC 최적화

Latency는 개별 GC 이벤트가 애플리케이션을 중단시키는 시간을 의미합니다.

실시간 응답이 중요한 웹 서비스나 게임 서버에서는 GC로 인한 지연 시간을 최소화하는 것이 핵심입니다.

// Latency 측정을 위한 웹 서비스 시뮬레이션
@RestController
public class LatencyTestController {
    
    private final List<UserSession> activeSessions = new ConcurrentLinkedQueue<>();
    
    @GetMapping("/api/users/{userId}")
    public ResponseEntity<UserData> getUserData(@PathVariable String userId) {
        long startTime = System.nanoTime();
        
        // 사용자 데이터 조회 및 세션 관리
        UserData userData = fetchUserData(userId);
        manageUserSession(userId, userData);
        
        long responseTime = System.nanoTime() - startTime;
        
        // 응답 시간이 100ms를 초과하면 SLA 위반
        if (responseTime > 100_000_000) { // 100ms in nanoseconds
            log.warn("High latency detected: {}ms", responseTime / 1_000_000);
        }
        
        return ResponseEntity.ok(userData);
    }
}

Java GC 알고리즘별 특성과 선택 기준

G1GC (Garbage First Garbage Collector) 실전 튜닝

G1GC는 Java 9부터 기본 GC로 채택된 low-latency 지향 가비지 컬렉터입니다.

대용량 힙 메모리(4GB 이상)를 가진 애플리케이션에서 예측 가능한 pause time을 제공합니다.

# G1GC 기본 설정 예제
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:G1HeapRegionSize=16m
-XX:G1NewSizePercent=20
-XX:G1MaxNewSizePercent=30
-XX:G1MixedGCCountTarget=8
-XX:G1MixedGCLiveThresholdPercent=85

실제 운영 환경에서 G1GC를 적용한 사례를 살펴보면, 8GB 힙 메모리를 사용하는 전자상거래 애플리케이션에서 다음과 같은 결과를 얻었습니다.

// G1GC 모니터링을 위한 JVM 메트릭 수집
public class G1GCMetricsCollector {
    private final MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
    private final List<GarbageCollectorMXBean> gcBeans = ManagementFactory.getGarbageCollectorMXBeans();
    
    public void collectMetrics() {
        MemoryUsage heapUsage = memoryBean.getHeapMemoryUsage();
        
        System.out.println("Heap Memory Usage:");
        System.out.println("  Used: " + formatBytes(heapUsage.getUsed()));
        System.out.println("  Max: " + formatBytes(heapUsage.getMax()));
        System.out.println("  Usage: " + (heapUsage.getUsed() * 100.0 / heapUsage.getMax()) + "%");
        
        for (GarbageCollectorMXBean gcBean : gcBeans) {
            System.out.println(gcBean.getName() + " GC:");
            System.out.println("  Collection Count: " + gcBean.getCollectionCount());
            System.out.println("  Collection Time: " + gcBean.getCollectionTime() + "ms");
        }
    }
    
    private String formatBytes(long bytes) {
        return String.format("%.2f MB", bytes / (1024.0 * 1024.0));
    }
}

ZGC (Z Garbage Collector) 초저지연 솔루션

Java 11에서 실험적으로 도입된 ZGC는 ultra-low latency를 목표로 설계된 차세대 가비지 컬렉터입니다.

멀티 테라바이트 힙에서도 10ms 미만의 pause time을 보장합니다.

# ZGC 활성화 및 튜닝 파라미터
-XX:+UnlockExperimentalVMOptions
-XX:+UseZGC
-XX:SoftMaxHeapSize=30g
-XX:ZCollectionInterval=5
-Xmx32g

실시간 금융 거래 시스템에서 ZGC를 적용한 결과, 기존 G1GC 대비 평균 응답 시간이 40% 개선되었습니다.

실전 GC 튜닝 사례 연구

사례 1: 전자상거래 플랫폼의 Throughput 최적화

대규모 온라인 쇼핑몰에서 발생한 성능 이슈와 해결 과정을 살펴보겠습니다.

초기 상황에서는 Parallel GC를 사용했으나, 피크 시간대에 GC로 인한 처리량 저하가 심각했습니다.

// 전자상거래 주문 처리 시스템 예제
@Service
public class OrderProcessingService {
    
    private final Map<String, OrderCache> orderCache = new ConcurrentHashMap<>();
    private final ExecutorService executor = Executors.newFixedThreadPool(10);
    
    @Async
    public CompletableFuture<OrderResult> processOrder(OrderRequest request) {
        return CompletableFuture.supplyAsync(() -> {
            // 주문 데이터 캐싱으로 메모리 사용량 증가
            OrderCache cache = new OrderCache(request);
            orderCache.put(request.getOrderId(), cache);
            
            // 복잡한 비즈니스 로직 처리
            OrderResult result = executeBusinessLogic(request);
            
            // 처리 완료 후 캐시 정리 (메모리 해제)
            orderCache.remove(request.getOrderId());
            
            return result;
        }, executor);
    }
    
    private OrderResult executeBusinessLogic(OrderRequest request) {
        // 재고 확인, 결제 처리, 배송 준비 등
        return new OrderResult(request.getOrderId(), "SUCCESS");
    }
}

문제 해결을 위해 다음과 같은 GC 튜닝을 적용했습니다.

# 기존 설정 (Parallel GC)
-XX:+UseParallelGC
-Xms4g -Xmx8g
-XX:NewRatio=3

# 개선된 설정 (G1GC)
-XX:+UseG1GC
-Xms8g -Xmx16g
-XX:MaxGCPauseMillis=100
-XX:G1HeapRegionSize=32m
-XX:+G1UseAdaptiveIHOP
-XX:G1MixedGCCountTarget=12

결과적으로 전체 처리량이 25% 향상되었고, GC로 인한 중단 시간도 평균 150ms에서 80ms로 단축되었습니다.

사례 2: 실시간 채팅 서비스의 Latency 최적화

수백만 명의 동시 접속자를 처리하는 실시간 채팅 서비스에서 GC latency 문제를 해결한 사례입니다.

// 실시간 채팅 메시지 처리 시스템
@Component
public class ChatMessageProcessor {
    
    private final Map<String, ChatRoom> activeRooms = new ConcurrentHashMap<>();
    private final BlockingQueue<ChatMessage> messageQueue = new LinkedBlockingQueue<>();
    
    @EventListener
    public void handleChatMessage(ChatMessage message) {
        long startTime = System.nanoTime();
        
        // 메시지 큐에 추가
        messageQueue.offer(message);
        
        // 채팅방별 메시지 브로드캐스트
        ChatRoom room = activeRooms.get(message.getRoomId());
        if (room != null) {
            room.broadcastMessage(message);
        }
        
        long processingTime = System.nanoTime() - startTime;
        
        // 50ms 초과 시 성능 경고
        if (processingTime > 50_000_000) {
            log.warn("High message processing latency: {}ms", 
                     processingTime / 1_000_000);
        }
    }
    
    @Scheduled(fixedRate = 1000)
    public void processMessageQueue() {
        List<ChatMessage> messages = new ArrayList<>();
        messageQueue.drainTo(messages, 100);
        
        // 배치 처리로 GC 압박 감소
        processBatchMessages(messages);
    }
}

초기 상황에서는 CMS GC를 사용했으나, concurrent mode failure가 빈번하게 발생했습니다.

# 기존 설정 (CMS GC) - Java 8 환경
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly

# 개선된 설정 (ZGC) - Java 17 환경
-XX:+UseZGC
-XX:+UnlockExperimentalVMOptions
-Xmx32g
-XX:SoftMaxHeapSize=28g
-XX:ZCollectionInterval=5

ZGC로 전환한 결과, 99.9% 메시지 처리 응답 시간이 200ms에서 15ms로 대폭 개선되었습니다.

GC 모니터링과 성능 분석 도구 활용법

JVM 기본 모니터링 도구 활용

효과적인 GC 튜닝을 위해서는 정확한 모니터링이 필수입니다.

// GC 로그 분석을 위한 커스텀 모니터링 클래스
public class GCPerformanceMonitor {
    
    private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
    private final Map<String, Long> previousGCTimes = new ConcurrentHashMap<>();
    
    public void startMonitoring() {
        scheduler.scheduleAtFixedRate(this::collectGCMetrics, 0, 10, TimeUnit.SECONDS);
    }
    
    private void collectGCMetrics() {
        List<GarbageCollectorMXBean> gcBeans = ManagementFactory.getGarbageCollectorMXBeans();
        
        for (GarbageCollectorMXBean gcBean : gcBeans) {
            String gcName = gcBean.getName();
            long currentTime = gcBean.getCollectionTime();
            long currentCount = gcBean.getCollectionCount();
            
            Long previousTime = previousGCTimes.get(gcName);
            if (previousTime != null) {
                long timeDiff = currentTime - previousTime;
                if (timeDiff > 0) {
                    System.out.printf("[%s] GC occurred: %dms total time%n", 
                                    gcName, timeDiff);
                }
            }
            
            previousGCTimes.put(gcName, currentTime);
            
            // GC 빈도가 높으면 경고
            if (currentCount > 100 && (currentTime / (double) currentCount) > 100) {
                System.out.printf("WARNING: High GC frequency detected for %s%n", gcName);
            }
        }
    }
}

GC 로그 분석과 최적화 포인트 도출

실제 운영 환경에서 수집한 GC 로그를 통해 성능 병목점을 식별하는 방법을 알아보겠습니다.

# 상세한 GC 로그 수집을 위한 JVM 옵션
-Xloggc:gc.log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=10M

수집된 로그를 분석하여 다음과 같은 최적화 포인트를 도출할 수 있습니다.

메모리 누수 방지와 객체 생명주기 관리

효율적인 객체 생성 패턴

GC 성능을 최적화하려면 불필요한 객체 생성을 최소화해야 합니다.

// 비효율적인 문자열 연산 (개선 전)
public class IneffientStringBuilder {
    public String buildMessage(List<String> parts) {
        String result = "";
        for (String part : parts) {
            result += part + " "; // 매번 새로운 String 객체 생성
        }
        return result;
    }
}

// 효율적인 StringBuilder 사용 (개선 후)
public class EfficientStringBuilder {
    private final StringBuilder reusableBuilder = new StringBuilder();
    
    public String buildMessage(List<String> parts) {
        reusableBuilder.setLength(0); // 기존 버퍼 재사용
        
        for (String part : parts) {
            reusableBuilder.append(part).append(" ");
        }
        
        return reusableBuilder.toString();
    }
}

메모리 풀링과 객체 재사용 전략

대용량 트래픽을 처리하는 애플리케이션에서는 객체 풀링을 통해 GC 압박을 줄일 수 있습니다.

// ByteBuffer 풀링을 통한 메모리 최적화
@Component
public class ByteBufferPool {
    
    private final Queue<ByteBuffer> bufferPool = new ConcurrentLinkedQueue<>();
    private final int bufferSize;
    private final int maxPoolSize;
    
    public ByteBufferPool(@Value("${buffer.size:8192}") int bufferSize,
                          @Value("${pool.max-size:100}") int maxPoolSize) {
        this.bufferSize = bufferSize;
        this.maxPoolSize = maxPoolSize;
        
        // 풀 초기화
        for (int i = 0; i < maxPoolSize / 2; i++) {
            bufferPool.offer(ByteBuffer.allocateDirect(bufferSize));
        }
    }
    
    public ByteBuffer acquire() {
        ByteBuffer buffer = bufferPool.poll();
        if (buffer == null) {
            return ByteBuffer.allocateDirect(bufferSize);
        }
        buffer.clear();
        return buffer;
    }
    
    public void release(ByteBuffer buffer) {
        if (buffer != null && bufferPool.size() < maxPoolSize) {
            bufferPool.offer(buffer);
        }
    }
}

실무에서의 GC 튜닝 체크리스트

단계별 GC 최적화 프로세스

효과적인 GC 튜닝을 위한 체계적인 접근 방법을 제시합니다.

1. 현재 상태 분석: 애플리케이션의 메모리 사용 패턴과 GC 성능 지표 수집
2. 목표 설정: Throughput 우선인지 Latency 우선인지 명확한 목표 설정
3. GC 알고리즘 선택: 애플리케이션 특성에 맞는 최적의 GC 선택
4. 파라미터 튜닝: 단계적으로 파라미터를 조정하며 성능 측정
5. 지속적 모니터링: 운영 환경에서의 지속적인 성능 모니터링

성능 테스트와 벤치마킹

// GC 성능 테스트를 위한 벤치마크 코드
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
@State(Scope.Benchmark)
public class GCPerformanceBenchmark {
    
    private List<byte[]> memoryHolder;
    
    @Setup
    public void setup() {
        memoryHolder = new ArrayList<>();
    }
    
    @Benchmark
    public void allocateMemory() {
        // 1MB 크기의 배열 생성
        byte[] data = new byte[1024 * 1024];
        Arrays.fill(data, (byte) 1);
        memoryHolder.add(data);
        
        // 메모리 사용량이 100MB 초과 시 정리
        if (memoryHolder.size() > 100) {
            memoryHolder.clear();
            System.gc(); // 명시적 GC 호출 (테스트 목적)
        }
    }
    
    @TearDown
    public void cleanup() {
        memoryHolder.clear();
    }
}

최신 GC 기술 동향과 미래 전망

차세대 GC 기술 소개

Java 생태계에서는 지속적으로 새로운 GC 기술이 개발되고 있습니다.

Shenandoah GC는 OpenJDK에서 개발한 ultra-low latency GC로, concurrent compaction을 통해 pause time을 최소화합니다.

# Shenandoah GC 설정 예제
-XX:+UseShenandoahGC
-XX:ShenandoahGCHeuristics=adaptive
-XX:ShenandoahGuaranteedGCInterval=30000
-XX:+UseLargePages

클라우드 환경에서의 GC 최적화

컨테이너 기반 마이크로서비스 환경에서는 메모리 제약과 동적 스케일링을 고려한 GC 튜닝이 중요합니다.

// 컨테이너 환경을 고려한 메모리 관리
@Configuration
public class CloudOptimizedGCConfig {
    
    @Value("${container.memory.limit:#{null}}")
    private String memoryLimit;
    
    @PostConstruct
    public void optimizeForContainer() {
        if (memoryLimit != null) {
            long maxMemory = Runtime.getRuntime().maxMemory();
            long containerLimit = parseMemoryLimit(memoryLimit);
            
            // 컨테이너 메모리 한계의 70%만 JVM 힙으로 사용
            long recommendedHeap = (long) (containerLimit * 0.7);
            
            if (maxMemory > recommendedHeap) {
                System.out.printf("Warning: JVM heap (%d MB) exceeds recommended size (%d MB)%n",
                                maxMemory / (1024 * 1024), 
                                recommendedHeap / (1024 * 1024));
            }
        }
    }
    
    private long parseMemoryLimit(String limit) {
        // 메모리 제한값 파싱 로직
        return Long.parseLong(limit.replaceAll("[^0-9]", "")) * 1024 * 1024;
    }
}

결론

Java GC 튜닝은 애플리케이션의 성능 요구사항에 따라 Throughput과 Latency 중 우선순위를 명확히 하고, 체계적인 접근을 통해 최적화해야 합니다.

실무에서는 단순히 파라미터를 조정하는 것을 넘어서 애플리케이션의 메모리 사용 패턴을 이해하고, 적절한 모니터링 체계를 구축하는 것이 중요합니다.

특히 클라우드 환경과 마이크로서비스 아키텍처의 확산으로 인해 GC 최적화의 중요성은 더욱 커지고 있으며, 최신 GC 기술에 대한 지속적인 학습과 실험이 필요합니다.

효과적인 GC 튜닝을 통해 애플리케이션의 성능을 대폭 개선할 수 있으며, 이는 곧 사용자 경험 향상과 운영 비용 절감으로 이어질 것입니다.