Little's Law로 읽는 성능 한계와 용량 계획

처리량이 멈추는 지점은 어떻게 읽는가

Little's Law(리틀의 법칙)는 대기행렬 이론에서 평균 체류 수, 평균 유입률, 평균 체류 시간의 관계를 설명하는 정리다. 웹 서비스, API, 배치 처리처럼 요청이나 작업이 시스템 안을 통과하는 환경에서 성능 시험 결과를 해석하는 기준으로 쓸 수 있다.

핵심 관계는 다음과 같다.

평균 객체 수 L = 평균 유입률 λ × 평균 체류 시간 W
L = λ × W

이 식은 안정 상태(steady state)와 보존 법칙, 평균값을 전제로 한다. 성능 관점에서는 시스템 안에 머무는 요청 수, 처리량, 응답 시간이 서로 분리된 지표가 아니라는 점을 보여 준다.

부하 모델에 지표를 대입하는 방법

폐쇄형 부하 모델에서는 동시사용자 수를 처리 중인 사용자와 비활성 사용자로 나눠 볼 수 있다.

CU = ActiveUser + InActiveUser
TPS(건/초) = CU(명) / (RT(초) + TT(초))
AC ≈ ActiveUser
MRT ≈ RT
TPS = AC / MRT

여기서 Request Interval은 Response Time(RT) + Think Time(TT)이다. 고정된 사용자 수와 사고 시간(Think Time)을 제어하는 폐쇄형 모델은 실험 조건을 통제하기 쉽다.

개방형 부하 모델에서는 평균 큐 길이 또는 동시 처리 건수를 다음과 같이 해석한다.

L = TPS × MRT

큐가 늘어날수록 RT가 높아지고 L이 급격히 커질 수 있다. 랜덤 도착률을 제어하는 개방형 모델은 실제 트래픽을 가깝게 재현하는 데 유리하지만, 안정 상태를 확보하기는 더 어렵다.

성능 시험에서 함께 관찰할 지표는 ConcurrentUser, ActiveUser/InActiveUser, Throughput(TPS), Response Time(RT), Think Time(TT), Request Interval(RT+TT), 부하(Load)다. 이들의 단위가 맞아야 하며, 모니터링 수집 주기와 테스트 시나리오의 Request Interval도 정합성을 가져야 한다.

선형 구간이 끝나는 순간의 징후

안정 상태가 유지되는 동안에는 평균값 기준으로 L, λ, W의 선형 관계를 이용해 예측할 수 있다. 그러나 CU를 계속 늘려도 TPS가 더 이상 늘지 않고 완만해지면 포화점에 접근한 것이다.

이때 보통 다음 현상이 함께 나타난다.

TPS 대 CU 곡선의 기울기가 낮아진다.
RT가 급격히 상승한다.
에러와 타임아웃이 증가한다.
큐 길이가 늘어난다.

포화점 이전에는 수평 확장의 효율이 높고 RT 분산도 안정적이다. 포화 구간으로 넘어가면 증설 대비 성능 개선 폭이 제한되고 비용 효율도 나빠진다. RT 변동성과 긴 꼬리(latency tail)가 커지며, 오류·재시도·큐 폭증이 운영 복잡도를 높인다.

항목	임계치 이하(선형 구간)	임계치 이상(포화 구간)
성능(Throughput)	CU 증가에 비례하여 TPS 선형 증가	ΔTPS/ΔCU 감소, TPS 정체 또는 하락
확장성	수평 확장 효율 높음	증설 대비 성능 개선 한계, 비용 비효율
일관성	RT 분산 안정, P90/P99 완만	RT 변동성 급증, 긴 꼬리(latency tail) 확대
안정성	에러율·타임아웃 낮음	오류·재시도·큐 폭증으로 불안정
운영 편의	튜닝 난이도 낮음, 예측 용이	임시 완화책 증가, 운영 복잡도 상승

용량 산정과 운영 판단에 연결하기

웹/API 용량을 산정할 때는 목표 SLA에 맞춰 TT를 가정하고 CU를 증가시키며 TPS를 측정한다. TPS ≈ CU/(RT+TT)의 선형 구간이 유지되는 범위가 허용 가능한 용량 판단의 근거가 되며, 포화점 직전의 CU는 운영 한계치 후보가 된다.

데이터베이스 커넥션 풀도 활성 세션(AC)과 MRT를 관찰해 L = TPS×MRT 관계로 살펴볼 수 있다. 큐 대기가 증가하면 커넥션 증설이 필요한지, 쿼리나 인덱스를 최적화해야 하는지 판단할 수 있다.

클라우드 오토스케일 정책은 포화점 대비 안전 여유인 70~80% 지점에서 스케일아웃을 트리거로 삼을 수 있다. 워크로드 특성에 따라 TT를 조정하면 사용자 체감 품질을 관리하는 데도 도움이 된다.

테스트 결과가 남기는 근거

성능 테스트는 트래픽 목표, SLA, 위험 가정을 세우는 계획 단계에서 시작한다. 이어 테스트베드·데이터 세트·애플리케이션·DB·시스템 모니터링을 준비하고, CU 범위와 RT/TT 가정, 종료 조건, 실패 기준을 설계한다.

실행 구간은 런업, 스테디, 런다운으로 나누고 에러와 타임아웃을 기록한다. 분석 단계에서는 TPS-CU 곡선과 RT 분포를 함께 읽어 임계치와 허용 가능 용량을 산정한다.

⤢✕

임계치를 판단할 때는 TPS-CU 곡선의 구간 기울기 ΔTPS/ΔCU가 임계값 ε 이하로 처음 떨어지는 지점을 확인한다. 예를 들어 ε ≤ 0.1 TPS/사용자를 기준으로 둘 수 있다. 같은 시점에 RT 중앙값과 90퍼센타일이 급상승하는지, 에러율이 늘어나는지, L = TPS×MRT가 급증하는지, CPU/IO 같은 자원 사용률과 상관이 있는지를 함께 검증한다.

RT=0.2s, TT=0.8s, CU=100이면 TPS≈100/(0.2+0.8)=100 TPS다. CU가 늘면서 TPS가 130까지 선형으로 증가한 뒤 ΔTPS/ΔCU < 0.05로 둔화된다면 포화점은 CU≈130으로 추정할 수 있다. 운영 한계치는 이 포화점의 70~80%로 설정하는 방식을 권장한다.

수식으로 일관된 용량 관리 체계를 만들기

포화점 이전에서 운영하면 타임아웃과 오류율이 30~70% 감소할 것으로 기대할 수 있다. 수평·수직 확장 전략의 비용 대비 효과도 정량화할 수 있다.

같은 관계식을 테스트와 운영에서 공유하면 애플리케이션, DB, 인프라 중 어디에서 성능 문제가 시작됐는지 분리하기 쉬워진다. 릴리스 게이트의 기준도 명확해지고, 성능 결과를 두고 논의하는 방식이 표준화된다.