성능 향상을 위한 인프라 구조 (3tier 시스템 병목현상, 응답과 처리량)

응답과 처리량

• 성능 문제의 두 가지 원인
• 응답 문제
• 처리량 문제

 

병목 현상이란?

• 처리 속도의 제한 요소가 되는 병목 현상
• 병목 현상은 어떻게 해결되는가?
• 병목 지점은 반드시 존재한다

 

3계층형을 통해 본 병목 현상

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

 

---

응답과 처리량

성능 문제의 두 가지 원인

시스템 성능을 가르킬 때 응답(Reponse)과 처리량(Throughput)이라는 지표가 자주 사용됩니다.

응답은 처리 하나당 소요 시간을 의미

처리량은 단위 시간당 처리하는 양을 의미

 

예를 들어, 검색 엔진에서 키워드를 입력해서 '검색' 버튼을 누른 후 검색 결과가 표시되기까지 걸리는 시간이 응답 시간(Reponse Time)

처리량은 이 검색 엔진이 초당 받아 들이는 사용자 수에 해당

 

3tier 시스템 관점에서 처리량과 응답 예

응답 시간: 웹 서버에 요청을 던져서 AP 서버나 DB 서버를 거쳐서 응답이 돌아오기까지의 시간

처리량: 1분당 최대 10,000HTTP 요청을 처리 가능

 

응답 문제

사용자 체감 시간에는 각 계층의 처리 시간이 포함되므로 응답 문제가 발생하는 위치는 로그나 실제 장비 시험 등을 통해서 구체적으로 어떤 계층에서 응답 지연이 발생하고 있는지 파악

 

각 서버 이상으로 인한 응답 시간 지연은 로그 등을 보면 어느 정도 문제 파악이 가능

 

하지만, 네트워크 문제는 물리적인 한계를 가지고 있음. ( cf. 시스템에 도달하기까지의 경로가 복잡한 경우)

따라서, 응답 시간 개선에 한계가 보일 때는 처리량 개선을 통해서 시스템 전체 사용률을 개선하는 것이 일반적

 

처리량 문제

대량의 데이터를 교환하고 싶은데 영역이 부족한 경우에 처리량 문제가 발생

즉, 물리적으로 데이터를 통과시킬 수 없을 때 처리량 관점의 병목 현상이 발생

 

응답과 처리량은 밀접한 관계

응답이 매우 느린 시스템에서는 다수의 사용자 요청이 시스템 내에 누적되므로 전체 처리량도 낮아짐

처리량이 포화 상태가 되면 리소스가 부족해져서 응답도 함께 악화

 

성능 병목 현상을 개선하려면 반드시 양쪽을 고려해서 진행

 

---

병목 현상(Bottleneck)이란?

병목 현상이란 '병(Bottle)' , '목(Neck)'

 

3tier 시스템에서 AP 서버의 CPU 사용률이 높아져 처리량이 한계에 다다른다면 AP서버에 대한 응답시간이 악화된다.

그렇다면 사용자 측면에서도 응답시간이 악화되는데, 이때 병목지점은 AP 서버가 된다고 할 수 있다.

 

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

각 서버의 처리량이나 응답 상황 로그를 취득해서 어느 서버가 병목 지점이 되고 있는 찾아내는 것부터 시작

 

병목 지점을 찾았다면 2가지 접근법이 있음.

1. 병목 위치를 파악해서 해결 (cf. Scale Out을 통해 서버 증설)

2. 시스템 이용자 수를 제한

 

 

병목 지점은 반드시 존재한다

모든 서버, 소프트웨어, 물리 장비가 균등하게 처리량을 분배하는 것은 이론상 불가능

조금이라도 특정 부분의 처리량이 낮다면 그곳이 병목 지점

 

따라서, 인프라를 구축할 때 "특정 응답은 몇 퍼센트 개선시킨다." , "100명이 접속해도 문제 없도록 처리량을 개선한다" 등 목표를 만드는 것이 매우 중요

 

