큐와 대기는 어떤 지표로 드러나는가

앞 글에서 “무엇을 봐야 하는가”를 정했다면,
이번에는 그게 실제로 어떤 숫자로 나타나는지를 고정한다.

---

큐와 대기는 어떤 지표로 드러나는가

— 보이지 않던 병목을 숫자로 붙잡는 법

성능 문제를 처음 관측하려 하면
대부분 여기서 막힌다.

• “큐가 있다는데, 어디에 있죠?”
• “대기 시간이 늘었다는데, 뭐가 늘어난 거죠?”
• “지표는 많은데, 연결이 안 돼요”

문제는 지표가 없는 게 아니다.
지표를 해석할 기준이 없는 것이다.

큐와 대기는
하나의 숫자로 나타나지 않는다.
‘패턴’으로 드러난다.

---

1. 큐를 직접 보려 하지 마라

먼저 중요한 전제를 하나 세우자.

대부분의 큐는
직접 볼 수 없다.

• 이벤트 루프 큐 ❌
• 내부 요청 큐 ❌
• 스레드 대기열 ❌

그래서 우리는 간접 지표를 본다.
큐는 항상 시간으로 자신을 드러낸다.

---

2. 큐가 생기면 가장 먼저 변하는 숫자

큐가 생길 때
가장 먼저 변하는 건 이거다.

응답 시간의 분포

평균은 거의 안 움직일 수 있다.
하지만 다음이 달라진다.

• p95
• p99
• 최대 응답 시간

이 패턴을 기억하자.

평균은 정상인데
꼬리(tail)만 길어진다 →
큐가 생겼다.

 

---

3. “느린 요청 비율”은 큐의 그림자다

이 지표를 반드시 봐야 한다.

• 전체 요청 중
• 특정 시간 이상 걸린 요청의 비율

예를 들면:

• 1초 초과 요청 2% → 정상
• 1초 초과 요청 20% → 위험

이 비율이 늘어난다는 건:

일부 요청이
먼저 큐에 들어가기 시작했다는 뜻

---

4. 처리 시간 vs 전체 시간, 반드시 나눠 봐야 한다

관측에서 가장 중요한 분해다.

• Service Time: 실제 실행 시간
• Total Latency: 클라이언트가 느낀 시간

이 둘의 차이가 바로:

대기 시간(wait time)

패턴은 아주 명확하다.

• Service Time → 거의 동일
• Total Latency → 점점 증가

일은 그대로인데
기다림만 늘어난다 = 큐

---

5. Node.js에서 큐는 이렇게 드러난다

Node.js에서는 큐가
이 지표들로 새어나온다.

• 이벤트 루프 지연(Event Loop Lag)
• 응답 시간 p95/p99
• 처리량은 그대로인데 지연 증가

특히 이 패턴은 강력하다.

이벤트 루프 지연 ↑
CPU 사용률 ↓ 또는 동일

이 조합은:

**“일이 쌓였는데
실행이 못 따라간다”**는 뜻이다.

---

6. Java 서버에서 큐는 이렇게 보인다

Java에서는 큐가
다른 얼굴로 나타난다.

• 스레드 풀 사용률 100%
• 처리량 정체
• 응답 시간 급증

하지만 여기서도 핵심은 같다.

• 실행 시간은 비슷
• 대기 시간이 증가

즉,

스레드 대기 = 큐

---

7. “처리량이 유지되는데 느리다”는 신호

이 말이 나오면
거의 확정이다.

• TPS는 유지
• 에러도 없음
• 응답만 느림

이건 최적화 문제가 아니다.

큐가 생겼고,
시스템이 실패를 미루고 있다.

---

8. 타임아웃 지표는 큐의 끝자락이다

타임아웃은
큐가 임계점에 다다랐다는 신호다.

• 타임아웃이 늘기 시작하면
• 이미 큐는 한참 전부터 쌓였다

그래서 타임아웃은:

원인이 아니라
결과 지표다.

---

9. 관측 대시보드를 볼 때의 올바른 순서

이 순서를 기억하자.

1. 처리량 (TPS)
2. 응답 시간 분포 (p95/p99)
3. 느린 요청 비율
4. 대기 관련 지표
5. 타임아웃 / 재시도

이 순서를 지키면
“CPU부터 보는 습관”에서 벗어난다.

---

10. 한 문장 정리

큐는
숫자로 존재하지 않고,
‘시간의 왜곡’으로 드러난다.

---

다음 글 예고

이제 마지막 질문이 남았다.

“이 지표들이
언제부터 위험한가?”

다음 글에서는
임계점을 어떻게 잡는지를 다룬다.

p95는 언제 경고가 되고,
p99는 언제 장애가 되는가
— 숫자에 의미를 부여하는 기준선 만들기

이제 관측은
해석의 단계로 들어간다.