초당 요청 수

초당 요청 수는 1초 동안 서버에 걸린 요청이 몇 건인지를 숫자 하나로 말해 줍니다. 이 숫자 하나로 지금 들어오는 양과 서버가 버티는 한계를 같은 잣대로 견줍니다. 부하 테스트에서 목표를 잡을 때도, 운영 중인 서비스가 얼마나 바쁜지 볼 때도 이 숫자를 씁니다.

상세

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

초당 요청 수는 1초 동안 센 요청의 개수입니다. 영어로는 RPS(Requests Per Second)라고 적습니다. 실무에서도 이 줄임말을 그대로 부릅니다. 웹 서버라면 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜) 요청 하나가 한 건입니다.

세는 쪽은 둘 중 하나입니다. 서버로 들어오는 요청을 셀 수 있습니다. 서버가 끝낸 요청을 셀 수도 있습니다. 정의는 같고 세는 위치만 다릅니다.

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

세는 법과 측정 창

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

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

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

들어오는 쪽과 끝내는 쪽

들어오는 쪽에서 센 초당 요청 수를 도착률이라고도 부릅니다. 서버가 들어오는 만큼 끝내고 있으면 이 값은 끝내는 쪽에서 센 값과 같습니다.

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

아래 그림은 그 갈림을 그렸습니다. 대기 줄 앞에서 두 값을 견줍니다. 들어오는 값이 끝내는 값보다 크면 대기 줄이 길어집니다.

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

줄이 길어지면 요청 하나가 답을 받기까지 걸리는 시간이 늘어납니다. 이 시간을 지연이라고 부릅니다. 응답 시간도 같은 것을 가리킵니다. 이때 끝내는 쪽의 초당 요청 수는 제자리에 머뭅니다. 치솟는 것은 지연뿐입니다.

부하를 거는 도구가 센 초당 요청 수는 보낸 속도라서 들어오는 쪽 값입니다. 서버가 따라가는 동안에는 끝내는 쪽 값과 같아서 둘을 가를 일이 없습니다.

서버 안에 머무는 건수

초당 요청 수는 지연과 따로 놀지 않습니다. 이 관계를 리틀의 법칙이 한 줄로 적습니다. 시스템 안에 머무는 평균 건수는 평균 도착률에 한 건이 머무는 평균 시간을 곱한 값과 같다는 식입니다(L = λW).

머무는 시간은 대기 줄에서 기다린 시간과 처리되는 시간을 합친 것입니다. 머무는 건수는 서버가 동시에 붙잡고 있는 요청의 수입니다.

세 값은 모두 오래 잰 평균입니다. 그리고 시스템이 정상 상태, 곧 오랫동안 같은 모습으로 돌고 있을 때 성립합니다. 서버가 들어오는 만큼 끝내고 있으면 도착률이 곧 끝내는 쪽의 초당 요청 수입니다. 그러면 식을 이렇게 읽을 수 있습니다.

초당 요청 수 × 한 건이 머무는 시간 = 서버 안에 머무는 평균 건수

200 × 0.05                          // 평균 10건
200 × 0.2                           // 평균 40건

첫 줄은 한 건이 0.05초 머무는 요청을 초당 200건 끝내는 서버입니다. 대기 줄 없이 바로 처리된다면 이 0.05초가 곧 처리 시간입니다. 서버 안에 요청이 평균 열 건 머문다는 뜻입니다.

둘째 줄은 같은 초당 요청 수에서 한 건이 네 배 오래 머물 때입니다. 서버가 붙잡고 있는 건수도 평균 마흔 건으로 늘어납니다. 스레드나 커넥션 풀처럼 동시에 쓸 수 있는 몫에 상한이 있으면 여기서 막힙니다. 그때부터 넘친 요청은 대기 줄에서 기다립니다.

천장을 정하는 병목

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

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

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

요청 하나의 무게

같은 숫자라도 뜻이 다를 수 있습니다. 초당 요청 수는 건수만 셉니다. 한 건이 얼마나 많은 일을 시키는지는 안 봅니다.

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

평균도 같은 것을 가립니다. 평균 지연이 100밀리초인 웹 서비스가 초당 1,000건을 받는다고 합시다. 이런 서비스에서는 요청의 1%가 5초씩 걸리는 일이 쉽게 생길 수 있습니다. 평균과 초당 요청 수만 보면 이 1%가 안 보입니다.

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

세는 대상만 다른 이름

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

