성능 향상을 위한 인프라 아키텍처

응답과 처리량

성능 문제의 두가지 원인

시스템 성능을 가리킬 때 응답과 처리량이라는 지표가 자주 사용된다. 응답은 처리 하나당 소요 시간을 의미하며, 처리량은 단위 시간당 처리하는 양을 의미한다.
예를 들어 검색 엔진에서 키워드를 입력해서 검색 버튼을 누른 후 검색 결과가 표시되기까지 걸리는 시간이 응답시간이다. 한편 처리량은 이 검색 엔진이 초당 받아 들이는 사용자 수에 해당한다. 응답은 서비스를 이용하는 한 명의 사용자 관점 지표인 반면, 처리량은 서비스 제공자 관점의 지표라고 할 수 있다.
예를 들어, 웹/애플리케이션/DB 서버를 한 세트로 하는 시스템이 시스템 전체에서 1분간 10000HTTP 요처을 처리하는 처리량을 가지고 있다고 하자. 응답 시간은 한 명의 사용자가 본 지표이기 때문에 사용자가 웹 브라우저에서 특정 조작을 한 후 눈에 보이는 결과가 반환되기까지의 시간이다.
실제 시스템에서는 단일 사용자 응답 시간만으로는 부족하기 때문에 여러 사용자의 평균값을 이용한다. 이 때 퍼센타일 개념을 이용한다. 극단저긍로 응답시간이 긴 사용자는 다른 문제를 내포하고 있을 수 있기 때문에 오차라고 생각하고 평균값에 포함하지 않는다. 10%의 사용자 값을 버리고 나머지 90%사용자의 평균 응답 시간을 이용하는 형태이다.

---

병목현상이란?

처리 속도의 제한 요소가 되는 병목 현상

병목현상이란 처리량을 제한하고 있는 요인을 가리킨다. 3계층 시스템을 예로 AP 서버에서 CPU 사용률이 높아져서 처리량이 한계에 다다르고 있다고 하자. 처리량이 포화 상태이기 때문에 애플리케이션 서버의 응답 시간도 약화된다. 사용자는 응답 식나이 전체적으로 지연되고 있는 것을 느끼게 된다. 이때 애플리케이션 서버가 병목 지점이 된다고 할 수 있다.

병목 현상은 어떻게 해결하는가?

병목 현상이 있다는 것을 인지해도 사용자 관점에서 응답이 느려지는 형태로 나타나기에 어디가 원인인지 발견하기 어렵다.
성능 분석의 시작은 먼저 이 병목 현상이 발생하고 있는 위치를 정확히 파악하는 것이다. 이를 위해서는 각 서버의 처리량이나 응답 상황 로그를 취득해서 어느 서버가 병목 지점이 되고 있는지 찾아내는 것부터 시작해야 한다.

병목 현상 해결 방법

병목 지점을 찾았다면 이제 해결해야 한다. 이때 가능한 주요 접근법에는 두 가지가 있다. 첫 번째는 병목 위치를 파악해서 어떻게든 해결하는 것이다. 이것을 튜닝이라고 한다. 튜닝 시에는 병목 위치를 작은 단위로 세분화해서 병목 영역을 더 집중적으로 파헤치는 접근법이 유효하다. 서버 내에서는 여러 가지 하드웨어와 소프트웨어가 동작하고 있기 때문에 각 컴포넌트의 로그를 확인해 갈 필요가 있다.
다른 한 가지 방법은 시스템 이용자 수를 제한하는 것이다. 대부분 병목 현상은 당초 예상했던 부하보다 많은 부하가 걸려서 발생하게 된다. 유량 제어는 적절한 계층에서 이용자 수를 제한하는 접근법이다. 예를 들어, 일반적인 웹 시스템 등에서도 '해당 사이트는 트래픽 초과로 차단되었습니다.'는 것을 본 적이 있을텐데, 웹 서버 계층에서 유량 제어를 하고 있는 것이다.
단, 유량 제어에서는 사용자에게 에러를 반환하는 것이 전부라서 근본적인 해결책은 되지 못한다. 수평 분할을 통해 서버를 증설함으로써 시스템 전체 허용량을 늘리는 접근법을 병용할 필요가 있다.

