8.1 응답과 처리량
8.1.1 성능 문제의 두 가지 원인
시스템 성능을 가리킬 땐 응답과 처리량이라는 지표가 자주 사용된다. 응답은 처리 하나당 소요시간을 의미하며 처리량은 단위 시간당 처리하는 양을 의미한다.
편의점을 예로 들면 계산대가 두 개 있고, 고객이 균등하게 계산대에 줄을 섰을 때, 이때 줄의 끝에 선 후 계산이 끝나기까지 걸리는 시간이 응답시간이고, 계산대에서 한 명당 1분이 걸린다고 하면 계산대가 두 개이기 때문에 1분당 두 명분을 정산할 수 있다. 이것을 처리량이라고 한다.
8.1.2 응답 문제
응답 문제가 발생하는 위치는 로그나 실제 장비 시험 등을 통해서 구체적으로 어떤 계층에서 응답 지연이 발생하고 있는지 파악해야 한다.
8.1.3 처리량 문제
대량의 데이터를 교환하고 싶은데 영역이 부족한 경우에 처리량 문제가 발생한다. 물리적으로 데이터를 통과시킬 수 없을 때 처리량 관점의 병목 현상이 발생하게 된다.
일반적으로 CPU에서 멀수록 처리량이 낮아진다. 따라서 CPU, 메모리 주변 처리량은 높지만 디스크, 네트워크 통신 대역은 낮아서 병목 현상이 발생하기 쉽다.
응답과 처리량은 밀접한 관계가 있다. 응답이 매우 느린 시스템에서는 다수의 사용자 요청이 시스템 내에 누적되므로 전체 처리량도 낮아진다.
8.2 병목 현상이란?
8.2.1 처리 속도의 제한 요소가 되는 병목 현상
인프라 아키텍처 용어로서 병목 현상이란 처리량을 제한하고 있는 요인을 가리킨다. 예를 들어 AP 서버에서 CPU 사용률이 높아져서 처리량이 한계에 다다르고 있다고 할 때 처리량이 포화상태 이기 때문에 AP 서버의 응답 시간도 악화된다. 이때 AP 서버가 병목 지점이 된다고 할 수 있다.
8.2.2 병목 현상은 어떻게 해결하는가?
성능 분석의 시작은 먼저 병목 현상이 발생하고 있는 위치를 정확히 파악하는 것이다.
병목 현상 해결방법
- 병목 위치를 파악해서 어떻게든 해결하는 것이다(튜닝), 튜닝시에는 병목 위치를 작은 단위로 세분화해서 병목 영역을 더 집중적으로 파헤치는 접근법이 유효하다.
- 시스템 이용자 수를 제한하는 것(유량 제어)
8.2.3 병목 지점은 반드시 존재한다.
예) AP 서버가 병목 지점이 되어 AP 서버를 추가한 경우 웹 서버는 두 대의 AP 서버에 대해 요청을 균등하게 분산한다. AP 서버의 병목 현상이 해결되고 처리량이 개선되었지만 DB 서버에는 두 대의 AP 서버에서 요청이 날라오면서 새로운 병목 지점이 된다.
이처럼 하나의 계층에서 병목 현상이 해결되면 반드시 다른 위치에서 병목 현상이 발생한다. 성능 개선시 반드시 시스템 전체 관점에서 목표를 만드는 것이 중요하다.
8.3 3계층형 시스템 그림을 통해 본 병목 현상
8.3.1 CPU 병목 현상 예
반드시 CPU 사용률이 높다 = 나쁘다가 아니다. CPU 사용률은 처리 효율성을 나타내는 것으로 병목 현상 유무와는 관계가 없다.
프로세스가 효율적으로 처리를 진행하다 보면 CPU 사용률이 100%가 될 수 있다. 시스템 관점에서는 비효율적인 상태가 아니라 그 반대다. CPU 사용률이 급증해서 문제가 있는지 없는지를 판단하려면 사용자 관점의 응답 속도나 시스템 전체 처리량을 확인해야 한다.
대기 행렬의 병목 현상
CPU 사용률이 높고 OS상에서 가동하고 있는 프로세스 수가 많으면 대기 행렬에서 병목 현상이 발생한다. 대기 행렬은 CPU가 순조롭게 처리를 진행하고 있다면 언젠가는 해결된다. 대기 행렬의 병목 현상은 처리량 측면의 문제를 의미한다. 시스템에서 CPU를 코어 수가 많은 것으로 변경하거나 서브를 추가해서 병렬 처리하면 처리량이 증가한다. 이 방법들 중 하드웨어의 CPU 코어 수를 늘리거나 수평 분할에 따른 서버 수를 늘리거나 하는 튜닝을 스케일 아웃이라고 부른다.
응답의 병목 현상
대기 행렬을 튜닝하면 처리량 문제는 해결된다. 하지만 처리량 문제를 해결해도 반드시 응답 문제가 해결되는 것은 아니다. 응답 시간을 개선하는 방법은 다음과 같이 있다.
- 처리 능력을 향상시킨다 : 스케일업이라고도 한다. CPU에서 클럭 수 단위는 헤르츠로 이것은 1초당 명령 처리 수를 가리킨다.
- 병렬로 처리한다 : 처리를 분할해서 다수의 CPU 코어에게 동시 처리를 시키는 것이다.
CPU 사용률이 오르지 않는다
대부분 CPU 사용률이 100%에 도달하는 경우가 거의 없다. 그전에 디스크 I/O나 네트워크 I/O에서 막히는 경우가 많다. 데이터베이스는 I/O가 많아서 상태를 개선할 방법으로 다음이 있다.
- 처리 다중화 : 처리를 다중화 해서 CPU를 적절하게 활용
- I/O 비동기화 : 비동기 I/O를 이용하면 프로세스는 I/O 처리 완료를 기다리지 않고 다음으로 넘어갈 수 있다.
8.3.2 메모리 병목 현상 예
- 영역 부족
- 동일 영역의 경합
영역 부족에 의한 병목 현상
프로세스가 가동해서 어떤 처리를 하려면 반드시 전용 메모리 영역이 필요하다. 하지만 서버상의 메모리 영역은 유한하다. 메모리 영역이 부족하지 않도록 OS 커널 측에서 페이징 또는 스와핑이라는 처리를 해서 빈 메모리를 확보하는 구조가 있다.(가상메모리)
동일 데이터에 대한 병목 현상
디스크 I/O 시간을 단축하기 위해서는 메모리에 캐시로 데이터를 배치해 두는 것도 일례가 될 수 있다. 또 애초에 경합이 발생하지 않도록 복수의 프로세스나 스레드가 같은 메모리 영역을 참조하지 않도록 만들면 된다.
8.3.3 디스트 I/O 병목 현상 예
I/O가 병목 지점이 될 때는 CPU 수를 늘리거나 클럭 주파수를 높여도 효과가 없다. I/O 효율을 높이든가 I/O를 줄이는 방법을 고민해야 한다.
- 외부저장소 : SAN, NAS 저장소 등을 사용하는 경우가 많다.
- 순차 I/O와 랜덤 I/O : 순차는 선두부터 차례로 액세스하는 방식, 랜덤은 헤드가 움직이면서 해당 위치로 바로 건너뛰는 방식이다.
8.3.4 네트워크 I/O 병목 현상
네트워크를 경유한 I/O는 CPU 버스나 메모리 간 I/O 보다도 응답 시간 오버헤드가 크다.
통신 프로세스의 병목 현상
하나의 프로세스로 처리하는 경우 높은 처리량을 실현하는 것이 매우 어렵다. 또 통신이 고속화되면 CPU에서 병목 현상이 발생할 수도 있다. 통신에서 대역을 모두 사용하려면 처리를 다중화해서 병렬화할 필요가 있다. 다중화할수록 통신량이 많아지므로 대역폭이 최대치에 가까운 처리량을 실현할 수 있다.
네트워크 경로의 병목 현상 328~329p
8.3.5 애플리케이션 병목 현상 예
330~334p