Apache2.0 Multi-Processing Modules(MPM)

[HTML]
출처: http://www.apache-kr.org



아파치 2.0 이 소개되면서 가장 큰 변화는 Multi-Processing Modules(MPM)의 소개며, 2.0 이 탄생하기까지의 가장 큰 원인을 제공하였다. 아파치 2.0 은 기존 1.3 버전이 안고 있는 한계인 확장성의 부분에 초점을 맞추었고, 이에 대한 솔루션으로 하이브리드(Hybrid) 웹 서버를 내세웠다. 1.3 버전에서 가지고 있었던 프로세스 방식과 스레드 방식을 혼용한 것으로, 하나의 프로세스가 제공해 주지 못하던 신뢰성을 스레드 개념을 도입하여 문제를 해결하고자 하였다. 2.0 의 새로운 각각의 프로세스 모델을 설명하기 전에, 여러분들은 아파치 1.3 의 프로세스 생성 방법에 대한 이해가 필요하다. 아파치 1.3 및 이전 버전에서도 마찬가지로 요청이 이루어지는 만큼 프로세스 자신을 계속 복사하는 방식을 취하였다. 클라이언트의 많은 요청이 들어오면 그 만큼 그에 해당되는 자식 프로세스를 생성하며, 원래의 부모 프로세스는 웹 서버의 설정과 요청되어지는 수에 따라 그것을 관리 감독하는 일을 수행하였다. 이러한 모델은 대부분의 유닉스에서 사용되어 졌으나, 윈도우 환경 하에서는 프로세스 관련부분을 다시 재작성 하여 기존 아파치 웹 서버가 수용하고 있던 뛰어난 성능 및 기능들을 윈도우 환경에서 이용할 수 있도록 하였다.





이제 유닉스환경의 플랫폼에서는 다음에서 소개할 프로세스 방법으로 여러 개의 프로세스 및 스레드로 일시적으로 늘어나는 요청 등을 유연하게 대처할 수 있는 방법을 사용하여 클라이언트에게는 좀더 신뢰성 있는 서비스 및 확장성을 제공하게 되는 것이다. 그러나, 일부 오래된 플랫폼 환경에서는 스레드를 지원하지 않기 때문에, 1.3 의 ‘pre-forking’ 프로세스 모델을 계속적으로 이용하여야만 한다. 이러한 맥락에서, 아파치 웹 서버에서는 다양한 프로세스 모델을 여러분들에게 제시할 것이며, 현재의 환경을 고려하여 적합한 프로세스 모듈을 선택해야 한다.





현재 MPM 에는 몇 가지의 옵션들이 가능하며, Apache 2.0 베타를 기준으로 각 옵션에 대한 설명을 하도록 하겠다. 정식버전에서는 이러한 이름이 바뀔 수도 있으므로, 프로세스 모듈에 대한 기본적인 개념을 이해하도록 하자. (참고로, 알파버전에서 사용하던 프로세스 모델이 베타에 들어서며 약간 바뀌었다.)







l PREFORK



이름에서 느껴지는 것과 같이, 1.3 의 프로세스 모듈과 같은 것으로 생각하면 된다. 각 요청에 프로세스가 매핑되어, 서비스 요청이 많은 경우 프로세스는 더욱 증가하게 될 것이다. 프로세스를 제어하는 부모 프로세스는 클라이언트의 요청이 들어올 경우 대기하고 있다가 자식 프로세스의 생성여부 등을 관리하게 된다. ‘MinSpareServers’, ‘MaxSpareServers’, ‘MaxServers’ 의 프로세스 관련 지시어를 바탕으로 프로세스의 상태를 관리하게 되며, 스레드를 지원하지 않는 오래된 플랫폼의 경우나 스레드 없이 작동하기를 바라는 경우에는 이 옵션을 선택한다.



l MPMT_PTHREAD (threaded)



’PREFORK MPM’ 에 기반을 두고 있는 모듈이다. 이 뜻은, 지정된 만큼의 스레드에 얼마나 많은 자식 프로세스를 생성할 것인지 지정하는 것이다. 페이지 요청이 들어오게 되면, 스레드는 요청을 받게 되고 그에 따라 자연히 응답을 한다. 그러나, 이미 충분히 요청을 처리하는데 있어서의 한계를 넘는 경우에는, 새로운 자식 프로세스를 생성하게 된다.



