지연·대역폭·처리량·혼잡

빠르다는 말은 세 질문으로 나눠야 한다

한 주문이 0.2초 만에 끝나는 서비스와 초당 만 건을 처리하는 서비스는 둘 다 빠르다고 불릴 수 있지만 같은 성질은 아니다. 통신로가 넓어도 왕복 거리가 길면 한 요청은 늦고, 한 요청이 빨라도 동시에 몰리면 전체 처리량은 떨어질 수 있다. 성능을 판단할 때는 기다린 시간, 운반할 수 있는 양, 실제 끝낸 양을 구분하는 데서 시작한다.

먼저 되짚기: 신호와 채널

신호와 채널은 정보를 물리량으로 표현해 매체로 전달하는 관계다. 전송 자체의 시간·용량을 서비스가 실제 완료한 작업량과 구분해야 지연·대역폭·처리량을 혼동하지 않는다.

세 성능축의 정의

지연시간(latency)은 한 작업이나 데이터가 시작해 결과를 얻기까지 걸린 시간이다. 대역폭(bandwidth)은 통신로나 장치가 단위시간에 실어 나를 수 있는 이론적 또는 허용 용량이다. 처리량(throughput)은 시스템이 단위시간에 실제로 완료한 작업량이다. 지연은 보통 시간, 대역폭은 초당 비트, 처리량은 초당 요청처럼 측정하며 단위와 측정 경계를 반드시 붙인다.

부하가 늘면 왜 갑자기 느려지는가

평균 요청 도착률이 처리능력보다 낮아도 요청이 한꺼번에 도착하거나 처리시간이 달라지면 기다릴 수 있다. 도착·처리의 변동과 경합이 있는 시스템에서는 도착률이 한계에 가까워질수록 대기가 길어질 수 있고, 실제 계산시간이 같아도 대기 때문에 지연이 커질 수 있다. 처리량은 가장 좁은 병목의 능력을 넘지 못한다. 따라서 회선만 넓히기보다 CPU, 저장장치, 연결 수, 잠금과 외부 API 가운데 실제 병목을 찾아야 한다.

평균 하나만 보면 생기는 오판

평균 지연만 보면 소수의 매우 느린 요청이 가려질 수 있고, 순간 최대 처리량만 보면 장시간 지속 가능한 능력을 과장할 수 있다. 요청 크기와 동시 사용자 수가 다른 실험도 직접 비교할 수 없다. 판단할 때는 측정구간, 부하, 자료크기, 오류율과 상위 지연구간을 함께 적고, 한 축을 개선하며 다른 축과 자원을 얼마나 희생했는지 확인한다.

한 요청의 시간과 전체 흐름을 함께 그린다

도착률·유한 대기열·병목 능력과 실제 완료량을 구분한다 · 상태 따라가기

초당 55건 유입·50건 처리라면 대기는 초당 5건 늘어난다. 모든 단계에서 대기량·수용·처리의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

도착률 λ와 서버 처리능력 μ는 각각 유입과 가정한 용량이며 완료 처리량은 단위시간 동안 유효한 결과를 낸 양이다. 거절·손실 없이 λ=55건/s·μ=50건/s가 이어지면 5건/s가 누적되지만 이 설계는 대기열에 25건이 차면 초과 요청을 거절한다. 한 건 지연 = 같은 요청의 시작부터 끝까지 겹치지 않게 나눈 구간의 합. 전송시간의 하한 ≈ 데이터 크기 / 사용 가능한 전송률. 이미 외부 호출에 포함된 시간은 다시 더하지 않는다.

이 예의 조건

