동시 요청 수를 늘리자 초당 처리량은 올랐지만 일부 사용자는 훨씬 오래 기다립니다. 처리량과 응답 시간의 관계를 어떤 지표로 판단하나요?

처리량은 일정 시간 동안 몇 건을 완료했는지이고, 응답 시간은 요청 하나가 끝날 때까지 얼마나 걸렸는지입니다. 둘은 관련은 있지만 같은 지표는 아닙니다. 한꺼번에 처리하는 요청을 늘려 완료 건수가 많아지더라도, 각 요청이 기다리는 시간은 길어질 수 있습니다. 평균 응답 시간만으로는 그런 변화를 충분히 알 수 없습니다.

예를 들어 DB 연결 풀이 이미 가득 찼는데 요청 수를 더 늘린다고 하겠습니다. DB가 처리하는 속도는 비슷한데 연결을 기다리는 요청만 쌓이면, 처리량은 거의 그대로이고 응답 시간은 나빠집니다. 저는 우선 실제 쿼리 시간과 연결 대기 시간을 나눠 보겠습니다. 대기가 늘어난 것이라면 실행 스레드부터 추가하지 않고, 들어오는 작업 수를 제한하거나 DB 쪽 병목을 먼저 줄이겠습니다.

평균도 대부분이 빠르면 일부의 긴 지연을 가릴 수 있습니다. 그래서 p95나 p99처럼 느린 쪽 요청이 어느 정도 걸리는지 함께 봐야 합니다. p99가 1초라는 것은 측정한 요청 대부분이 1초 안에 끝났다는 뜻이지, 모든 요청의 상한이 1초라는 뜻은 아닙니다. 여러 서버의 p99를 평균 내서 전체 값으로 쓰는 것도 맞지 않습니다. 전체 요청 분포를 모아서 계산해야 합니다.

부하 테스트에서도 서버가 느려지면 도구가 보내는 요청까지 줄어드는지 확인하겠습니다. 응답을 받아야 다음 요청을 보내는 방식으로만 테스트하면, 실제로 사용자가 계속 들어오는 서비스의 적체를 충분히 드러내지 못할 수 있습니다. 이런 측정 누락을 coordinated omission이라고 합니다. 도착률을 유지하는 테스트도 함께 하되, 부하 생성기 자체가 밀려 목표만큼 보내지 못한 것은 아닌지 확인해야 합니다.

최종적으로 저는 최대 TPS보다 정해진 지연과 오류 목표를 만족하면서 처리한 요청 수를 보겠습니다. 부하를 단계적으로 올려 p99와 오류가 나빠지기 시작하는 지점을 찾고, 그보다 여유 있는 범위를 운영 용량으로 잡겠습니다. 빠르게 실패한 요청이 늘어 평균만 좋아지는 경우도 있으므로 성공과 실패를 분리해서 비교하겠습니다. 성능 개선은 숫자 하나를 높이는 것이 아니라, 사용자가 기대한 시간 안에 실제 일을 끝내는 능력을 높이는 것이라고 생각합니다.

같은 처리량에서도 사용자가 기다리는 시간은 다릅니다

처리량을 throughput, 요청 시작부터 응답까지 걸린 시간을 latency라고 합니다. 응답 시간에는 실제 계산·I/O뿐 아니라 실행 자원을 기다리는 큐잉 지연(queueing delay)이 포함됩니다. 자원이 한계에 가까워지면 작은 입력 증가나 긴 작업 하나에도 큐가 길어질 수 있습니다. 그래서 CPU가 100%가 되기 전부터 지연 목표를 넘을 수 있고, 평균 이용률만으로 운영 여유를 정하면 순간 폭주에 취약합니다. 동시성을 늘리는 것은 대기를 겹쳐 처리량을 높일 수 있지만 포화 이후에는 경쟁과 적체를 키울 수 있습니다.

안정된 시스템에서 평균 진행 중 요청 수는 처리율과 평균 체류 시간의 곱이라는 리틀의 법칙을 사용할 수 있습니다. 예를 들어 초당 100개를 완료하며 평균 체류 시간이 0.2초면 평균 20개가 시스템 안에 있습니다. 여기서 시스템 경계에 대기열을 포함했는지에 따라 값의 의미가 달라집니다. 시간대가 다른 통계나 서로 다른 종류의 요청을 섞어 워커 수를 계산해서는 안 됩니다. 적체가 끝없이 증가하는 상황에 정상 상태의 평균 관계를 그대로 적용해 p99까지 예측할 수도 없습니다.

느린 일부 요청과 빠른 오류를 숨기지 않습니다

분포의 느린 쪽을 꼬리 지연(tail latency)이라고 부릅니다. p99는 관찰한 표본의 약 99%가 그 값 이하라는 뜻이지만 표본 수·계산 방법·집계 구간에 따라 안정성이 다릅니다. 100건 안팎의 적은 표본으로 p99 변화를 정밀하게 해석하기는 어렵고, 각 서버의 p99만 모아 평균 내면 요청량이 다른 서버의 분포를 복원하지 못합니다. 같은 버킷 경계의 히스토그램을 합쳐 분포를 계산하는 등 집계 가능한 측정 방식을 선택하겠습니다.

타임아웃된 요청을 지연 통계에서 빼면 가장 느린 요청이 사라집니다. 실패 응답이 즉시 반환돼 평균을 낮추는 경우도 있으므로 성공 지연, 실패·타임아웃 비율, 실제 성공 완료율을 함께 보겠습니다. 특히 캐시 적중 요청과 DB 요청의 비율이 달라졌다면 코드가 빨라지지 않아도 평균이 바뀝니다. 같은 사용자 경로와 데이터 분포에서 비교하고, 전체 수치 아래의 요청 종류별 변화도 확인해야 합니다.

부하 생성기가 실제 대기를 숨길 수 있습니다

응답을 받은 뒤 다음 요청을 보내는 방식을 폐쇄형 부하 모델(closed-loop), 응답과 무관하게 정한 도착률로 요청을 보내는 방식을 개방형 부하 모델(open-loop)이라고 합니다. 전자는 동시 사용자의 반복 행동에 맞을 수 있지만 외부에서 계속 주문이 들어오는 상황을 그대로 재현하지 못할 수 있습니다. 서버가 느릴 때 생성기까지 새 요청을 줄이면 원래 더 들어왔을 요청의 긴 대기가 측정에서 빠집니다. 이런 누락이 coordinated omission입니다.

개방형 시험에서도 생성기가 목표 속도를 못 내면 결과가 왜곡됩니다. 예정 발송 시각·실제 발송 시각·완료 시각을 나눠 생성기 지연과 서버 지연을 구분하겠습니다. 목표에 따라 실제 전송부터의 지연과 예정 도착부터의 전체 지연을 함께 보고, 달성한 입력률도 기록합니다. 최종 용량은 한 번 찍은 최대 TPS가 아니라 목표 분포와 오류율을 유지하는 부하 범위, 그리고 폭주 뒤 회복 시간으로 정하겠습니다.