시스템 성능의 지표
시스템을 사용하는 사용자는 불만을 얘기한다.
- 시스템이 느려서 사용할 수 없어
- 클릭한 후 아무리 기다려도 화면이 뜨지 않아
- 일괄 처리가 아침이 되어도 끝나지 않아
인프라 관점에서 응답(Response)과 처리량(Throughput)은 시스템 성능의 중요한 지표다.
응답은 사용자 입장에서 요청을 보낸 후 응답받기까지를 의미한다.
처리량은 서비스 제공자 입장에서 시간당 처리하는 양이다.
응답 문제
응답 시간은 아래와 같이 세세히 나눌 수 있다.
사용자가 브라우저를 클릭하여 요청이 실행되기까지
+ 웹 서버 통신 + 웹 서버 처리
+ AP 서버 통신 + AP 서버 처리
+ DB 서버 통신 + DB 처리
+ ...
+ 브라우저 화면이 결과를 표시하는 시간
서버 처리 시간은 데이터 구조나 탐색 알고리즘 등으로 단축할 수 있지만 통신 시간을 단축하는 데에는 한계가 있다.
응답 문제에 대한 한계는 아래 처리량 문제를 통해 개선하는 것이 일반적이다.
처리량 문제
처리량 문제에 대해 쉬운 비유를 들어보자.
2차선 도로에서는 자동차 세 대가 동시에 통과할 수 없다.
처리하는 영역에 비해 데이터가 많을 경우 처리량 문제가 생긴다.
시스템의 특정 구간에서 처리량 문제가 생기는 경우 이를 병목 현상이라고 한다.
성능 개선을 위해서는 가장 먼저 병목 현상이 발생하고 있는 위치를 정확히 파악하고, 로그를 통해 문제를 분석해야 한다.
주요 방법은 두 가지다.
- 문제를 어떻게든 해결하는 것.
다른 말로는 튜닝. - 시스템 이용자 수를 제한하는 것.
트래픽 초과로 차단되었습니다란 메세지를 띄우는 것.
다만 두 번째 방법은 근본적인 해결책이 아니므로 서버를 증설하는 방향으로 나아가야 한다.
병목 지점은 존재할 수밖에 없다.
만약 AP 서버의 병목 현상을 해결하게 된다면, DB 서버가 더 많은 요청을 받게 되며 병목 지점으로 바뀌는 상황을 초래할 수 있다.
따라서 성능 개선의 목표는 단순히 병목 현상을 전부 해결하는 것이 아니라 '특정 기능의 응답 시간을 몇 퍼센트 개선한다'와 같이 구체적인 목표를 정하는 것이 좋다.
"이런 문제도 모든 것을 메모리에 저장하는 시대가 오면 해결될 거라고 말하는 사람도 있지만,
나는 시스템 성능 진화와 데이터양 증가는 같은 속도로 진행되기 때문에 아무리 시간이 지나도 성능 문제는 사라지지 않을 것이라고 생각한다."
참고
<그림으로 공부하는 IT 인프라 구조>