Apache 대 Nginx: 실용적인 고려 사항
소개
Apache와 Nginx는 세계에서 가장 일반적인 오픈 소스 웹 서버입니다. 이들은 모두 인터넷 트래픽의 50% 이상을 담당하고 있습니다. 두 솔루션 모두 다양한 워크로드를 처리하고 다른 소프트웨어와 함께 작동하여 완전한 웹 스택을 제공할 수 있습니다.
Apache와 Nginx는 많은 특성을 공유하지만 완전히 상호 교환이 가능하다고 생각해서는 안 됩니다. 각각은 고유한 방식으로 탁월하며 이 기사에서는 각각의 강점과 약점을 다룰 것입니다.
일반 개요
Apache와 Nginx의 차이점에 대해 알아보기 전에 이 두 프로젝트의 배경과 일반적인 특징을 간단히 살펴보겠습니다.
아파치
Apache HTTP Server는 1995년 Robert McCool에 의해 만들어졌으며 1999년부터 Apache Software Foundation의 지시에 따라 개발되었습니다. HTTP 웹 서버는 재단의 원래 프로젝트이고 지금까지 가장 인기 있는 소프트웨어이기 때문에 종종 간단히 "아파치\라고 합니다.
Apache 웹 서버는 적어도 1996년부터 2016년까지 인터넷에서 가장 인기 있는 서버였습니다. 이러한 인기로 인해 Apache는 훌륭한 문서와 다른 소프트웨어 프로젝트의 통합 지원을 통해 이점을 얻습니다.
관리자는 유연성, 성능 및 거의 보편적인 지원 때문에 Apache를 선택하는 경우가 많습니다. 동적으로 로드 가능한 모듈 시스템을 통해 확장 가능하며 추가 소프트웨어 없이 PHP와 같은 많은 스크립팅 언어를 직접 제공할 수 있습니다.
엔진엑스
2002년에 Igor Sysoev는 C10K 문제에 대한 답으로 Nginx 작업을 시작했습니다. 이는 웹 서버가 10,000개의 동시 연결을 처리할 수 있어야 하는 뛰어난 과제였습니다. Nginx는 2004년에 공개적으로 출시되었으며 비동기식 이벤트 기반 아키텍처에 의존하여 이 목표를 달성했습니다.
Nginx는 가벼운 설치 공간과 최소한의 하드웨어에서 쉽게 확장할 수 있는 기능으로 인해 인기에서 Apache를 능가했습니다. Nginx는 정적 콘텐츠를 빠르게 제공하는 데 탁월하고 자체적인 강력한 모듈 시스템을 갖추고 있으며 필요에 따라 동적 요청을 다른 소프트웨어로 프록시할 수 있습니다.
Nginx는 부하 시 리소스 효율성과 응답성, 간단한 구성 구문 때문에 관리자가 선택하는 경우가 많습니다.
연결 처리 아키텍처
Apache와 Nginx의 한 가지 차이점은 연결 및 네트워크 트래픽을 처리하는 구체적인 방법입니다. 이것은 아마도 부하가 걸린 상태에서 반응하는 방식에서 가장 중요한 차이점일 것입니다.
아파치
Apache는 클라이언트 요청을 처리하는 방법을 지시하는 다양한 다중 처리 모듈(Apache는 이러한 MPM이라고 함)을 제공합니다. 이를 통해 관리자는 연결 처리 아키텍처를 구성할 수 있습니다. 이것들은:
- mpm_prefork: 이 처리 모듈은 요청을 처리하기 위해 각각 단일 스레드가 있는 프로세스를 생성합니다. 각 자식은 한 번에 하나의 연결을 처리할 수 있습니다. 요청 수가 프로세스 수보다 적은 한 이 MPM은 매우 빠릅니다. 그러나 요청이 프로세스 수를 초과하면 성능이 빠르게 저하되므로 많은 시나리오에서 좋은 선택이 아닙니다. 각 프로세스는 RAM 소비에 상당한 영향을 미치므로 이 MPM은 효과적으로 확장하기 어렵습니다. 스레드를 염두에 두고 구축되지 않은 다른 구성 요소와 함께 사용하는 경우에도 여전히 좋은 선택일 수 있습니다. 예를 들어 PHP는 항상 스레드로부터 안전한 것은 아니므로 이러한 파일을 처리하기 위한 Apache 모듈인
mod_php와 함께 작업하는 안전한 방법으로 이 MPM이 권장되었습니다.\n - mpm_worker: 이 모듈은 각각 여러 스레드를 관리할 수 있는 프로세스를 생성합니다. 이러한 각 스레드는 단일 연결을 처리할 수 있습니다. 스레드는 프로세스보다 훨씬 더 효율적입니다. 즉, 이 MPM이 프리포크 MPM보다 더 잘 확장됩니다. 프로세스보다 스레드가 더 많기 때문에 이는 새 연결이 사용 가능한 프로세스를 기다리지 않고 즉시 사용 가능한 스레드를 사용할 수 있음을 의미합니다.\n
- mpm_event: 이 모듈은 대부분의 상황에서 작업자 모듈과 유사하지만 연결 유지 연결을 처리하도록 최적화되어 있습니다. 작업자 MPM을 사용하는 경우 연결이 활성 상태로 유지되는 한 요청이 활발하게 이루어지고 있는지 여부에 관계없이 연결이 스레드를 유지합니다. 이벤트 MPM은 연결 유지를 처리하고 활성 요청을 다른 스레드로 전달하기 위한 전용 스레드를 별도로 설정하여 연결 유지를 처리합니다. 이렇게 하면 연결 유지 요청으로 인해 모듈이 정체되는 것을 방지하여 더 빠르게 실행할 수 있습니다.\n
Apache는 다양한 연결 및 요청 처리 알고리즘을 선택할 수 있는 유연한 아키텍처를 제공합니다. 제공되는 선택 사항은 주로 서버의 발전과 인터넷 환경이 변화함에 따라 증가하는 동시성에 대한 요구의 기능입니다.
엔진엑스
Nginx는 사이트가 대규모로 직면하는 동시성 문제에 대해 더 잘 인식하면서 Apache 이후에 등장했습니다. 결과적으로 Nginx는 처음부터 비동기, 비차단, 이벤트 기반 연결 처리 알고리즘을 사용하도록 설계되었습니다.
Nginx는 각각 수천 개의 연결을 처리할 수 있는 작업자 프로세스를 생성합니다. 작업자 프로세스는 이벤트를 지속적으로 확인하고 처리하는 빠른 루프 메커니즘을 구현하여 이를 수행합니다. 연결에서 실제 작업을 분리하면 각 작업자는 새 이벤트가 트리거된 경우에만 연결에 관심을 가질 수 있습니다.
작업자가 처리하는 각 연결은 이벤트 루프 내에 배치됩니다. 루프 내에서 이벤트는 비동기식으로 처리되므로 비차단 방식으로 작업을 처리할 수 있습니다. 연결이 닫히면 루프에서 제거됩니다.
이 스타일의 연결 처리를 통해 Nginx는 제한된 리소스로 확장할 수 있습니다. 서버가 단일 스레드이고 각각의 새 연결을 처리하기 위해 프로세스가 생성되지 않기 때문에 로드가 많은 경우에도 메모리 및 CPU 사용량이 비교적 일정하게 유지되는 경향이 있습니다.
정적 콘텐츠와 동적 콘텐츠
실제 사용 사례 측면에서 Apache와 Nginx 간의 가장 일반적인 비교 중 하나는 각 서버가 정적 및 동적 콘텐츠에 대한 요청을 처리하는 방식입니다.
아파치
Apache 서버는 기존의 파일 기반 방법을 사용하여 정적 콘텐츠를 처리할 수 있습니다. 이러한 작업의 성능은 주로 위에서 설명한 MPM 방법의 기능입니다.
Apache는 해당 언어의 프로세서를 각 작업자 인스턴스에 내장하여 동적 콘텐츠를 처리할 수도 있습니다. 이를 통해 외부 구성 요소에 의존하지 않고도 웹 서버 자체 내에서 동적 콘텐츠를 실행할 수 있습니다. 이러한 동적 프로세서는 동적으로 로드 가능한 모듈을 사용하여 활성화할 수 있습니다.
내부적으로 동적 콘텐츠를 처리하는 Apache의 기능은 PHP 코드가 웹 서버 자체에서 기본적으로 실행될 수 있기 때문에 LAMP(Linux-Apache-MySQL-PHP) 아키텍처의 인기에 직접적인 기여를 했습니다.
엔진엑스
Nginx는 기본적으로 동적 콘텐츠를 처리하는 기능이 없습니다. PHP 및 동적 콘텐츠에 대한 기타 요청을 처리하기 위해 Nginx는 실행을 위해 요청을 외부 라이브러리에 전달하고 출력이 반환될 때까지 기다려야 합니다. 그런 다음 결과를 클라이언트에 전달할 수 있습니다.
이러한 요청은 Nginx가 말하는 방법을 알고 있는 프로토콜(http, FastCGI, SCGI, uWSGI, memcache) 중 하나를 사용하여 Nginx와 외부 라이브러리에서 교환해야 합니다. 실제로 FastCGI 구현인 PHP-FPM은 일반적으로 드롭인 솔루션이지만 Nginx는 실제로 특정 언어와 밀접하게 결합되지 않습니다.
그러나 이 방법에는 몇 가지 장점도 있습니다. 동적 인터프리터는 작업자 프로세스에 내장되어 있지 않기 때문에 동적 콘텐츠에 대해서만 오버헤드가 발생합니다. 정적 콘텐츠는 간단한 방식으로 제공될 수 있으며 통역사는 필요할 때만 연락을 받습니다.
분산 및 중앙 집중식 구성
Apache와 Nginx는 디렉토리별로 재정의를 허용하는 접근 방식이 크게 다릅니다.
아파치
Apache에는 콘텐츠 디렉터리 자체 내 숨겨진 파일의 지시문을 검사하고 해석하여 디렉터리별로 추가 구성을 허용하는 옵션이 포함되어 있습니다. 이러한 파일을 .htaccess 파일이라고 합니다.
이러한 파일은 콘텐츠 디렉토리 자체에 상주하므로 요청을 처리할 때 Apache는 .htaccess 파일에 대한 요청된 파일 경로의 각 구성 요소를 확인하고 그 안에 있는 지시문을 적용합니다. 이는 URL 재작성, 액세스 제한, 권한 부여 및 인증, 심지어 캐싱 정책을 구현하는 데 자주 사용되는 웹 서버의 분산 구성을 효과적으로 허용합니다.
위의 예제는 기본 Apache 구성 파일에서 모두 구성할 수 있지만 .htaccess 파일에는 몇 가지 중요한 이점이 있습니다. 첫째, 이들은 요청 경로를 따라 발견될 때마다 해석되기 때문에 서버를 다시 로드하지 않고 즉시 구현됩니다. 둘째, 권한이 없는 사용자가 전체 구성 파일에 대한 제어 권한을 부여하지 않고도 자신의 웹 콘텐츠의 특정 측면을 제어할 수 있습니다.
이는 콘텐츠 관리 시스템과 같은 특정 웹 소프트웨어가 중앙 구성 파일에 대한 액세스를 제공하지 않고도 환경을 구성할 수 있는 쉬운 방법을 제공합니다. 이것은 또한 공유 호스팅 공급자가 기본 구성에 대한 제어를 유지하면서 클라이언트가 특정 디렉토리에 대한 제어를 제공하는 데 사용됩니다.
엔진엑스
Nginx는 .htaccess 파일을 해석하지 않으며 기본 구성 파일 외부의 디렉토리별 구성을 평가하기 위한 메커니즘도 제공하지 않습니다. Apache는 원래 단일 서버에서 여러 이기종 웹 배포를 나란히 실행하는 것이 유리하고 권한 위임이 합리적이던 시기에 개발되었습니다. Nginx는 개별 배포가 컨테이너화되고 자체 네트워크 구성과 함께 제공되어 이러한 필요성을 최소화할 가능성이 더 높은 시기에 개발되었습니다. 이는 일부 상황에서 Apache 모델보다 덜 유연할 수 있지만 고유한 장점이 있습니다.
디렉터리 수준 구성의 .htaccess 시스템에 비해 가장 눈에 띄는 개선 사항은 향상된 성능입니다. 모든 디렉토리에서 .htaccess를 허용할 수 있는 일반적인 Apache 설정의 경우 서버는 각 요청에 대해 요청된 파일에 이르는 각 상위 디렉토리에서 이러한 파일을 확인합니다. 이 검색 중에 하나 이상의 .htaccess 파일이 발견되면 읽고 해석해야 합니다. 디렉터리 재정의를 허용하지 않음으로써 Nginx는 다음을 통해 요청을 더 빠르게 처리할 수 있습니다.
또 다른 장점은 보안과 관련된 것입니다. 디렉터리 수준 구성 액세스를 배포하면 이 작업을 잘 처리하도록 신뢰할 수 없는 개별 사용자에게 보안 책임도 분산됩니다. 이러한 문제가 마음에 든다면 Apache에서 .htaccess 해석을 해제할 수 있음을 명심하십시오.
파일 대 URI 기반 해석
웹 서버가 요청을 해석하고 시스템의 실제 리소스에 매핑하는 방법은 이 두 서버가 다른 또 다른 영역입니다.
아파치
Apache는 요청을 파일 시스템의 물리적 리소스 또는 보다 추상적인 평가가 필요할 수 있는 URI 위치로 해석하는 기능을 제공합니다. 일반적으로 이전 Apache의 경우
Apache는 처음부터 웹 서버로 설계되었기 때문에 일반적으로 기본적으로 요청을 파일 시스템 리소스로 해석합니다. 문서 루트를 가져오고 실제 파일을 찾기 위해 호스트 및 포트 번호 뒤에 요청 부분을 추가하는 것으로 시작합니다. 기본적으로 파일 시스템 계층 구조는 웹에서 사용 가능한 문서 트리로 표시됩니다.
Apache는 요청이 기본 파일 시스템과 일치하지 않는 경우에 대한 여러 가지 대안을 제공합니다. 예를 들어 Alias 지시문을 사용하여 대체 위치에 매핑할 수 있습니다.
Apache는 기본 파일 시스템과 다른 웹 URI 모두에서 작동할 수 있는 기능이 있지만 파일 시스템 메서드에 크게 의존합니다. 이는 디렉토리별 구성을 위한 .htaccess 파일 사용을 포함하여 일부 설계 결정에서 볼 수 있습니다. Apache 문서 자체는 요청이 기본 파일 시스템을 미러링할 때 액세스를 제한하기 위해 URI 기반 블록을 사용하는 것에 대해 경고합니다.
엔진엑스
Nginx는 웹 서버와 프록시 서버로 만들어졌습니다. 이 두 역할에 필요한 아키텍처로 인해 주로 URI와 함께 작동하며 필요한 경우 파일 시스템으로 변환합니다.
이것은 Nginx 구성 파일이 구성되고 해석되는 방식에서 분명합니다. Nginx는 파일 시스템 디렉토리에 대한 구성을 지정하는 메커니즘을 제공하지 않고 대신 URI 자체를 구문 분석합니다.
예를 들어 Nginx의 기본 구성 블록은 server 및 location 블록입니다. server 블록은 요청된 호스트를 해석하는 반면 location 블록은 호스트와 포트 뒤에 오는 URI의 일치하는 부분을 담당합니다. 이 시점에서 요청은 파일 시스템의 위치가 아니라 URI로 해석됩니다.
정적 파일의 경우 모든 요청은 결국 파일 시스템의 위치에 매핑되어야 합니다. 먼저 Nginx는 요청을 처리할 서버 및 위치 블록을 선택한 다음 문서 루트를 URI와 결합하여 지정된 구성에 따라 필요한 모든 것을 조정합니다.
비슷해 보일 수 있지만 파일 시스템 위치 대신 주로 URI로 요청을 구문 분석하면 Nginx가 웹, 메일 및 프록시 서버 역할 모두에서 더 쉽게 작동할 수 있습니다. Nginx는 다양한 요청 패턴에 응답하는 방법을 배치하여 구성됩니다. Nginx는 요청을 처리할 준비가 될 때까지 파일 시스템을 확인하지 않습니다. 이는 .htaccess 파일 형식을 구현하지 않는 이유를 설명합니다.
Apache와 Nginx를 함께 사용
Apache와 Nginx 모두의 이점과 제한 사항을 검토한 후 어떤 서버가 요구 사항에 더 적합한지 더 잘 알 수 있습니다. 경우에 따라 각 서버를 함께 사용하여 각 서버의 장점을 활용할 수 있습니다.
이 파트너십의 기존 구성은 Nginx를 Apache 앞에 리버스 프록시로 배치하는 것입니다. 이렇게 하면 Nginx가 모든 클라이언트 요청을 처리할 수 있습니다. 이는 Nginx의 빠른 처리 속도와 많은 수의 연결을 동시에 처리하는 기능을 활용합니다.
Nginx가 뛰어난 정적 콘텐츠의 경우 파일 또는 기타 지시문이 클라이언트에 신속하고 직접 제공됩니다. 예를 들어 PHP 파일과 같은 동적 콘텐츠의 경우 Nginx는 요청을 Apache로 프록시하여 결과를 처리하고 렌더링된 페이지를 반환할 수 있습니다. 그런 다음 Nginx는 콘텐츠를 다시 클라이언트로 전달할 수 있습니다.
이 설정은 Nginx가 분류 기계로 기능할 수 있게 해주기 때문에 많은 사람들에게 잘 작동합니다. 처리할 수 있는 모든 요청을 처리하고 기본적으로 처리할 수 없는 요청은 전달합니다. Apache 서버가 처리해야 하는 요청을 줄임으로써 Apache 프로세스 또는 스레드가 점유될 때 발생하는 일부 차단을 완화할 수 있습니다.
또한 이 구성은 필요에 따라 추가 백엔드 서버를 추가하여 수평 확장을 용이하게 합니다. 요청을 여러 서버로 전달하도록 Nginx를 구성하여 이 구성의 성능을 높일 수 있습니다.
결론
Apache와 Nginx는 모두 강력하고 유연하며 기능이 있습니다. 자신에게 가장 적합한 서버를 결정하는 것은 주로 특정 요구 사항을 평가하고 예상되는 패턴으로 테스트하는 기능입니다.
프로덕션 환경에서 각 솔루션을 사용하는 데 필요한 원시 성능, 기능 및 구현 시간에 매우 실질적인 영향을 미치는 이러한 프로젝트 간에는 차이점이 있습니다. 목표에 가장 부합하는 솔루션을 사용하십시오.