---

병목 현상 예

병목 현상은 5가지로 분류한다.

• CPU 병목 현상
• 메모리 병목 현상
• 디스크 I/O 병목 현상
• 네트워크 I/O 병목 현상
• 애플리케이션 병목 현상

CPU 병목 현상 예

CPU 사용률은 처리 효율성을 나타내는 것으로 병목 현상 유무와는 관계가 없다. 프로세스가 효율적으로 처리하다 보면 CPU 사용률이 100%가 될 수 잇다. 이것은 시스템 관점에서 비효율적인 상태가 아니라 그 반대이다. 이 상태는 다른 계층의 처리량이 매우 좋아서 최종적으로는 CPU에서 병목 현상이 발생한다는 것을 의미한다.
CPU 사용률은 하나의 상태를 가리키는 지표일 뿐이다. CPU 사용률이 급증해서 문제가 있는지 없는지를 판단하려면 사용자 관점의 응답 속도나 시스템 전체 처리량을 확인해야 한다. 사용자가 만족하지 못한다면 CPU 사용률이 높은 상태 자체를 문제로 생각하지 말고 근본적인 원인을 조사한다.
CPU에 기인한 성능 문제는 주로 두가지가 있다.

대기 행렬의 병목 현상

CPU 사용률이 높고 OS 상에서 가동하고 있는 프로세스 수가 많으면 대기 행렬에서 병목 현상이 발생한다. 커널 영역에는 OS에 CPU 대기 프로세스를 관리하는 큐가 있다. 이 큐는 커널이 관리한다. 대기 행렬은 CPU가 순조롭게 처리하고 있다면 언젠가는 해결된다. 그러나 CPU 처리량보다 사용자 요청이 많다면, 이 대기 행렬이 늘어난다.
대기 행렬의 병목 현상은 처리량 측면의 문제를 의미한다. CPU 코어 수가 많은 것으로 변경하거나, 서브를 추가해서 병렬 처리하면 처리량이 증가한다. 또한, 처리 자체를 짧게 만드는 방법도 유효하다.

응답의 병목현상

처리량 문제를 해결해도 반드시 응답 문제가 해결되는 것은 아니다. 응답 시간을 개선하는 몇 가지 방법이 있다.

1. 처리 능력을 향상시킨다.
   이것은 Scale-up이라고 한다. Scale-up하면 처리에 필요한 시간이 반으로 줄어들기 때문에 응답 시간도 반이 되는 것을 기대할 수 있다. 단, Scale-up으로 성능을 향상시키는 것은 한계가 있다. 최근 CPU는 클럭 차이가 크지 않아서 이를 통한 극적인 개선 효과는 기대하기 어렵다.
2. 병렬로 처리한다.
   두 번째는 처리를 분할해서 다수의 CPU 코어에게 동시 처리를 시키는 것이다. 처리를 '병렬화', '멀티 프로세스화', '멀티 스레드화'해서 복수의 CPU 코어를 이용함으로써 전체적인 처리 응답 시간을 향상시킬 수 있다. 처리를 병렬화할 수 있는가가 중요사항이 도니다. 처리에 따라서는 병렬화하는 것이 매우 어려운 경우도 있으며, 병렬화가 안 되는 경우는 CPU 코어 수를 늘리거나 서버를 늘려서 스케일아웃한다고 해도 큰 효과를 보기 어렵다.
3. CPU 사용률이 오르지 않는다.
   CPU를 사용률이 낮아도 I/O 대기 큐에서 대기하느 프로세스 수가 증가할 수 있다. 이 상태는 CPU 병목 현상일까? 애플리케이션이 CPU, 메모리, I/O 등의 하드웨어 리소스를 제대로 활용하지 못하는 것이 주된 문제다. 이런 상태를 개선할 수 있는 방법이 몇 가지 있다.

• 처리 다중화
• I/O 비동기화

메모리 병목 현상 예

메모리 영역의 병목 현상은 크게 두 가지로 나눌 수 있다.

• 영역 부족
• 동일 영역의 경합

영역 부족에 의한 병목 현상

