[Infra Ops] 애플리케이션 성능 모니터링과 대시보드 구성

인프라 모니터링(CPU, 메모리, 디스크)은 "서버가 힘들다"는 신호는 줍니다. 하지만 "왜 힘든지", "어느 코드가 원인인지"는 알 수 없습니다. APM은 그 공백을 채웁니다.

APM이 할 수 있는 것:

• 특정 HTTP 요청의 전체 처리 시간 측정
• 요청 안에서 어떤 메서드, 어떤 DB 쿼리가 시간을 먹는지 추적
• 느린 쿼리 Top 10을 자동으로 정렬
• 서비스 간 호출 관계(Service Map) 시각화
• 에러 발생 시 스택트레이스를 포함한 전체 컨텍스트 저장

APM 없이 장애를 찾는 현실:

"서비스 느림" 신고
→ top, free, df 확인 → 정상
→ 로그에서 Exception 검색
→ 느린 API가 어딘지 추측
→ 코드 리뷰 시작
→ 30분 경과

APM 있을 때:

"서비스 느림" 신고
→ APM 트랜잭션 목록 열기
→ /api/orders GET 평균 2.1초
→ 내부에서 DB 쿼리 1.8초
→ 해당 쿼리 즉시 확인
→ 5분 경과

APM이 "이 API의 DB 쿼리가 1.8초"라고 짚어주는 건 마법이 아닙니다. 앱에 심은 계측이 요청 하나를 구간별로 쪼개 시간을 재고, 그 조각(스팬)을 모아 하나의 트레이스로 잇기 때문입니다. 이 흐름을 알면 "왜 이 구간이 트레이스에 안 보이지", "APM을 켰더니 왜 느려졌지"를 어느 단계의 문제인지로 좁힐 수 있습니다.

[요청 도착]  GET /api/orders
   │
   ① 계측 삽입      -javaagent · SDK가 프레임워크 · 드라이버에 훅
   │
   ② 트랜잭션 시작   요청 진입에 trace id · 루트 스팬 발급
   │
   ③ 스팬 기록       메서드 · DB 쿼리 · 외부 호출 구간의 시작 · 끝 시각
   │
   ④ context 전파    trace id를 HTTP 헤더로 다음 서비스에 넘김
   │
   ⑤ 수집 · 집계     스팬을 수집 서버로 전송 → 하나의 트레이스로 조립
   ▼
⑥ 시각화  scatter(응답 분포) · call tree(구간별 시간) · service map

각 단계가 하는 일과, 막혔을 때의 증상:

"서버는 멀쩡한데 왜 느린가"에 APM이 답하는 건 ③에서 구간마다 시간을 따로 재기 때문입니다. 그래서 트레이스가 비면 대개 ①계측 누락, 끊기면 ③·④의 context 전파 문제이고, APM을 켠 뒤 앱이 느려졌다면 ⑤샘플링 · 오버헤드를 먼저 의심합니다. 이 계측 · 트레이스 축은 뒤에서 다루는 JMX Exporter+Prometheus(메트릭 축)와 상보적입니다 — 메트릭은 "무엇이 얼마나", 트레이스는 "한 요청이 어디서" 느린지를 봅니다.

APM 솔루션은 오픈소스 자체 호스팅부터 글로벌 SaaS 유료 서비스까지 범위가 넓어, 환경과 예산에 맞지 않는 선택을 하면 도입 후 운영 비용이나 유지 관리 부담이 기대를 초과하는 경우가 많습니다. 국내 공공·금융 환경에서는 규제 리포팅을 지원하는 상용 솔루션이 필요한 반면, 스타트업이나 온프레미스 팀에서는 무료 오픈소스로도 충분히 트랜잭션 추적이 가능합니다. 각 솔루션의 적합 환경과 핵심 특징을 파악해두면 "APM 도입" 논의가 나왔을 때 근거 있는 선택을 빠르게 제안할 수 있습니다.

확대

팀장이 "APM 하나 도입해보자"고 했습니다. 구글에서 검색하면 Pinpoint, New Relic, Datadog, Dynatrace가 나옵니다. 오픈소스와 유료 SaaS의 차이도, 자바 전용과 멀티언어 지원의 차이도 처음에는 구분이 안 됩니다. 환경에 맞지 않는 APM을 도입하면 운영 비용이 기대 이상으로 들거나, 설치는 했는데 실제로 아무도 보지 않는 대시보드가 됩니다. 주요 솔루션의 특성을 파악해야 상황에 맞는 선택을 할 수 있습니다.

Pinpoint (오픈소스, 네이버 개발):

