사용자 도구

사이트 도구


소프트:nginx

NGINX(엔진엑스)

엔진엑스 로고

소프트명:
NGINX
한국어명:
엔진엑스
기능분류:
서버, 리버스 프록시
개발사:
NGINX
가격:
자유
저작권:
BSD
주개발자:
이고르 시쇼에프
최신판:
1.7.10
첫발매일:
2004-10-04
최종판올림:
2015-02-10
운영상태:
운영중
기반언어:
C
지원플랫폼:
리눅스, FreeBSD(프리BSD), 유닉스, 유사 유닉스, 윈도우NT 계열
홈페이지:
http://nginx.org

NGINX는 러시아의 서버 관리자이자 개발자인 이고르 시쇼에프(Игорь Сысоев)가 만든 리버스 프록시 서버 프로그램으로, 2002년부터 개발내용을 발표하기 시작해 2004년 10월 4일 첫 정식버전을 런칭했다. ‘엔진엑스’라고 발음하지만, 표기가 특이해서 페이지는 원어명을 따서 만들었으므로 참고하자.

웹서버로 가장 널리 사용되며, 특히 정적인 파일 서버로서의 성능이 무척 뛰어나며, CGISCGI, FastCGI 기법을 통해서 다양한 프로그램과의 연동으로 웹서비스를 제공할 수 있다. 기본적으로는 리버스 프록시 서버이기 때문에 모듈을 붙이는 것에 따라 웹서버 뿐만 아니라 메일서버 등으로도 사용가능하다. HTTP, HTTPS, SMTP, POP3, IMAP 등의 프로토콜을 지원하며 모듈에 따라 해당 기능을 서비스할 수 있으며, HTTP계열 서비스에서는 FLV, MP4 등의 동영상 파일 스트리밍 전송 기능도 제공한다.

대표적인 웹서버인 아파치 웹서버에서 사용하고 있는 프로세스나 쓰레드 방식이 아닌 비동기 이벤트 구조로 작동하며, 기본적으로 단일 쓰레드 방식으로 작동한다. 이로인해 프로세스나 쓰레드 방식에서 발생하는 블록킹에 의한 지연이나 자원 소모가 적어 가벼운 프로그램 구조와 빠른 속도를 자랑한다. 서버업계에서 2000년대 중후반부터 입소문을 타기 시작해 점차 사용자가 급증하고 있다.1)

아무래도 안정성이 성능이나 비용보다도 더 높은 우선순위를 가지는 보수적인 서버 업계의 특성과 거의 하나의 플랫폼으로 확대되어버린 아파치 웹서버의 영향력이 큰 탓에 아직까지는 전체 사용률은 높지 않은 것이 사실이다. 그러나 기타 플랫폼에 묶인 경우라도 해당 플랫폼 윗단에 프록시(Proxy) 서버나 부하분산(로드 밸런스, Load balance) 서버로 엔진엑스를 채용해 사용하는 경우가 늘고 있다.

현재 넷플릭스, 훌루, 핀터레스트, 클라우드 플레어, 워드프레스, 깃허브, 사운드 클라우드, 징가 등 많은 업체들이 서비스에 엔진엑스를 채용하고 있다.

상세설명

역사

러시아의 포탈 업체인 램블러(Rambler)에 근무하던 이고르 시쇼에프는 2000년대에 들어 급증하는 인터넷 트래픽과 접속자 수, 그리고 웹페이지에 들어가는 엄청나게 늘어난 이미지 수와 CSS 등의 파일 전송량으로인해 서버 및 서비스의 원활한 관리가 점차 어려워지고 있음을 느끼고 있었다. 흔히 C10K 문제라고 부르는 일종의 한계에 봉착해 있었던 것이다. 당시 아파치가 거의 점거하고 있던 서버 업계는 한계선까지 아파치를 트윅하는 것은 기본이었으나, 그것으로 문제를 해결하는데에는 분명 근본적인 한계가 있었기에 그에대한 대안이 필요했다.

2002년부터 이문제에 대한 해결책으로서 엔진엑스 개발을 시작한 이고르 시쇼에프는 2003년 즈음 실제 테스트를 시작, 즈부끼(Zvuki)라는 MP3 다운로드 사이트에서 처음으로 실제 서비스에 적용하여 좋은 결과를 얻었고, 근무처인 램블러의 사진 공유 서비스에 엔진엑스를 적용해 서비스를 시작했다.

2004년에 이르러 BSD 라이센스로 정식 버전을 공개했으나, 당시에는 러시아어로만 만들어져 있었던 매뉴얼과 주석으로 인해 사용자는 크게 늘지 않았다. 2005년 즈음에 사용자가 대략 100여명 정도였다고. 이 때부터 영어 매뉴얼 및 토론을 확대하기 시작했고, 2006년에 이르러서 매뉴얼 등이 영어로 충실해지자 사용자가 확대되기 시작했다.

