처리량과 응답시간, 어느 것이 더 중요한가?

사람들은 흔히 "성능 = 짧은 응답시간" 으로만 여기는 경향이 있다.

 

응답시간은 업무 유형이 다양하여 동일 기준을 적용하기 어려우므로 업무별 응답시간이 다를 수 밖에 없고, 부하 수준에 따른 변동성을 내포하고 있어 시점에 따라 그 판단이 다를 수 있다. 그러기에 성능의 척도는 빠른 처리보다는 단위 시간당 처리한 트랜잭션량을 우선시한다. 물론, 응답시간과 처리량은 밀접한 상관 관계를 가지고 있지만 이 둘은 엄연히 구분되어야 한다. 다음의 예를 살펴보자.

김해공항에는 5개의 입국 심사대가 있어 5명이 동시에 입국 심사를 받을 수 있다고 가정하자. 한 사람당 심사에 걸리는 시간은 30초라고 한다. 이 때, 입국 심사 시스템의 성능은 무엇으로 평가하고 또 어떻게 개선될 수 있을까? 심사원의 개별 심사 시간일까? 그래서 일 처리가 빠른 선임 사원으로 교체하면 성능이 더 좋아질까?

 

단위 시간당 심사한 사람 수 측면에서 볼 때, 이는 완전한 답이 아니다.

만일, 인천공항에서는 15개의 입국 심사대에서 동시에 처리하고 있다면? 비록, 심사 처리 시간은 60초가 소요되어 김해 공항보다 느릴 지라도 같은 시간 동안 완료한 전체 심사 건수는 인천공항이 훨씬 더 많다. 이는 심사원의 일 처리 속도 향상으로는 한계가 있음을 의미한다. 즉, 처리 시간만으로는 입국 심사 시스템의 성능을 대변하지 못한다.

 

이를 달리 표현하면, 5,000명이 사용하여 건별 3초가 소요되는 A시스템은 초당 1,667건을, 15,000명이 사용하여 건별 6초가 걸리는 B시스템은 초당 2,500건을 처리한 결과다.

이렇게, 시스템의 성능은 처리량으로 대변될 수 있지만 응답시간과는 뗄레야 뗄 수 없는 밀접한 관계에 있다. Little’s law에 의해 응답시간이 작을수록 처리량이 증가하게 되므로 병렬처리를 고려하지 않는다면 튜닝을 통해 응답시간을 낮추어야만 처리량을 향상시킬 수 있으므로 응답시간은 성능을 개선시키는 가장 임팩트 있는 요소가 된다.

 

처리량과 응답시간, 이 두 메트릭은 때로는 동일 응답시간 비용으로 더 높은 처리량을 가지거나 동일 처리량의 비용으로 더 나은 응답시간을 가질 수 있다. 사용자가 수용할 수 있는 적절한 성능은 사용자의 기대에 크게 벗어나지 않는 응답시간과 함께 예상되는 트랜잭션 처리량을 기반으로 한다.

 

---

 

스토리지의 경우, 다양한 업무별 어플리케이션 성능을 평가하는 기업의 정보시스템과는 달리, I/O에 따른 성능만을 평가하므로 좀 더 단순하게 접근할 수 있다. 즉, 고정된 I/O 프로파일에 따른 Latency와 IOPS를 측정하게 된다. 스토리지 역시 최대 처리량 (IOPS)이 중요한 이유는, 단위 시간당 처리 가능한 I/O가 많을 수록 더 많은 호스트 I/O를 처리할 수 있기 때문이다.

예를 들어, 성능 요구사항이 1,000,000 IOPS일 경우, A 제품은 최대 성능이 200,000 IOPS, B 제품은 250,000 IOPS라면, A 제품은 5대, B 제품은 4대로 요구사항을 충족할 수 있다. 고객이 4대로 목표 성능을 충족하기를 원했다면, 처리속도가 더 빠르고 느리고를 떠나 A 제품으로는 불가한 것이다. 이렇게, 고성능은 비용을 줄이는 결과로 이어진다.

 

반면, 성능 요구사항이 100,000 IOPS일 경우를 생각해보자.

