티스토리 뷰

Infra Structure/.system

Apache MPM 및 Nginx

가그린민트 2017. 9. 3. 23:30

Apache Web Server

  • (html, css, js, img 등) 정적인 부분은 웹 서버에서 처리
  • MPM (Multi-Processing Module) : 여러 개의 프로세싱 모듈 기반의 서비스를 제공

병렬처리를 수행하지 않는 서버는 특정 클라이언트가 접속하여 서버와 입출력을 하고 있는 동안 다른 클라이언트는 서버에 접속할 수가 없기 때문에, 병렬 처리의 구현이 서버의 성능에 미치는 영향이 크다

.


Process와 Thread 비교 포스팅 바로가기



방식처리주체장점단점대응 예
프로세스 기반 방식프로세스구조가 간단하고 구현이 쉬움대량의 메모리가 필요, 느림

아파치(prefork)

스레드 구동 방식프로세스와 스레드의 하이브리드메모리를 적게 사용, 설정에 따라 약간 빠름이벤트 구동 방식보다 성능 한계가 먼저 옴

아파치 (worker)

이벤트 구동방식
(마스터 프로세스가 클라이언트 대응)
마스터 프로세스가 클라이언트 요청 수신, 워커 프로세스가 응답마스터 프로세스 부분의 구현이 비교적 간단마스터 프로세스가 병목이 됨

lighttpd

이벤트 구동 방식
(워커 프로세스가 클라이언트 대응)
워커 프로세스가 클라이언트 요청 수신과 응답메모리를 가장 적게 사용, CPU 코어를 최대로 사용하면 상당히 빠름구현이 매우 어려움(버그가 섞이기 쉽고, 문제 발생시 원인 분석의 어려움)

nginx


프로세스를 여러 개 생성해서 병렬처리를 실현하는 멀티프로세스 모델



프로세스가 아니라 보다 경량의 실행단위인 쓰레드를 사용하는 멀티쓰레드 모델



(MPM으로 무엇을 이용할지는 아파치 설치할 때, 컴파일시에 결정되므로, 나중에 다른 MPM을 이용할 경우에는 기본적으로 아파치를 재컴파일해야 한다. 기본설치할 경우 prefork 방식이며, worker로 설치(./configure --with-mpm=worker)시엔 /etc/sysconfig/httpd 파일에서 “HTTPD=/usr/sbin/httpd.worker” 주석을 해제하면 된다.)


 prefork와 worker 방식의 차이가 성능에 미치는 영향을 확인해보면,

  • prefork를 worker로 변경하더라도 하나의 클라이언트에 대한 응답시간이 고속화되는 것은 아니다.
  • prefork를 worker로 변경하더라도 메모리가 충분하다면 동시에 처리할 수 있는 접속 수는 변하지 않는다.
  • prefork를 worker로 변경하더라도 대량의 컨텍스트 스위치가 없다면(동시에 병렬적으로 대량의 액세스가 없다면) 효과는 크지 않다.
  • prefork를 사용하더라도 카피온라이트로 인해 갱신되지 않은 메모리 공간은 공유되므로, 그렇게까지 현저한 차가 나는 것은 아니다.

worker로 변경해서 효과적인 부분은,

  • 이용할 수 있는 메모리 용량이 그다지 크지 않은 경우나, 메모리 소비량을 줄이고자 할 경우. 이런 경우, 프로세스보다 메모리 소비량이 적은 쓰레드의 이점이 살아난다
  • 컨텍스트 스위치 횟수가 많아서 그만큼의 CPU 리소스를 줄이고자 할 경우, 즉 대량의 액세스로 인한 CPU 사용률(컨텍스트 스위치 횟수는 sar -C로 확인 가능)을 줄이고자 할 경우에 프로세스 보다 쓰레드 쪽이 context switch overhead가 낮으므로 CPU 소비가 줄어든다.

다만, 멀티쓰레드에서는 메모리 공간 전체를 복수의 쓰레드가 공유하므로, 리소스 경합이 발생하지 않도록 주의할 필요가 있다. 이것이 멀티쓰레드 프로그래밍이 복잡하다고 하는 이유다.



입출력을 감시해서 이벤트가 발생하는 타이밍에 처리를 전환하는, 시그널 쓰레드로 병렬처리를 수행하는 이벤트 구동모델

    - 이벤트 구동방식 (마스터 프로세스가 클라이언트 대응)
마스터 프로세스라는 부모 프로세스가 하나의 클라이언트의 웹 액세스를 받아들이고,
 실제 이벤트처리는 워커 프로세스라는 여러 자식 프로세스에서 처리하는 방식
    

이벤트 구동방식 (워커 프로세스가 클라이언트 대응)
각 워커 프로세스에서 이벤트를 받아들이고 이벤트를 처리하는 방식



nginx 도입시 장점은,

  • worker 프로세스 / 싱글 스레드를 채택하여 Context Switch overhead가 발생하지 않는다.
  • 비동기 처리로 인해 적은 메모리사용량으로 동시성을 보장한다.
  • nginx는 웹서버 기능 이외에도 로드밸런스와 같은 캐시 기능도 있다.

즉, nginx는 싱글 프로세스 스레드로 이벤트 구동에 의한 넌블로킹(Non-Blocking) 처리를 하므로 처리속도가 매우 빠르다. 그러나 넌블로킹 처리에 따라 프로그램의 제어가 이벤트 핸들러(Event Handler)로 넘어왔다고는 해도 실제 데이터를 읽고 쓰는건 OS(커널) 내에 있는 시스템 호출 프로그램과 하드웨어 사이에서 실행되므로, 해당 처리가 너무 길어지면(I/O 시간이 길어지면) 결국 시스템 호출 큐에 요청이 많이 쌓여 성능이 저하될 수 있다.


따라서 nginx는 매우 작은 데이터를 대량으로 전송하는 서버나, 하드디스크 읽기와 쓰기가 발생하지 않는 In-memory Cache Server / Reverse Proxy Server / Front-end Load Balancer와 같은 역할에 적합하다.
반대로 매우 복잡한 CGI 처리, 동영상 데이터 전송, 데이터베이스 처리를 실행하는 데는 적합하지 않다.

(아파치는 과거 java servlet이 대중적이지 않던 시절 CGI를 통한 웹서비스를 위해 생겨났기 때문에 process-base 방식이고, nginx의 경우  Http Proxy의 목적으로 생겨났기 때문에 event-base 방식이다.)


blocking vs non-blocking / synchronous vs asynchronous 포스팅 바로가기




참조 : 인프라 엔지니어의 교과서, 서버 / 인프라를 지탱하는 기술



'Infra Structure > .system' 카테고리의 다른 글

윈도우 특정 프로세스 죽이기  (0) 2017.10.24
레드마인 설치  (0) 2017.10.23
Apache MPM 및 Nginx  (0) 2017.09.03
Process와 Thread  (0) 2017.09.03
[Linux]성능 이슈 간단히 확인하기  (0) 2017.08.24
[Linux][Command]vim 연습을 위한 툴 & vimcheatsheet  (0) 2017.08.07
댓글
댓글쓰기 폼
링크
«   2020/02   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
Total
86,950
Today
23
Yesterday
151