이 사이트의 실습은 자바스크립트를 켜야 움직입니다. 아래는 같은 내용을 글로 적은 것입니다.

공부 › 아키텍처와 운영 › 관측

평균과 백분위

평균 응답 시간은 멀쩡한데 왜 느리다는 불만이 오나

요청 1,000건의 응답 시간을 모았습니다. 대부분은 0.1초 안팎이지만 일부가 아주 느립니다. 평균은 모든 값을 더해 개수로 나눈 값이고, 백분위는 값을 순서대로 줄 세웠을 때 몇 퍼센트 지점에 있는 값인지를 말합니다(p99는 99% 지점의 값). 같은 데이터를 평균과 백분위로 나란히 놓고, 느린 요청이 어느 쪽에서 드러나는지 봅니다.

실행으로 대조 · 같은 데이터를 자바로 따로 계산해 대조

이 실습에 나오는 개념

TPS와 응답 시간 백분위

TPS는 시스템이 1초에 처리하는 요청(트랜잭션)의 수다. 응답 시간은 평균만 보면 일부 느린 요청이 가려지므로 백분위로 본다. p95가 1초라는 것은 요청의 95%가 1초 안에 처리된다는 뜻이고, p99는 99%를 기준으로 한 값이다. 느린 일부 요청이 사용자 경험을 좌우하므로 p95, p99를 함께 관리한다.

부하 테스트

실제와 비슷한 양의 요청을 인위적으로 보내 시스템이 어느 정도까지 견디는지, 한계에 이르렀을 때 어디가 먼저 문제가 되는지(병목) 확인하는 테스트다. 운영 전에 처리 가능한 용량을 파악하고 개선 효과를 측정하는 데 쓴다. JMeter, nGrinder, k6 같은 도구를 사용한다.

APM

애플리케이션의 성능을 모니터링하는 도구다. 요청별 응답 시간, 어느 메서드나 쿼리에서 시간이 걸렸는지, 오류 발생 현황 등을 수집해 보여 준다. 자바에서는 주로 에이전트 방식으로 코드 수정 없이 적용한다. Pinpoint, Scouter, Datadog 등이 있다.

관측성(로그, 지표, 추적)

시스템의 외부 출력만으로 내부 상태를 파악할 수 있는 능력이다. 로그는 개별 사건의 기록, 지표(메트릭)는 요청 수나 응답 시간처럼 수치로 집계한 값, 추적은 하나의 요청이 여러 서비스를 거쳐 가는 경로와 구간별 소요 시간의 기록이다. 세 가지를 함께 갖춰야 문제를 감지하고 원인을 찾을 수 있다.

이렇게 바꿔 보세요

• 처음 설정으로 — 2%가 3초. 평균은 0.16초로 괜찮아 보이지만 p99는 3초입니다.
• 느린 요청이 없을 때 — 평균, 중앙값, p99가 거의 같습니다.
• 0.5%만 느릴 때 — p99에도 잡히지 않습니다. 최댓값이나 p99.9를 봐야 보입니다.
• 6%가 느릴 때 — p95부터 튀어 오릅니다.
• 20%가 10초 — 평균이 2초를 넘었지만, 그런 응답을 받은 사용자는 한 명도 없습니다.

처음 설정으로 실행하면

1. 요청 1,000건의 응답 시간을 모았습니다. 980건은 0.08~0.12초, 20건은 3초입니다.
2. 평균: 모든 응답 시간을 더해 1,000으로 나누면 0.16초입니다. 빠른 요청이 훨씬 많아서 느린 요청의 존재가 평균에 묻힙니다. 그리고 실제로 0.16초 만에 응답받은 요청은 하나도 없습니다.
3. p50(중앙값): 응답 시간을 빠른 순으로 줄 세웠을 때 500번째 값은 0.10초입니다. "절반의 요청은 이 시간 안에 끝났다"는 뜻입니다. 보통의 사용자가 겪는 속도입니다.
4. p95: 950번째 값은 0.12초입니다. "95%의 요청은 이 시간 안에 끝났고, 나머지 5%는 이보다 느렸다"는 뜻입니다.
5. p99: 990번째 값은 3.00초입니다. "99%의 요청은 이 시간 안에 끝났고, 가장 느린 1%만 이보다 느렸다"는 뜻입니다. 평균으로는 보이지 않던 느린 요청이 여기서 드러납니다.
6. 최댓값은 3.00초, p99.9(999번째 값)는 3.00초입니다. 하루 요청이 100만 건이라면 이 비율로 약 20,000건이 3초씩 걸린다는 뜻입니다.

실행 결과

• 평균은 소수의 느린 요청을 가립니다. 응답 시간은 대부분 빠르고 일부만 매우 느린 치우친 분포라서, 평균이 "대표적인 경험"을 나타내지 못합니다. 그래서 성능 목표는 "평균 0.2초"가 아니라 "p99가 1초 이하"처럼 백분위로 정합니다.
• 사용자 한 명이 화면 하나를 볼 때 여러 API를 호출하므로, 그중 하나라도 느린 쪽에 걸릴 확률은 개별 요청의 비율보다 높습니다. 꼬리 쪽 지연이 체감 속도를 좌우하는 이유입니다.

코드

// Micrometer: 응답 시간의 백분위를 함께 기록
Timer.builder("http.server.requests")
    .publishPercentiles(0.5, 0.95, 0.99)
    .register(registry);

# application.yml
management.metrics.distribution.percentiles:
  http.server.requests: 0.5, 0.95, 0.99

이 모형의 전제

요청 1,000건의 고정된 가상 데이터입니다. 백분위는 값을 작은 순으로 줄 세워 해당 순번의 값을 취하는 방식(최근접 순위법)으로 계산했습니다. 실제 모니터링 도구는 모든 값을 저장하지 않고 구간별 개수로 근사하므로 약간의 오차가 있고, 여러 서버의 백분위를 평균 내는 것은 올바른 계산이 아닙니다. 같은 데이터로 평균과 백분위를 자바에서 따로 계산해 화면의 값과 일치하는 것을 확인했습니다.

앞 실습: 쿠버네티스 자가 치유 · 다음 실습: 분산 추적