프로세스가 가동해서 어떤 처리를 하려면 반드시 전용 메모리 영역이 필요하다. 하지만 서버상의 메모리 영역은 유한하다. 이 유한한 메모리 영역이 부족하지 않도록 OS 커널 측에서 '페이징'또는 '스와핑'이라는 처리를 해서 빈 메모리를 확보하는 구조가 있다. 부족한 부분은 디스크 영역으로 보완해서 가상적인 큰 메모리가 있는 것처럼 보인다. 그러나 실제로는 한계가 있으므로 메모리와 디스크에는 압도적인 성능 차이가 있어 조금이라도 디스크에 저장하거나 메모리로 되돌리는 처리가 발생하면 성능 저하가 발생한다.
이 문제는 웹/애플리케이션/DB 서버나 클라이언트 PC 등 어디에서도 발생할 수 있는 문제이다.

동일 데이터에 대한 병목 현상

경합이 발생하지 않도록 복수의 프로세스나 스레드가 같은 메모리 영역을 참조하지 않도록 만들면 된다.

디스크 I/O 병목 현상 예

I/O 병목 현상은 하드 디스크 등의 저장 장치에 대한 I/O 병목이다. 메모리와 비교해서 디스크 I/O는 매우 느리다. SSD 등의 고속 디스크가 있어도 한계가 있다.
I/O가 병목 지점이 될 때는 CPU 수를 늘리거나 클럭 주파수를 높여도 효과가 없다. I/O 효율을 높이든가 I/O를 줄이는 방법을 고민해야 한다.

외부 저장소

많은 기업형 환경에서는 데이터베이스의 저장 위치로 외부 저장소를 사용한다. SAN을 경유하는 SAN 저장소나 네트워크를 경유하는 NAS 저장소 등이 그 예다.
어떤 경로를 통과하든지 애플리케이션 관점에서는 디스크 I/O의 시스템 콜이 발행되고, OS 커널 측에서 필욯나 프로토콜로 요청을 변경해서 디스크나 저장소 측에 요청을 전달한다.
성능 관점에서는 대부분 로컬 디스크는 3~4대의 디스크로 RAID를 구성하고, 캐시로는 서버의 OS 메모리를 이용한다. 이에 비해 외부 저장소는 수십 대에서 수백 대 단위의 디스크를 배치하고, 거기에 캐시 전용 메모리 영역까지 갖추고 있다. 디스크 수에 따라 처리량이 증가하므로 처리량 관점에서는 외부 저장소가 압도적으로 유리하다.
처리량은 동일 영역을 이용하고 있는 사용자가 많을수록 저하된다. 하나의 RAID 그룹을 독점할 수 있으면 좋지만, 다른 애플리케이션과 영역을 공유하고 있는 경우도 있다.
이것은 OS 및 저장소 설정에 의존하므로 애플리케이션 측면에서 조정이 어려워 주의가 필요하다.
단일 응답은 로컬 디스크가 가장 빠르다. 이 차이를 따라잡기 위해 외부 저장소는 자신이 가진 메모리 영역을 잘 활용해서 데이터 캐시를 효율적으로 작성함으로써 개선하려 하고 있다.

순차 I/O와 랜덤 I/O

디스크 I/O에는 순차 액세스와 랜덤 액세스가 있다. 단일 디스크가 기록 위치인 경우는 순차 방식이 빠르고 랜덤은 느리다.
기업 시스템에서 이용하는 저장소는 내부에 다수의 디스크를 가지고 있는데, 이런 I/O 특성을 어떻게 활용하는 것일까? 저장 장치 측에서는 큰 파일에 대한 일괄 읽기 처리가 발생하면 다수의 디스크에 대해 동시에 순차 액세스를 한다. 이를 통해 순차 및 병렬로 액세스할 수 있어서 대용량 데이터라도 고속으로 처리할 수 있다.
하지만 작은 파일에 액세스하는 경우에는 단일 디스크에 랜덤 I/O를 하기 때문에 그다지 빠르지 않다. 때문에 저장 장치 측에서는 앞서 언급한 메모리나 SSD 등 랜덤 I/O에 강한 기억 영역을 이용하여 디스크의 내용을 캐시하는 구조를 적용해서 효율화를 도모하고 있다. 참고로, 순차/랜덤 특성은 파일 크기에 의존하지 않는다.

