Spring Boot 성능 최적화 10

로그 처리 · 모니터링 고도화 (ELK · Prometheus · Grafana)

애플리케이션 성능을 개선하기 위해서는 단순히 코드를 최적화하는 것뿐 아니라, 서비스를 운영하면서 발생하는 지표와 로그를 정교하게 관측해야 한다.
관측(Observability)은 장애 감지, 성능 병목 추적, 트래픽 분석, 자원 사용량 최적화까지 서비스 운영의 핵심 요소다.
이 글에서는 실무에서 가장 많이 사용하는 모니터링 구성인 ELK + Prometheus + Grafana 중심으로 로그 · 메트릭 운영 전략을 정리한다.

---

＃로그(Log) 시스템 설계의 기본 원칙

로그는 많다고 좋은 것이 아니며, 적다고 안전한 것도 아니다.
로그는 “정확한 정보 · 적절한 양 · 구조화된 형태”의 3가지를 만족해야 한다.

로그 설계 3원칙

• 구조화된 로그 (JSON 권장)
• 레벨 기반 관리 (INFO / WARN / ERROR)
• 중복 로그 금지

JSON 로그는 검색, 필터링, 분석이 쉽기 때문에 ELK·Loki 같은 로그 시스템과 결합될 때 강력한 장점을 가진다.

Spring Boot JSON 로그 예시

logging:
  pattern:
    console: "{\"time\": \"%d{ISO8601}\", \"level\": \"%p\", \"msg\": \"%m\"}"

실무에서는 Logback JSON Encoder 또는 Logstash Encoder를 많이 사용한다.

---

＃ELK 스택(Logstash · Elasticsearch · Kibana)

ELK는 대규모 로그 시스템의 표준 구성이다.
로그를 수집(Logstash) → 저장(Elasticsearch) → 분석(Kibana) 하는 구조로 이루어진다.

ELK 구성 요소

• Logstash – 로그 수집기
• Elasticsearch – 로그 검색 엔진
• Kibana – 시각화 및 분석 UI

ELK가 필요한 이유

• 대량 로그 저장 및 검색 성능 우수
• 서비스별 로그 분리 및 필터링 용이
• 장애 분석·API 추적·사용자 행동 분석에 적합

Logstash 파이프라인 예시

input { beats { port => 5044 } }

filter {
  json { source => "message" }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "service-log-%{+YYYY.MM.dd}"
  }
}

서비스 규모가 커질수록 로그 파이프라인의 성능 영향이 커지므로, JSON 기반 구조화가 매우 중요하다.

---

＃Prometheus로 메트릭 수집

Prometheus는 시계열 메트릭(TSDB)을 저장하는 모니터링 시스템으로, Spring Boot Actuator와 결합하면 서버 성능을 상세히 분석할 수 있다.

Spring Boot Actuator 연동

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  metrics:
    enable:
      jvm: true
      system: true

Prometheus는 HTTP 엔드포인트(`/actuator/prometheus`)를 주기적으로 스크랩한다.

Prometheus가 제공하는 주요 지표

• JVM Heap / Non-Heap 사용량
• CPU 사용률
• GC 횟수 및 시간
• HTTP 요청 수 및 응답 시간
• DB 커넥션 풀 상태(HikariCP)

GC 튜닝, 장애 분석, 성능 최적화에서 Prometheus 메트릭은 사실상 필수다.

---

＃Grafana로 대시보드 구성

Grafana는 Prometheus 메트릭을 시각화하는 도구로, 실시간 서버 상태를 한눈에 확인할 수 있게 해준다.

실무에서 반드시 구성하는 대시보드

• API 응답 속도 (p95 / p99)
• DB 커넥션 풀 사용률
• Redis hit/miss 추이
• 트래픽 급증 탐지
• GC Pause 시간 변화
• 오류 로그 수집 대시보드

Grafana 알람(Alert) 구성

• API p99 > 1초
• CPU > 80%
• 메모리 사용률 > 85%
• 레디스 응답 시간 증가
• Elasticsearch 색인 지연 증가

알람을 잘 구성하면 장애 발생 전에 조기 탐지가 가능하다.

---

＃로그 · 메트릭 · 트레이싱 통합 (OpenTelemetry)

OpenTelemetry는 로그, 메트릭, 트레이스를 통합 관리하는 최신 관측성 표준이다.
특히 마이크로서비스 환경에서는 개별 서비스의 흐름을 추적하는 데 필수적이다.

OpenTelemetry가 제공하는 기능

• 분산 트레이싱(traceId 기반)
• 서비스 간 호출 관계 분석
• 오류 발생 지점 위치 파악
• API 레벨 지연 원인 추적

API 규모가 커질수록 Logging만으로는 병목 분석이 어려우며,
OpenTelemetry 기반 분산 트레이싱이 점점 필수화되는 추세다.

---

＃운영 환경에서의 실전 전략

1) API 병목 감지

• Grafana p99 증가 감지
• ELK에서 해당 API 로그 집중 조회
• Prometheus에서 DB/Redis 지연 확인

2) 장애 원인 분석

• ELK에서 ERROR 로그 패턴 분석
• OpenTelemetry로 호출 흐름 추적
• GC Pause 시간과 메모리 지표 확인

3) 트래픽 급증 대응

• Rate Limit 경고 알람
• API p99 지연 감지
• Redis · DB 커넥션 풀 증가 여부 확인

---

마치며

로그 · 메트릭 · 트레이싱은 단순한 기록이 아니라
서비스 성능, 장애 대응, 운영 안정성의 핵심 지표이다.
Spring Boot 서비스에서는 ELK + Prometheus + Grafana가 가장 실용적이며,
필요에 따라 OpenTelemetry로 확장하면 더 높은 수준의 관측성을 구축할 수 있다.

이렇게 해서 Spring Boot 성능 최적화 시리즈를 1편부터 10편까지 정리해보았다.
개별 요소들을 하나씩 살펴보면서, 단순히 “빠르게 만드는 법”이 아니라
어떤 부분이 실제 서비스 성능에 영향을 주고, 어떤 기준으로 선택해야 하는지를 더 명확하게 이해할 수 있었다.
앞으로 이 내용들을 프로젝트나 운영 환경에 하나씩 적용해보면서 더 깊게 다듬어갈 예정이다.