mpmt_pthread 는 ‘Prefork MPM’ 과 유사하며, 단 각 자식프로세스가 가지고 있는 스레드 개수를 제외하고는 같다. 만약 모듈에 예상치 않은 문제로 스레드가 죽게 된다면, 전체 프로세스 와 현재 자식 프로세스에 의해 제공되어지고 있는 것 또한 같이 잃게 될 것이다. 이 모듈은, 아파치 1.3 에서 보여주었던 MinSpareServers ,MaxSpareServers 지시어를 이용하여 풀 사이즈와 같은 기능을 제공하여 준다. 얼마나 많은 스레드가 생성되어야 할지를 추측하기 보다는, 지시어에 의해 지정된 범위 안에서 아파치 웹 서버가 동적으로 최소 유지하고 있어야 할 스레드 수보다 적으면 새로운 프로세스를 생성하게 되고 그렇지 않고 반대의 경우라면 최대 스레드 여유분에 도달한 프로세스를 죽이게 될 것이다.







l Perchild



서버는 시작시에 고정적인 프로세스 개수를 정의하며 각 프로세스는 특정 스레드 개수로 작동하게 된다. 이 프로세스가 증가하게 되면, 정의되어 있는 기능에 의해 자연히 스레드 개수는 증가된다. 프로세스는 요청이 많은지 그렇지 않은지를 판별하여 최소/최대 여유 분의 스레드 개수를 유지하게 된다. 또한, 각 자식 프로세스에 대하여 각기 다른 사용자와 그룹을 지정할 수가 있다. 이 기능은 mod_perl, PHP 등을 포함한 CGI 스크립트들이 자식프로세스의 소유주 아이디로 작동이 가능하기 때문에 웹 서버 입장에서는 보안적인 기능을 제공해 준다 할 수 있다. 이 프로세스 모듈이 요즘 스레드를 지원하는 대부분 플랫폼 환경에서 사용되어 질 수 있으며, 최대 가능한 많은 요청을 처리하기 위하여 CPU 사용량을 줄일 수 있는 방안을 제시할 것이다.





l Winnt



이 모델은 기존의 1.3 모델과 유사하다. 윈도우 환경에서는 프로세스를 ‘fork’ 하는 방법을 사용하는 것이 아니라 멀티스레드 방법을 이용한다. 두개의 프로세스로 구성되어 하나는 부모 프로세스로 자식프로세스들을 살펴보고 요청에 프로세스가 제대로 응답하고 있는지 부분 등을 관여한다.








위에선 알아본 각 MPM 에는 나름대로의 장점과 단점을 겸비하고 있으니 여러분들의 사이트에는 어떠한 것에 우선 순위를 두어야 할지를 생각해 보아야 한다. 예를 들어, 만약 자식 프로세스가 예상치 못한 상황으로 인하여 종료된다면 클라이언트와의 연결을 잃게 될 것이며, 어떤 MPM 을 사용하느냐에 따라 “얼마나 많은 접속을 잃을지는” 달라지게 되는 것이다. ‘Prefork MPM’ 을 이용한다면, 단순히 그 프로세스에 해당하는 연결만을 잃을 것이다. 하지만, ‘mpmt_pthread MPM’ 을 사용한다면 자식프로세스가 사용하고 있는 개수의 n 개만큼 접속을 잃을 것이다.







어떠한 방식의 MPM 을 사용할 것인지는 여러분들이 사이트의 특성 그리고 필요로 하는 것에 따라 달라지게 된다. ‘Prefork MPM’ 은 비용과 성능을 고려한 확장성 부분에서는 가장 떨어진다. 그리고 만약 여러분들이 운영하는 사이트가 아파치에서 배포하는 기본 모듈이외에 안정성이 입증되지 않은 외부의 모듈을 사용하거나, 특성상 접속이 끊어지는 부분을 최소화 하고자 한다면 ‘Prefork MPM’ 방식을 선택하는 것이 오히려 바람직 할 것이다. 왜냐하면, 모듈의 불안정으로 발생하여 사이트에 미치는 영향을 최소화하기 위함이다. 이와 반대로, 사이트가 일반적으로 동적인 페이지가 아닌 정적인 웹 페이지와 특별히 다른 모듈을 필요로 하지 않고 하루에 초당 많은 히트수를 기록한다면 스레드 방식을 선택하는 것이 아마도 올바른 방법일 것이다.
[/HTML]