NginX - Useful Proxy
Techs정윤진 ( yjjeong@rsupport.co.kr )
비교적 시스템적으로 간단한 현실세계의 웹 서비스 구조는, 요 몇년 전 부터 비약적으로
발전하고 있다. 글로벌 서비스의 영향 및 지역적으로 다른 망 속도의 영향, 서비스 구조의 복잡성 증가 등으로 인해 각종 스토리지 및 데이터베이스 튜닝, 서버 자원에 대한 업그레이드
만으로는 이제 힘든 시기가 되었다.
따라서 복잡한 로직의 경우에 분산 시스템 구조를 도입하는것이 필연 적이며, 이에 대해서 동일 목적의 서버간 그룹화 하고 더 나아가서는 특정 부하유발 구간 ( 병목구간 ) 에 더 많은 리소스를 투입하여 세분화된 분산 구조를 적용해 준다면, 더 좋은 서비스 퍼포먼스를 기대 할 수 있다.
기존의 APM 구조의 경우 필요한 모듈을 모두 가져다 붙이면 서버는 무겁게 동작하게 되고
따라서 웹서버와 이미지 서버의 분리와 같은 방법등이 등장하였으며, L4 를 사용한 서버 로드밸런싱, Apache 를 대신할 lighttpd 등과 같은 Light Weight 웹 서버등이 그것이다. 물론
규모에 따라 CDN 을 도입 할 수도 있겠지만, 이는 네임 서버의 커스터마이징 또는 상용 솔루션
( 이를테면 F5 Networks 의 Big-IP GTM 와 같은 ) 을 사용하여 자금력이 있는 경우 직접
CDN 비슷한 효과를 낼 수 있다.
이번 프로젝트에 사용했던 이 놀라운 웹서버는, 주 목적이 L7 Level 의 Proxing 이다.
실제 서버 구성은 AJ ( Andrew J. Kim ) 가 거의 다 했지만. ㅋㅋ;
Nginx 홈페이지에서 말하고 있는 대략적인 기능은 다음과 같다.
Basic HTTP features;
Mail proxy server features:
- User redirection to IMAP/POP3 backend using an external HTTP authentication server;
- User authentication using an external HTTP authentication server and connection redirection to internal SMTP backend;
- Authentication methods:
- POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
- IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
- SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;
- SSL support;
- STARTTLS and STLS support.
Tested OS and platforms:
- FreeBSD 3 — 7 / i386; FreeBSD 5 — 7 / amd64;
- Linux 2.2 — 2.6 / i386; Linux 2.6 / amd64;
- Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
- MacOS X / ppc, i386;
- Windows XP, 2003;
Architecture and scalability:
- one master process and several workers processes. The workers run as unprivileged user;
- kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), event ports (Solaris 10), select, and poll support;
- various kqueue features support including EV_CLEAR, EV_DISABLE (to disable event temporalily), NOTE_LOWAT, EV_EOF, number of available data, error codes;
- sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5), sendfile64 (Linux 2.4.21+), and sendfilev (Solaris 8 7/01+) support;
- accept-filter (FreeBSD 4.1+) and TCP_DEFER_ACCEPT (Linux 2.4+) support;
- 10,000 inactive HTTP keep-alive connections take about 2.5M memory;
- data copy operations are kept to a minimum.
대략적인 시스템 구조를 그리면 다음과 같다.
라우터 --- L4 --- NginX --- L2 --- Real SVRs
이중화 하게 되면 부쩍 고민할 것들이 많아지겠지만 일단은 이런 구성이다.
이 NginX 로 처리하고자 하는 것은, 비교적 적은 공인 IP 로 실제 내부 웹서버들에 대한
요청 uri 의 라우팅이며 이를테면 이미지 서버가 아닌 웹 서버간에도 기능별 통합 및 분산을
구현하고 memcached 까지 붙여주면 거의 날아 다닌다.
linux 의 경우 기본적으로 epoll 및 sendfile 을 지원하기 때문에 성능에 대한 우려는 없으나,
버전이 아직 0. 으로 다소 불안한 부분이 있을 수 있겠으나, 프로젝트 자체는 굉장히 오래된 것이어서 적절히 이중화 해 준다면 큰 효과를 볼 수 있을 것이다.
이런말은 좀 그렇지만, 잘 구성할 수 있는 인력이 있는경우 F5 Big-IP LTM 에 Ram Cache 및
Compress 의 feature 를 돈천만원씩 붇는 것 만큼 매력적이다.
물론 php와 연동하는경우, xcache 및 fast-cgi 등을 원하는대로 가져다가 붙일 수도 있다.
만약, 웹서버와 이미지 서버의 분리가 되어있고 웹서버가 수행 기능별 또는 플랫폼 별로
분리를 해야 할 필요가 있다면 nginx 는 저렴한 비용으로 구축할 수 있는 가장 효과적인
솔루션이 될 수 있다. 또는 내부 서버간 세션 공유 처리가 잘 되어 있다면, http 전용 서버와
SSL 처리 전용 서버를 구분 할 수도 있다.
또는, 이미지 전용 도메인을 따로 따기가 힘든 경우, 이를 테면 image.a.com 과 같은 도메인
으로 변경하려 하나 웹 소스가 난잡하거나, 도메인 변경이 쉽지 않은 경우에 다음과 같은
내부 분산을 통해 효과를 거둘 수 있다.
a.com/webroot 는 A 서버 그룹으로
a.com/images 는 B 서버 그룹으로
이 외에도, 별의 별 모듈이 다 있다.
몇가지 쓸만한 것을 ( 직접 테스트 해 보진 않았지만~ ) 을 추려보면,
GeoIP
Gzip
HTTP Limit Requests
..
나머지는 아래의 wiki 를 참조 한다. lighttpd 의 trac 과는 다르게, 굉장히 잘 정리 되어있어
별도의 설명이 필요 없을 정도다.
아무튼,
이 놀라운 L7 Proxy ( 나는 그렇게 생각하고, 그렇게 쓴다. ) 에 대해서는 추후 몇몇 key config를 걸어 놓도록 하고, 실제 apache 와 nginx , lighttpd 등과의 비교를 시도해 보아야 겠다.
http://wiki.nginx.org/Main
http://nginx.net/