표에서 갈리는 것은 「한 건」을 무엇으로 볼지뿐입니다. 웹 서버 앞에서는 HTTP 요청 하나가 한 건입니다. 데이터베이스 앞에서는 질의 하나가 한 건입니다.

배경

서비스를 굴리다 보면 「요즘 트래픽이 많다」는 말이 자주 나옵니다. 이 말은 사람마다 다른 것을 가리킵니다. 누구는 접속한 사람 수를, 누구는 오간 데이터 양을 떠올립니다. 이래서는 서버를 몇 대 둘지, 어디까지 견디는지를 정할 수 없습니다.

필요한 것은 시스템에 걸린 수요를 셀 수 있는 숫자였습니다. 사용자를 마주하는 시스템을 모니터링할 때 먼저 재는 네 신호를 골든 시그널이라고 부릅니다. 지연·트래픽·오류·포화도(자원이 얼마나 꽉 찼는지)입니다. 그중 트래픽이 시스템에 걸린 수요의 크기를 재는 신호입니다.

트래픽을 무엇으로 셀지는 시스템마다 고릅니다. 웹 서비스에서는 이 값이 대개 초당 HTTP 요청 수입니다. 수요를 재는 값이라 들어오는 쪽에서 센 초당 요청 수입니다. 정적 콘텐츠와 동적 콘텐츠처럼 요청의 성격으로 나눠 세기도 합니다. 오디오 스트리밍 시스템이라면 네트워크 입출력 속도나 동시 세션 수를 볼 수 있습니다. 키-값 저장소라면 초당 트랜잭션 수와 조회 수가 될 수 있습니다.

예시

이 절은 초당 요청 수가 값으로 찍히는 곳 셋을 봅니다. 부하를 거는 도구 둘과 요청을 받는 웹 서버 하나입니다. 셋 다 「건수를 초로 나눈다」는 같은 계산을 다른 모양으로 보여 줍니다.

wrk 의 실행 결과

wrk 는 HTTP 서버에 벤치마크를 돌리는 명령줄 도구입니다. 아래 명령은 스레드 12개로 HTTP 연결 400개를 열어 둔 채 30초 동안 벤치마크를 돌립니다.

wrk -t12 -c400 -d30s http://127.0.0.1:8080/index.html

끝나면 이렇게 찍힙니다.

Running 30s test @ http://127.0.0.1:8080/index.html
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   635.91us    0.89ms  12.92ms   93.69%
    Req/Sec    56.20k     8.07k   62.00k    86.54%
  22464657 requests in 30.00s, 17.76GB read
Requests/sec: 748868.53
Transfer/sec:    606.33MB

22464657 requests in 30.00s 줄이 30초 동안 요청 22,464,657건을 처리했다고 알려 줍니다. 이를 30으로 나누면 약 74만 9천입니다. 바로 아래 Requests/sec 줄이 그 값입니다. 측정 창이 30초인 초당 요청 수입니다.

Thread Stats 표 안의 Req/Sec 는 표 제목대로 스레드별 통계입니다. 전체 초당 요청 수는 맨 아래 Requests/sec 줄에서 읽습니다.

k6 의 http_reqs

k6 는 자바스크립트로 쓴 스크립트를 되풀이해 실행하며 부하를 거는 도구입니다. http_reqs 는 k6 가 만들어 낸 HTTP 요청의 총 건수를 세는 지표입니다. 종류는 Counter 입니다. Counter 는 값을 더해 가기만 하는 지표입니다.

시험이 끝나면 요약에 이런 줄이 찍힙니다.

http_req_failed....................: 0.00%  0 out of 45
http_reqs..........................: 45     6.56109/s

EXECUTION
iteration_duration.................: avg=152.38ms min=119.37ms med=141.27ms max=684.62ms p(90)=147.11ms p(95)=148.39ms
iterations.........................: 45     6.56109/s
vus................................: 1      min=1        max=1

http_reqs 줄의 45 는 보낸 요청의 총 건수입니다. 옆의 6.56109/s 가 초당 값입니다. 이 숫자는 k6 가 보낸 쪽에서 센 값이라 서버로 들어오는 쪽의 초당 요청 수입니다. 서버가 따라가는 동안에는 서버가 끝낸 값과 같습니다.

k6 문서는 어느 지표를 볼지 모르겠으면 요청 수(http_reqs)·오류율(http_req_failed)·소요 시간(http_req_duration) 셋부터 볼 수 있다고 적습니다. 이 세 지표는 RED(Rate·Errors·Duration, 초당 요청 수·오류·소요 시간) 방법이 보는 세 기준을 잽니다. 첫 기준인 Rate 가 이 표제어인 초당 요청 수입니다.