국내에서 가장 널리 쓰이는 무료 APM입니다. Java 에이전트를 Tomcat/Spring Boot JVM에 붙이면, 트랜잭션이 HBase에 저장되고 Web UI에서 Scatter Chart(응답시간 분포)와 Call Tree(메서드 추적)를 확인할 수 있습니다.

# Pinpoint Agent 설정 (Tomcat JAVA_OPTS에 추가)
# /opt/tomcat/bin/setenv.sh
JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/pinpoint-agent/pinpoint-bootstrap.jar"
JAVA_OPTS="$JAVA_OPTS -Dpinpoint.agentId=was01"
JAVA_OPTS="$JAVA_OPTS -Dpinpoint.applicationName=my-service"
JAVA_OPTS="$JAVA_OPTS -Dpinpoint.collector.ip=pinpoint-collector-host"

Jennifer (제니퍼소프트, 국내 기업 필수):

금융, 공공기관, 대기업에서 가장 많이 보이는 상용 APM입니다. 실시간 트랜잭션 히트맵, 액티브 서비스 현황, 서버 자원을 통합 화면에서 보여줘, 운영팀이 대시보드 한 화면으로 전체 상황을 파악합니다. 국내 규제 환경에 맞는 리포팅 기능이 포함됩니다.

Dynatrace / New Relic (글로벌 SaaS APM):

에이전트 설치 후 자동으로 서비스 맵을 생성하고, ML 기반으로 이상 징후를 탐지합니다. 글로벌 SaaS 서비스나 MSA 환경에서 주로 선택합니다. 비용이 높지만 설치와 유지 관리가 단순합니다.

Grafana 대시보드에서 "Tomcat JVM 메모리를 보고 싶다"는 요구가 생겼습니다. 이미 Prometheus는 서버 OS 메트릭을 수집하고 있는데, JVM 내부 Heap과 GC 정보는 보이지 않습니다. JVM은 JMX라는 자체 관리 인터페이스로 내부 상태를 노출하는데, Prometheus는 이 형식을 직접 읽지 못합니다. JMX Exporter가 변환 다리 역할을 합니다. 설정 파일 하나와 JVM 시작 옵션 한 줄이 전부입니다.

Prometheus는 HTTP /metrics 엔드포인트에서 텍스트 형식 메트릭을 pull합니다. JVM은 JMX(Java Management Extensions)로 내부 상태를 노출합니다. 두 형식이 달라 JMX Exporter가 변환 역할을 합니다.

JMX Exporter는 Java 에이전트(-javaagent)로 동작해 JVM 내부 MBean 값을 HTTP로 노출합니다.

# /opt/jmx_exporter/config.yml
# 모든 MBean 수집 (기본 설정)
rules:
- pattern: ".*"

# /opt/tomcat/bin/setenv.sh — Tomcat 시작 시 JAVA_OPTS에 추가
JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=9090:/opt/jmx_exporter/config.yml"

9090 포트로 메트릭이 노출됩니다. Tomcat을 재시작한 후 확인합니다.

# 메트릭 노출 확인
curl http://localhost:9090/metrics | head -30

# JVM 관련 메트릭만 필터링
curl -s http://localhost:9090/metrics | grep jvm_memory_bytes
# 예시 출력:
# jvm_memory_bytes_used{area="heap",} 1.34217728E8
# jvm_memory_bytes_max{area="heap",} 5.36870912E8

방화벽에서 9090 포트를 Prometheus 서버 IP에서만 허용해야 합니다. 외부에 노출하면 JVM 내부 정보가 공개됩니다.

# iptables로 Prometheus 서버만 9090 허용
iptables -A INPUT -p tcp --dport 9090 -s <prometheus-server-ip> -j ACCEPT
iptables -A INPUT -p tcp --dport 9090 -j DROP

JMX Exporter를 설치했는데 Grafana에 여전히 JVM 메트릭이 안 보입니다. Prometheus가 그 엔드포인트를 수집 대상으로 등록하지 않았기 때문입니다. Prometheus는 수동으로 타겟을 지정해야 데이터를 가져옵니다. prometheus.yml의 scrape_configs에 등록하지 않으면 메트릭이 아무리 노출되어 있어도 수집되지 않습니다.

Prometheus에서 JMX Exporter 엔드포인트를 수집 대상으로 등록합니다.

# /etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s      # 기본 수집 주기
  evaluation_interval: 15s  # alert rule 평가 주기