---

3계층형을 통해 본 병목 현상

CPU 병목 현상 예

"CPU  사용률이 높다 = 나쁘다" 성립하지 않음

"CPU 사용률이 낮다 = 좋다" 성립하지 않음

실제로 "CPU 사용률은 처리 효율성"을 나타내는 것으로 병목 현상 유무와는 관계가 없음.

 

CPU 사용률이 100%가 될 수 있음. 이것은 시스템 관점에서는 효율적인 상태. (CPU 자원을 유용하게 쓰고 있기에 투자 효과가 높기 때문)

즉, 다른 계층의 처리량이 매우 좋아서 최종적으로 CPU 에서 병목 현상이 발생한다는 의미

만일, 사용자가 응답시간에 불만족 한다면 CPU 사용률이 높은 상태를 문제로 생각하지 말고 근본적인 원인을 조사해보는 것이 현명함

대부분 애플리케이션에서 CPU 사용률이 100%에 도달하는 경우는 거의 없음 (디스크 I/O 혹은 네트워크I/O에서 막히는 경우가 많기 때문)

 

 

CPU에 기인한 성능 문제는 주로 2가지 원인으로 분류

 

1. CPU를 이용하는 처리가 많아서 대기 큐가 발생 (대기 큐의 병목 현상)

• 순조롭게 처리된다면 언젠가는 해결
• 하지만, CPU 처리량보다 사용자 요청이 많다면, 대기큐는 점점 커지게 됌.

 

2. CPU 응답이 느림 (응답의 병목 현상)

• CPU 성능의 부족

 

두 가지 문제 모두 Scale Up, Out으로 해결 가능

 

대부분 애플리케이션에서 CPU 사용률이 100%에 도달하는 경우는 거의 없음 (디스크 I/O 혹은 네트워크I/O에서 막히는 경우가 많기 때문)

이런 경우 "병렬도 병목 현상" 이 그나마 나을 수 있음.

 

처리 다중화

예를 들어 CPU 자원을 적절하게 사용하기 위해 스레드를 여러 개 가동해서 동기 I/O 명령을 스레드 단위로 병행 실행하여 CPU 사용률과 I/O 부하 증가

 

I/O 비동기화

비동기 I/O를 이용하면 프로세스는 I/O 처리 완료를 기다리지 않고 다음으로 넘어가기에 CPU처리와 I/O 처리를 동시에 진행하여 CPU 사용률과 I/O 부하 증가

 

 

 

메모리 병목 현상 예

메모리 영역 병목 현상은 크게 영역 부족과 동일 영역의 경합으로 나눌 수 있음

1. 영역 부족

메모리 양이 모자라 가상 메모리를 사용으로 일어나는 병목 현상

 

2. 동일 영역의 경합

특정 영역을 복수의 프로세스가 공유하는 경우, 메모리 영역을 참조 또는 갱신할 때 관리가 필요.

1바이트 메모리 영역을 관리하기 위해 대기 행렬을 작성했다고 하면 1바이트 이상의 대기행렬 메모리 공간이 필요하기에 오버헤드 발생

해결 방법은 애초에 경합이 발생하지 않도록 복수의 프로세스나 스레드가 같은 메모리 영역을  참조하지 않도록 설계. 혹은 메모리 락(Lock) 관리를 통해 방지.

 

 

디스크 I/O 병목 현상 예

디스크 I/O 병목 지점이 될 때는 I/O 효율을 높이거나 I/O를 줄이는 방법을 고민해야 함.

 

1. 외부 저장소

로컬 디스크는 서너 대의 디스크로 RAID를 구성하고 캐시로는 서버의 OS 메모리를 이용하는 반면,

SAN 를 경유하는 SAN 저장소나 NAS 저장소 등의 외부 저장소는 수십 수백 대 단위의 디스크를 배치하고, 거기에 캐시 전용 메모리 영역까지 갖추고 있어 처리량 관점에서 외부 저장소가 압도적으로 유리.

