이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- APM은 Spring 백엔드 장애를 어떤 관점에서 보여 주는가?
- Latency, error rate, throughput, saturation을 어떻게 함께 읽어야 하는가?
- APM 지표를 보고 원인을 단정할 때 무엇을 조심해야 하는가?
개요
APM은 Application Performance Monitoring의 약자다.
Spring 애플리케이션 안에서 요청이 얼마나 들어오고, 얼마나 오래 걸리고, 어디서 실패하고, 어떤 외부 의존성이 느린지 보여 준다.
APM은 서버 CPU 그래프만으로는 보이지 않는 애플리케이션 내부 경로를 보여 주는 도구다.
하지만 APM 화면 하나만 보고 원인을 확정하면 위험하다.
APM은 로그, 메트릭, 트레이스, 배포 이력과 함께 읽어야 한다.
핵심 지표
APM에서 가장 먼저 보는 지표는 보통 네 가지다.
latency: 요청 처리 시간
error rate: 실패 비율
throughput: 단위 시간당 요청량
saturation: thread, connection pool, queue, CPU 같은 자원 포화Latency가 오르고 throughput이 그대로라면 내부 처리 지연을 의심한다.
Throughput이 급증하면서 latency가 오르면 트래픽 증가나 rate limit 기준을 본다.
Error rate만 오르면 특정 endpoint, 예외 유형, 최근 배포를 먼저 본다.
Saturation이 함께 오르면 자원 병목이 원인 후보가 된다.
Spring Transaction
APM은 보통 HTTP transaction을 endpoint 단위로 보여 준다.
예를 들어 POST /api/orders의 p95 latency, error rate, 호출량을 볼 수 있다.
Spring controller, service, repository, 외부 HTTP client 호출이 trace나 segment로 나뉘어 보일 수도 있다.
이때 endpoint 이름이 path variable 값으로 폭발하지 않도록 template 기준으로 잡혀야 한다.
/api/orders/{id}가 아니라 /api/orders/12345가 metric 이름처럼 쌓이면 분석과 비용이 모두 나빠진다.
외부 의존성
APM의 장점은 DB query, Redis, 외부 API 호출 시간을 애플리케이션 요청과 연결해 보는 것이다.
POST /api/orders p95 1200ms
DB SELECT product 80ms
DB INSERT order 40ms
HTTP payment-api 950ms이 예시에서는 Spring 코드 전체가 느리다기보다 payment API 지연이 핵심 후보가 된다.
반대로 DB connection pool 대기 시간이 길면 query 자체보다 pool saturation을 먼저 봐야 한다.
배포와 연결
APM 지표는 배포 version과 함께 봐야 한다.
새 version 배포 직후 error rate가 올랐다면 version별 지표가 필요하다.
/actuator/info, artifact version, APM release marker가 서로 맞아야 한다.
배포 이벤트가 APM timeline에 표시되면 latency 상승 시점과 변경 시점을 빠르게 비교할 수 있다.
운영 체크리스트
- APM에서 endpoint별 latency p95/p99를 볼 수 있는가?
- Error rate가 status, exception, endpoint 기준으로 분리되는가?
- Throughput 변화와 latency 변화를 함께 볼 수 있는가?
- DB, Redis, external API 시간이 transaction 안에서 보이는가?
- Thread pool, connection pool, queue 같은 saturation 지표가 있는가?
- Release/version 정보가 APM timeline과 연결되는가?
- APM 지표와 로그/trace id를 함께 추적할 수 있는가?
장애 신호
- 전체 latency는 정상인데 특정 endpoint p99만 치솟는다.
- Error rate가 증가하지만 exception grouping이 너무 뭉뚱그려져 있다.
- Throughput은 그대로인데 DB connection pool wait가 증가한다.
- 외부 API segment가 전체 transaction 시간 대부분을 차지한다.
- 배포 직후 새 version에서만 5xx가 증가한다.
- APM agent overhead나 sampling 설정 변경 후 지표가 급격히 변한다.
안전한 완화 조치
APM에서 느린 구간이 보이면 해당 구간을 바로 원인으로 확정하지 않는다.
DB 지연이면 slow query, connection pool, lock wait를 함께 확인한다.
외부 API 지연이면 timeout, retry, circuit breaker, upstream status를 확인한다.
APM agent 설정을 장애 중 크게 바꾸면 관측 기준 자체가 바뀔 수 있다.
Sampling이나 instrumentation 변경은 영향 범위를 알고 작은 단위로 적용한다.
인프라 담당자와 공유할 자료
증상: 주문 생성 p95 latency 증가
service: order-api
version: 1.8.3-abc1234
APM transaction: POST /api/orders
latency: p95 240ms -> 1200ms
throughput: 평소와 유사
slow segment: HTTP payment-api 950ms
error rate: 0.1% -> 0.4%
요청: payment-api latency와 network timeout 지표 확인APM 자료는 endpoint, version, 지표 변화, 느린 segment, 최근 변경을 함께 전달해야 실무적으로 쓸 수 있다.
실전 팁
- APM 첫 화면은 원인 확정이 아니라 후보 축소에 쓴다.
- 평균보다 p95/p99를 본다.
- Error rate는 endpoint와 exception 기준으로 나눈다.
- 외부 의존성 시간과 application 처리 시간을 분리한다.
- 배포 marker와 version field를 APM에 연결한다.
위험 신호!
- APM 화면 하나만 보고 DB가 원인이라고 단정한다.
- Throughput 변화를 보지 않고 latency만 본다.
- Endpoint 이름이 고유 id를 포함해 폭증한다.
- Agent 설정을 장애 중 무작정 바꾼다.
- APM 지표와 실제 사용자 영향이 연결되어 있지 않다.
확인 질문
확인 질문
- APM이 서버 CPU 그래프보다 더 알려 주는 것은 무엇인가?
- 요청별 latency, error, endpoint, 외부 의존성, DB query 같은 애플리케이션 내부 경로를 보여 준다.
- Latency 상승을 볼 때 throughput도 같이 봐야 하는 이유는 무엇인가?
- 트래픽 증가로 인한 지연인지, 같은 요청량에서 내부 처리 지연이 생긴 것인지 구분하기 위해서다.
- APM 지표만으로 원인을 확정하면 위험한 이유는 무엇인가?
- APM은 후보를 좁히는 신호이며 로그, trace, DB 지표, 배포 이력과 맞춰 봐야 실제 원인을 판단할 수 있기 때문이다.