성능 기술과 백분위 ( percentile )

성능 기술하기

• 부하 매개 변수를 증가시키고 시스템 자원은 그대로면 성능은 어떻게 될까?
• 부하 매개변수를 증가시켰을 때 성능을 그대로 하려면 자원은 얼마나 늘려야 할까?

 

두 질문 모두 성능수치가 필요하다. 하둡 (Hadoop) 같은 일괄 처리 시스템은 보통 처리량 ( throughput ) ( 초당 처리 가능한 레코드 수나 일정 크기의 데이터 집합으로 작업을 수행할 때 걸리는 전체 시간 )에 관심을 가진다. 온라인 시스템에서 더 중요한 사항은 서비스 응답 시간 ( response time ), 즉 클라이언트가 요청을 보내고 응답을 돌려받기 까지의 시간이다.

 

클라이언트가 몇 번이고 반복해서 동일한 요청을 하더라도 매번 응답 시간은 다르다. 이 때, 대부분의 요청은 꽤 빨라도, 특히 오래 걸리는 특이 값 ( outlier ) 이 있다. 아마도 이 느린 요청은 더 많은 데이터를 처리하기 때문에 본질적으로 비쌀지도 모르지만, 모든 요청이 동일한 시간이 걸려야 한다고 생각될 때에도 발생할 수 있다. 백그라운드 프로세스의 컨텍스트 스위치, 네트워크 패킷 손실과 TCP 재전송, 가비지 컬렉션 휴지 ( garbage collection pause ), 디스크에서 읽기를 강제하는 페이지 폴트 ( page fault ), 서버 랙의 기계적인 진동이나 다른 여러 원인으로 추가적인 지연이 발생할 수 있다.

 

백분위 사용하기

일반적으로 산술 평균된 값은 좋은 지표가 아니다. 평균은 사용자들이 실제로 얼마나 지연을 경험했는지를 알려주지 않기 때문이다. 따라서 평균보다는 백분위 ( percentile ) 를 사용하는 것이 낫다. 중앙값을 p50이라고 하고, 그 값이 200ms라고 가정하면, 사용자의 절반은 200ms보다 빠르게, 나머지 절반은 200ms보다 느리게 응답을 돌려받았다는 의미가 된다.

 

특이 값이 얼마나 좋지 않은지 알아보려면 상위 백분위를 보는 것이 좋다. 이 때 사용하는 백분위는 95분위, 99분위, 99.9분위가 일반적이다. 축약해서 p95, p99, p999라고 한다. 예를 들어 95분위 응답시간이 1.5초라면, 100개 요청 중 95개는 1.5초 이내라는 뜻이다.

 

꼬리 지연 시간 ( tail latency )

꼬리 지연 시간은 상위 백분위 응답 시간이다. 상위 백분위 응답 시간은 사용자 경험에 직접 영향을 주기 때문에 매우 중요하다. 예를 들어 아마존은 내부 서비스의 응답 시간 요구사항을 99.9분위로 기술한다. 99.9분위는 1,000개의 요청 중 1개에만 영향을 준다. 극히 적은 숫자라고 생각될 수 있음에도 이게 중요한 이유는, 보통 응답 시간이 가장 느린 요청을 경험한 고객들이 가장 많은 데이터를 가지고 있기 때문이다. 가령 결제가 느린 고객은, 가장 많은 물건을 장바구니에 담고 구매를 했기 때문에 느린 응답 시간을 경험했을 가능성이 크다. 그리고 통상 이런 고객이야 말로 가장 중요한 고객이다. 아마존은 웹 사이트가 0.1초 느려지면 판매랑이 1% 줄어들고, 1초가 느려지면 고객의 만족도는 16% 줄어드는 현상을 관찰했다.

 

반면 99.99분위는 최적화에 들어가는 비용이 과다할 뿐더러, 실제 효용은 적다고 여겨진다. 최상위 백분위는 통제할 수 없는 임의 이벤트에 쉽게 영향을 받기 때문에 시간을 줄이기가 매우 어렵다.

 

큐 대기 지연 ( queueing delay )

서버는 병렬로 소수의 작업만 수행할 수 있고, 예를 들어 CPU 코어 수에 제한된 일을 처리할 수 있다. 따라서 소수의 느린 요청 처리는, 그 처리 뿐만 아니라 후속 처리 전체를 지연시킨다. 이런 현상을 선두 차단 ( head-of-line blocking ) 이라고 한다. 서버에서 후속 요청을 빠르게 처리하더라도 이전 요청이 완료되길 기다리는 시간 때문에 클라이언트는 전체 응답 시간이 느리다고 생각할 것이다. 이런 문제 때문에 클라이언트 쪽 응답 시간 측정이 중요하다. ( 서버에서만 시간을 재면 각 요청마다의 시간이 나오기 때문이고, 실제 클라이언트의 대기 시간이 아니기 때문이다. )