같은 문서는 세 지표가 각각 트래픽·가용성·지연을 잰다고도 적습니다. 요청 수가 트래픽을, 오류율이 가용성을, 소요 시간이 지연을 맡습니다.

nginx 의 stub_status

nginx 의 ngx_http_stub_status_module 모듈은 기본 상태 정보를 간단한 웹 페이지로 보여 줍니다. 그 페이지는 이렇게 생길 수 있습니다.

Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106

requests 칸의 31070465 는 클라이언트 요청의 총 건수입니다. 맨 왼쪽 accepts 칸은 받아들인 클라이언트 연결의 총 건수입니다. 연결 수와 요청 수를 따로 셉니다.

requests 는 늘어나기만 하는 누적 건수입니다. 한 번 읽어서는 초당 요청 수가 안 나옵니다. 두 번 읽어 늘어난 건수를 그 사이의 초 수로 나눠야 합니다. 측정 창 나눗셈과 같은 계산입니다.

경계

가상 사용자 1,000명으로 부하를 걸면 초당 요청 수도 1,000인가. 아닙니다.

가상 사용자는 부하 테스트 도구가 흉내 내는 사용자 한 명입니다. 정해진 동작을 되풀이하며 요청을 보냅니다. k6 에서는 VU(Virtual User)라고 부릅니다.

가상 사용자 하나가 1초에 보내는 요청 수에는 두 시간이 끼어듭니다. 서버의 응답 시간, 그리고 가상 사용자가 동작 한 바퀴를 마치고 다음 바퀴 전에 쉬는 시간입니다. 이 쉬는 시간은 서버 앞 대기 줄에서 기다리는 시간과 다른 것입니다. 사용자 수는 그 셈에 들어가는 한 값일 뿐입니다.

응답을 기다리는 닫힌 모델

닫힌 모델에서는 가상 사용자가 앞 반복이 끝나야 다음 반복을 시작합니다. 반복은 가상 사용자가 정해진 동작을 한 바퀴 도는 단위입니다. 아래 예에서는 반복 하나가 요청 하나입니다.

가상 사용자 1명을 1분 동안 돌린다고 합시다. 요청 하나는 6초쯤 걸립니다. 그러면 반복이 6초에 한 번 꼴로 시작됩니다. 1분 동안 반복은 모두 10번 끝날 것으로 봅니다.

가상 사용자가 1명이어도 초당 요청 수는 1이 아니라 6초에 1건입니다. 리틀의 법칙 L = λW 로 읽어도 같습니다. 서버 안에 머무는 건수가 1, 한 건이 머무는 시간이 6초이니 초당 1/6건입니다.

sequenceDiagram
    participant 사용자 as 가상 사용자
    participant 서버
    사용자->>서버: 요청 1
    Note over 서버: 6초쯤 걸린다
    서버-->>사용자: 응답 1
    사용자->>서버: 요청 2
    Note over 사용자,서버: 앞 응답이 와야 다음 요청이 나간다

이 방식에서는 서버의 응답 시간이 시험의 처리량을 바꿀 수 있습니다. 서버가 버거워 답이 늦어지면 반복이 길어집니다. 새 반복이 시작되는 속도도 떨어집니다.

부하 도구가 느려진 서버에 맞춰 요청을 덜 보내게 되는 이 문제를 coordinated omission 이라고 부르기도 합니다. 정해진 도착률, 넓게는 정해진 초당 요청 수를 흉내 내려는 목적에는 바람직하지 않은 효과입니다.

속도를 직접 거는 열린 모델

열린 모델은 반복의 시작을 반복이 끝나는 것과 떼어 놓습니다. 서버의 응답 시간이 서버에 걸리는 부하를 더는 바꾸지 않습니다.

k6 에서는 실행기가 가상 사용자를 돌리는 일정을 짭니다. 그중 constant-arrival-rate 와 ramping-arrival-rate 두 실행기가 열린 모델입니다.

constant-arrival-rate 에 rate: 1 · timeUnit: '1s' · duration: '1m' 을 주면 새 반복이 1초에 하나씩 시작됩니다. 1분 동안 반복 60번이 끝날 것으로 봅니다. 이때 거는 값은 사용자 수가 아니라 초당 반복 수입니다.