이 때는, 굳이 높은 IOPS에 집착할 필요가 없다. 과부하를 더 발생시켜 10,000~20,000 IOPS 더 나오게 한들, 이미 Saturation point를 넘어섰기 때문에 Little's law에 의해 Latency만 크게 증가하기 때문이다. 예를 들어, A 제품의 최대 처리량이 200,000 IOPS, 이 때, Latency가 1ms이고, B 제품은 270,000 IOPS, 5ms의 테스트 결과를 받는다면, 당신의 선택은? 당연히 A 제품을 선택해야 한다.

B 제품이 더 많은 호스트 연결, 또는 더 많은 I/O를 처리할 수 있으나, A 제품보다 상대적으로 5배 느리기 때문이다. (실제로는 이 정도 차이는 아니겠지만 무리하게 테스트한 결과가 그러하므로) 또한, 이 경우의 요구사항은 많은 I/O 처리량을 필요로 하지 않는다. (대부분의 고객들은, 실제로는 한 스토리지가 발휘하는 최대 IOPS의 1/10도 사용하지 않는 경우가 허다하다는 사실을 인지하지 못한다.)

 

처리량이 스토리지의 대표 성능 요소이기는 하나, 제품의 성능 비교 시, IOPS만 보는 것은 안일한 일일 수 있다. IOPS는 기본적으로 Latency의 영향을 받지만, 어느 한 제품이 하드웨어 사양이 높다면 이는 전혀 다른 이야기가 된다. CPU 코어 수/클럭 주파수가 높거나 프론트엔드/백엔드 대역폭이 높다면 당연히 성능에 유리할 수 밖에 없다. 벤더별 제품은 저마다 하드웨어 사양이 다르고, 이로 인한 IOPS 편차가 클 수 밖에 없다. 그러므로 단순히 IOPS만 보기보다는 Latency를 함께 살펴봐야 하는 이유이다.

 

그런데, 하드웨어 사양이 높다고 하여 반드시 Latency가 좋다고 할 수는 없다.

예를 들어, 스토리지 컨트롤러의 CPU가 4Socket이라고 할 때, 여기에 1Socket을 추가한다고 하여 Latency가 낮아질까? CPU의 처리능력이 증대되었기에 처리 가능한 IOPS가 더 늘어날 것이다. Latency는 하드웨어 사양보다는 Controller OS에 직접적인 영향을 받는다. 이는, I/O Flow 및 Caching 알고리즘, Meta 데이터 처리, 중복제거/압축 방식 등 전체적인 I/O를 처리하는 로직이 얼마나 효율적인가에 대한 영향이다. 이를 흔히, 스토리지 아키텍처라 표현한다.

 

제품별 사양이 다르기에 최대 IOPS만으로 성능을 평가하는 것은 공정하다고 보기 어려우므로, (물론 사양이 낮아도 더 높은 처리량을 내는 제품이 있다. 앞서 말한 아키텍처가 훌륭하므로) Latency 평가가 동시에 이루어져야 한다. 예를 들면, 예상하는 최대 호스트 I/O량 (e.g. 100,000 IOPS)을 설정하고, 이 기준으로 Latency를 측정하거나, 사용하는 어플리케이션에 따른 빠른 응답시간을 고려하여 스토리지 Latency (e.g. 1ms)를 정하고, 이 때의 처리량 (IOPS)을 측정하는 것이다. 또는 최대 IOPS에서의 Latency를 측정할 수도 있다.

이 말은 곧, 성능 목표 수립이 아주 중요하다는 것을 의미한다.

대부분 성능 목표 없이 부하 테스트한 후, 최대 IOPS 결과만 보는 경우가 많은데, 이는 성능 측정일 뿐, 성능 평가는 아닌 것이다. 성능을 제대로 비교 테스트하기 위해서는 원하는 IOPS와 Latency에 대한 고려가 선행되어야 하며, 설정한 기준에 따라, 보다 낮은 Latency에, 보다 높은 IOPS를 나타내는 스토리지를 선택해야 할 것이다.

 

 

정리하면, 처리 속도를 높이는 요인은 응답시간/Latency이고, 이 응답시간/Latency이 낮을 수록 성능 측면에서 얼마나 잘 만든 시스템인지를 평가할 수 있고, 응답시간/Latency이 낮을 수록 높은 처리량으로 이어지게 되며, 결국 이 처리량이 한 시스템의 성능 지표로 대표된다.