진단 루프

대시보드 이상치를 코드 수준 병목으로 좁히는 순서

모니터링은 느려졌다는 신호를 잡고, 프로파일링은 어느 함수와 메모리 구간이 시간을 쓰는지 확인합니다.

메트릭이 가리키는 병목 가설

응답 시간

느린 라우트

특정 URL의 latency가 튀면 컨트롤러, 서비스, 외부 호출 순서로 범위를 좁힙니다.

처리량

포화 지점

RPS 증가와 함께 지연이 커지면 앱 인스턴스, 큐, DB 연결 수를 함께 봅니다.

에러율

실패 패턴

5xx 증가와 timeout은 로그와 트레이스에서 실패 지점을 먼저 확인합니다.

CPU

동기 계산

CPU가 높고 event loop가 밀리면 flame graph로 오래 도는 함수를 찾습니다.

Heap

메모리 증가

요청 후에도 heap이 내려오지 않으면 snapshot으로 참조가 남은 객체를 추적합니다.

DB

쿼리와 잠금

앱 메트릭만으로 부족하면 쿼리 실행 시간과 lock 지표를 함께 대조합니다.

모니터링에서 프로파일링으로 넘어가는 판단

1 대시보드 이상치 시간대, 라우트, 인스턴스별로 문제가 반복되는지 먼저 확인합니다.
2 로그와 트레이스 어떤 요청 경로에서 DB, 외부 API, 큐 대기가 길어지는지 연결합니다.
3 CPU와 heap 분석 코드 내부 병목이 의심될 때 Chrome DevTools나 clinic.js로 깊게 봅니다.
4 수정 후 재측정 같은 메트릭과 같은 부하 조건으로 개선 전후를 비교해야 합니다.
운영 해석

평균 응답 시간만 내려도 tail latency가 남으면 사용자 체감은 나쁠 수 있습니다. Prometheus의 히스토그램과 프로파일 결과를 함께 읽어야 수정 우선순위가 선명해집니다.