Latency, TPS와 RPS 측정

Overview

Latency와 Throughput은 측정 경계를 적지 않으면 비교할 수 없다. API RPS, DB TPS, Kafka Consume Rate, SMTP Success TPS는 서로 다른 일을 센다. 특히 Attempt가 늘어도 성공이 늘지 않으면 성능 개선이 아니다.

핵심 용어

지표	정의
Latency	한 작업의 시작부터 완료까지 걸린 시간
RPS	초당 Request 수. 시도/완료/성공 중 무엇인지 명시
TPS	초당 Business Transaction 또는 DB Commit 수
Concurrency	동시에 진행 중인 작업 수
Service Time	Queue 대기를 제외하고 실제 처리한 시간
Response Time	Queue·Network를 포함해 Client가 느낀 시간

왜 필요한가

한 시스템의 “50 TPS”가 발송 시도인지 실제 성공인지 모르면 Capacity 판단을 잘못한다. Client p99가 긴데 Server 처리 시간은 짧다면 Network나 Queue가 병목일 수 있다. 같은 단위와 Window를 맞춰야 원인과 결과를 연결할 수 있다.

핵심 원리와 내부 동작

Little's Law의 안정 상태 근사 L = λW는 동시 진행 작업 수가 도착률×평균 체류시간과 연결됨을 보여준다. 100 RPS에 평균 0.2초면 약 20개가 동시에 진행된다. Timeout·Retry가 생기면 Attempted RPS와 Unique Business 성공률을 별도로 센다.

Example

휴머스온 대량발송 기록처럼 Attempt TPS 96인데 Success TPS가 약 48이고 실패가 절반이면 “2배 빨라졌다”가 아니다. 외부 SMTP 제한에 먼저 막혔다는 가설을 세우고 Producer 유입, Consumer Lag, Buffer, Worker, 성공률을 같은 Timeline으로 본다.

attempted_rps = 전체 시도 / 시간
completed_rps = 응답 완료 / 시간
success_rps   = 비즈니스 성공 / 시간
goodput       = SLO 안에서 완료된 유효 작업 / 시간

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

평균은 Tail을 숨기고, 짧은 Window 최대치는 Noise에 민감하다. Batch TPS는 Batch 크기에 따라 달라진다. Retry를 새 성공처럼 세면 처리량이 부풀려진다. Async API 응답 속도만 재고 실제 Queue 완료를 빼면 End-to-end 성능을 놓친다.

흔한 오해

TPS와 RPS는 언제나 교환 가능한 말이 아니다.
낮은 Server Time이 낮은 Client Latency를 보장하지 않는다.
처리량 증가가 오류와 Queue 증가를 동반하면 Capacity 개선이 아니다.
평균 Latency만으로 사용자의 느린 경험을 설명할 수 없다.

Production Considerations

Metric 이름에 Boundary, Outcome, Unit을 넣는다. Client/Ingress/App/Queue/DB/Dependency 시간을 Trace로 분해하고 동일 Timestamp를 사용한다. Timeout과 실패 요청도 Histogram에 포함하며, Success Goodput과 Backlog 회복 시간을 함께 보고한다.

다른 사람에게 설명한다면

30초: “RPS는 요청 수, TPS는 정의한 Transaction 수이고 반드시 시도·완료·성공 경계를 적어야 합니다. Latency도 Client 전체 시간과 Server 처리 시간을 구분해야 하며, 오류를 제외한 Goodput과 p99를 함께 봅니다.”

2분: Little's Law로 RPS·Latency·Concurrency를 연결한 뒤 Attempt TPS와 Success TPS가 다른 실제 발송 사례, Queue 포함 End-to-end 측정을 설명한다.

Interview Questions

TPS와 RPS는 언제 다른가?
Attempt TPS와 Success TPS를 왜 나누는가?
Little's Law를 Capacity에 어떻게 쓰는가?
Async 작업의 Latency 종료점은 어디인가?

부하 테스트, Percentile 측정 오류, 병목 분석로 이어간다.