8. GC 메트릭 모니터링: JVM 힙과 G1GC STW 추적

지금까지 우리는 인프라(Prometheus)와 시각화(Grafana)를 배웠습니다. 이번 장에서는 시선을 한 단계 위로 옮겨, 우리가 만든 Java 애플리케이션 그 자체를 모니터링합니다. 아무리 Cassandra, Kafka, Redis가 튼튼해도, 결국 이것들을 호출하는 Java 프로세스가 무너지면 모든 게 멈춥니다. 트래픽 폭증 시 JVM 힙이 포화되고 GC가 오래 걸려 수백 ms의 응답 지연(STW)이 발생하는 현상을 Prometheus 메트릭으로 사전에 감지하고 대응하는 방법을 배웁니다.

1. JVM 메모리 구조: 무엇을 모니터링해야 하는가

GC를 이해하려면 먼저 JVM이 메모리를 어떻게 나눠 쓰는지 알아야 합니다.

GC 단계별 STW 발생 패턴

2. JVM 핵심 메트릭과 PromQL

4장에서 설정한 Spring Boot Actuator + Micrometer가 아래 메트릭들을 자동으로 Prometheus에 노출합니다. 이 메트릭들로 "힙이 얼마나 찼는가"와 "GC가 얼마나 오래 걸리는가"를 실시간으로 추적합니다.

핵심 메트릭 목록

실전 PromQL 쿼리

# 1. Heap 사용률 (%) — 가장 먼저 확인하는 지표
sum(jvm_memory_used_bytes{area="heap"})
  / sum(jvm_memory_max_bytes{area="heap"}) * 100

# 2. 평균 GC pause 시간 (초) — P99 레이턴시 스파이크의 원인
rate(jvm_gc_pause_seconds_sum[5m])
  / rate(jvm_gc_pause_seconds_count[5m])

# 3. GC pause 빈도 (초당 횟수) — 급증하면 힙 압박 신호
rate(jvm_gc_pause_seconds_count[5m])

# 4. Old Gen 승격률 (bytes/sec) — 이 값이 급증하면 Full GC 전조
rate(jvm_gc_memory_promoted_bytes_total[5m])

# 5. 객체 할당률 (bytes/sec) — 트래픽 폭증 시 Eden 포화 속도 측정
rate(jvm_gc_memory_allocated_bytes_total[5m])

3. Grafana 패널 구성

앞 장에서 배운 Grafana 대시보드에 아래 패널들을 추가해 JVM 전용 뷰를 만듭니다.

4. Alertmanager 경보 규칙 설정

6장에서 배운 Alertmanager에 JVM 경보를 추가합니다. 아래 두 개가 핵심입니다.

groups:
  - name: jvm_alerts
    rules:
      # 경보 1: Heap 85% 초과 — OOM 전 최후 경고선
      - alert: HighHeapUsage
        expr: |
          sum(jvm_memory_used_bytes{area="heap"})
          / sum(jvm_memory_max_bytes{area="heap"}) * 100 > 85
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Heap 사용률 {{ $value | printf \"%.1f\" }}% 초과"
          description: "2분 이상 85%를 넘었습니다. OOM 발생 전에 조치하세요."

      # 경보 2: GC pause 평균 500ms 초과 — P99 레이턴시 직접 영향
      - alert: LongGCPause
        expr: |
          rate(jvm_gc_pause_seconds_sum[5m])
          / rate(jvm_gc_pause_seconds_count[5m]) > 0.5
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "평균 GC pause {{ $value | printf \"%.2f\" }}초"
          description: "GC pause가 500ms를 넘어 P99 레이턴시에 직접 영향을 줍니다."

      # 경보 3: Full GC 발생 감지 (cause="G1 Compaction Pause")
      - alert: FullGCDetected
        expr: |
          increase(jvm_gc_pause_seconds_count{cause=~"G1 Compaction.*|G1 Humongous.*"}[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "Full GC 발생 감지"
          description: "Full GC는 수백 ms ~ 수 초 STW를 유발합니다. 즉시 힙 덤프 분석이 필요합니다."

5. OOM 발생 시: 힙 덤프 분석 실습

Prometheus 경보가 울렸는데도 조치를 못 했거나, 이미 OOM이 발생했을 때의 대응 절차입니다.

Step 1. 힙 덤프 자동 생성 설정

애플리케이션 기동 옵션에 아래 JVM 플래그를 추가해두면 OOM 발생 시 자동으로 힙 덤프 파일이 생성됩니다.

# JVM 시작 옵션에 추가
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/app/heapdump.hprof

Step 2. 힙 덤프 분석 (Eclipse MAT)

생성된 .hprof 파일을 Eclipse Memory Analyzer Tool(MAT)로 열어 아래 순서로 분석합니다.

1. Leak Suspects Report 실행 — MAT가 자동으로 메모리 누수 가능성이 있는 객체를 찾아줍니다. "Problem Suspect 1"에 표시된 클래스가 가장 의심스러운 대상입니다.
2. Dominator Tree 확인 — 힙을 가장 많이 점유하는 객체 계층을 내림차순으로 보여줍니다. 상위 5개 객체가 힙의 80% 이상을 차지한다면 누수를 강하게 의심해야 합니다.
3. Retained Heap 기준 정렬 — 어떤 객체가 GC를 막고 있는지(참조를 붙들고 있는지) 확인합니다. List, Map, Cache 구현체가 비정상적으로 크다면 해제되지 않은 캐시나 세션을 의심합니다.

트래픽 폭증 시 힙 포화 시나리오

6. GC 튜닝 기본 전략