아파치는 NGIINX와 마찬가지로 가장 성공적인 오픈소스 웹 서버 중 하나다.
아파치가 성공할 수 있는 핵심 요인은 아키텍처 모델의 간결함이었다고 한다. 당시에는 많은 네트워크 서비스가 inetd라는 마스터 서비스에서 트리거 됐는데, 새로운 네트워크 연결(TCP)가 수신되면 inetd는 fork()와 exec()를 사용해서 해당 연결을 처리할 프로세스를 만들었다.
프로세스는 연결에서 요청을 읽고, 응답을 처리해서 전송하고 종료된다. 아파치는 이 모델을 사용했는데, 단점은 모든 연결마다 httpd worker 프로세스를 만드는 비용이 든다는 것이다. 그래서, worker 프로세스 풀을 만들어서 활용했다고 한다.
각 프로세스는 한 번에 하나의 연결을 처리하며, 모든 프로세스가 사용 중인 경우, Apache 는 트래픽 급증에 대비하여 더 많은 worker 프로세스를 생성했다.
인터넷이 급격하게 성장하면서, 웹페이지 부하가 꾸준하게 증가했다. 이러한 변화가 아파치에서 연결당 프로세스 모델을 만드는 모델에 문제를 제시했다. 높은 트래픽양과 무거운 페이지에 직면해서 잘 확장이 되지 않았다고 한다.
웹 클라이언트는 리소스를 욕심내서 사용한다.
페이지 렌더링 시간을 줄이기 위해서 브라우저는 일반적으로 사용자 세션마다 웹 서버에 대해 6개 이상의 TCP를 연다. 이렇게 함으로써 자원을 병렬로 다운하고, 브라우저는 사용자가 세션중에 만들 수 있는 향후 요청에 대해서 지연을 줄이고자 Keep alive를 활용해 연결을 유지시킨다.
열려있는 각 연결을 httpd 프로세스를 독점적으로 사용하므로, 사용량이 많은 시간에 Apache 는 많은 수의 프로세스를 생성해야 한다.
아파치는 두가지 방법을 사용했는데, 서버 자원을 고갈시키지 않기 위해 프로세스의 최대 수를 제한하는 것이었다. 하지만, 이 때문에 TCP 연결 수가 프로세스 수를 초과하면 새로운 연결은 무기한으로 대기 상태에 머무르게 됐다. 다른 방법은 keepalive 연결을 비활성화하거나 기간을 단축해서, 프로세스를 빠르게 해제하는 것이었다.
다만, 이 두가지 방식은 사용자 경험에 좋지 않을수밖에 없었다.
아차피 팀은 MPM을 만들었는데, 이는 프로세스를 적게 만들고 그 안에서 스레드로 작업을 처리하게 하는 방식이었다. 하지만, 리눅스에서는 스레드와 프로세스가 같은 운영체제의 다른 형태이기때문에(유사하기 때문에) 큰 효과가 없었다.
event MPM을 추가하기도 했는데, keepalvie을 별도로 관리하는 스레드를 추가한 것이다.
이러한 조치들은 어느정도도움이 됐지만, 트래픽 수가 증가하고 웹 사이트가 복잡해지면서 여전히 어려움을 겪게 된다.
엔진엑스의 등장
엔진엑스는 이러한 문제를 해결하기 위해서 개발됐다. 엔진엑스 성능과 확장성은 이벤트 기반 아키텍처에서 비롯한다. 엔진엑스에서는 각 worker 프로세스가 수천 개의 HTTP 연결을 동시에 처리할 수 있다.
아파치가 하나의 스레드가 하나의 요청을 처리한다면, 엔진엑스는 하나의 스레드가 여러개의 요청을 처리한다. 이벤트 방식의 비동기를 사용하기 때문으로 보인다. 엔진엑스에서는 워커 프로세스가 여러 요청을 처리할 때 다른 요청을 블록킹하지 않는다.
아파치는 동적 컨텐츠 처리가 강하지만, 엔진엑스는 정척 컨텐츠 처리에 강하다.(엔진엑스는 동적 컨텐츠를 처리할 때 외부 프로세스가 필요하다)
메모리 사용 측면에서는, 트래픽이 많아질 때 아파치는 cpu와 메모리를 많이 사용한다. 요청마다 스레드와 프로세스를 만들어야 하기 때문이다. 엔진엑스는 이 부분에서 굉장히 효율적이다. 이벤트 드리븐/논블록킹 아키텍처 덕분에 엔진엑스는 적은 메모리와 cpu를 활용해서 수천만개의 동시 연결을 처리한다.
아차피는 작은 사이즈, 개인화가 많이 필요한 경우 활용하기 좋다. 엔진엑스는 트래픽이 많고, 리버스 프록시나 로드 밸런싱을 수행해야 할 때 활용하기 좋다. (+정적 컨텐츠를 많이 사용할 떄)
이렇게 정리를 하고서 레딧 내용들을 좀더 보니
두개를 같이 사용하는 경우도 왕왕 있다고 한다.
참고자료
