웹 서버의 세계: Apache vs. Nginx

Apache 및 Nginx 소개

웹 서버와 프로토콜은 사용자가 웹 페이지를 볼 수 있도록 설계되었습니다. 이들은 서버가 수락하는 문서 보기 요청을 보냅니다. 그러면 호스트는 기본적으로 뷰어에게 문서나 정보를 제공합니다. 웹 서버는 브라우저에서 웹 페이지를 보고 액세스할 수 있도록 하는 데 중심적인 역할을 합니다.

이 목적으로 사용할 수 있는 웹 서버는 많습니다. 가장 인기 있는 웹 서버로는 Nginx 및 Apache가 있습니다. 실제로 이 서버들은 현재 인터넷에서 이용 가능한 대부분의 웹사이트를 호스팅하고 있습니다.

Apache와 Nginx는 여러 면에서 매우 유사합니다. 우선, 두 웹 서버 모두 오픈 소스입니다. 이는 전 세계 누구나 비용을 전혀 들이지 않고 사용할 수 있음을 의미합니다. 하지만 각 서버마다 고유한 기능이 많이 있습니다. 이러한 특별한 특성 덕분에 다양한 애플리케이션과 목적에 가장 적합합니다.

귀하가 어떤 웹 서버가 더 우수하거나 자신에게 이상적인지 결정하는 데 도움이 되도록, Nginx와 Apache를 비교해 보겠습니다. 이 비교는 웹 서버 사용자에게 중요한 여러 필수 매개변수를 대상으로 진행됩니다. 시작해 볼까요!

기본 개요

두 웹 서버에 대한 일반적인 개요부터 시작하겠습니다. Apache와 Nginx 모두 커뮤니티에서 훌륭한 명성을 쌓아왔습니다. 이들은 뛰어난 성능으로 찬사를 받고 있으며, 전 세계의 여러 유명 기관에서 사용하고 있습니다.

Apache

Apache는 1995년에 출시되었습니다. Robert McCool은 이 HTTP 서버를 the Apache Software Foundation 산하에서 개발했으며, 이로 인해 이러한 이름이 붙여졌습니다. 출시 이후 전 세계 수십만 명의 사람들이 Apache를 사용해 왔습니다.

엄청난 인기 덕분에 많은 타사 소프트웨어 및 소스가 이와 빈번하게 협업합니다. 따라서 많은 통합 기능과 훌륭한 지원 네트워크를 찾고 있다면 Apache가 적합합니다. Apache는 또한 더 동적이고 유연하기 때문에 많은 사람들이 선호합니다. 또한 해석할 수 있는 언어의 범위도 더 넓습니다.

Nginx

Nginx은 2004년에 출시된 비교적 최신 웹 서버입니다. 이는 현재 C10K 문제로 알려진 문제를 해결하기 위한 Igor Syosev의 노력의 결과물입니다. 이 문제는 서버가 막대한 양의 트래픽을 처리하기 어려워지면서 발생했습니다. 점점 더 많은 사람들이 인터넷을 사용하기 시작하면서 웹사이트 서버가 과부하되기 시작했습니다. 이러한 서버가 동시에 수천 개의 연결을 처리하지 못해 사이트가 다운되고 장애가 발생했습니다.

Nginx는 이 문제를 해결하기 위해 출시되었습니다. 그렇기 때문에 Nginx의 아키텍처는 제한된 리소스와 하드웨어로도 작동할 수 있는 믿을 수 없을 정도로 가벼운 디자인을 가지고 있습니다. 정적 콘텐츠와 함께 작동하는 데 가장 적합하지만, 동적 콘텐츠를 적절하게 처리할 수 있는 소프트웨어와도 통합할 수 있습니다.

트래픽 처리 기능

이제 각 서버에 대한 기본적인 개념을 파악했으므로 더 자세히 알아보겠습니다. 먼저 살펴볼 첫 번째 기능은 개별 서버의 트래픽 및 처리 기능입니다. 이는 두 플랫폼을 구분하는 주요 차이점 중 하나입니다. 이들의 아키텍처는 여러 연결을 동시에 처리할 때 서로 다른 원칙에 따라 작동합니다.

Apache

Apache는 MPM- Multi-Processing Modules이라는 것을 사용합니다. 관리자는 다양한 MPM을 사용하여 연결 처리 아키텍처를 조작하고 수정합니다. Apache 웹 서버의 매력 중 하나는 아키텍처가 제공하는 유연성입니다. 처리를 개별 및 그룹 스레드로 나누는 이러한 모듈 기반 인프라 덕분에 다양한 유형의 연결에 맞게 확장하고 적응하기가 더 쉽습니다.