• 도착률 λ와 서버 처리능력 μ는 각각 유입과 가정한 용량이며 완료 처리량은 단위시간 동안 유효한 결과를 낸 양이다. 거절·손실 없이 λ 55건/s·μ 50건/s가 이어지면 5건/s가 누적되지만 이 설계는 대기열 25건 이후 초과를 거절한다. 한 건 지연 = 같은 요청의 시작부터 끝까지 겹치지 않게 나눈 구간의 합. 전송시간의 하한 ≈ 데이터 크기 / 사용 가능한 전송률. 이미 외부 호출에 포함된 시간은 다시 더하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상요청 도착률 λ	원 설명새 요청/초 / 예: 45 또는 55건/s
대상대기열	원 설명대기시간·길이 / 상한 25건 · 초과 거절
대상서버 처리능력 μ	원 설명가정한 지속 용량 / 예: 50건/s
대상유효 완료 처리량	원 설명실제로 끝낸 요청/초

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결요청 도착률 λ → 대기열	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결대기열 → 서버 처리능력 μ	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결서버 처리능력 μ → 유효 완료 처리량	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
유입과 처리 초당 55건 유입·50건 처리라면 대기는 초당 5건 늘어난다.	값·보충 정보 대기량: 순증가 5/s 수용·처리: 도착 55/s·처리 50/s	변화·이유 처리율보다 유입이 높다는 조건 때문에 대기가 생긴다.
유한 대기 25건 한도까지 대기를 허용한다.	값·보충 정보 대기량: 대기≤25 수용·처리: 한도 25	변화·이유 무한히 받아들이는 정책이 아니다.
한도 도달 한도가 차면 새 요청을 거절해 대기 예산을 넘지 않는다.	값·보충 정보 대기량: 대기 25 수용·처리: 추가 요청 거절	변화·이유 수용 성공과 업무 완료를 구별한다.

도착률·유한 대기열·병목 능력과 실제 완료량을 구분한다 · 상태 따라가기

초당 55건 유입·50건 처리라면 대기는 초당 5건 늘어난다. 모든 단계에서 대기량·수용·처리의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

도착률 λ와 서버 처리능력 μ는 각각 유입과 가정한 용량이며 완료 처리량은 단위시간 동안 유효한 결과를 낸 양이다. 거절·손실 없이 λ=55건/s·μ=50건/s가 이어지면 5건/s가 누적되지만 이 설계는 대기열에 25건이 차면 초과 요청을 거절한다. 한 건 지연 = 같은 요청의 시작부터 끝까지 겹치지 않게 나눈 구간의 합. 전송시간의 하한 ≈ 데이터 크기 / 사용 가능한 전송률. 이미 외부 호출에 포함된 시간은 다시 더하지 않는다.

이 예의 조건

• 도착률 λ와 서버 처리능력 μ는 각각 유입과 가정한 용량이며 완료 처리량은 단위시간 동안 유효한 결과를 낸 양이다. 거절·손실 없이 λ 55건/s·μ 50건/s가 이어지면 5건/s가 누적되지만 이 설계는 대기열 25건 이후 초과를 거절한다. 한 건 지연 = 같은 요청의 시작부터 끝까지 겹치지 않게 나눈 구간의 합. 전송시간의 하한 ≈ 데이터 크기 / 사용 가능한 전송률. 이미 외부 호출에 포함된 시간은 다시 더하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상요청 도착률 λ	원 설명새 요청/초 / 예: 45 또는 55건/s
대상대기열	원 설명대기시간·길이 / 상한 25건 · 초과 거절
대상서버 처리능력 μ	원 설명가정한 지속 용량 / 예: 50건/s
대상유효 완료 처리량	원 설명실제로 끝낸 요청/초

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결요청 도착률 λ → 대기열	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결대기열 → 서버 처리능력 μ	원 라벨·방향라벨 없는 연결 / 정방향 / 실선
연결서버 처리능력 μ → 유효 완료 처리량	원 라벨·방향라벨 없는 연결 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
유입과 처리 초당 55건 유입·50건 처리라면 대기는 초당 5건 늘어난다.	값·보충 정보 대기량: 순증가 5/s 수용·처리: 도착 55/s·처리 50/s	변화·이유 처리율보다 유입이 높다는 조건 때문에 대기가 생긴다.
유한 대기 25건 한도까지 대기를 허용한다.	값·보충 정보 대기량: 대기≤25 수용·처리: 한도 25	변화·이유 무한히 받아들이는 정책이 아니다.
한도 도달 한도가 차면 새 요청을 거절해 대기 예산을 넘지 않는다.	값·보충 정보 대기량: 대기 25 수용·처리: 추가 요청 거절	변화·이유 수용 성공과 업무 완료를 구별한다.

