RED와 USE 방법론: 서비스 증상에서 시스템 병목까지 연결하는 법

RED와 USE는 dashboard template 이름이 아니라 무엇을 빠뜨리지 않고 물어볼지 정하는 성능 분석 방법이다. RED는 request를 처리하는 service의 사용자 관점에서 시작하고, USE는 CPU·memory·storage·network 같은 resource의 병목을 훑는다.

둘 중 하나를 고르는 문제가 아니다. RED로 ‘어느 service operation이 언제부터 나빠졌는지’를 찾고, 같은 시간대의 USE signal로 ‘어느 resource가 기다림을 만들었는지’를 좁히면 symptom과 cause를 연결하기 쉽다.

RED: 모든 Service의 Rate·Errors·Duration

Tom Wilkie가 정리한 RED method는 request-driven service마다 세 가지를 본다.

• Rate: 단위 시간에 처리하거나 시도한 request 수
• Errors: 실패한 request 수 또는 rate
• Duration: request가 완료되는 데 걸린 시간의 distribution

‘service’는 HTTP API에만 한정되지 않는다. RPC method, queue consumer, database operation처럼 작업이 들어오고 결과가 나오는 경계를 정할 수 있다면 RED 관점으로 볼 수 있다.

Rate의 분모부터 고정한다

HTTP server request만 셀지, retry와 background request를 포함할지, client와 server 중 어느 관측 지점을 쓸지 정해야 한다. 평균 RPS 하나는 burst를 숨길 수 있으므로 짧은 window와 긴 trend를 함께 본다.

Error는 status code 목록이 아니다

5xx뿐 아니라 timeout, cancellation, invalid result, dependency failure처럼 사용자 요청이 목적을 달성하지 못한 경우를 domain에 맞게 정의한다. 4xx도 모두 server error이거나 모두 정상인 것은 아니다. metric에는 bounded label만 사용하고 raw URL, user ID, exception message처럼 cardinality가 무한히 늘 수 있는 값은 넣지 않는다.

Duration은 평균보다 distribution으로 본다

평균 latency는 느린 일부 요청을 감출 수 있다. p50·p95·p99와 request volume을 함께 보고, SLO를 계산하려면 threshold 이하 ‘good request’ 비율도 측정한다. Prometheus histogram을 쓸 때 bucket은 실제 SLO threshold와 latency range에 맞춰 설계한다.

rate     = Δrequest_count / Δtime
error    = failed_requests / eligible_requests
duration = latency distribution + requests_under_SLO / eligible_requests

USE: 모든 Resource의 Utilization·Saturation·Errors

Brendan Gregg의 USE method는 각 resource마다 다음을 확인하는 checklist다.

• Utilization: 일정 구간 동안 resource가 busy였던 비율 또는 capacity 사용 정도
• Saturation: 처리하지 못한 extra work가 queue·wait·stall로 쌓인 정도
• Errors: error event 수

USE는 hardware에 특히 잘 맞지만 thread pool, file descriptor, cgroup quota 같은 software resource에도 유용할 수 있다. 중요한 것은 먼저 resource list를 만들고, 각 signal을 실제로 어떤 metric에서 읽을지 적는 것이다.

Resource	Utilization 예시	Saturation 예시	Error 예시
CPU	non-idle time, quota 대비 사용	run queue, scheduler delay, throttling	machine check·CPU fault 등 환경별 counter
memory capacity	working set·cgroup limit 대비 사용	reclaim·page scan·swap·memory PSI	OOM, allocation failure
storage device	busy time, IOPS·throughput	queue depth, I/O wait latency	timeout, reset, device error
network interface	link 대비 throughput	drop·overrun, queue backlog	carrier·CRC·driver error
thread pool	busy worker / capacity	waiting task·queue time	rejection·timeout