Apache에서 사용되는 몇 가지 개별 모듈을 살펴보겠습니다.

• mpm_prefork

첫 번째는 mpm_prefork입니다. 이는 방문자의 수신 요청을 처리하는 프로세싱 모듈입니다. 특정 시점에 하나의 연결을 처리하기 위해 하나의 스레드 또는 자식(child)을 생성합니다. 즉, 요청 수가 프로세스 수보다 적으면 mpm_prefork는 기능 면에서 매우 효율적입니다.

개별 자식이 각 요청을 따로 처리하므로 요청이 신속하게 처리됩니다. 하지만 이는 요청 수가 프로세스 수를 초과할 경우 속도가 상당히 느려질 수 있음을 의미하기도 합니다. 결과적으로 요청 처리 단계에서 많은 RAM을 소모하게 됩니다.

• mpm_worker

이미 알고 있듯이, 하나의 스레드는 하나의 연결을 담당합니다. 이 모듈은 한 단계 더 나아가 한 번에 여러 스레드를 관리할 수 있도록 합니다. 이는 특정 임계값을 넘어서면 어려움을 겪는 mpm_prefork에 비해 훨씬 더 확장성이 뛰어난 모듈입니다. 새로운 연결은 대기할 필요 없이 즉시 스레드에 연결될 수 있습니다.

• mpm_event

mpm_event는 keep-alive 연결을 유지하는 역할을 합니다. 이 모듈의 주된 목적은 keep-alive 요청으로 인해 시스템이 느려지는 것을 방지하는 것입니다. 활성 요청이 없는 경우에도 연결에 스레드를 할당함으로써 이를 수행합니다. 스레드는 연결이 유지되는 동안 전용으로 남아있게 됩니다. 들어오는 모든 요청은 비어 있는 스레드로 전달됩니다.

Nginx

Apache와 달리 Nginx는 매우 구체적인 목적을 염두에 두고 구축되었습니다. 우리는 이미 이 수준에서 연결 및 확장성과 관련하여 발생하는 문제들을 알고 있었습니다. 그렇기 때문에 비동기식 및 비차단형(non-blocking) 알고리즘을 사용합니다. 각 연결에 개별 스레드를 할당하지 않습니다. 대신 Nginx는 한 번에 수천 개의 연결을 처리할 수 있는 수많은 워커 프로세스(worker process)를 생성합니다.

Nginx 아키텍처의 작동 원리는 빠른 루핑 메커니즘입니다. 이 알고리즘은 지속적으로 이벤트를 처리하고 모니터링합니다. 즉, 프로세스는 이벤트 기반(event-driven)이며 각 워커 프로세스는 자체 연결에만 전념합니다. 워커 프로세스의 모든 연결은 이벤트 루프에 위치합니다. 여기서 연결들은 공존하며 해당 워커 아래의 다른 연결들과 비동기적으로 처리를 거치게 됩니다.

이러한 아키텍처의 주요 이점은 뛰어난 확장성을 제공한다는 것입니다. 이는 리소스가 제한되어 있거나 최소한의 하드웨어로 작업하려는 경우에 특히 유용합니다. 트래픽이 많이 발생하더라도 RAM 사용량에는 거의 영향을 미치지 않습니다. 각 연결에 대해 개별 스레드를 생성하지 않기 때문입니다.

정적 및 동적 콘텐츠 처리

두 웹 서버를 비교하는 데 사용할 수 있는 또 다른 기준은 이들이 정적 및 동적 콘텐츠를 처리하는 방식입니다..

Apache

Apache는 정적 콘텐츠를 처리하기 위해 파일 기반 방식을 사용합니다. MPM 처리 시스템을 통해 이 전통적인 방식으로 작동할 수 있습니다.

동적 콘텐츠 처리와 관련하여 Apache는 외부 구성 요소의 도움 없이도 이를 수행할 수 있습니다. 모듈을 로드하여 동적 프로세서를 활성화할 수 있습니다. 이 모듈은 언어를 분석한 다음 관련 프로세서를 워커에 내장하여 콘텐츠를 처리합니다.

동적 콘텐츠를 처리하기 위해 외부 구성 요소를 사용할 필요가 없다는 점의 주요 이점은 구성 및 조정 중에 분명하게 드러납니다. 내부 구성 요소들만 서로 조정하는 것이 훨씬 더 쉽습니다.

Nginx