scrape_configs:
  - job_name: 'tomcat-jvm'
    static_configs:
      - targets:
          - 'app-server-01:9090'
          - 'app-server-02:9090'
    scrape_interval: 15s
    metrics_path: /metrics    # 기본값, 생략 가능

  - job_name: 'node-exporter'
    static_configs:
      - targets:
          - 'app-server-01:9100'

# 설정 파일 검증
promtool check config /etc/prometheus/prometheus.yml

# Prometheus 재시작
systemctl reload prometheus

확대

"Tomcat이 느려졌다"는 신고가 들어왔을 때, CPU와 메모리는 정상인데 응답이 느립니다. JVM Heap이 꽉 차서 GC가 과도하게 돌고 있는 경우입니다. 하지만 이 상황을 OS 레벨 메트릭으로는 알 수 없습니다. JVM 전용 패널이 있어야 Heap 사용률과 GC 빈도를 즉시 확인할 수 있습니다. 핵심 패널 4개가 있으면 대부분의 JVM 성능 이슈를 진단할 수 있습니다.

Grafana에서 Prometheus를 Data Source로 등록한 후 JVM 모니터링 대시보드를 구성합니다. 핵심 패널 4개면 JVM 상태를 충분히 파악할 수 있습니다.

패널 1 — Heap 사용률 (%):

# Heap 사용률 계산
(jvm_memory_bytes_used{area="heap", job="tomcat-jvm"}
 / jvm_memory_bytes_max{area="heap", job="tomcat-jvm"}) * 100

패널 2 — GC 발생 빈도 (rate):

# 분당 GC 발생 횟수
rate(jvm_gc_collection_seconds_count{job="tomcat-jvm"}[5m]) * 60

패널 3 — GC 소요 시간 비율 (%):

# GC에 소비되는 CPU 시간 비율
rate(jvm_gc_collection_seconds_sum{job="tomcat-jvm"}[5m])
/ rate(jvm_gc_collection_seconds_count{job="tomcat-jvm"}[5m]) * 1000
# ms 단위로 환산

패널 4 — Thread 수:

jvm_threads_current{job="tomcat-jvm"}

Alert Rule — Heap 85% 초과 5분 지속:

Grafana의 Alert 탭에서 다음과 같이 설정합니다.

# Grafana Alert Rule (개념 표현)
condition: Heap 사용률 > 85
for: 5m       # 5분 이상 지속 시 알람
labels:
  severity: warning
annotations:
  summary: "JVM Heap 사용률 위험 수준"
  description: "{{ $labels.instance }} Heap {{ $value }}%"

Grafana 8.x 이상에서는 Unified Alerting을 사용하며, Alert > Contact Points에서 Slack/Email 연동을 설정합니다.

앞의 JMX Exporter 설정을 rules: - pattern: ".*"로 뒀는데, 이건 시작용 편의일 뿐 운영 기본값으로 두면 위험합니다. Prometheus를 안정적으로 운영하려면 '무엇을 수집하지 않을지'가 '무엇을 수집할지'만큼 중요합니다.

• Prometheus의 비용은 시계열 수(카디널리티)로 결정된다: Prometheus는 (메트릭 이름 + 라벨 값 조합) 하나하나를 개별 시계열로 저장합니다. .*로 모든 MBean을 노출하면 시계열이 수천~수만 개가 되고, 메모리·디스크·쿼리 시간이 모두 이 수에 비례합니다.
• unbounded 라벨 하나가 폭발을 부른다: path(요청 URL), user_id, session_id, trace_id처럼 값의 종류가 무한히 늘어나는 라벨을 하나만 붙여도 시계열이 수백만으로 튑니다. status_code(값 몇 개)는 안전하지만, URL·ID 같은 고카디널리티 라벨은 치명적입니다.
• 증상은 대상이 아니라 Prometheus에서 터진다: head series 급증 → Prometheus 메모리 폭증·OOM, scrape 지연, 쿼리 타임아웃. 정작 앱은 멀쩡한데 모니터링 시스템이 먼저 쓰러집니다. prometheus_tsdb_head_series 값으로 상시 감시해야 합니다.
• 다음 단계는 화이트리스트와 relabel: .* 대신 필요한 MBean만 pattern으로 좁히고, 불필요한 시계열은 metric_relabel_configs의 drop으로 잘라냅니다. unbounded 값은 애초에 라벨로 만들지 않습니다(URL은 라우트 템플릿으로 정규화). 무거운 대시보드 쿼리는 recording rule로 미리 집계해 둡니다.

즉 "다 수집해두면 언젠가 쓰겠지"가 아니라, "이 라벨의 값이 몇 종류까지 늘 수 있나"를 노출 전에 따지는 것이 관측 파이프라인의 기본 위생입니다.