처리량

처리량은 시스템이 정해진 시간 동안 끝낸 일의 양입니다. 서버라면 1초에 요청을 몇 개 끝냈는지로 잽니다. 한 건이 얼마나 빨리 끝나는지를 보는 지연과 달리 한꺼번에 얼마나 많이 처리하는지를 봅니다. 팀이 코드를 배포하는 흐름에서도 같은 이름으로 변경이 얼마나 많이 운영 서버까지 가는지를 잽니다.

쉽고 빠른 이해

무슨 일을 하는 값인가 — 시간당 끝낸 일의 개수를 셉니다. 웹 서버가 1초에 요청 800개를 끝냈다면 처리량은 초당 800건입니다.

왜 재나 — 들어오는 요청 수만 봐서는 서버가 버티는지 모릅니다. 끝내는 양이 들어오는 양보다 적으면 못 끝낸 요청이 쌓입니다. 사용자는 점점 오래 기다립니다.

어떻게 정해지나

1. 한 번에 여러 건을 동시에 처리하면 시간당 끝내는 수가 늘어납니다
2. 일이 여러 단계를 거치면 시간당 가장 적게 처리하는 단계가 전체의 양을 정합니다
3. 그 단계가 시간당 처리하는 양을 늘려야 전체가 늘어납니다

대가 — 처리량을 올리려고 요청을 모아서 한꺼번에 처리하면, 먼저 온 요청은 모일 때까지 기다립니다. 많이 처리하는 것과 한 건을 빨리 끝내는 것은 따로 움직입니다.

다른 뜻 하나 — 팀의 배포 흐름에서도 같은 이름을 씁니다. 이때는 일정 기간 동안 운영 환경까지 간 코드 변경의 흐름을 봅니다.

상세

이 절은 처리량이 무엇을 세는 값인지부터 봅니다. 그다음 지연과 어떻게 다른지, 무엇이 처리량을 막는지를 웹 서버 한 대의 예로 따라갑니다. 끝에서 배포 흐름에서 쓰는 뜻을 짚습니다.

고속도로 톨게이트를 떠올리면 쉽습니다. 한 시간에 차가 몇 대 빠져나가는지가 처리량입니다. 차 한 대가 줄 서서 게이트를 지나기까지 걸린 시간은 지연입니다. 부스를 늘리면 한 대가 요금을 내는 시간은 그대로여도 빠져나가는 차는 늘어납니다. 부스 수가 서버에서는 동시에 처리하는 요청 수에 해당합니다.

끝낸 일의 개수

처리량은 들어온 일이 아니라 끝낸 일을 셉니다. 요청이 1초에 1000개 들어와도 서버가 800개만 끝내면 처리량은 초당 800건입니다. 못 끝낸 200개는 큐에 쌓여 차례를 기다리거나 버려집니다.

큐는 도착한 일이 처리를 기다리며 줄 서는 곳입니다. 줄이 짧게 유지되면 서버가 들어오는 양을 따라가고 있다는 뜻입니다. 줄이 계속 길어지면 들어오는 양이 처리량을 넘어선 것입니다.

flowchart TD
    A["들어온 요청 · 1초에 1000개"] --> Q["큐 · 못 끝낸 요청이 1초에 200개씩 쌓인다"]
    Q --> W["서버가 처리한다"]
    W --> D["끝낸 요청 · 1초에 800개"]

그림에서 처리량으로 세는 것은 「끝낸 요청」뿐입니다. 들어온 수와 끝낸 수의 차이인 1초에 200개가 큐에 쌓입니다.

세는 단위

무엇을 한 건으로 치는지는 시스템마다 다릅니다. 그래서 처리량을 말할 때는 단위를 같이 말합니다. 단위가 빠지면 「초당 500」이 요청인지 트랜잭션인지 알 수 없습니다.

표의 단위는 줄임말로도 자주 씁니다. 초당 요청 수는 RPS(Requests Per Second)입니다. 초당 트랜잭션 수는 TPS(Transactions Per Second), 초당 질의 수는 QPS(Queries Per Second)입니다.

지연과 갈리는 지점

지연은 한 건이 끝나기까지 걸린 시간입니다. 처리량은 정해진 시간 동안 끝낸 건수입니다. 하나는 시간을 재고 다른 하나는 개수를 셉니다.

둘은 동시에 처리하는 요청 수로 이어집니다. 서버가 요청을 한 번에 열 건씩 동시에 처리한다고 해 봅시다. 한 건에는 0.1초가 걸립니다. 1초 동안 열 건짜리 묶음을 열 번 끝내니 처리량은 초당 100건입니다.

그렇다고 둘이 한 방향으로 움직이지는 않습니다. 동시에 처리하는 수를 늘리면 처음에는 처리량이 늘어납니다. 그러다 CPU(Central Processing Unit)나 데이터베이스 연결이 모자라기 시작하면 작업끼리 자원을 기다리느라 한 건씩 느려집니다. 이때부터는 동시에 처리하는 수를 늘려도 처리량이 더 오르지 않습니다. 지연만 늘어납니다.

요청을 모아서 한꺼번에 처리하는 배치 처리도 같은 갈림을 보입니다. 묶어서 처리하면 처리량이 오릅니다. 대신 먼저 온 요청은 묶음이 찰 때까지 기다리므로 지연이 늘어납니다.

