[Server] Nginx vs Apache

 

Web Server

Web Server란 HTTP 프로토콜을 기반으로 클라이언트가 웹 브라우저에서

어떠한 요청을 하면 그 요청을 받아 정적 컨텐츠를 제공하는 서버이다.

정적 컨텐츠란 단순 HTML 문서, CSS, 이미지, 파일 등 즉시 응답 가능한 컨텐츠이다.

 

이때 웹 서버가 정적 컨텐츠가 아닌 동적 컨텐츠를 요청받으면

WAS에게 해당 요청을 넘겨주고, WAS에서 처리한 결과를 클라이언트에게 전달하는 역할도 해준다. 

대표적으로 Apache, Nginx 가 있다.

웹 서버와 WAS 서버에 대한 개념과 자세한 차이점은 아래 포스팅을 참고하면 된다.

[Server] Web Server / WAS 개념 및 차이점

 

Apache

Apache Server는 MPM(멀티 프로세스 모듈) 방식을 사용하는 웹 서버이다. 

아파치 서버는 요청이 들어오면 커넥션을 형성하기 위해 프로세스를 생성한다.
따라서 새로운 클라이언트의 요청 들어올 때마다 새로운 프로세스를 만들게 된다.

그런데 프로세스를 만드는 것이 시간이 걸리는 작업이므로,

요청이 들어오기 전에 프로세스를 미리 만들어 놓는 prefork 방식을 사용한다.

Apache prefork 방식

 

그래서 새로운 클라이언트로부터 요청이 들어오면 미리 만들어 놓은 프로세스를 가져다 사용한다.
만약 만들어 놓은 프로세스가 모두 할당되었다면 추가로 프로세스를 만드는 과정을 거치게 된다.

현재는 Worker, Event 방식도 존재한다. 이에 대해 살펴보면 다음과 같다.

Apache Worker 방식

 

Worker MPM 방식은 프로세스의 관리 작업이 무겁기 때문에,

각 요청마다 스레드를 할당하여 작업을 진행한다.

프로세스와 달리, 하나의 프로세스가 cpu에 들어가도, 다양한 작업을 병렬적으로 수행할 수 있다.

또한 prefork에 비해 메모리 등 리소스 사용량이 비교적 적다는 장점이 존재한다.

하지만 프로세스 오류가 발생할 때 프로세스 내 스레드까지 죽어버리므로,

여러 연결이 동시에 끊어질 수 있다. 이러한 Woker 방식은 통신량이 많은 대규모 환경에 적합하다.

 

Event MPM 방식은 Worker 방식을 기반으로 멀티스레드와 멀티프로세스로 동작한다.

클라이언트로부터 데이터를 기다리도록 유지되는 단점을 보완하기 위해

각 프로세스에 대한 전용 리스너 스레드를 사용하여 Listening 소켓,

Keep Alive 상태에 있는 모든 소켓, 처리기 및 프로토콜 필터가

작업을 수행한 소켓 및 나머지 유일한 소켓을 처리한다.

기존에는 클라이언트의 연결이 완전히 끝나지 않는 한

하나의 프로세스(또는 스레드)를 계속 연결하고 있다는 단점이 존재하고

이는 리소스 부하 및  대량 접속이 발생하는 경우 효율이 굉장히 떨어지게 된다.

하지만 Event 방식은 한 개 또는 고정된 프로세스만 생성하고

그 프로세스의 내부에서 비동기 방식으로 효율적으로 작업을 처리하는 방식으로, 

속도가 가장 빠르다는 장점이 존재한다.

 

이러한 아파치 서버의 장점은 개발자가 개발하기 쉬운 환경이라는 것이다.

개발자는 다양한 모듈을 만들어서 서버에 빠르게 기능을 추가할 수 있고,
PHP 애플리케이션과 같은 동적 콘텐츠를 처리하는 서버에 적합한 구조를 가지고 있다.

또한 다양한 모듈 자체를 제공하고, 다양한 환경에서 유연하게 사용할 수 있다. 
그리고 확장성이 좋다는 그 장점 덕분에 요청을 받고 응답을 처리하는 과정을 

하나의 서버에서 해결하기 좋고 다양한 인증과 보안 기능을 제공하기 때문에, 

보안에 민감한 서버에서 사용하기 좋다.

하지만 아파치 서버는 구조적 한계가 존재한다.

 

Apache Server의 구조적 한계

Worker MPM(멀티 스레드) 방식이 Prefork에 비해 대량의 클라이언트를 잘 다루는 것은 맞지만, 

클라이언트 접속 시마다 프로세스 또는 스레드를 생성하는 구조적인 특성을 가지고 있다.

