TPS , Latency, 에러율, CPU 사용률이 높을때

전체 요청 흐름 파악해보자.

 

Client → Load Balancer → Web Server → Application Server → DB → 외부 API

 

대게 이런 구조인데,

 

 

1)

TPS 높음 + Latency 높음

• 의미: 요청이 많고, 각 요청 처리에 시간이 오래 걸림
• 필요 조치: 어떤 계층이 지연되는지 추적 필요

 

 

2)

CPU 사용률 높음

• Application 서버 병목 가능성
  • GC, 스레드 경쟁, 루프, 무한 재시도
• DB CPU 높음
  • 쿼리 최적화 필요성 검토

 

3)

모니터링 도구:

• 시스템: top, htop, perf
• Java: jstack, jstat, jvm heap dump
• 통합: APM (Datadog, New Relic, Pinpoint, Skywalking)

 

 

⏱️ Latency 높음

• 각 구간별 지연 시간 확인 필요
• 트레이싱 도구:
  • Spring Sleuth + Zipkin
  • OpenTelemetry
  • Jaeger

 

❌ 에러율 높은 경우

• DB 커넥션 풀 부족
• 타임아웃 설정 미흡
• 외부 API 응답 지연/오류
• 서버 자원 부족 (5xx 에러)

 

로그 분석 도구:

• Kibana + ELK stack
• Grafana + Loki
• CloudWatch Logs

 

포인트

Load Balancer	5xx 비율, Target 반응 시간	타겟 서버 과부하 여부
WAS (App 서버)	CPU, Memory, GC 시간, 스레드 수	GC 병목, 코드 루프 여부
DB	쿼리 응답 시간, CPU, Slow Query	인덱스 부재, Full Scan 여부
캐시(Redis 등)	히트율, 커넥션 수	캐시 미스 비율
외부 API	응답 시간, 에러율	타임아웃, 재시도로 인한 부하

 

 

병목 추적 단계별 접근법

 

1. APM으로 전체 트레이싱 확인 - 어디서 지연이 발생하는지 파악
2. 애플리케이션 서버 로그 분석 - 예외, 재시도 루프 등 검토
3. DB 모니터링 툴 확인 - 쿼리 응답시간, 실행계획 분석
4. 시스템 지표 검토 - CPU, Memory, Thread dump 등
5. 외부 의존성 점검 - API 연동, 캐시 성능 확인

 

 

결론 )

 

• 스레드 덤프에서 BLOCKED 스레드가 많으면 → 락 경합 또는 DB 병목 의심
• GC Time이 높으면 → 메모리 누수 또는 과도한 객체 생성 의심
• DB 쿼리 Execution Plan에서 Full Scan이 발견되면 → 인덱싱 검토 필요
• Latency만 높고 TPS는 낮으면 → 외부 API 병목 가능성 높음