아래 그림은 닫힌 모델 그림과 짝입니다. 앞 응답이 오기 전에도 다음 요청이 1초 간격으로 나갑니다.

sequenceDiagram
    participant 도구 as 부하 도구
    participant 서버
    도구->>서버: 요청 1 · 0초
    도구->>서버: 요청 2 · 1초
    도구->>서버: 요청 3 · 2초
    Note over 도구,서버: 앞 응답을 안 기다리고 1초에 하나씩 시작한다
    서버-->>도구: 응답 1

사용자 수와 초당 요청 수를 잇는 셈

Locust 는 k6 처럼 가상 사용자를 띄워 부하를 거는 도구입니다. Locust 에서는 가상 사용자가 되풀이하는 동작 한 덩어리를 태스크라고 부릅니다. 태스크를 한 번 도는 것이 앞에서 말한 반복 하나에 해당합니다. 태스크 하나에는 요청이 여러 개 들어갈 수 있습니다.

Locust 는 쉬는 시간을 wait_time 으로 정합니다. 가상 사용자는 태스크를 한 번 마칠 때마다 이 시간만큼 쉬었다가 다음 태스크를 돕니다. 그중 constant_throughput(X) 는 태스크가 1초에 (많아야) X번 돌도록 쉬는 시간을 알아서 맞춥니다.

최대 부하에서 1초에 태스크 500번을 돌리려면 constant_throughput(0.1) 에 사용자 5,000명을 줄 수 있습니다. 한 명이 1초에 0.1번이니 5,000명이 합쳐 1초에 500번입니다.

이 쉬는 시간은 처리량을 묶을 수만 있습니다. 목표에 닿으려고 사용자를 새로 띄우지는 않습니다. 위 예에서 태스크 한 번이 10초를 넘기면 처리량이 500보다 낮아집니다.

쉬는 시간은 요청이 아니라 태스크에 걸립니다. constant_throughput(2) 를 주고 태스크 안에서 요청을 두 번 보내면 사용자 한 명의 초당 요청 수는 4입니다.

아래 그림은 사용자 수에서 초당 요청 수까지 가는 곱셈을 이었습니다. 사용자 수와 초당 요청 수 사이에 태스크 속도와 태스크 하나에 든 요청 수가 끼어듭니다.

flowchart TD
    U["사용자 수"] -->|"× 한 명이 1초에 도는 태스크 수 · 많아야"| T["초당 태스크 수"]
    T -->|"× 태스크 하나에 든 요청 수"| R["초당 요청 수"]
    T -.-> N["태스크 한 번이 쉬는 간격보다 오래 걸리면 목표보다 낮아진다"]

운영

운영 중인 서비스에서 요청 수는 두 모양으로 들어옵니다. 하나는 요청이 올 때마다 하나씩 늘어나기만 하는 누적 카운터입니다. 다른 하나는 정한 기간 동안 센 건수입니다. 어느 쪽이든 건수를 그 기간의 초 수로 나눠야 초당 값이 됩니다.

누적 카운터는 Prometheus 같은 모니터링 도구가 읽어 갑니다. 고를 것은 둘입니다. 어느 함수로 나누는지, 창을 얼마로 잡는지입니다. 기간마다 센 건수는 아래 로드 밸런서의 RequestCount 가 그 예입니다.

Prometheus 의 rate()

Prometheus 의 질의 rate(http_requests_total[5m]) 은 지난 5분 동안 HTTP 요청 수가 초당 평균 얼마씩 늘었는지를 돌려줍니다. 5분짜리 측정 창으로 본 초당 요청 수입니다.

rate() 는 카운터에만 씁니다. Prometheus 가 값을 읽어 오는 서버를 대상이라고 부릅니다. 대상이 재시작해 카운터가 처음으로 돌아가도 rate() 가 알아서 보정합니다.

Prometheus 가 대상에서 값을 한 번 읽어 오는 일을 스크레이프라고 부릅니다. rate() 는 창의 양 끝까지 값을 늘여 잡아 계산합니다. 덕분에 스크레이프를 놓쳤거나 읽는 주기가 창과 어긋나도 메워 줍니다.

비슷한 함수가 둘 더 있습니다. 같은 카운터를 놓고 무엇을 내는지가 다릅니다.

irate() 를 알림에 쓰면 짧은 변화가 알림 규칙의 FOR 조건을 다시 시작하게 할 수 있습니다. 드문 봉우리만으로 이루어진 그래프도 읽기 어렵습니다. 알림과 천천히 변하는 카운터에 rate() 를 쓰는 까닭입니다.

