NGINX

러시아의 프로그래머인 이고르 시쇼브(Игорь Сысоев, Igor Sysoev)가 아파치 웹 서버의 이른바 C10K 문제를 해소하기 위해 개발을 시작한 오픈 소스 웹 서버로, 2004년 스푸트니크 발사일에 첫 버전을 공개했다. 이후 시쇼브가 2011년에 설립한 NGINX Inc.가 프로젝트를 운영하다가 웹 애플리케이션 서비스를 주력 사업으로 하는 미국 기업인 F5 네트웍스가 이 회사를 인수하면서 지금은 F5가 운영하고 있다. 인수 이후에도 개발은 주로 러시아에서 이루어져 왔지만 2022년 러시아의 우크라이나 침공 사태를 계기로 러시아 법인도 철수하고 러시아에서 F5 네트워크에 접속할 수 없도록 막아버리면서, F5는 2022년 3월, "이제 NGINX의 소스 코드는 오픈 소스든 상용 소스든 러시아에 없다"고 선언했다.

현재 NGINX는 오픈 소스에 무료로 사용할 수 있는 NGINX, 그리고 구독 기반 유료 웹 서버인 NGINX Plus 두 가지 버전이 있다. NGINX Plus는 NGINX의 기능에 더해 헬스 체크, 향상된 캐시 제어, 스트리밍 미디어 배포와 같은 고급 기능을 제공한다.

특징

아파치 웹 서버는 접속 요청이 들어올 때마다, 즉 네트워크 소켓이 필요할 때마다 프로세스 또는 스레드를 새로 만들어서 배당하는 구조인데, 이 때문에 소켓이 10,000개 이상 열리면 아무리 하드웨어의 성능이 좋아도 웹 서버의 성능이 급격하게 저하되는 현상이 일어나며 이를 이른바 C10K 문제라고 부른다. 사실 이 문제는 정확히는 아파치 웹 서버가 잘못되었다기보다는 UNIX 계열 운영체제의 입출력(I/O) 시스템에 한계가 있기 때문이다. 지금 주류를 이루는 UNIX 계열 운영체제들을 설계할 당시에는 동시에 열리는 소켓 수가 10,000개나 된다는 건 상상도 못할 일이었고, 따라서 소켓이 필요할 때마다 프로세스나 스레드를 새로 만드는 게 별 문제가 안 되었다. 그러나 인터넷 시대가 열리고 서버가 처리해야 하는 동시 접속 수가 급격하게 불어나면서 문제가 제기 되기 시작했다.

이를 극복하기 위한 방안 중 하나가 비동기 이벤트 기반의 싱글 스레드 방식으로, 즉 소켓이 필요할 때 프로세스나 스레드를 새로 만들지 않고 하나의 스레드가 모든 요청을 처리하되, 이벤트가 발생할 때에만 해당 소켓의 요청을 처리하는 방식이다. Node.js도 이러한 방식을 사용하고 있으며, C10K 문제를 극복하기 위해 NGINX가 채택한 해결책도 역시 비동기 이벤트 기반의 싱글 스레드다. 따라서 10,000개 이상의 동시 소켓도 잘 처리하는 것은 물론이고 새로운 요청이 발생했을 때 자원 소모가 아파치에 비해 확실히 적다. 아파치도 문제를 극복해 보려고 멀티스레드를 적극 활용하는 쪽으로 개발을 하고 있지만 '1소켓 = 1프로세스 또는 스레드'인 한은 근본적인 한계를 벗어나지 못한다.

NGINX의 또 한 가지 주요한 특징으로는 리버스 프록시(reverse proxy)가 있다. 리버스 프록시란 클라이언트와 내부 서버 사이에 NGINX가 있으면서 클라이언트로부터 요청이 들어왔을 때 내부 서버로 전달해서 처리를 하게 한 다음, 응답을 받아서 클라이언트로 전달하는 기능이다. 즉 NGINX는 양쪽 사이에서 오로지 '전달자' 구실만 한다. 예를 들어 아파치 웹 서버에서 PHP 파일을 처리할 때에는 아파치에 PHP 모듈(mod_php.c)을 붙여서 스크립트를 처리하는데, NGINX는 PHP-fpm이라는 FastCGI 프로세스로 요청을 넘기고, PHP-fpm이 돌려주는 결과를 요청에 대한 응답으로 돌려준다. 이 방식의 장점은 NGINX가 단순 웹 서버를 넘어 로드 밸런서로도 동작할 수 있고, CDN으로도 활용할 수도 있고, 그밖에도 다양한 활용법을 제공한다. 다만 처리 속도로 본다면 외부 프로그램과 리버스 프록시로 통신하는 방식으로 동적 파일을 처리하므로 모듈이 한몸처럼 동작하는 아파치에 비해 별다른 성능 이득이 별로 없거나 아파치보다 오히려 느릴 수 있다.

NGINX vs. 아파치 웹 서버

NGINX는 아파치 웹 서버의 근본적인 단점을 극복하고 대량의 웹 소켓 처리가 가능하며, 리버스 프록시 기능으로 단순 웹 서버를 넘어선 다양한 기능으로도 활용할 수 있다. 하지만 NGINX가 아파치와 비교해서 장점만 있는거 하면 그렇지는 않다. 아파치 웹 서버의 장점 중 하나는 폴더 별로 .htaccess 설정 파일을 만들어서 폴더에 따라 웹 서버의 동작을 다르게 만들 수 있다. NGINX는 이러한 기능이 없으며 설정 파일에서 다 해결해야 한다. 단 설정 파일은 여러 개를 만들고 메인 설정 파일에 포함시킬 수 있다. 이는 양날의 검이라는 면도 있는데, 폴더에 따라 .htaccess 파일을 읽어서 처리하는 과정이 성능을 떨어뜨리는 원인으로 지적되기 때문이다.

추가 기능을 위한 모듈 제작이 NGINX에 비해 쉽다는 것도 아파치 웹 서버의 장점으로 꼽힌다. 오랜 역사를 가진 웹 서버 답게 이미 만들어져 있는 모듈도 많다. 하지만 실제로 쓸모 있는 모듈은 많지 않고 오히려 자원만 잡아먹는다는 반론도 있다. 아무튼 반드시 어느 한 쪽이 정답은 아니며, 어떤 웹 서비스를 제공할 것인가에 따라서 적절한 웹 서버를 선택할 필요가 있다.

정적 파일의 처리는 확실하게 NGINX가 뛰어나다. 반면 PHP, 파이썬 스크립트와 같은 동적 파일 처리는 두 웹 서버가 비슷한 성능을 보이거나 경우에 따라 아파치가 좀 더 앞서기도 한다. 대체로 처리해야 할 동적 파일의 크기가 작으면 커지면 별 차이가 없으며, 크기가 클수록 아파치 쪽이 좀 더 앞서는 것으로 알려져 있다.

한편으로, 아파치 웹 서버와 NGINX를 같이 사용할 수도 있다. NGINX의 특징인 리버스 프록시 기능을 활용해서 정적 파일 처리는 NGINX가 직접 하고, 아파치 쪽 기능이 필요한 부분은 아파치에 넘겨서 처리할 수도 있다.

설정 파일이 좀 더 깔끔하다는 것도 NGINX의 장점이다. 양쪽 널리 알려진 표준 파일 형식은 아니지만 아파치보다는 덜 난잡한 느낌이다.