초당 요청 수

초당 요청 수는 서버가 1초에 요청을 몇 건이나 끝내는지를 숫자 하나로 말해 줍니다. 그래서 지금 들어오는 양과 이 서버가 버티는 한계를 같은 잣대로 견줄 수 있습니다. 부하 테스트에서 목표를 잡을 때도 이 숫자를 씁니다.

쉽고 빠른 이해

초당 요청 수는 1초 동안 서버가 끝낸 요청 건수입니다. 주문 페이지가 1초에 300건을 받아냈다면 그 페이지의 초당 요청 수가 300입니다.

이 값이 없으면 「트래픽이 많다」는 말이 사람마다 다른 뜻이 됩니다. 서버를 몇 대 둘지, 어디까지 견디는지를 정할 때 댈 숫자가 없습니다.

어떻게 도나:

정해진 구간 동안 끝난 요청을 셉니다
센 건수를 그 구간의 초 수로 나눕니다
나온 값이 그 구간의 초당 요청 수입니다

대가는 뭉개짐입니다. 나눈 값이라 구간 안의 짧고 뾰족한 몰림이 평평해져 안 보입니다. 요청 하나하나의 무게가 다르면 같은 숫자라도 서버가 지는 부담은 다릅니다.

상세

고속도로 요금소를 떠올려 봅시다. 1분에 차 몇 대를 통과시켰는지 세면 그 요금소가 지금 얼마나 바쁜지, 얼마까지 감당하는지를 한 숫자로 말할 수 있습니다. 초당 요청 수는 서버에 대고 같은 것을 세는 값입니다.

초당 요청 수는 서버가 1초 동안 끝낸 요청의 개수입니다. 영어로는 RPS(Requests Per Second)라고 적고 실무에서도 이 줄임말을 그대로 부릅니다.

이 값이 없으면 「트래픽이 많다」는 말을 사람마다 다른 뜻으로 쓰게 됩니다. 서버를 몇 대 둘지, 어디까지 견디는지를 정하려면 셀 수 있는 잣대가 하나 있어야 합니다. 요청 건수는 웹 서버라면 어디서나 셀 수 있어서 이 잣대가 널리 쓰입니다.

이 값은 처리량의 한 갈래입니다. 처리량은 정해진 시간에 끝낸 일의 양을 두루 가리키는 말입니다. 그 일을 「요청」으로 잡고 시간을 「1초」로 잡은 것이 초당 요청 수입니다.

세는 법과 측정 창

세는 법은 나눗셈 하나입니다. 어떤 구간 동안 끝난 요청을 세고, 그 구간의 초 수로 나눕니다. 이 구간을 측정 창이라고 부릅니다.

측정 창을 얼마로 잡느냐가 보이는 그림을 바꿉니다. 창이 길수록 값이 평평해지고 짧을수록 봉우리가 드러납니다. 같은 하루를 1분 창으로 보면 튀는 구간이 보이지만 1시간 창으로 보면 그 구간이 사라집니다.

그래서 초당 요청 수를 말할 때는 창 길이를 같이 밝혀야 견줄 수 있습니다. 창을 안 밝힌 두 숫자는 같은 단위처럼 보여도 다른 것을 잰 값일 수 있습니다.

보낸 요청과 끝낸 요청

요청이 들어오는 속도와 서버가 끝내는 속도는 다릅니다. 들어오는 쪽을 도착률이라고 부르고, 끝내는 쪽이 초당 요청 수입니다. 서버가 들어오는 만큼 끝내고 있으면 두 값이 같습니다.

서버가 못 따라가면 두 값이 갈라집니다. 남은 요청은 큐에 쌓입니다. 큐는 아직 처리하지 못한 요청을 순서대로 세워 두는 줄입니다.

아래 그림은 그 갈림을 그렸습니다. 들어오는 값이 끝내는 값보다 크면 가운데 줄이 길어집니다.

flowchart TD
    A["들어오는 요청 · 도착률"] --> Q["대기 줄"]
    Q --> S["처리하는 서버"]
    S --> D["끝낸 요청 · 초당 요청 수"]
    D --> C{"두 값이 같나"}
    C -->|같다| E["줄 길이가 유지된다"]
    C -->|들어오는 쪽이 크다| F["줄이 길어지고 기다리는 시간이 늘어난다"]

줄이 길어지면 요청 하나가 답을 받기까지 걸리는 시간이 늘어납니다. 그 시간을 지연이라고 부릅니다. 초당 요청 수는 그대로인데 지연만 치솟는 구간이 이렇게 생깁니다.

동시에 도는 건수

초당 요청 수는 지연과 따로 놀지 않습니다. 한 건이 오래 걸릴수록 같은 초당 요청 수를 내는 데 필요한 동시 처리 건수가 많아집니다. 이 관계를 리틀의 법칙이 한 줄로 적습니다.

