리틀의 법칙으로 성능과 용량을 계산하는 방법

시스템 안에 쌓이는 양은 처리율과 체류 시간으로 설명된다

리틀의 법칙은 시스템 내부의 평균 객체 수, 시스템으로 들어오는 비율, 그리고 객체가 머무는 시간을 연결하는 대기열 이론의 원리다. 1961년 존 리틀(John Little)이 증명했으며, 안정적인 시스템이라면 세부 구조와 무관하게 적용할 수 있다.

핵심 관계는 다음과 같다.

L = λW

• L: 시스템 안의 평균 객체 수. 재고, 고객, 요청 등이 될 수 있다.
• λ: 단위 시간당 시스템 진입률(arrival rate)
• W: 시스템 내 평균 체류 시간(처리 시간)

이 관계는 시스템에 들어온 객체가 결국 시스템을 떠난다는 보존 원칙을 전제로 한다. 일시적인 변동보다 장기 평균을 다룰 때 유용하며, FIFO(선입선출) 방식이 아니어도 적용할 수 있다.

고객과 부품의 흐름으로 보는 계산

편의점에 시간당 100명의 고객이 들어오고(λ=100), 각 고객이 평균 6분(0.1시간)을 머문다면(W=0.1), 매장 안의 평균 고객 수는 다음과 같다.

L = λ × W = 100 × 0.1 = 10명

평균적으로 편의점에는 10명의 고객이 있는 셈이다.

레스토랑도 같은 방식으로 좌석 수를 계획할 수 있다. 시간당 30명이 방문하고(λ=30), 평균 식사 시간이 45분(W=0.75시간)이면 평균 손님 수는 L = 30 × 0.75 = 22.5명이다.

제조 라인에서 시간당 60개 부품을 생산하고(λ=60), 각 부품의 처리 시간이 5분(W=1/12시간)이라면 라인 위 평균 부품 수는 L = 60 × (1/12) = 5개가 된다.

동시 사용자와 처리량을 연결하는 성능 분석

IT 성능 테스트에서는 리틀의 법칙을 다음처럼 해석한다.

CU = λ × W

• CU: 동시 사용자 수(Concurrent Users)
• λ: 초당 트랜잭션 수(TPS)
• W: 요청 처리 시간(Response Time)과 사용자 생각 시간(Think Time)의 합

웹 서비스에서 사용자는 요청을 보내고 응답을 받은 뒤, 다음 요청 전까지 Think Time을 보낸다.

⤢✕

초당 50개 요청을 처리하고(λ=50 TPS), 평균 응답 시간이 0.2초, Think Time이 평균 4.8초라면 총 체류 시간은 W = 0.2 + 4.8 = 5초다. 이때 동시 사용자 수는 CU = 50 × 5 = 250명으로 계산된다.

데이터베이스에서도 같은 관계를 적용할 수 있다. 초당 100개 쿼리가 들어오고(λ=100), 평균 실행 시간이 0.15초(W=0.15)라면 동시 실행 쿼리 수는 L = 100 × 0.15 = 15개다. 이 값은 데이터베이스 서버에 필요한 리소스를 예측하는 기준이 된다.

측정값을 혼동하지 않기 위한 기준

성능 테스트에서 사용자 수는 같은 의미로 쓰이지 않는다.

• Named User: 시스템에 등록된 총 사용자 수
• Active User: 특정 기간에 시스템을 사용한 사용자 수
• Concurrent User: 동시에 시스템을 사용하는 사용자 수

시간 측정에는 Mean Response Time, Think Time, Request Interval Time이 쓰인다. Mean Response Time은 요청의 평균 응답 시간이고, Think Time은 다음 요청 전 사용자가 생각하는 시간이며, Request Interval Time은 요청 사이의 평균 시간 간격이다.

처리량은 TPS(Transaction Per Second)와 RPS(Request Per Second)로 측정한다. TPS는 초당 처리되는 트랜잭션 수, RPS는 초당 처리되는 요청 수다.

클라우드 용량을 조절할 때의 활용

클라우드 환경에서는 초당 트랜잭션 수(λ)와 평균 처리 시간(W)을 관찰하면서 필요한 서버 용량(L)을 조절할 수 있다.

⤢✕

이 관계는 오토스케일링 정책 수립, 비용 효율적인 리소스 프로비저닝, 필요한 서비스 수준을 위한 용량 산정에 활용할 수 있다.

단계별로 나누면 병목이 드러난다

여러 단계를 거치는 시스템은 각 단계에 리틀의 법칙을 따로 적용할 수 있다.

⤢✕

전체 시스템에 머무는 객체 수는 각 단계의 합으로 표현된다.

L = L1 + L2 + L3 = λ(W1 + W2 + W3)

단계별 처리 시간(W)을 비교하면 가장 긴 시간이 걸리는 구간을 찾을 수 있다. 특정 단계의 객체 수(L)가 비정상적으로 높다면 그 지점 역시 병목 후보가 된다.

용량 계획과 서비스 수준에 쓰는 관계식

예상 수요(λ)와 원하는 서비스 시간(W)이 있으면 필요한 리소스(L)를 산정할 수 있다. 처리 시간(W)을 줄였을 때 처리량(λ)과 수용 능력(L)이 어떻게 달라지는지도 예측할 수 있다.

따라서 리틀의 법칙은 SLA를 만족하기 위한 시스템 요구사항을 정하고, 필요한 최소 리소스로 서비스 수준을 맞추며, 자원 배분의 근거를 세우는 데 쓰인다.

성능 개선 시나리오로 확인하기

현재 평균 응답 시간이 2초이고 초당 트랜잭션이 50 TPS라면 동시 사용자 수는 L = 50 × 2 = 100명이다.

동시 사용자 200명을 지원하려는 목표 상태에서는 L = 200, λ = 50 TPS일 때 필요한 응답 시간이 W = L/λ = 200/50 = 4초가 된다.

시스템 개선 후 응답 시간을 1초로 낮추면, 동일한 인프라에서 처리 가능한 TPS는 λ = L/W = 100/1 = 100 TPS다. 처리량은 100% 향상할 수 있다.