Apache와 Nginx가 콘텐츠를 처리하는 방식의 가장 큰 차이점은 Nginx가 내부적으로 동적 콘텐츠를 처리할 수 없다는 것입니다. 동적 콘텐츠에 대한 요청을 처리하려면 외부 구성 요소와 결합해야 합니다. 즉, Nginx 서버를 외부 프로세서와 함께 사용해야 합니다. 해당 구성 요소는 PHP/동적 콘텐츠에 대한 요청을 수신하고, 이를 처리한 다음, 다시 서버로 전송합니다.

두 구성 요소 간에 정보를 전달해야 하므로, 이들 간의 통신을 조정해야 합니다. 허용할 연결 수와 프로토콜을 구성하는 방법을 결정해야 합니다. Nginx가 읽고 이해할 수 있는 프로토콜(예: HTTP, FastCGI, SCGI, uWSGI, memcache 등)을 사용해야 합니다.

반면에 Nginx는 정적 콘텐츠 처리를 매우 잘 수행합니다. 그렇게 하기 위해 외부 소스의 도움이 필요합니다. 또한 필요할 때만 인터프리터를 활성화합니다. 이것이 Nginx를 사용하는 이점 중 하나입니다. 인터프리터는 프로세스에 내장되어 있지 않습니다. 즉, 동적 콘텐츠를 처리할 때만 존재하게 됩니다.

콘텐츠 디렉터리: 분산형 vs 중앙 집중식 구성

모든 웹 서버에는 자체 콘텐츠 디렉터리가 있습니다. Apache와 Nginx를 평가하는 가장 중요한 매개변수 중 하나는 디렉터리 수준의 구성을 허용하는지 여부입니다.

Apache

콘텐츠 디렉터리에는 지시어를 포함하는 특정 숨김 파일이 있습니다. 바로 .htaccess 파일입니다. Apache를 사용하면 이러한 지시어를 디렉터리별로 해석할 수 있습니다. 따라서 요청을 보낼 때 Apache는 파일 경로를 검사하여 .htaccess 파일을 찾습니다. 파일을 찾으면 그 안의 지시어를 즉시 해석하고 적용합니다. Apache는 이러한 지시어를 구현하기 위해 서버를 재로드하지 않습니다.

위에서 정의한 프로세스를 통해 웹 서버 디렉터리의 분산형 구성이 가능해집니다. 분산형 구성은 URL 재작성(rewrite), 액세스 제한 구현, 권한 확인 및 캐싱 정책 설정에 유용합니다.

.htaccess 파일의 이점 중 하나는 인증 권한이 없는 사용자도 브라우저에서 보고 있는 콘텐츠의 일부 측면을 제어하고 수정할 수 있다는 점입니다. 이것이 공유 호스팅 제공업체에서 Apache를 자주 사용하는 이유입니다. 서비스 제공업체는 중앙 구성에 대한 인증된 액세스 권한을 가집니다. 클라이언트는 기본 구성에 액세스하지 않고도 특정 디렉터리를 제어할 수 있습니다.

원하는 경우 Apache에서 .htaccess 해석을 비활성화할 수 있습니다.

Nginx

Apache와 달리 Nginx는 .htaccess 파일과 함께 작동하지 않습니다. 이로 인해 상대적으로 유연성이 떨어집니다. 하지만 Nginx는 대신 구성 스타일에서 여러 가지 개선 사항을 제공합니다. 우선, Apache보다 훨씬 빠른 속도로 요청을 처리할 수 있습니다. 경로에서 발견되는 각 .htaccess 파일을 검색, 읽기, 해석 및 구현하지 않기 때문입니다. Nginx는 각 상위 디렉터리를 검색하는 대신 하나의 요청에 대해 단 한 번의 디렉터리 조회만 수행합니다.

또한 Nginx는 Apache에 비해 큰 보안상의 이점을 가지고 있습니다. Nginx는 Apache와 달리 콘텐츠 디렉터리 구성의 어떤 부분도 개별 사용자에게 넘겨주지 않습니다. 귀하가 엄격한 보안 조치를 유지하고 있더라도, 개별 사용자도 똑같이 할 수 있다고 누가 보장하겠습니까? Nginx를 사용하면 전체 디렉터리 네트워크의 보안 상태와 구성에 대한 제어권을 유지할 수 있습니다.

요청 해석

두 서버를 구분하는 또 다른 방법은 요청을 해석하는 방식입니다.

Apache

서버가 요청을 받으면 이를 해석한 다음 관련 시스템 리소스에 연결합니다. 요청을 파일 시스템의 물리적 리소스로 해석하거나 URI 위치로 해석합니다.

