병목 분석과 Capacity 비교

Overview

병목은 “CPU가 높다”가 아니라 처리량을 더 늘리지 못하게 하는 제한 자원이다. Load를 단계적으로 높이며 Throughput 증가가 둔화되고 Latency·Queue가 급증하는 Knee Point를 찾아야 한다.

핵심 용어

왜 필요한가

Connection Pool을 바꾼 뒤 p99가 줄었다고 원인을 단정할 수 없다. Waiting Thread, DB CPU, Query 시간, 오류를 같은 Timeline에서 봐야 한다. Kafka Consumer Lag도 Broker가 아니라 SMTP Worker·내부 Buffer가 제한한 결과일 수 있다.

핵심 원리와 내부 동작

요청 RED로 증상을 찾고 자원 USE로 원인을 좁힌다. Queue는 병목 앞에 쌓인다. CPU 100%뿐 아니라 DB Connection Waiting, Thread Pool Queue, GC Pause, Network, 외부 Rate Limit이 Saturation 신호다.

flowchart LR; A[Load Rate] --> B[App Pool]; B --> C[DB Pool]; C --> D[(DB)]; B --> E[Broker Queue]; E --> F[Worker]; F --> G[External API]; Q1[Queue/Wait] -.병목 앞.-> C; Q2[Lag] -.병목 앞.-> F

Example

Before/After는 Application Version 외 CPU, JVM, DB 데이터, Warm-up, 요청 분포를 같게 한다. 각 부하 단계에서 p99, Success RPS, Error, CPU, GC, Pool Waiting, DB Query, Queue를 기록한다. 200 RPS에서 Success가 멈추고 Waiting이 오르면 Pool/DB 경로를 조사한다.

실무에서 발생하는 문제와 Trade-off

Pool 크기를 늘리면 Application 대기는 줄어도 DB 경쟁이 늘 수 있다. Worker를 늘리면 외부 Rate Limit 실패가 증가한다. Queue를 크게 하면 순간 부하는 흡수하지만 장애 발견과 복구 시간이 늦어진다. 최적화는 병목을 다음 단계로 이동시킨다.

흔한 오해

• 낮은 CPU가 여유를 뜻하지 않는다. I/O·Lock·Pool에서 기다릴 수 있다.
• Queue가 비어 있다고 건강한 것은 아니다. 앞 단계가 실패해 유입이 끊겼을 수 있다.
• Attempt Throughput 증가는 Goodput 증가가 아니다.
• 한 번의 최고 결과는 Capacity가 아니다.

Production Considerations

Peak 예측 오차, 장애 중 한 Instance 손실, 성장률을 포함해 Headroom을 둔다. Capacity Test 결과와 운영 Dashboard 지표 이름을 맞춘다. 중단 기준, 회복 시간, Auto Scaling 지연과 비용도 기록한다.

다른 사람에게 설명한다면

30초: “병목은 처리량 증가를 막는 제한 자원입니다. 요청은 RED, 자원은 USE로 보고 Queue가 쌓인 다음 단계를 찾습니다. 부하를 높여 Goodput이 둔화되고 p99가 치솟는 Knee Point에서 안전 여유를 뺀 값이 운영 Capacity 후보입니다.”

2분: Pool Waiting과 Kafka Lag 사례로 증상→원인 Timeline, 통제된 Before/After, 병목 이동과 Headroom을 설명한다.

Interview Questions

1. RED와 USE는 어떻게 함께 쓰는가?
2. Knee Point를 어떻게 찾는가?
3. Pool 크기를 늘리면 왜 DB가 더 느려질 수 있는가?
4. Capacity와 최고 처리량의 차이는?

Related Topics

부하 테스트, Latency·TPS·RPS로 연결한다.