아파치 서버는 구조상 커넥션이 형성될 때마다 프로세스를 할당한다.
그렇기 때문에 동시에 처리하고 있는 커넥션이 많아지면

그만큼 형성된 프로세스가 많다는 거고 이는 곧 메모리 부족 현상으로 이어진다.

아파치 서버의 '여러 가지 기능을 쉽게 추가할 수 있는' 특징은

프로세스가 차지하는 리소스의 양을 늘린다. 커넥션에서 요청이 들어오기 시작하면

CPU 코어는 계속해서 프로세스를 바꿔가며 해당 임무를 수행하게 된다.

즉 컨텍스트 스위칭을 굉장히 많이 한다는 건데,

그만큼 CPU가 감당해야 할 일이 지나치게 많게 되는 것이다.

수많은 동시 커넥션을 감당하기엔 아파치 서버의 구조가 적합하지 않다.

물론 apache 진영과 서버 개발자들은 이런 구조적인 한계를 극복하기 위해 다양한 시도를 하게 된다.
아파치 서버의 구조를 완벽히 바꾸지는 못하지만, 성능 개선이 지금까지도 이루어지고 있다.

아파치 서버를 보완하기 위한 소프트웨어가 나오는데 그것이 바로 Nginx이다.

 

Nginx

초창기 Nginx는 Apache와 함께 사용하기 위해 만들어졌다.
웹 서버이긴 하지만, 아파치 서버를 완전히 대체할 목적은 아니었다.
아파치 서버가 지닌 구조적 한계를 Nginx를 사용함으로써 극복하려고 한 것이다.

Nginx Reverse Proxy

 

다음과 같이 아파치 서버 앞단에 Nginx를 두고 리버스 프록시 서버의 역할을 진행한다.
이렇게 하면 기존에 아파치 서버가 감당해야 했던

수많은 동시 커넥션을 Nginx가 대신해서 유지할 수 있게 된 것이다.
구조적으로 동시 커넥션을 많이 유지 못 하는 아파치 서버의 부하를 Nginx를 이용해

크게 줄일 수가 있게 되었다. 이제 Nginx에 대해 자세히 살펴보면 다음과 같다.

 

Event Driven Programming

Nginx 한 개 또는 고정된 프로세스만 생성하고,

모든 http요청들을 Event-Handler를 통해 비동기 방식으로 처리한다.

Apache와 같이 요청을 들어올 때마다 프로세스 & 스레드를 생성하지 않고,

N개의 고정된 프로세스로 처리하기 때문에 Context Swiching 비용이 매우 적고, CPU 소모가 적다.

http 요청마다  프로세스, 혹은 스레드 생성 작업이 거의 필요 없기에,

시스템 자원 관리에 이점이 있는 것이다.

따라서 Apache와 달리 동시 접속자 수가 많아져도 추가적인 생성 비용이 들지 않는다. 

Master / Worker Process

 

위의 그림처럼 Nginx는 하나의 Master Process와 N개의 고정된 Worker Process로 구성된다.

Master Process는 설정 파일을 읽고 검증하며 Worker Process를 관리하는 역할을 한다.

Worker Process에서 요청에 대한 실질적인 처리를 수행하며,

비동기 이벤트 기반 모델을 통해서 Worker Process 간의 요청을 효율적으로 분산한다.

 

Nginx의 처리 과정을 좀 더 자세히 살펴보면 다음과 같다.

Nginx가 실행되면 마스터 프로세스가 생성되고, 설정 파일을 읽어 워커 프로세스를 생성한다.
워커프로세스가 생성될 때 내부에 listen 소켓을 배정받게 된다.
클라이언트로 요청이 들어오면 소켓에 커넥션을 형성하고 처리하게 된다.

커넥션은 여러 개가 구성될 수 있으며, 정해진 keep alive time만큼 유지된다.
그리고 서버에서 처리해야 할 작업 또는 상황을 event라고 한다.
이벤트는 큐에 담긴 상태에서 워커 프로세스가 처리할 때까지 비동기 방식으로 대기하게 된다.
그리고 워커 프로세스는 하나의 스레드로 이벤트를 꺼내서 처리해 나간다.
만약 큐에 담긴 요청 중 하나가 시간이 오래 걸리면 

스레드 풀(Thread Pool)을 만들어 그 요청은 따로 수행하게 된다.
워커 프로세스는 처리할 요청이 시간이 오래 걸릴 것 같으면

스레드 풀에 이벤트를 위임하고 다른 이벤트를 처리한다.
그래서 코어가 담당하는 프로세스를 바꾸는 횟수를 줄이기에 CPU의 컨텍스트 스위칭이 줄어든다.
이게 바로 Nginx가 사용하는 Event-Driven Model(이벤트 기반 구조)이다.

 

즉 Apache의 단점이었던 CPU 컨텍스트 스위칭이 많다는 점을

