Apache vs NGINX: 완벽 비교
Apache HTTP 서버와 NGINX는 오늘날 인터넷을 지배하는 가장 있는 오픈 소스 웹 서버입니다. 10년 전 Igor Sysoev가 NGINX에 대한 작업을 시작했을 때 아무도 그가 Apache 기반 서비스를 가속화하기 위해 시작된 이 프로젝트가 지금과 같은 영향력을 가질 것이라고는 아무도 예상하지 못했습니다.
Apache HTTP 서버는 지난 20년 동안 개발된 거의 모든 웹 기술에 대해 견고한 플랫폼입니다. 그러나 시간이 지남에 따라, 코드가 처음으로 작성될 때 만들어진 아키텍처적 결정들이 현대 웹 요구에 대한 적합성을 제한하는 요소로 나타나고 있습니다.
이 포스트에서는 이러한 변화와 제한 사항에 대한 저의 관점을 공유하고, 현대 웹 개발자가 어떻게 대응할 수 있는지 설명합니다. 저는 Apache 의 초기 사용자로서(그 이전의 NCSA의 httpd도 포함하여) 매우 초창기부터 사용했으며, PHP가 주류에 가까워지기 전에 bash와 Perl로 CGI 스크립트를 작성한 사람으로서, 그리고 Apache 방식에 도전하는 최초의 이벤트 기반 웹 서버 중 하나인 Zeus에서 일한 경험이 있는 소프트웨어 엔지니어가 이 글을 썼습니다. 이 글은 절대로 Apache 가 목적에 맞지 않다는 것이 아니라, 현대 웹 애플리케이션의 도전에 직면하여 지금은 시대에 뒤떨어졌으며 효과적으로 작동하기 위해 지원이 필요하다는 것입니다.
목차
1. Apache의 초기 성공의 열쇠
1-1. 아키텍처의 단순성
1-2. 쉬운 개발, 쉬운 혁신
2. World Wide Web의 성장에 따른 도전
2-1. 웹 클라이언트는 리소스를 욕심내어 사용합니다.
2-2. 관리자는 리소스를 복구하기 위해 고객과 싸웠습니다.
2-3. Apache팀은 대체 MPM을 구현했습니다.
2-4. Apache의 헤비급 모놀리식 모델은 한계가 있습니다.
3. NGINX 소개 – 높은 동시성을 위한 설계
3-1. 아키텍처의 비밀
4. NGINX와 Apache – 좋은 출발점
5. 최신 웹 애플리케이션은 과거의 LAMP 스택과 매우 다릅니다.
5-1. NGINX는 마이크로서비스 애플리케이션을 제공합니다.
5-2. NGINX를 사용하여 각 컨테이너화된 서비스 내에서 일관성 제공
6. NGINX vs Apache 결론
7. NGINX vs Apache 인터넷 통계 자료
8. NGINX vs Apache 추가 자료
1. Apache 의 초기 성공의 열쇠
Apache 는 1세대 World Wide Web의 기반을 이루었으며, 1995년에 데뷔하자마자 웹 서비스의 업계 표준이 되었습니다. 그 당시 World Wide Web이 아직 생소한 시기였고 새로운 것이었습니다. 트래픽 수준은 낮았고, 웹 페이지는 간단했으며, 대역폭은 제한되고 비용이 많이 들었으며, CPU는 비교적 저렴했습니다. 초기 커뮤니티에서는 새로운 기술로 혁신하려는 열망이 컸고, Apache 는 선택의 플랫폼이었습니다.
1-1. 아키텍처의 단순성
Apache 의 아키텍처 모델의 간결함은 초기 성공의 핵심 요인이었습니다. 그 당시에는 많은 네트워크 서비스가 inetd라는 마스터 서비스에서 트리거되었습니다. 새로운 네트워크(TCP) 연결이 수신되면 inetd는 fork()와 exec()를 사용하여 해당 연결을 처리할 올바른 유닉스 프로세스를 생성했습니다. 프로세스는 연결에서 요청을 읽고, 응답을 계산하여 다시 연결로 전송한 다음 종료되었습니다.
Apache는 이 모델을 채택하여 발전시켰습니다. 가장 큰 단점은 각각의 새로운 연결에 대해 새로운 httpd worker 프로세스를 fork하는 비용이었으며, Apache 개발자들은 사전에 준비된 worker 프로세스 풀을 빠르게 만들고, 각각의 프로세스가 새로운 HTTP 연결을 받을 수 있는 상태로 유지하는 프리포크(prefork) 모델을 채택했습니다.
prefork Apache 웹 서버는 HTTP 연결을 받으면 httpd worker 프로세스 중 하나가 해당 연결을 가져와 처리했습니다. 각 프로세스는 한 번에 하나의 연결을 처리하며, 모든 프로세스가 사용 중인 경우, Apache 는 트래픽 급증에 대비하여 더 많은 worker 프로세스를 생성했습니다.
1-2. 쉬운 개발, 쉬운 혁신
한 연결 당 하나의 프로세스 모델에 의해 제공되는 격리와 보호는 Apache 의 웹 서비스 로직 어디에서든 추가 코드(모듈 형태로)를 삽입하기 매우 쉽게 만들었습니다. 개발자들은 코드를 추가할 수 있고, 그 코드가 차단되거나 느리게 실행되거나 리소스가 누출되거나 심지어 충돌이 발생해도, 해당 코드를 실행하는 worker 프로세스만 영향을 받을 것을 알고 안전하게 코드를 추가할 수 있었습니다. 나머지 모든 연결의 처리는 문제없이 계속되었습니다.
Apache 는 초기 World Wide Web에서 가장 빠르게 지배적인 웹 서버가 되었습니다. 웹 사이트에서의 채택은 꾸준히 증가하여 2005년 말에 70% 이상의 시장 점유율을 기록했습니다.
출처: Netcraft 2005년 11월 웹 서버 조사
2. World Wide Web의 성장에 따른 도전
지난 20년 동안 World Wide Web의 트래픽 양과 사용자 수는 폭발적으로 증가했습니다.
동시에, 웹 페이지의 무게(웹 브라우저가 페이지를 렌더링하기 위해 가져와야 하는 구성 요소의 크기와 수)는 꾸준히 증가했으며, 사용자들은 웹 페이지가 로드될 때까지 기다리는 시간이 점점 줄어들었습니다.
(이러한 변경 사항에 대한 자세한 내용은 이 포스트 끝에 있는 인터넷 통계 리소스 목록을 확인하십시오.)
이러한 모든 변경 사항은 Apache 의 연결당 프로세스 모델에 실질적인 문제를 제시했습니다. 이 모델은 높은 트래픽 양과 무거운 페이지(더 많은 임베디드 리소스가 더 많은 HTTP 요청을 필요로 함)에 직면하여 잘 확장되지 않았습니다.
2-1. 웹 클라이언트는 리소스를 욕심내어 사용합니다.
페이지 렌더링 시간을 줄이기 위해 브라우저는 일반적으로 사용자 세션마다 웹 서버에 대해 6개 이상의 TCP를 여는데, 이렇게 함으로써 자원을 병렬로 다운로드합니다. 브라우저는 사용자가 세션 중에 만들 수 있는 향후 요청에 대한 지연을 줄이기 위해 일정 기간 이러한 연결을 열어 둡니다(HTTP keepalive). 열려있는 각 연결을 httpd 프로세스를 독점적으로 예약하므로 사용량이 많은 시간에 Apache 는 많은 수의 프로세스를 생성해야 합니다.
많은 프로세스를 실행하는 것은 많은 메모리를 소비합니다. 과도한 메모리 소비는 스래싱과 많은 컨텍스트 스위치를 유발하여 웹 서버의 성능을 크게 저하시킬 수 있습니다.
2-2. 관리자는 리소스를 복구하기 위해 고객과 싸웠습니다.
prefork Apache 서버의 성능 문제를 완화하기 위해 시스템 관리자들은 두 가지 조치를 취하도록 권장되었습니다. 첫째로, 서버 자원을 고갈하지 않기 위해 httpd 프로세스의 최대 수를 제한하는 것이었습니다(일반적으로 256으로 제한). 결과적으로, 동시 TCP 연결 수가 프로세스 수를 초과하면 새로운 연결은 무기한으로 대기 상태에 머무릅니다. 둘째로, keepalive 연결을 비활성화하거나 기간을 단축하여 httpd 프로세스를 빠르게 해제하는 것이었습니다.
이 두 가지 조치 모두 사용자 경험에 해로운 영향을 미쳐 웹 페이지가 더 느리고 덜 안정적으로 로드됩니다.
2-3. Apache팀은 대체 MPM을 구현했습니다.
Apache 의 핵심 개발자들은 일부 플랫폼에서의 이식성과 확장성을 향상시키기 위해 두 가지 처리 모델(다중 처리 모듈 또는 MPM이라고 함)을 만들었습니다.
Worker MPM은 별도의 httpd 프로세스를 여러 worker 스레드를 실행하는 소수의 자식 프로세스로 대체하고, 각 연결에 하나의 스레드를 할당하는 방식입니다. 이는 스레드가 프로세스보다 가볍기 때문에 IBM의 AIX와 같은 상업용 Unix 버전에서 유용합니다. 그러나 Linux에서는 스레드와 프로세스가 같은 운영체제 객체의 다른 형태이기 때문에 효과가 덜합니다.
나중에 Apache 는 event MPM을 추가했습니다(NGINX의 이벤트 기반 아키텍처와 혼동해서는 안 됩니다). event MPM은 worker MPM을 확장하여 HTTP 요청이 완료된 후 유휴 keepalive 연결을 관리하는 별도의 리스닝 스레드를 추가합니다.
2-4. Apache 의 헤비급 모놀리식 모델은 한계가 있습니다.
이러한 조치들은 성능을 향상시키는데 일부 도움이 되지만, Apache 의 초기 성공의 핵심이었던 단일 서버 모델은 트래픽 수가 증가하고 웹 사이트가 점점 더 복잡해지면서 여전히 어려움을 겪고 있습니다. 실험실에서의 성능 평가 결과가 바쁜 웹 사이트의 실제 운영 환경에서 재현되지 않는 경우가 많으며, Apache 를 실제 트래픽에 대응할 수 있도록 조정하는 것은 복잡한 기술입니다. 불공정하게도, Apache 는 비대하고 지나치게 복잡하며 성능이 제한된 웹 서버로 인식되고 있으며, 느린 서비스 거부(DoS) 공격에 취약할 수 있다는 평가를 받고 있습니다.
3. NGINX 소개 – 높은 동시성을 위한 설계
NGINX는 Apache 웹 서버의 성능 제한을 해결하기 위해 특별히 개발되었습니다. 이는 2002년에 인기 있는 러시아 포털 사이트(Rambler.ru)의 시스템 관리자인 Igor Sysoev가 사이트에서 점차 증가하는 트래픽을 관리하기 위한 확장 솔루션으로 개발되었습니다. NGINX는 2004년 10월 47주년인 스푸트니크 발사 기념일에 오픈 소스로 공개되었습니다.
NGINX는 독립 실행형 웹 서버 및 Apache 및 기타 웹 서버용 프론트엔드 프록시로 배포할 수 있습니다. 이 드롭인 솔루션은 Apache 서버 앞에서 네트워크 Offload 디바이스로 작동하여 느린 인터넷 연결을 빠르고 신뢰할 수 있는 서버 측 연결로 변환하며, Apache 서버에서 keepalive 연결을 완전히 Offload합니다. 이로 인해 관리자가 로컬 벤치마크에서 볼 수 있는 수준에 가까운 성능을 Apache 에 되찾을 수 있습니다.
또한 NGINX는 충격 흡수 디바이스 역할을 하여 트래픽 급증과 Slowloris 및 slowhttprequest와 같은 저속 연결 공격으로부터 취약한 Apache 서버를 보호합니다.
3-1. 아키텍처의 비밀
NGINX의 성능과 확장성은 이벤트 기반 아키텍처에서 비롯됩니다. 이는 Apache 의 연결당 프로세스 또는 스레드 접근 방식과 크게 다릅니다. NGINX에서는 각 worker 프로세스가 수천 개의 HTTP 연결을 동시에 처리할 수 있습니다. 그 결과 가볍고 확장 가능하며 고성능인 높은 평가를 받는 구현이 탄생했습니다.
NGINX의 정교한 아키텍처의 단점은 이를 위한 모듈 개발이 Apache 만큼 간단하고 쉽지 않다는 것입니다. NGINX 모듈 개발자는 리소스 누출 없이 효율적이고 정확한 코드를 생성하고 복잡한 이벤트 기반 커널과 적절하게 상호 작용하여 차단 작업을 피하기 위해 매우 주의해야 합니다. 결과적으로 NGINX 프로젝트의 성공은 NGINX 오픈 소스의 미래를 보장하기 위해 Igor Sysoev가 2011년에 설립한 회사인 NGINX가 고용한 핵심 개발팀에 크게 의존했습니다.
동적 모듈에 대한 향후 지원에 대한 nginx.conf의 발표는 이전 compile‑in architecture보다 진입 장벽이 적은 third-party 개발자 에코시스템의 다음 단계를 나타냅니다.
4. NGINX와 Apache – 좋은 출발점
많은 애플리케이션 유형에서 NGINX와 Apache는 서로를 잘 보완하므로 ” NGINX와 Apache ” 대신 ” NGINX와 Apache “에 대해 이야기하는 것이 더 적합합니다. 매우 일반적인 시작 패턴은 NGINX 오픈 소스를 Apache 기반 웹 애플리케이션 앞에 프록시로(또는 애플리케이션 제공 플랫폼으로 NGINX Plus) 배포하는 것입니다. NGINX는 Apache 서버가 안전한 보안 환경에서 애플리케이션 코드를 실행할 수 있도록 HTTP 관련 무거운 작업(정적 파일 제공, 콘텐츠 캐싱, 느린 HTTP 연결 오프로드)을 수행합니다.
NGINX는 웹 서버를 성공적으로 만든 경량 및 고성능 품질을 희생하지 않으면서 웹 서버의 모든 핵심 기능을 제공하며 HTTP 요청을 업스트림 웹 서버(예: Apache 백엔드)로 전달하는 프록시 역할을 할 수도 있습니다. FastCGI, memcached, SCGI 및 uWSGI 서버. NGINX는 애플리케이션을 실행하는 데 필요한 광범위한 기능을 구현하려고 하지 않고 대신 PHP‑FPM, Node.js 및 Apache 와 같은 특수 third-party 서버에 의존합니다.
“ Apache 는 Microsoft Word와 같습니다. 백만 가지 옵션이 있지만 6개만 필요합니다. NGINX는 이 6가지 작업을 수행하며 그 중 5가지 작업을 Apache 보다 50배 더 빠르게 수행합니다. ”
이러한 이유로 NGINX의 시장 점유율은 Netcraft 및 W3Techs의 조사에서 보고된 바와 같이 최근 몇 년 동안 꾸준히 증가했습니다.
출처: Netcraft 2015년 9월 웹 서버 설문조사
(이러한 설문 조사는 들어오는 인터넷 트래픽을 처리하는 소프트웨어를 감지하고 식별 가능한 서버 헤더로 나가는 응답을 스탬프 처리합니다. 애플리케이션 내에 어떤 소프트웨어와 플랫폼이 있는지에 대한 많은 통찰력을 제공하지 않습니다.)
그래서 프론트엔드에서 NGINX를 실행하여 가속기 및 완충기 역할을 하는 아키텍처 패턴과 백엔드에서 애플리케이션을 실행하는 데 가장 적합한 기술이 등장했습니다.
5. 최신 웹 애플리케이션은 과거의 LAMP 스택과 매우 다릅니다.
컨테이너, 마이크로서비스, Node.js 및 Python/uWSGI와 같은 경량 애플리케이션 프레임워크에 대한 소문을 들어보셨을 것입니다.
최신 웹 애플리케이션이 구축되는 방식에 상당한 변화가 일어나고 있습니다.
이러한 변화의 근간에는 무거운 모놀리식 아키텍처에서 보다 느슨하게 결합된 분산 아키텍처로 이동하여 새로운 웹 애플리케이션 및 기능의 출시 시간을 단축하려는 욕구가 있습니다. 지속적인 제공은 이러한 변화의 근본적인 원동력입니다.
5-1. NGINX는 마이크로서비스 애플리케이션을 제공합니다.
컨테이너화된 마이크로서비스 애플리케이션에는 그 뒤에 있는 애플리케이션의 복잡성과 끊임없이 변화하는 특성을 숨기는 안정적이고 신뢰할 수 있는 프런트엔드가 필요합니다.
HTTP 요청을 업스트림 애플리케이션 구성 요소로 전달하려면 프런트엔드에서 “충격 흡수 디바이스” 보호 및 라우팅과 함께 HTTP, HTTPS 및 HTTP/2 연결 종료를 제공해야 합니다. 또한 기본 로깅 및 1차 액세스 제어를 제공하고 글로벌 보안 규칙을 구현하며 HTTP 무거운 작업(캐싱, 압축)을 Offload하여 업스트림 애플리케이션의 성능을 최적화해야 합니다.
여기에서 NGINX 및 NGINX Plus가 마이크로서비스 및 컨테이너에 이상적인 다음 12가지 기능을 제공하는 요소가 됩니다.
- 신뢰할 수 있는 단일 진입점
- 정적 콘텐츠 제공
- 통합 로깅
- SSL/TLS 및 HTTP/2 termination
- 여러 백엔드 앱 지원
- 손쉬운 A/B 테스트
- 확장성 및 내결함성
- 캐싱(오프로드 및 가속용)
- GZIP 압축
- 제로 다운타임
- 더 간단한 보안 요구 사항
- 보안 및 DDoS 공격 완화
5-2. NGINX를 사용하여 각 컨테이너화된 서비스 내에서 일관성 제공
최신 분산 웹 애플리케이션은 다양한 애플리케이션 구성 요소를 혼합하여 사용할 수 있으며 다양한 기술과 플랫폼을 결합하는 것은 드문 일이 아닙니다. 일반적인 요구 사항은 각 구성 요소가 가볍고 확장 가능하며 리소스가 제한된 멀티 테넌트 서버의 컨테이너에 배포하기에 적합해야 한다는 것입니다.
많은 컨테이너에는 임베디드 웹 서버가 필요하지 않습니다. 프레임워크 자체의 간단한 HTTP 프런트엔드를 사용하거나 FastCGI 또는 uWSGI와 같은 프로토콜을 사용하여 서비스를 제공합니다. 그러나 경우에 따라 효율성, 로깅, 보안, 모니터링 또는 추가 기능을 위해 강력하고 가벼운 웹 서버가 필요합니다. NGINX의 가벼운 특성으로 인해 Apache 모놀리스보다 컨테이너에 삽입하는 것이 훨씬 더 좋습니다.
6. NGINX vs Apache 결론
Apache와 NGINX는 둘 다 제 자리를 차지하고 있으며 NGINX는 확실히 우위에 있습니다. 귀하의 요구 사항과 경험으로 인해 하나 또는 둘 다를 선택하거나 다른 경로를 선택할 수도 있습니다.
모놀리식 아키텍처 프레임워크는 Apache가 새롭고 참신했을 때 건전한 관행이었지만, 앱 개발자는 이러한 접근 방식이 비즈니스에서 요구하는 속도로 복잡한 애플리케이션을 제공하는 작업에 더 이상 적합하지 않다는 것을 알고 있습니다. 마이크로서비스 아키텍처는 웹 앱과 사이트를 위한 미래의 물결로 부상하고 있으며 NGINX는 현대 웹을 위한 이상적인 애플리케이션 제공 플랫폼으로서 해당 아키텍처에서 그 자리를 차지할 완벽한 태세를 갖추고 있습니다.
7. NGINX vs Apache 인터넷 통계 자료
Cisco의 Visual Networking Index(수십 개의 통계에 대한 과거 보고서 및 예측 링크)
웹사이트 수(internetlivestats.com의 실시간 카운터)
웹 페이지 크기: 2015년까지의 페이지 크기에 대한 간략한 역사
8. NGINX vs Apache 추가 자료
Martin Fowler의 마이크로서비스 리소스 가이드
Chris Richardson의 마이크로서비스 아키텍처 패턴 및 모범 사례
NGINX 포스트:
- NGINX: 성능 & 확장을 위한 설계 방법
- Keepalive 설정으로 NGINX HTTP 성능 향상
- NGINX로 트래픽 급증에 대한 리스크를 제거하는 방법
- 마이크로서비스 아키텍처(MSA) 패턴의 이해
NGINX 또는 NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.
사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.