서버는 살아있는데 서비스가 느릴 때 확인 순서 7단계: 운영 장애를 빠르게 진단하는 실무 가이드

서버는 살아있는데 서비스가 느릴 때 확인 순서 7단계

운영 중인 서버가 다운되지는 않았는데, 사용자만 느리다고 말할 때가 있다.
헬스체크는 통과하고, 프로세스도 살아 있고, 에러 로그도 조용하다.

이런 상황에서 가장 위험한 대응은 감으로 추측하며 여기저기 설정을 바꾸는 것이다.
성능 문제는 반드시 순서가 있고, 그 순서를 지키지 않으면 원인을 놓치기 쉽다.

이 글에서는 실제 운영 환경에서 사용하는 방식 그대로,
“서버는 살아있는데 서비스가 느릴 때” 확인해야 할 7단계 진단 순서를 정리한다.

---

1단계. 정말 ‘느린’ 것이 맞는지부터 확인한다

첫 단계는 기술이 아니라 현상 정의다.

느리다는 말은 상황에 따라 의미가 다르다.

• 모든 요청이 느린가?
• 특정 API만 느린가?
• 특정 시간대에만 느린가?

이 단계에서 반드시 확인해야 할 것은 정량적인 수치다.
평균 응답 시간, 95퍼센타일, 타임아웃 발생 비율을 먼저 본다.
“느리다”는 감정이 아니라, 숫자로 표현되는 현상이어야 다음 단계로 갈 수 있다.

 

---

2단계. 네트워크/프록시 계층에서 막히는지 확인한다

서비스 요청은 대부분 다음 경로를 거친다.
클라이언트 → 프록시(Nginx) → WAS → DB

이 중 가장 바깥쪽부터 확인해야 한다.

프록시 계층에서 확인할 포인트는 다음과 같다.

• 요청이 프록시까지 도달하는 데 지연이 있는지
• 타임아웃 설정(proxy_read_timeout 등)
• 동시 연결 수 제한

이 단계에서 프록시 로그를 보면,
요청이 WAS로 넘어가기 전인지, 이후에 막히는지를 분리할 수 있다.

 

---

3단계. WAS 스레드 상태를 확인한다

서버는 살아 있는데 느릴 때 가장 흔한 원인은 스레드 고갈이다.

CPU 사용률이 낮아도, 스레드가 모두 대기 중이면 요청은 처리되지 않는다.

확인해야 할 질문은 단순하다.

• 현재 사용 중인 스레드 수는?
• 대기 중인 요청이 있는가?
• 특정 요청이 스레드를 오래 점유하고 있지는 않은가?

스레드 덤프를 보면,
“서버가 왜 멀쩡해 보이는데도 느린지”가 눈에 보이기 시작한다.

---

4단계. 외부 호출(API, 파일, 메시지 큐)을 의심한다

WAS 내부 로직이 단순해도,
외부 시스템 호출 하나가 전체 응답 시간을 잡아먹을 수 있다.

대표적인 예는 다음과 같다.

• 외부 API 응답 지연
• 파일 시스템 접근 지연
• 메시지 브로커 대기

이 단계에서는 반드시 호출 전/후 로그가 필요하다.
로그가 없다면, 느린 지점을 증명할 방법도 없다.

---

5단계. DB 쿼리 성능을 점검한다

서비스 지연의 상당수는 결국 DB로 수렴한다.

다음 항목을 순서대로 확인한다.

• 느린 쿼리가 있는가?
• 실행계획이 바뀌지는 않았는가?
• 인덱스가 사용되고 있는가?

특히 중요한 것은 최근 배포 이후 실행계획 변화다.
SQL은 바뀌지 않았는데 통계 정보 변화로 성능이 급격히 나빠지는 경우도 흔하다.

---

6단계. 락(Lock)과 트랜잭션을 확인한다

CPU도 여유 있고 쿼리도 빠른데 서비스가 느리다면,
락 대기를 의심해야 한다.

다음과 같은 패턴은 특히 위험하다.

• 긴 트랜잭션
• 대량 업데이트와 실시간 조회의 충돌
• 불필요한 SELECT FOR UPDATE

락은 눈에 잘 보이지 않지만,
한 번 발생하면 전체 서비스 체감을 급격히 떨어뜨린다.

---

7단계. 캐시와 트래픽 패턴을 점검한다

마지막 단계는 구조적인 관점이다.

동일한 요청이 반복해서 DB까지 내려가고 있다면,
그 자체가 설계 문제일 수 있다.

• 캐시 적중률은 적절한가?
• 트래픽이 특정 API에 몰려 있지는 않은가?
• 불필요한 재요청이 발생하지는 않는가?

이 단계까지 오면, 단순한 장애 대응을 넘어
아키텍처 개선 포인트가 보이기 시작한다.

 

---

결론: 느림은 현상이 아니라 경로다

서비스가 느릴 때 가장 중요한 것은 “빨리 고치기”가 아니다.

어디서부터 어디까지 느린지 경로를 분리하는 것이다.

이 7단계 순서를 지키면,
감에 의존하지 않고도 문제를 재현하고 설명할 수 있다.

운영에서 성장하고 싶다면,
느림을 두려워하기보다 분해해서 이해하는 습관을 가져야 한다.