여러 대의 값을 합칠 때는 순서가 있습니다. sum by (job) (rate(http_requests_total[5m])) 처럼 rate() 를 먼저 하고 그다음에 합칩니다. 거꾸로 합부터 하면 대상이 재시작할 때 생긴 카운터 리셋을 rate() 가 알아채지 못합니다.

측정 창의 길이

rate(http_requests_total[5m]) 의 5m 이 측정 창입니다. 이 창을 얼마로 잡느냐가 초당 요청 수 그래프에 보이는 것을 정합니다. 창이 길수록 짧게 튀는 구간이 평평해집니다.

Google 의 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) 책은 시스템의 측면마다 재는 단위를 다르게 잡아야 한다고 적습니다. 그 책이 드는 예는 초당 요청 수가 아니라 CPU 부하입니다.

꼬리 지연은 가장 오래 걸리는 몇 퍼센트 요청의 지연입니다. CPU 부하를 1분 단위로 보면 꼬리 지연을 높게 끌어올리는 튀는 구간이 드러나지 않습니다. 그 구간이 꽤 오래 이어져도 마찬가지입니다.

반대로 CPU 부하를 초 단위로 모으면 흥미로운 데이터가 나올 수 있습니다. 대신 그렇게 잦은 측정은 모으고 쌓고 분석하는 비용이 매우 클 수 있습니다.

초당 요청 수를 얼마나 잘게 볼지에도 같은 저울질이 걸립니다.

창 길이와 그래프의 점 간격은 따로 정하는 값입니다. rate(http_requests_total[5m])[30m:1m] 은 지난 30분 동안 1분 간격으로, 매번 5분 창의 초당 요청 수를 냅니다. 창이 간격보다 길어서 이웃한 점의 창은 서로 겹칩니다.

로드 밸런서의 RequestCount

AWS(Amazon Web Services)의 Application Load Balancer 는 지표 서비스 CloudWatch 에 RequestCount 라는 지표를 보냅니다. IPv4 와 IPv6(Internet Protocol version 4·6, 인터넷 프로토콜 4판과 6판)로 처리한 요청 수입니다.

이 지표는 로드 밸런서가 요청을 넘길 뒤쪽 서버를 고를 수 있었던 요청만 셉니다. 뒤쪽 서버를 고르기 전에 거절된 요청은 안 셉니다. 헬스 체크 요청도 빠집니다.

값은 요청이 흐를 때만 60초 간격으로 올라옵니다. 요청이 없으면 값이 안 올라옵니다.

통계는 정한 기간에 걸쳐 모은 값입니다. 이 지표에서 가장 쓸모 있는 통계는 Sum 입니다. Sum 은 그 기간 동안 모든 로드 밸런서 노드가 센 요청 건수를 합친 값입니다. 이를 기간의 초 수로 나눈 값이 그 기간의 초당 요청 수입니다.

관련 항목

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

지연 · 응답 시간 · 오류율 · 처리량 · 포화도 · 백분위수 · 꼬리 지연 · 가용성 · 서비스 수준 지표 · 서비스 수준 목표 · 골든 시그널 · RED 방법

초당 요청 수와 세는 대상만 다른 단위

TPS · QPS · 초당 입출력 수 · 도착률 · 동시 접속 · 동시 세션

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

병목 · 대역폭 · 큐 · 동시성 · 커넥션 풀 · 스레드 풀 · 락 경합 · 컨텍스트 스위칭 · 큐잉 이론 · 리틀의 법칙

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

수평 확장 · 수직 확장 · 로드 밸런서 · 캐싱 · 커넥션 재사용 · 배치 처리 · 비동기 처리

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

속도 제한 · 백프레셔 · 스로틀링 · HTTP 429 · 할당량 · 서킷 브레이커

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

부하 테스트 · 성능 테스트 · 스트레스 테스트 · 벤치마크 · 용량 계획 · 램프업

초당 요청 수를 만들어 내는 부하 생성기와 부하 모델

가상 사용자 · Locust · k6 · wrk · 열린 모델 · 닫힌 모델 · coordinated omission

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

메트릭 · 모니터링 · 대시보드 · 액세스 로그 · 측정 창 · 카운터 · Prometheus · PromQL · Grafana · nginx · CloudWatch · Application Load Balancer

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

HTTP · 요청 · 엔드포인트 · API · 웹 서버 · 리버스 프록시 · 웹소켓