p95·p99 레이턴시 차이 분석

p95는 전체 요청중 95%가 이 시간 이내의 처리됨을 의미하고 하위 5% 사용자는 이보다 느린 응답을 받는다. 대다수의 사용자의 일반적인 최악의 경험을 대변한다

p99는 이제 눈치까셨겠지만 99가 이 시간 이내의 처리됨을 의미하고 하위 1%만이 이보다 느린 응답을 받는다. 롱테일 레이턴시, 극단적으로 느린응답과 안정성을 대변한다.

걍 단순히 95 99 뭐가 차이인거지 싶을 수 있다. 걍수치적으로 보여주는 값이니까. 상세한 차이나 의미하는 바를 알아보겠다.

물론 서버 시스템의 도메인 유형에 따라 뭔가 다를 순잇지만 보편적인 기준으로 설명하겠다.

p95, p99 사이의 레이턴시 갭은 시스템의 예측 가능성과 안정성을 나타낸다.

격차가 작을때 (안정적임)

격차가 클때

p95 = 50ms, p99 = 800ms
95는 쾌적함을 느끼지만, 나머지 극소수의 사용자는 매우 심각한 지연을 겪고잇다. 트래픽이 많은 대규모 서비스에서 1%는 적은수가 아니다. 100만번의 요청중 1만번이 느린 응답인거니까.

대부분의 요청은 정상 처리되는데 극소수의 요청만이 크게 지연되는 데에는 다음과 같은 백엔드/인프라적 원인이 존재한다

가비지 컬렉션 stw: java, go, nodejs 등의 언어에서 메모리를 정리하기 위해 애플리케이션 실행을 멈추는 stw 때문에 그 순간 들어온 요청에대한 레이턴시다
캐시 미스: 95%요청은 cache hit고 redis나 memcached 같은 빠른 캐시에서 처리되지만 나머지 요청이 캐시에 없어 느린 메인데이터베이스까지 다녀와야하는경우가 발생했을때도 레이턴시차이가 길게난다.
db lock: 특정테이블이나 로우 트랜잭션이 몰려 lock이 걸리면서 일부 쿼리가 대기 상태에 빠질때 발생한다.
네트워크 패킷 손실 및 재전송: 네트워크 일시적 혼잡으로 인해 tcp 패킷이 손실되어 재전송이 일어나는 경우 지연시간이 크게 튄다.
콜드 스타트: 서버리스 환경이나 컨테이너 스케일아웃시 새로 생성된 인스턴스가 첫 요청을 처리할 때 걸리는 초기지연이다.

평균 average 레이턴시는 극단적인 지연 outlier을 숨기기 때문에 모니터링 지표로 적합하지 않다

SLO(서비스 수준 목표)는 p99를 기준으로 설정한다. 고가용성 시스템을 지향하면 p95가 아닌 99 or 99.9 지표를 기준으로 목표를 잡아야한다.

분산 추적도 있으면 좋은데 jaeger, zipkin 같은 툴을통해서 p99에 해당하는 1% 느린 요청들이 마이크로서비스 아키텍처 내의 정확히 어느 구간 db, external api, 특정서비스에서 지연되어있는지 추적해야한다.