네트워크 I/O 병목 현상 예

네트워크를 경유한 I/O는 CPU 버스나 메모리 간 I/O보다도 응답 시간 오버헤드가 크다. 이 때문에 응답을 근복적으로 개선하는 것은 어려우며, 처리량을 개선하는 접근법이나 네트워크 I/O 자체가 발생하지 않도록 하는 방법이 효과가 있다.

통신 프로세스의 병목 현상

하나의 프로세스로 처리하는 경우 높은 처리량을 실현하는 것이 매우 어렵다. 이유는 통신에는 반드시 '데이터 전송', '통신 결과 확인' 같은 처리가 포함되므로 항상 풀 파워로 송수신이 이루어지지 않기 때문이다. 또한, 통신이 고속화되면 CPU에서 병목 현상이 발생할 수도 있다.
통신에서 대역을 모두 사용하려면 처리를 다중화해서 병렬화할 필요가 있다. 다중화할수록 통신량이 많아지므로 대역폭이 최대치에 가까운 처리량을 실현할 수 있다. OS나 소프트웨어에 따라서는 이 다중화를 자동으로 구현하고 있는 것도 있다.
병렬화라는 개념은 대역을 최대로 사용한다는 관점에서 매우 유용한 접근법이다. 특히, CPU의 멀티 코어화가 진행되고 있어서 처리 병렬화의 유용성이 높아지고 있다.
또한, 압축을 이용해서 전송량을 줄이는 것도 한 가지 접근 방법이 될 수 있다. 단, 이 접근 법은 압축 및 해제 시 발생하는 CPU 오버헤드를 감안해야 한다.

네트워크 경로의 병목 현상

애플리케이션 서버에서 클라이언트 PC로 DB 서버에서 AP 서버로 가는 큰 트랜잭션들이 모두 게이트웨이인 특정 라우터를 경유하는 바람에 라우터가 처리 한계에 다다랐던 것이다. 애플리케이션 서버와 DB 서버용으로 전용 네트워크를 증설해서 트래픽을 분할했다. 그 결과, 애플리케이션 서버에서 클라이언트로 가는 통신 분량만큼 응답 문제가 개선됐다.
라우터 중에는 방화벽 기능을 갖추고 있는 것이나, 세션 감시를 해서 장시간 지연되고 있는 세션을 강제적으로 끊어버리는 기능 등 고기능을 갖춘 것도 있다. 시스템을 신규 구축할 때는 IP 주소 수가 부족하지만 확인하는 것이 아니라 경로와 트래픽 증감에 대해서도 검토한다.

애플리케이션 병목 현상 예

데이터 갱신의 병목 현상

데이터베이스를 이용한 시스템에서 자주 발생하는 것이 특정 데이터에 의존하는 처리가 병목 지점이 되는 것이다. 두 가지 개선안이 있다.

• 값의 캐시화
  별도 서버에 질의를 던지는 것이 병목 지점이 된다면, 더 가까운 장소에 캐시화하는 것이 일반적인 방법이다. 단, 네트워크를 경유하는 질의가 없어지므로 처리 효율이 개선될 수 있지만, 병목 지점이라는 것에는 변함이 없어서 근본적인 해결책은 되지 못한다.
• 병목 지점 분할
  레코드를 두 개로 나누는 형태다. 이 경우 한번에 두개의 처리를 진행할 수 있어서 처리 다중화가 가능하다. 결과적으로는 데이터 일관성 문제와 한쪽이 먼저 고갈된 경우 데이터 최신성 문제가 새롭게 발생한다. 최신성에 대해서는 복제 등도 고려해야 한다.
  참고로, 오라클 DB에서는 레코드를 분할해도 같은 데이터베이스 블록 내부에 저장될 가능성이 있으므로 병목 현상이 해결되지 않을 수도 있다. 이런 경우에는 테이블 자체를 나누든가, 파티션 기능을 이용해서 각각의 레코드를 다른 파티션에 저장하는 접근법이 유용하다.

외부 질의의 병목 현상

대부분 시스템은 다른 시스템과 데이터 연계 등을 통해 협력할 필요가 있다. 이 부분이 병목 지점이 되는 경우도 많다.