동시에 도는 건수는 초당 요청 수에 한 건의 처리 시간을 곱한 값입니다. 처리 시간이 0.05초인 요청을 초당 200건 끝내고 있다면 어느 때든 요청 열 건이 서버 안에서 돌고 있다는 뜻입니다.

초당 요청 수 × 한 건 처리 시간 = 동시에 도는 건수

200 × 0.05                    // 동시에 10건
200 × 0.2                     // 동시에 40건

둘째 줄은 같은 초당 요청 수에서 한 건이 네 배 오래 걸릴 때입니다. 동시에 붙잡고 있어야 하는 건수가 그만큼 늘어납니다. 스레드나 커넥션 풀처럼 동시에 쓸 수 있는 몫에 상한이 있으면 여기서 막히고, 그때부터 요청은 줄에서 기다립니다.

천장을 정하는 병목

서버가 낼 수 있는 초당 요청 수에는 상한이 있습니다. 상한을 정하는 것은 가장 먼저 꽉 차는 자원 하나입니다. 그 자원을 병목이라고 부릅니다.

병목이 될 수 있는 것은 여럿입니다. CPU(Central Processing Unit, 중앙 처리 장치) 계산량일 수도 있고, 디스크나 네트워크가 나르는 양일 수도 있고, 데이터베이스 커넥션 개수처럼 세어서 정해 둔 몫일 수도 있습니다.

천장에 닿은 뒤에도 요청은 계속 들어옵니다. 그때부터 초당 요청 수는 더 안 오르고 지연과 오류율만 올라갑니다. 부하를 조금씩 올리며 이 꺾이는 점을 찾는 것이 부하 테스트가 하는 일입니다.

요청 하나의 무게

같은 숫자라도 뜻이 다를 수 있습니다. 초당 요청 수는 건수만 세고 한 건이 얼마나 많은 일을 시키는지는 안 보기 때문입니다.

정적 파일 하나를 돌려주는 요청과 여러 테이블을 훑어 보고서를 만드는 요청이 똑같이 한 건입니다. 그래서 초당 요청 수가 같은 두 서비스가 전혀 다른 부담을 지고 있을 수 있습니다.

이 숫자를 혼자 두고 읽지 않는 까닭이 이것입니다. 응답 시간 분포와 오류율을 같이 봐야 지금 값이 여유 있는 값인지 아슬아슬한 값인지 알 수 있습니다. 경로마다 따로 세면 부담이 큰 경로를 가려낼 수 있습니다.

같은 꼴로 세는 다른 이름

세는 대상만 바꿔 같은 꼴로 만든 이름이 여럿 있습니다. 이름이 다르다고 다른 개념인 것은 아닙니다.

이름	1초에 세는 것
초당 요청 수	요청
TPS(Transactions Per Second, 초당 트랜잭션 수)	트랜잭션
QPS(Queries Per Second, 초당 질의 수)	질의
대역폭	오간 바이트

표에서 갈리는 것은 「한 건」을 무엇으로 볼지뿐입니다. 웹 서버 앞에서는 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜) 요청 하나가 한 건이고, 데이터베이스 앞에서는 질의 하나가 한 건입니다.

이 잣대가 맞는 통신 방식

초당 요청 수는 짧은 요청과 답이 되풀이되는 곳에서 잘 맞습니다. 요청 하나의 시작과 끝이 뚜렷해서 세기 쉽기 때문입니다. 웹 서버가 대표입니다.

한 번 이어 놓고 오래 쓰는 통신에는 안 맞습니다. 웹소켓이나 스트리밍은 연결 하나가 몇 분씩 살아 있어서 셀 「건」이 생기지 않습니다. 이럴 때는 동시 연결 수나 초당 메시지 수처럼 다른 것을 셉니다.

밤에 한 번 도는 배치 처리에도 안 맞습니다. 요청을 받아 답하는 모양이 아니라 초당 건수라는 잣대가 뜻을 잃습니다. 그런 일은 한 번 도는 데 걸린 시간이나 처리한 건수로 잽니다.

초당 요청 수

상세

세는 법과 측정 창

보낸 요청과 끝낸 요청

동시에 도는 건수

천장을 정하는 병목

요청 하나의 무게

같은 꼴로 세는 다른 이름

이 잣대가 맞는 통신 방식

관련 항목

초당 요청 수와 나란히 서비스를 재는 지표

초당 요청 수와 같은 꼴로 세는 다른 단위

초당 요청 수의 천장을 정하는 요인

초당 요청 수를 끌어올리는 수단

초당 요청 수를 일부러 묶어 두는 장치

초당 요청 수를 재고 시험하는 활동

초당 요청 수를 모으고 보여 주는 도구

초당 요청 수를 세는 대상이 되는 요청