이후 사용자가 점차 늘기 시작했고, 한국에도 이 즈음을 기점으로 유입되기 시작해 이름을 알리기 시작했다. 그러나 사용해본 사람들의 높은 평은 잇달아 나왔음에도, 이즈음에는 아직 마이너한 소프트웨어였고 대규모 서비스에 실제 적용된 사례가 별로 없었기 때문에 신뢰도 면에서도 확신을 가진 사람들이 많지 않아 상용 서비스에서 채용되는 경우는 그렇게 많지 않았다.

엔진엑스의 안정성과 신뢰도는 2008년에 이르러 블로그 서비스인 워드프레스의 홈페이지(wordpress.com)와 서비스 페이지에 채용되며 급격하게 올라가기 시작했다. 그리고 이러한 성과를 인정받아 서서히 점유율을 높이기 시작했는데, 그들의 서비스의 신뢰도를 급격히 올려준 사건이 바로 그 이듬해에 일어난다.

2009년 CDN 서비스 및 보안 DNS서비스를 제공하는 클라우드플레어(CloudFlare) 서비스를 만들 때, 빠르고 가벼우며 멀티코어에서 더 잘 작동하는 서버를 필요로 했다. 그들은 이고르 시쇼에프를 고용, 엔진엑스를 개량해 자사 서비스에 맞는 결과물을 만들어내는데 성공했다. 클라우드 플레어는 월간 조단위의 페이지 뷰를 전송하는 세계 최대급의 CDN 서비스업체이기에 엔진엑스의 안정성과 신뢰성은 이것만으로도 거의 확실하게 인정받게 되었다.

또한 시기적으로 커져가는 클라우드 서버 서비스 등에서 제한된 프로세싱 능력과 메모리를 십분 활용하기 위해 엔진엑스를 사용하는 사용자가 급증하기 시작했으며 거기에 맞춰 다양한 모듈들이 선보이며 그 전까지 부족하다고 평가받았던 기능적으로도 많은 개선을 이루게 되었다.

이러한 성공을 기반으로 이고르 시쇼에프는 주식회사 엔진엑스 설립, 2011년에 미국 샌프란시스코에 사무실을 세우고 회사로서 활동을 시작했다. 2013년에는 유료 엔진엑스 플러스 서비스를 시작했다.

2012년 11월 1일 공개된 OpenBSD 5.2부터는 아예 베이스 시스템에 아파치 웹서버 대신 엔진엑스가 내장되었다.2)

구조

엔진엑스 처리 흐름도

엔진엑스는 크게 코어 파트와 모듈 파트로 분류된다.

엔진엑스 코어

엔진엑스는 앞서 설명했듯 기본적으로 리버스 프록시 프로그램이다. 때문에 정확히 말해서 ‘엔진엑스 코어’자체는 외부에서 들어온 요청을 직접처리하지 않는다.

예를 들어서 웹서버로서 엔진엑스를 쓰려면 HTTP 모듈을 설치해야한다. HTTP 모듈을 설치하지 않고 메일 관련 모듈만 설치하면 HTTP관련 기능은 모두 사용이 불가능하며 웹서버로서 기능하지 않는다.

엔진엑스 코어는 서비스 데몬으로 작동하는 본체를 지칭하며, 설정파일을 읽어 기본적인 작동에 직접 관계된 프로세서 숫자나 처리 방식(epoll, kqueue, select, poll 등)에 따라3) 대기하고 있다가 설정파일에 기술된 요청(Request) 이벤트가 들어오면 적절한 하부 모듈 핸들러에 전달하는 것이 주요 일이다.

엔진엑스 모듈

FreeBSD의 포트에서 컴파일 전에 모듈 선택하는 화면

코어에서 모듈로 전달된 요청(Request)은 모듈을 거쳐 요청을 처리하고 요청을 보낸 클라이언트에게 결과를 전달하게 된다. 이 과정에서 단순처리 뿐만 아니라 다양한 부가기능을 추가로 사용해 중간처리를 해줄 수 있는데, 이러한 추가 기능을 모듈 필터라고 부른다.

엔진엑스의 모듈은 작동하는 형태에 따라 크게 세종류(핸들러, 필터, 로드 밸런서)로 분류가 나뉘게 된다. 각 분류의 예시를 보면 이해하기가 쉽다

핸들러(handler)
HTTP요청을 처리하고 요청에 대한 응답을 만든다.
파일을 요청한 클라이언트에게 파일을 제공하는 핸들러 모듈
HTTP 요청을 다른 서버로 리다이렉트하는 핸들러 모듈
필터(filter)
핸들러가 만든 응답을 추가로 가공하거나 분석한다.
로드 밸런서(load-balancer)
HTTP 요청을 어느 백엔드(back-end) 서버에 보낼 것인지 결정한다.

아직 아파치에 비해서는 기능이 부족하긴 하지만 필수적이랄 수 있는 모듈들은 제공되고 있으며, 서드파티 모듈도 늘어가는 추세다. 무엇보다 간단하고 일관성있는 설정으로 각 모듈을 사용할 수 있는 점과, 다수의 필터를 처리하는 연결 구조인 필터 체인을 정적으로 링크할 정도로 속도에 집중한 모듈 필터의 구조는 엔진엑스의 강점을 십분 발휘하도록 도와준다.