도착률이 처리능력에 가까워질수록 작은 변동도 대기열을 크게 늘린다. 완료 처리량은 네트워크·중앙처리장치·저장장치·잠금·외부 API 가운데 가장 좁은 병목을 넘지 못한다. 지연 구성요소와 병목 위치를 나눠야 올바른 자원을 개선할 수 있다.

예를 들어 한 요청의 시작·끝을 0ms와 100ms로 측정하고 전송 0~10, 서버 대기 10~30, 서버 자체 처리 30~50, 외부 의존 호출 대기 50~90, 응답 전달 90~100으로 나누면 10+20+20+40+10=100ms다. 50~90ms 외부 호출의 왕복시간에는 그 구간의 전송·전파·상대 처리가 이미 포함될 수 있으므로 같은 항목을 다시 더하지 않는다. 동시에 겹쳐 실행하는 두 호출도 각각의 경과시간 합이 아니라 실제 시간축의 임계 경로로 판단한다.

세 축은 단위와 질문이 다르다

빠르다는 평가에는 측정 시작·종료점, 요청 크기, 동시성, 오류 포함 여부와 지속시간을 붙인다. 같은 수치라도 경계와 단위가 다르면 비교할 수 없다.

묶음과 동시성은 처리량을 높이지만 대기를 만든다

작업을 큰 묶음으로 보내면 호출·전송 고정비를 나눠 처리량을 높일 수 있지만 첫 작업은 묶음이 찰 때까지 기다린다. 동시 요청 수를 늘리면 빈 자원을 활용하다가 한계를 넘으면 대기·문맥전환·재시도가 늘어 지연과 오류율이 악화된다. 따라서 처리량 최대점이 아니라 지연 목표와 오류율을 만족하는 지속 가능한 부하를 용량으로 잡고, 유입 제한과 대기열 상한을 둔다.

계산 사례: 10 Mb/s 경로와 초당 50건 서버

5 MB 파일은 약 40 Mb이므로 10 Mb/s를 온전히 쓴다고 가정해도 전송에 최소 약 4초가 필요하다. 여기에 왕복·프로토콜·서버 대기가 더해져 실제 지연은 길어진다. 서버가 안정적으로 초당 50건을 처리할 때 평균 초당 45건이 와도 순간 변동 때문에 줄이 생길 수 있고, 55건이 지속되면 거절·손실 없이 받아들이는 동안 매초 약 5건씩 대기열이 증가한다. 유한 대기열이 차면 초과 요청의 거절을 따로 센다. 평균 100 ms만 보고 판단하지 말고 예를 들어 95번째 백분위 800 ms, 오류율 2%, 부하 45건/s처럼 조건을 함께 적는다.

여기서는 십진 단위 1MB=1,000,000B, 1Mb=1,000,000bit, 1B=8bit를 쓴다. 5MB×8=40Mb, 40Mb÷10Mb/s=4s에서 크기를 전송률로 나누면 시간 단위만 남는다.

백분위 계산법을 최근접 순위로 정하면 100개 관측의 95번째 값이 p95다. 오류·시간초과를 지연 표본에서 빼 좋은 값만 남기지 말고 완료 지연의 표본 조건과 전체 시도 분모의 오류율을 함께 적는다.

그림의 λ는 람다, μ는 뮤로 읽으며 여기서는 각각 도착률과 처리능력을 대신 쓴 기호다. 백프레셔(backpressure)는 받는 쪽의 처리 여유가 없음을 보내는 쪽에 알려 유입을 늦추거나 제한하는 동작을 뜻한다. 거절·대기 신호를 받은 호출자가 즉시 무제한 재시도하면 제한한 유입이 다시 몰리므로 전체 기한과 재시도 횟수도 함께 통제해야 한다.