응답 시간 관점에서는 로컬 디스크가 가장 빠르지만 이 차이를 따라잡기 위해 외부 저장소는 메모리 캐시를 효율적으로 작성하여 응답속도 개선 노력

하지만, 외부 저장소의 경우 동일 디스크 영역을 이용하는 사용자가 많을수록 처리량이 저하.

외부 저장소에서 하나의 RAID를 독점하면 좋겠지만 조정이 어렵고 주의가 필요

 

2. 순차 I/O 와 랜덤 I/O

 

3개에 디스크 파일에 접근할 때 순차 I/O 는 1번의 접근으로 조회가 가능하지만

랜덤 I/O 는 3번의 접근으로 조회가 가능.

 

일반적으로 순차 방식이 빠르고 랜덤이 느림.

 

순차 방식으로 접근하려면 데이터 항상 정렬이 되어야 함.

하지만, 오라클에서 기록을 처리하는 방식은 랜덤 특성을 가지기 때문에 비효율적.

따라서, DBWR 프로세스를 다중화해서 병렬 처리를 함으로 효율성을 증가시킴

 

 

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

네트워크를 경유한 I/O는 CPU 버스나 메모리 간 I/O보다도 응답 시간 오버헤드가 크다.

응답을 근본적으로 개선하는 것은 어려우며, 처리량을 개선하는 접근법이나 네트워크 I/O 자체를 발생하지 않도록 하는 방법이 효과가 있음

 

1. 통신 프로세스의 병목현상

통신에서 대역을 모두 사용하려면 처리를 다중화해서 병렬화할 필요가 있음. (CPU의 멀티 코어화가 진행되어 처리 병렬화 유용성 증가)

압축을 이용하는 방법도 전송량을 줄이는 접근 방법(하지만, 압축 해제 시 CPU 오버헤드 감안해야함)

 

2. 네트워크 경로의 병목 현상

큰 트랜잭션들이 모두 게이트웨이인 특정라우터를 경유하는 경우 라우터의 처리 한계로 병목 발생

시스템을 신규로 구축할 때는 IP 주소 수가 부족한 것만 확인하는 것이 아니라 경로와 트래픽 증감을 검토해 네트워크(라우터) 설계해야 함.

 

cf) 최근 라우터에는 세션을 감시해서 장시간 지연되고 있는 세션을 강제로 끊거나, 방화벽 기능을 갖춘 장비가 있음

 

 

애플리케이션 병목 현상 예

애플리케이션 병목 현상부분도 Scale Up, Out을 통해 해결이 가능함.

하지만, 알고리즘의 문제라면 인프라 측 리소스를 아무리 늘려도 응답 속도 개선 미미

 

1. 데이터 갱신의 병목 현상

특정 레코드에 여러 처리가 동시에 접근했을 때 발생.

대기 큐를 이용하거나 베타적 제어로 제어 가능. 외에도 2가지 개선안이 있음.

 

• 값의 캐시화
  • DB서버가 아닌 AP 서버에 값을 캐시.
  • 하지만, 병목 지점이라는 변함은 없어 근본적인 해결책이 아님

 

• 병목 지점의 분할
  • 재고 확인을 엄밀하게 처리하지 않고 레코드를 두 개로 나누는 형태
  • 예를 들어, 재고가 200개 있다고 하면 100개씩 레코드를 분할하여 각각  레코드에 접근하여 처리 다중화
  • 하지만, 데이터 일치성 문제와 한쪽이 먼저 고갈될 경우 데이터 최신성 문제가 새롭게 발생

 

2. 외부 질의의 병목 현상

시스템은 하나로 완성되는 경우는 없고 다른 시스템이나 데이터를 연계 협력하는 경우가 많음. 이때 외부 질의를 통해 병목이 발생할 수 있음.

예를 들어, 인증 서버에 질의를 할 때 1 트랜잭션마다 1 질의를 하면 병목이 발생.

1회 질의할 때 1회 인증을 하는 형식으로 변경 시 해결 가능