물리적 리소스로 해석할 때는 <Directory> 또는 <Files> 블록을 사용합니다. 이는 서버의 기본 해석 방법입니다. 문서의 루트를 가져옵니다. 그런 다음 요청의 호스트 및 포트 번호를 따라 문서 트리에서 관련 파일을 찾습니다.

반면에 URI 위치는 추상적인 평가가 필요합니다. 따라서 Apache는 파일 시스템을 사용하는 대신 추상 리소스에 대해 <Location> 블록을 사용합니다.

URI 외에도 기본 파일 기반 시스템을 사용하는 것에 대한 여러 다른 대안이 있습니다. 예를 들어, Alias 지시문을 사용하여 매핑할 대체 위치를 찾을 수 있습니다. 또한 표현식 변형을 사용하여 파일 시스템 구성을 더 유연하게 만들 수도 있습니다.

Nginx

Apache가 웹 서버로 태어난 반면, Nginx는 웹 서버뿐만 아니라 프록시 서버로서의 이중 역할을 수행합니다. 그렇기 때문에 Nginx는 파일 시스템을 지향하는 대신 URI로 작업하는 것을 선호합니다. Nginx에서는 파일 시스템 디렉토리에 대한 구성을 지정할 방법이 없다는 사실에서 이러한 선호도를 시각화할 수 있습니다. 하지만 필요한 경우 파일 시스템으로 변환할 수 있습니다.

Server와 location은 Nginx에서 주로 사용되는 구성 블록입니다. 전자는 요청되는 호스트를 해석합니다. 후자는 호스트와 포트 뒤의 URI 부분과 일치시킵니다. 결과적으로 서버는 요청을 시스템의 실제 파일 대신 URI 위치로 해석합니다.

URI 기반 해석 시스템 덕분에 Nginx는 웹 서버, 프록시 서버 및 메일 서버로서의 역할을 수행할 수 있습니다. 요청을 해석할 때 파일 시스템을 참조하지 않기 때문에 .htaccess 파일을 구현하지 않는 이유도 이해할 수 있습니다.

모듈 시스템

Apache와 Nginx 모두 확장을 위한 모듈 시스템 지원을 제공하지만, 내부 작동 방식에는 몇 가지 주요 차이점이 있습니다.

Apache

Apache를 사용하면 서버를 실행할 때 모듈을 동적으로 로드하고 언로드할 수 있습니다. 코어는 프로세스의 중심에 남아 있고 모듈은 기능을 확장하는 역할을 합니다. 이러한 탈부착 가능한 모듈을 사용하여 여러 작업을 수행할 수 있습니다. Apache의 방대한 라이브러리를 통해 옵션은 사실상 무한합니다.

실제로 mod_php와 같은 모듈을 사용하여 서버 코어의 기능을 수정할 수도 있습니다. 앞서 언급했듯이, 이 모듈을 사용하면 개별 워커 프로세스에 PHP 인터프리터를 내장할 수 있습니다. 이는 동적 콘텐츠를 처리해야 할 때 유용합니다.

하지만 이야기는 여기서 끝나지 않습니다. 모듈을 추가하여 클라이언트 인증, 서버 보안 강화, 캐싱, URL 재작성, 프록시, 속도 제한, 압축 및 암호화와 같은 기능을 활성화할 수도 있습니다.

Nginx

Nginx의 모듈 시스템은 메인 서버에 모듈을 동적으로 로드할 수 없다는 점에서 다릅니다. 대신 코어 소프트웨어에서 모듈을 수집하고 컴파일해야 합니다. 이는 유연성과 사용 편의성 측면에서 아쉬운 점이 많습니다. 배포 패키지에는 몇 가지 공통 모듈이 포함되어 있지만, 다른 모듈의 경우 서버를 직접 빌드해야 합니다. 따라서 기존 패키징 시스템 외부에서 컴파일된 소프트웨어를 유지 관리하는 방법을 알아야 합니다.

그럼에도 불구하고, 이 비표준 모듈 시스템의 장점은 높은 수준의 특이성을 제공한다는 것입니다. 필요한 기능만 통합하여 모듈을 맞춤 설정할 수 있습니다. 필요하지 않은 구성 요소를 배제하여 그 과정에서 보안 위험으로부터 스스로를 보호할 수 있습니다. 동시에 Nginx 모듈을 사용하면 Apache와 마찬가지로 동일한 작업을 수행할 수 있습니다. 여기에는 URL 재작성, 로깅, 인증 등이 포함됩니다.

생태계 및 지원

웹 서버에 있어서 통합 및 소프트웨어 지원은 매우 중요합니다. 다음으로 Apache와 Nginx에서 사용할 수 있는 호환성 및 지원에 대해 알아보겠습니다.