용량을 채택하는 절차를 작은 수치로 완성해 보자. 교육용 API 요청군은 같은 크기로 45건/s를 10분 유지하고 완료 요청의 p95가 1초 이하, 전체 시도의 오류·거절률이 1% 이하를 목표로 둔다. 서버 앞 대기열은 최대 25건이고 더 받아들일 공간이 없으면 즉시 과부하 응답을 보내며 운영 담당은 그 거절도 실패율 분모·분자에 포함한다. 5MB 파일의 4초 전송 예는 다른 요청군이므로 이 API의 1초 목표와 섞지 않는다.

45건/s를 600초 유지하면 총 시도는 27,000건이고 1%는 270건이다. 앞의 오류율 2%를 같은 분모에서 관찰했다면 540건으로 허용치를 넘으므로 p95 800ms가 통과해도 운영 용량을 승인하지 않는다. 병목을 확인해 개선한 뒤 같은 입력·부하·분모로 재시험하고 두 조건이 모두 맞을 때 채택한다. 대기열 상한을 없애면 오류를 잠시 숨길 수 있어도 대기시간과 미처리 요청이 계속 늘어날 수 있으므로 이 대안은 제외한다.

평균 도착률이 같아도 도착 모양에 따라 대기가 다르다

앞의 서버 처리능력 50건/s를, 요청 하나를 정확히 20ms에 처리하는 단일 FIFO 서버로 구체화해 보자. FIFO는 먼저 도착한 요청부터 처리하는 순서이며, 동시에 도착한 요청은 1번부터 20번까지 처리한다고 정한다. 처음에는 비어 있고 매초 시작 시점에 20건이 한꺼번에 들어온다. 각 요청의 처리시간은 같고 네트워크·입출력·전환 비용과 다른 요청은 없다는 자체 교육 모형이다. 대기열 25건은 실행 중인 1건을 제외한 대기 요청의 한도다.

0ms에 20건이 도착하면 1번은 바로 시작하고 19건은 기다린다. k번째 요청의 시작은 (k−1)×20ms, 완료는 k×20ms다. 20번은 380ms를 기다려 400ms에 끝난다. 최대 대기 19건은 한도 25건보다 작아 이 모형에서는 거절이 없다. 이후 600ms는 서버가 비어 있고 다음 묶음은 1000ms에 도착한다.

평균 도착률은 20건/s로 처리능력 50건/s보다 낮지만, 매 묶음의 19/20=95%가 대기한다. 따라서 평균 도착률만으로 대부분 즉시 처리된다고 판단할 수 없다. 이것은 대기와 병목의 도착률·용량·실제 완료 처리량을 구분하는 계산이며, 모든 도착·서비스 모형의 안정성이나 실제 서비스의 지연 목표 충족을 보장하는 조건은 아니다.

평균 20건/s를 유지하면서 50ms마다 1건씩 들어오면 첫 세 요청의 대기는 얼마인가? 위의 처리시간·초기 상태·비용 가정을 그대로 유지해 도착·시작·완료 시점을 써 보자.

두 도착 모양의 대기 계산 확인하기

첫 세 도착은 0·50·100ms다. 앞 요청은 각각 20·70ms에 끝나므로 다음 도착 전에 서버가 비어 있다. 시작도 0·50·100ms, 완료는 20·70·120ms이며 세 요청의 대기는 모두 0ms다. 같은 평균이라도 한꺼번에 도착한 20건과 일정 간격의 도착은 대기가 다르다. 실제 시스템에 적용할 때는 도착의 집중도, 처리시간 분포와 경합·대기열·거절 기록을 별도로 확인한다.

자체 10점 문제

지연시간·대역폭·처리량을 비교하고 부하 증가 시 성능 저하 원인과 개선방안을 설명하시오.