그러나 관리에 약간 불편함도 있는데, 엔진엑스의 모듈 필터는 정적 링크만 지원하기 때문에 컴파일 시에 때문에 모듈을 변경하려면 옵션을 변경해서 재컴파일 해줘야한다. 아파치 등의 경우 동적으로 관리하기 위해서 각종 툴킷이 추가로 제공되지만 엔진엑스는 가볍고 간단한 구조를 위해 이러한 부분을 배제한 것. 제작자인 이고르 시쇼에프도 불편함 자체는 알고 있고 장기적으로는 동적 모듈관리를 염두에 두고 있다는 말한 바 있다. 그러나 아직까지는 기약없는 계획이므로 참고만 하도록 하자.

장단점

장점

빠르다. 그리고 가볍다.

아파치 웹서버에 비해서 압도적으로 가벼운 무게를 자랑하기에 메모리 사용량이 극단적으로 적으며, 정해진 작업을 재빠르게 처리하는 것으로는 정평이 나있다. 단독 쓰레드 방식으로 처리를 하기 때문에 프로세스 블로킹(Blocking)이 일어나지 않아 대량의 접속을 처리하는데 있어서 최적이라고 할만하다. 또한 멀티코어 관련으로도 프로세서의 수만큼 프로세스를 늘려서 처리하면 매우 효율좋게 작업이 이뤄진다. (프로세스 수가 늘어나도 원체 가볍기 때문에 부담이 적다)

기본구조 자체가 스스로 스크립트 프로그램을 처리하지 않기 때문에 처리를 외부로 돌리고 결과를 받아 전달하는 기능이 매우 충실하다. 또한 부하분산(로드 밸런스)기능도 매우 간단하게 사용가능해서, 대규모 서비스에서 다수의 서버를 이용해 프로그램을 분산 처리할 때 매우 편리하다.

전체적인 설정이 매우 간단하고 직관적이다. 기본룰을 익히고나면 거의 대부분 반복적인 형태로 설정하기 쉽다.

단점

단순하고, 제한적이다.

지원 모듈이 제한적이며, 상대적으로 경쟁상대인 아파치 웹서버에 비해서 부실하다.4)

모듈에서 추가기능을 처리하는 필터 방식에서 사용하는 개별 필터의 연결(체인)을 컴파일 단계에서 만들기 때문에 모듈을 추가하거나 빼려면 보통 재컴파일을 해줘야한다. 2012년 인터뷰에서 선택형 모듈 방식을 나중에 추가할 예정이라고 언급한 바가 있긴 하지만 언제 변경될지 확실치 않다.

가장 널리 사용되는 주소재작성(rewrite)기능을 아파치의 mod_rewrite 기능과는 다른 형태로 처리하기 때문에 .htaccess 파일을 통한 주소재작성을 지원하지 않는다. 엔진엑스는 사이트 설정 항목에 주소 재작성 관련 내용을 추가해줘야 한다. 또한 해당 설정 내용이 변경될 경우 서버 자체를 재시동 해줘야 적용된다.

사실 단점 대부분이 처리속도를 높이기위해 선택한 것들이라 아마 앞으로도 한동안은 바뀔 가능성은 높지 않을 것으로 생각된다. 위 단점이 사용 용도에 맞지 않다고 생각되면 엔진엑스보다는 다른 서버를 선택하는 것이 더 나을 수 있다.

추가로 국내에서 가장 널리 쓰이는 웹스크립트 언어인 PHP의 내장 FastCGI 데몬인 PHP-FPM과 연결할 때 유닉스 도메인 소켓(Unix Domain Socket)을 사용하면 도중에 종종 뻗어버리는 경우가 있어서 아파치와 mod_php를 쓰던 사람들이 넘어와서 엔진엑스의 문제인걸로 자주 오해를 하곤 하는데, 이쪽은 PHP-FPM 자체 문제이다.(아파치에 프록시로 mod_proxy_fcgi를 써서 PHP-FPM을 연결해도 같은 문제가 발생한다) 대부분의 웹호스팅 업체나 클라우드 서버 업체들은 PHP-FPM 대신 PHP-FastCGI 등의 별도 데몬을 따로 사용하는걸 권하고 있으므로 사용하려 한다면 참고하도록 하자.

같이보기

안쪽고리

바깥고리

1) 엔진엑스의 영향만은 아니겠지만 아파치도 이벤트 방식의 MPM을 지원하게 되었고, 2.4버전부터는 이벤트 방식이 메인으로 바뀌었다
2) 보안을 최우선으로 생각하는 OpenBSD에 내장되면서 이 부문에 있어서의 안정성도 확고하게 되었다고 보아도 무방하겠다
3) 윈도우의 경우에는 select방식만 지원한다
4) 사실 이 부분은 리버스 프록시로 개발된 엔진엑스의 기본 이념과 관련된 부분이라 거의 독자 플랫폼이 되어있는 아파치와 비교하는 것은 좀 문제가 있다

 

덧글

소프트/nginx.txt · 마지막으로 수정됨: 2015/02/27 16:34 저자 에리얼