처리량이 오르는 까닭은 건마다 치르던 준비 비용이 한 번으로 줄기 때문입니다. 데이터베이스에 행을 하나씩 넣으면 넣을 때마다 서버와 한 번씩 주고받아야 합니다. 백 건을 한 번에 넣으면 그 주고받기가 한 번으로 줄어듭니다.

병목이 정하는 상한

요청 하나가 여러 단계를 거친다고 해 봅시다. 앱 서버가 요청을 받아 데이터베이스에 묻습니다. 그 결과로 답을 돌려줍니다. 이때 전체 처리량은 시간당 가장 적게 처리하는 단계가 정합니다. 그 단계를 병목이라고 부릅니다.

flowchart TD
    A["들어온 요청"] --> B["앱 서버 · 1초에 500건 처리할 수 있다"]
    B --> C["데이터베이스 · 1초에 200건 처리할 수 있다"]
    C --> D["전체 처리량 · 1초에 200건"]

앱 서버는 초당 500건을 처리할 수 있어도 데이터베이스가 200건에서 막히면 전체는 200건입니다. 이 상태에서 앱 서버를 두 배로 늘려도 전체 처리량은 오르지 않습니다. 앱 서버 앞의 큐가 데이터베이스 앞으로 옮겨 갈 뿐입니다.

그래서 처리량을 올리려면 먼저 병목을 찾습니다. 서버를 여러 대로 늘리는 수평 확장은 그 단계가 병목일 때만 효과가 있습니다.

여러 작업이 같은 잠금을 기다리는 락 경합처럼 나눠 가질 수 없는 자원이 병목이면 서버를 늘려도 소용이 없습니다.

서비스 수준 지표로 쓰는 처리량

서비스 수준 지표는 서비스가 얼마나 잘 돌고 있는지를 숫자로 잰 값입니다. 처리량은 지연·오류율과 함께 이 지표로 자주 쓰입니다. 보통 초당 요청 수로 잽니다.

처리량은 혼자 보면 속습니다. 서버가 오류 응답을 빠르게 쏟아내도 끝낸 요청 수는 많아 보입니다. 그래서 오류율을 나란히 보거나, 성공한 요청만 세어 처리량을 냅니다.

초당 값은 얼마 동안 모아서 평균을 냈는지에 따라서도 달라집니다. 그 모으는 시간을 측정 창이라고 합니다. 1분 창의 평균은 몇 초 동안 몰린 요청을 평평하게 뭉개서 안 보이게 합니다.

평소 처리량을 재 두면 한계도 미리 알 수 있습니다. 요청을 점점 늘려 보내며 어디서 처리량이 더 안 오르는지 찾는 일이 부하 테스트입니다.

그렇게 찾은 한계를 보고 서버를 언제 얼마나 늘릴지 정하는 일이 용량 계획입니다. 요청이 한계에 닿기 전에 서버를 늘려 두려는 것입니다.

배포 흐름에서 쓰는 뜻

같은 이름이 팀의 배포 성과를 재는 데도 쓰입니다. DORA(DevOps Research and Assessment)는 소프트웨어 배달 성능을 재는 연구 프로그램입니다.

이 연구는 지표를 두 갈래로 묶습니다. 하나는 변경이 얼마나 빠르고 많이 흘러가는지를 보는 처리량입니다. 다른 하나는 배포가 얼마나 자주 실패하는지를 보는 불안정성입니다.

이때 처리량은 일정 기간 동안 변경이 운영 환경까지 얼마나 빠르고 많이 흘러가는지를 나타냅니다. 세는 대상이 요청이 아니라 코드 변경입니다. 재는 기간도 초가 아니라 날이나 주입니다.

DORA 는 이 처리량을 세 값으로 잽니다. 커밋한 변경이 운영 환경에 배포되기까지 걸리는 변경 리드 타임, 정해진 기간 동안 배포한 횟수인 배포 빈도, 실패한 배포에서 되살아나기까지 걸리는 실패한 배포 복구 시간입니다.

셋 중 둘이 시간인 까닭은 흐름의 빠르기가 양을 정하기 때문입니다. 변경 하나가 운영까지 가는 시간이 짧으면 같은 기간에 더 많은 변경이 지나갑니다. 실패한 배포를 빨리 되살리면 그동안 멈춰 있던 변경도 다시 흘러갑니다.

관련 항목

처리량과 함께 서비스를 재는 지표

지연 · 오류율 · 포화도 · 가용성 · 서비스 수준 지표 · 서비스 수준 목표 · 백분위 · 측정 창

처리량을 세는 단위

RPS · TPS · QPS · 대역폭

처리량을 막거나 정하는 요인

병목 · 큐 · 동시성 · 락 경합 · 커넥션 풀 · 배치 처리 · 큐잉 이론

처리량을 늘리거나 지키는 수단

수평 확장 · 수직 확장 · 로드 밸런서 · 캐싱 · 백프레셔 · 속도 제한

처리량의 한계를 재고 대비하는 활동

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

배포 흐름에서 처리량으로 묶이는 지표

DORA · 변경 리드 타임 · 배포 빈도 · 실패한 배포 복구 시간 · 소프트웨어 배달 성능 · 데브옵스