요구어는 비교, 설명이다. 세 정의와 단위를 분리한 뒤 도착 → 대기 → 병목 처리 → 완료 흐름을 그린다. 평균·최대치의 오판, 묶음·동시성의 교환관계를 제시하고 백분위 지연·오류율·지속부하로 검증방안을 완성한다.

10점 풀이 방향과 모범답안 보기

답안 목차: 정의–대기–병목–검증

1. 지연·대역폭·처리량의 정의·단위·측정경계
2. 전송·대기·처리로 구성되는 한 건의 지연
3. 도착률·처리능력·병목과 처리량 상한
4. 묶음·동시성·자원 증설의 교환관계
5. 백분위·오류율·지속부하 기반 측정과 유입 통제

답안 도식: 세 축과 운영 통제

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

같은 크기 API 요청 45건/s를 10분 유지해 p95≤1초와 전체시도 오류·거절률≤1%를 함께 평가한다. 27,000건의 시도에서 1%는 270건이며 p95 800ms가 통과해도 2%인 540건 오류는 실패다. 병목·용량·유입제한·대기열 상한을 조정하고 같은 부하·입력·분모로 재시험한다. 무한 대기열이나 순간 최대 처리량은 승인 근거가 아니다.

모범답안 축약본

지연시간은 한 작업의 시작부터 결과까지 걸린 시간, 대역폭은 단위시간에 운반 가능한 이론적·허용 용량, 처리량은 단위시간에 실제 완료한 유효 작업량이다. 한 건의 지연은 전송·대기·처리·의존 대기로 구성되고 처리량은 가장 좁은 병목 능력을 넘지 못한다. 요청 도착률이 처리능력에 가까워지면 변동이 대기열로 누적되어 처리시간이 같아도 지연이 급증한다. 묶음과 동시성은 고정비를 나눠 처리량을 높이지만 첫 응답 대기와 경합을 늘릴 수 있다. 따라서 같은 입력·동시성·측정구간에서 평균뿐 아니라 상위 백분위 지연, 지속 처리량, 오류율과 자원 사용을 측정한다. 병목을 분해한 뒤 용량 조정, 유입 제한과 대기열 상한을 적용한다.

자체 25점 문제

초당 45건의 지속 부하와 대용량 전송이 함께 있는 서비스에서 지연·처리량 목표를 만족하도록 네트워크·처리 용량 통제안을 설계하시오.

요구어는 설계다. 대역폭·처리능력·대기열을 한 수치로 합치지 말고, 한 건 지연의 구성요소와 전체 완료량의 병목을 분리해 측정·증설·유입통제 기준을 제시한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 지연·대역폭·처리량 목표와 측정경계
2. 전송·전파·대기·처리시간 분해
3. 도착률과 지속 처리능력 비교
4. 네트워크·CPU·저장·외부의존 병목 확인
5. 상위 백분위·오류율·대기열 상한
6. 증설·묶음·동시성의 교환관계
7. 유입제한·백프레셔·재시도 통제
8. 부하 단계별 재측정과 종료조건

25점 답안 도식

유입·유한 대기열·실제 완료의 그림과 지연·오류의 동시 채택 기준을 재사용한다. 네트워크 대역폭, 서버 능력, 저장·외부 API의 병목을 따로 측정해 증설·유입제한·대기열 상한을 선택하고 같은 조건에서 재시험한다.

25점 모범답안

먼저 한 요청의 목표를 p95 지연, 오류율, 요청 크기와 측정구간으로 고정하고 초당 45건이 실제 지속 부하인지 확인한다. 전송시간·전파시간·대기시간·처리시간을 분리해 어느 구간이 한 건의 지연을 만드는지 측정한다. 동시에 네트워크 전송률, 서버 처리능력, 저장장치·잠금·외부 API의 완료량을 비교해 가장 좁은 병목을 찾는다.