Nginx가 비동기 이벤트 방식을 통해 보완한 것이다.

 

Nginx의 선호 이유

최근에는 Apache보다 Nginx를 더 사용하는 경향이 있다.

그 이유는 바로 Nginx가 트래픽이 많은 웹 사이트에 더 적합하기 때문이다.

Nginx는 대용량 트래픽을 처리하기 위해 가벼움과 높은 성능을 목표로 하는 경량 서버이다.

그런데 정적 파일을 제공하는 목적으로 Apache Server를 사용하던 시기와 달리

최근에는 리버스 프록시, 로드 밸랜서, 메일 프록시 및 HTTP 캐싱 등

전체 범위에서 서버 작업을 처리하는 웹 서버로 발전하였다.

다양한 기능과 클라이언트의 확장으로 대용량 트래픽을 처리해야 하는

요즘 서비스는 무겁고 대용량 트래픽을 처리하기 어려운 Apache와는 맞지 않기 때문에

Nginx가 점점 더 많이 사용되고 있는 것이다.

 

Apache / Nginx의 차이점

이제 두 웹 서버의 차이점을 정리하면 다음과 같다.

설계 아키텍처

Nginx

• 이벤트 중심 접근 방식으로 하나의 스레드 내에서 여러 요청을 처리하는 구조
• Event Handler에서 비동기 방식으로 먼저 처리되는 요청을 진행
• 코어 모듈이 Apache보다 적은 리소스로도 많은 트래픽을 효율적으로 처리 가능

Apache

• 프로세스 기반 접근 방식으로 하나의 스레드가 하나의 요청을 처리하는 구조
• 매 요청마다 스레드를 생성 및 할당해야 하기 때문에 많은 리소스 사용

 

성능

정적 컨텐츠

• 서버 PC의 디스크에 저장하는 파일 기반 방법으로 정적 컨텐츠 제공
• 설계 아키텍처 구조상 Nginx가 적은 비용으로 효율적인 서비스 제공

동적 컨텐츠

• 두 웹 서버 모두 서버 자체에서 동적 컨텐츠 처리 가능
• Nginx는 SCGI 핸들러와 FastCGI 모듈을 사용해서 동적 컨텐츠 제공
• 동적 컨텐츠는 두 웹 서버 성능이 비슷함

 

OS 지원

Nginx

• 거의 모든 Unix 계열 OS 지원
• Windows는 부분적으로 지원

Apache

• Linux 및 BSD를 포함한 모든 Unix 계열 OS 지원
• Windows 모두 지원

 

분산 / 중앙 집중식 구성

Nginx

• 추가 구성을 허용하지 않음
• 권한이 없는 사용자가 웹 사이트의 특정 측면을 제어할 수 없지만
  추가 구성을 제공하지 않음으로 성능 향상
• 디렉터리 구성을 허용하지 않음으로 .htaccess 파일을 검색하고
  사용자가 만든 요구 사항을 해석할 필요 없기 때문에 Apache보다 빠르게 요청을 처리 가능

Apache

• .htaccess 파일을 통해 디렉터리 별로 추가 구성을 허용
• 이로 인해 권한이 없는 사용자가 웹 사이트의 특정 측면을 제어 가능

 

요청을 처리 및 해석하는 방법의 차이

Nginx

• 요청을 해석하기 위해 URI를 전달
• URI로 전달함으로써 웹 서버뿐만 아니라
  프록시, 서버, 로드 밸런서 및 HTTP 캐시로 쉽게 동작
• 서버에서 클라이언트로 데이터가 전송되는 속도가 Apache보다 더 빠름

Apache

• 요청을 해석하기 위해 파일 시스템 위치 전달
• URI 위치를 사용하지만 일반적으로 더 추상적인 디렉터리 구조를 사용

 

따라서, 보통은 정적 콘텐츠가 많은 웹 사이트에서는 Nginx가 효율적이고, 

동적 콘텐츠가 많은 웹 사이트에서는 Apache가 효율적일 수 있다.

하지만 요새는 정적 파일을 비동기 방식을 매우 빠른 속도로 처리하여 

동적 파일을 대체하는 등의 방안들도 사용되고 있기에,

성능 측면이 중요한 서비스에서는 Nginx를, 보안이 중요한 서비스에서는 Apache를 사용하는 것이 좋다.

 

참고자료

https://velog.io/@cjyooong/apache-nginx

https://codenme.tistory.com/82

https://daram.tistory.com/532

https://nginxstore.com/blog/nginx/apache-vs-nginx-%EC%99%84%EB%B2%BD-%EB%B9%84%EA%B5%90/

https://rootkey.tistory.com/143

https://willseungh0.tistory.com/137?pidx=2