Apache

Apache는 더 오래되고 더 대중적인 플랫폼입니다. 따라서 Nginx에 비해 더 다양한 지원 도구와 소프트웨어를 보유하고 있는 것은 당연합니다. 코어 서버를 지원하기 위해 마음대로 사용할 수 있는 수많은 타사 문서가 있습니다. 그뿐만 아니라, 특정 작업을 수행하기 위해 다른 소프트웨어와 결합할 수도 있습니다. 이러한 도구를 프로젝트나 패키지에 추가할 수 있습니다. 이들은 Apache 생태계 내에서 쉽게 부트스트랩할 수 있습니다.

Nginx

이 점에서 Nginx가 Apache에 뒤처져 있는 것은 사실이지만, 따라잡기 위해 최선을 다하고 있는 것은 분명합니다. 점점 더 많은 사람들이 Nginx의 잠재력을 깨닫고 이를 채택하고 있습니다. 유용하고 빠른 처리 속도를 가진 웹 서버로서의 유기적인 성장과 함께 이 플랫폼에 대한 지원도 계속해서 증가하고 있습니다.

Nginx가 극복해야 했던 주요 지원 장벽 중 하나는 영어로 된 문서를 찾는 것이었습니다. 이는 대부분의 문서를 포함하여 Nginx의 상당 부분이 원래 러시아어로 작성되었기 때문입니다. 하지만 이 서버가 널리 보급되고 더 유명해짐에 따라, 이제는 세계 공용어로 된 수많은 서드파티 리소스를 이용할 수 있게 되었습니다.

협업 솔루션?

이제 Apache와 Nginx의 필수 구성 요소와 내부 작동 방식에 대해 훨씬 더 잘 이해하게 되셨을 것입니다. 두 서버는 서로 상당히 다르지만, 일부 사용자들은 이 점을 활용하여 두 세계의 장점을 모두 취합니다. 그것’은 맞습니다. Apache와 Nginx를 함께 사용하는 것이 가능합니다.

전통적으로 사용자들은 Nginx를 리버스 프록시로 사용하여 Apache 앞에 배치하는 경향이 있습니다. 이를 통해 Apache의 요청 처리 및 프로세싱 속도 부족을 보완할 수 있습니다. Nginx는 가장 빠른 속도로 모든 요청을 수신하고 처리합니다. 또한 많은 리소스를 투자하지 않고도 대량의 동시 요청을 신속하게 처리할 수 있습니다.

사용자들이 활용하는 또 다른 Nginx의 특징은 정적 콘텐츠를 효율적으로 처리하는 능력입니다. Nginx가 동적 콘텐츠를 처리하기 위해 외부 구성 요소가 필요하다는 점을 보완하기 위해, 프록시를 통해 PHP 및 기타 관련 요청을 Apache로 전달할 수 있습니다. Apache는 요청을 웹 페이지로 렌더링하여 Nginx로 다시 보내고, Nginx가 이를 클라이언트에 서비스할 수 있도록 합니다.

다음은 저희 블로그에서 찾을 수 있는 두 웹 서버를 시작하는 데 도움이 되는 몇 가지 리소스입니다:

Apache

• Ubuntu 18.04에 Apache 서버 설치하기: 가이드
• Ubuntu 20.04에서 Apache 가상 호스트 설정하기
• CentOS 7에 Linux, Apache, MySQL, PHP (LAMP) 스택을 설치하는 방법
• Ubuntu 18.04에서 Let’s Encrypt로 Apache 보안 강화하기

Nginx

• Ubuntu 18.04에 Nginx 설치하기
• Nginx를 위한 LetsEncrypt SSL 인증서 자동 갱신
• Ubuntu 20.04에서 Let’s Encrypt로 Nginx 보안 강화하기
• Ubuntu 20.04에 LEMP 스택(Linux, Nginx, MySQL PHP)을 설치하는 방법

결론

결국 Apache와 Nginx 모두 장단점이 있습니다. 프로젝트에 어떤 서버를 사용해야 하는지에 대한 절대적인 규칙이나 권장 사항은 없습니다. 귀하의 고유한 요구 사항을 바탕으로 귀하의 애플리케이션에 무엇이 가장 적합한지 가장 잘 판단할 수 있는 사람은 바로 귀하입니다.

타협할 수 없는 측면과 기능을 파악하고 그에 따라 선택해야 합니다. 결정을 내리기 어렵다면 언제든지 맞춤형 솔루션으로 두 서버를 함께 사용하는 방법을 선택할 수 있습니다.

즐거운 컴퓨팅 되세요!