서버의 지속 처리능력이 초당 50건이라도 45건이 한계에 가까우면 변동 때문에 대기열이 커질 수 있으므로 평균값만으로 안전여유를 선언하지 않는다. p95 지연, 대기열 길이, 오류율과 자원 사용률을 부하 단계별로 관측하고 목표를 넘기기 전에 유입제한과 대기열 상한을 적용한다.

대용량 전송이 병목이면 회선·전송형태를 조정하고, CPU·저장·외부 API가 병목이면 그 자원을 따로 개선한다. 묶음과 동시성은 처리량을 높일 수 있지만 첫 응답 지연과 경합을 늘릴 수 있으므로 같은 입력·부하에서 재측정한다. 목표를 만족하는 지속가능 부하를 운영 용량으로 두고 최대 순간 처리량을 용량으로 오인하지 않는다.

자체 설계에서는 같은 크기의 API 요청을 45건/s로 10분 유지하며 완료 요청 p95≤1초, 전체 시도 오류·거절률≤1%를 수용조건으로 선택한다. 서버 앞 대기열 상한은 25건이고 초과 유입은 즉시 과부하 응답으로 제한하며 이 응답도 전체 시도의 분모와 오류·거절 건수의 분자에 포함한다. 이는 5MB 파일 전송 4초 사례와 다른 요청군이다. 두 요청군을 각각 시험한 결과만으로 함께 실행할 때의 용량을 승인하지 않는다.

혼합 부하의 추가 설계 조건. 자체 시험 조건으로 API 45건/s와 5MB 파일 1건/s를 같은 회선·서버에서 같은 10분 동안 실행한다고 명시한다. 파일은 최대 4건을 동시에 전송하며 4초 완료 목표를 별도로 확인한다. 이때 파일의 순수 데이터만으로도 5MB × 1건/s × 8 = 40Mb/s가 필요하므로 앞의 10Mb/s 회선으로 이 혼합 목표를 만족할 수 없다. 전송 오버헤드와 API 트래픽까지 포함한 회선 여유를 확보하거나 파일 유입 목표를 낮춘 뒤, 공유 CPU·저장 경합도 다시 측정한다. 이는 새 시험을 설계하기 위한 가정이며 측정 완료 기록이 아니다. 같은 시간창에서 API p95·전체 시도 오류/거절률·대기열과 파일 완료시간·지속 처리량을 함께 확인하고 두 요청군의 조건을 모두 통과한 범위만 채택한다.

API의 가상 관측값 p95 800ms·오류율 2%이면 지연만 통과하므로 증설/병목 개선 후 같은 부하로 재시험하기 전에는 45건/s를 승인 용량으로 선언하지 않는다. 55건/s 지속 시험에서는 무제한 적체 대신 제한 동작과 오류율 상승이 기록되는지 확인한다.

출처와 적용 경계

지연·대역폭·처리량과 대기열·병목 구분은 안정된 성능 기초개념이다. 5MB·10Mb/s·초당 50건·95번째 백분위 800ms 수치는 단위와 병목을 연습하기 위한 자체 가정이며 실제 서비스 성능자료가 아니다.

자기교정과 조건 변경

경로가 100Mb/s로 넓어진다면? 40Mb 파일의 전송 하한은 약 0.4초로 줄지만 왕복·대기·처리시간은 별도로 남는다.

서버의 지속 처리능력이 초당 40건으로 낮아진다면? 초당 45건 유입도 장기적으로 대기열을 늘리므로 유입제한·증설·작업량 축소가 필요하다.

파일이 압축되어 2.5MB가 된다면? 동일한 10Mb/s 가정의 전송 하한은 약 2초로 줄며 압축·해제 처리비용은 별도로 측정한다.

한 번에 되찾기

지연은 한 건이 기다린 시간, 대역폭은 운반 가능한 용량, 처리량은 실제 완료량이다. 부하가 병목 능력에 가까워지면 대기열 때문에 지연이 급증하므로 세 축과 측정조건을 함께 판단한다.