CPU 80% 같은 고정 threshold만으로 병목을 판단하지 않는다. 긴 평균 window의 낮은 utilization 안에도 짧은 100% burst와 queueing이 숨어 있을 수 있다. 반대로 높은 utilization이어도 saturation과 user latency가 안정적이면 즉시 문제가 아닐 수 있다.

기존 예제에서 빠졌던 것

CPU·memory·disk 사용률만 출력하는 psutil loop는 USE 전체를 구현하지 않는다. utilization 일부만 볼 뿐 queue, stall, throttling, error를 보여 주지 않는다. random sleep과 random error를 넣은 HTTP loop도 RED instrumentation의 label·histogram·failure semantics를 설명하기에는 부족하다.

methodology를 code snippet으로 대체하기보다 service와 resource별 metric contract를 먼저 작성한다.

service: checkout / POST create-order
rate: accepted attempts per second
errors: timeout, 5xx, invalid order result
duration: end-to-end server latency histogram

resource: payment worker pool
utilization: busy workers / configured workers
saturation: queued jobs and queue wait time
errors: rejected or expired jobs

RED에서 USE로 내려가는 Incident Flow

1. user-impacting SLI나 RED alert의 시작 시각과 affected operation을 고정한다.
2. rate 변화가 traffic 증가인지 retry storm인지 구분한다.
3. error code와 duration distribution을 endpoint·region·version의 bounded dimension으로 나눈다.
4. 같은 timeline에 deployment와 dependency event를 겹친다.
5. affected instance·node·cgroup의 CPU, memory, storage, network USE signal을 확인한다.
6. saturation이 보이면 queue 앞뒤의 latency와 workload를 더 좁힌다.
7. 변경 전후에 같은 load와 같은 SLI·resource signal로 효과를 검증한다.

예를 들어 p99만 상승하고 error는 그대로일 때 CPU 평균 사용률 하나로 결론 내리지 않는다. CPU throttling·run queue, lock·thread-pool queue, storage tail latency, downstream duration을 같은 request path에서 비교한다.

Cloud와 Kubernetes에서의 해석

container의 resource boundary는 host 전체와 다르다. CPU utilization이 낮아 보여도 cgroup quota 구간마다 throttling될 수 있고, node memory가 남아 있어도 container limit에서 OOM이 날 수 있다. network와 storage도 cloud provider·instance type·volume tier의 외부 limit이 병목이 될 수 있다.

• Pod metric, cgroup metric, node metric의 scope를 섞지 않는다.
• request rate와 replica 수 변화로 instance당 load가 어떻게 바뀌었는지 본다.
• CPU request·limit, HPA signal, throttling counter를 함께 본다.
• memory는 ‘사용률’ 하나보다 working set, reclaim, PSI, OOM event를 연결한다.
• disk·network의 advertised maximum과 실제 workload pattern을 구분한다.

delivery·reliability 지표의 상위 구조는 DevOps·SRE 지표 설계, 관측과 실험의 큰 원칙은 시스템 성능 엔지니어링 1장 학습노트에서 이어진다.

자주 묻는 질문

RED만 보면 root cause를 찾을 수 있나

RED는 user-facing symptom과 affected operation을 찾는 데 강하다. resource contention, code path, dependency 문제의 원인을 확정하려면 USE, trace, profile, log, experiment가 더 필요하다.

Error가 0이면 service가 정상인가

아니다. 모든 요청이 성공해도 latency가 SLO를 넘거나 stale data를 반환할 수 있다. error definition과 duration·correctness·freshness SLI를 함께 본다.

Utilization이 낮으면 saturation도 없나

아니다. 평균 window가 burst를 숨기거나, quota·queue·lock처럼 별도 resource에서 기다림이 생길 수 있다. utilization과 saturation을 같은 scope와 시간 해상도로 비교한다.

참고 자료

• Grafana Labs: The RED Method
• Brendan Gregg: The USE Method
• Prometheus Histograms and Summaries
• Google SRE Workbook: Monitoring