1. nginx란?
Nginx(엔진 x라 읽는다)는 웹 서버 소프트웨어로, 가벼움과 높은 성능을 목표로 하며 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가집니다.
가장 많이 사용하는 방법은 앞 단에 nginx로 리버스 프록시로 사용하고, 뒷단에는 WAS (iis, jetty등)를 설치하는 것이 보편적인 방법입니다. (현재로는)
아파치는 마치 마이크로소프트 워드 같다.
수백만 개의 옵션이 있지만 사람들은 단지 여섯개만 사용한다.
그 여섯 개의 옵션은 엔진엑스에도 있고 그 중 다섯 개는 아파치보다 50배나 빠르다.
참고
물리적 1대 서버에서 cpu core 8인 경우 TPS 50,000 ~ 80,000 이 가능하다고 합니다.
2. nginx는 윈도우즈 or 리눅스?
Version of nginx for Windows uses the native Win32 API (not the Cygwin emulation layer). Only the select() connection processing method is currently used, so high performance and scalability should not be expected.
(nginx site 에서 발췌)
윈도우 nginx 버전은 win32API의 select() connection 방법만 사용하므로 고성능과 확장성을 기대할 수 없습니다.
결론 - nginx는 linux 버전으로 설치해야 한다.
또한 윈도우 버전의 critical issue 로 아래와 같은 문제가 있습니다.
1.여러 worker process 를 띄울 수 있지만 그들 중 1개는 작동
2.1024 worker 이상 못 띄움
3.윈도우 비스타 이후 버전에서 공유메모리 자원이 필요한 곳에서 기능 지원 못함
Linux nginx 버전으로 설치 하자. (현재 stable Version ? nginx-1.8.1.tar.gz)
3. Nginx 내부 프로세스
해당 부분은 현재 개발 release 버전 1.9.12 소스를 확인 한 부분에 대해 설명을 드리겠습니다. 직접 봐야 확실히 할 수 있을 것 같아서 입니다. (현재 core 디렉토리쪽만 확인하였고 해당 부분만 보시면 nginx 모듈을 이해 하시는 데에 도움이 되실 것입니다.)* 버전 ? nginx-1.9.12 (현재 stable version은 1.8.1 입니다.) 개발 언어는 C 입니다.
binary folder는 windows 경우 conf, contrib, docs, html, logs, temp, nginx.exe 이렇게 구성되어 있습니다.
여기서 핵심적인 부분은 nginx.exe, conf 디렉터리 입니다.
conf 디렉터리는 리버스 proxy 할 파일을 json형태로 설정을 합니다.
(Server 명, worker connections, keep alive, SSL기타등등)
* nginx life cycle은 아래와 같습니다.
1) 프로세스 init 시 conf 파일(proxy 설정 및 기타등등) 을 읽어 들여 메모리 cache로 저장
2) worker process 를 개수(기본 설정은 cpu 개수)만큼 생성, worker process에서 worker connections만큼 요청 대기
3) request 전달 받음. 1개의 process 가 event-driven 방식으로 처리 (thread 로 처리 하지 않습니다.)
4) 다음 요청 대기 여기서 핵심은 2,3 번입니다.
(핵심적인 부분은 worker_connections 이며 default는 1024, 1개의 worker 에 1024 client를 붙을 수 있음)
worker_process 는 CPU갯수로 설정을 주로 셋팅을 합니다.
즉) clien에서 요청이 들어올 경우 worker process (cpu 갯수) X worker_connections 갯수만큼 처리합니다.
보통 cpu 4개 인 경우 work process 4 X work connections = 4096개 client 처리를 할 수 있도록 설정하는게 베스트 입니다.
또한 worker는 1개의 process 이며 내부 로직은 loop로 event-driven 방식으로 처리하며 여러 worker process는 master라는 구조체가 관리 합니다.
4. nginx 내부 프로세스 - 2
nginx는 부가서비스들을 많이 고려하지 않았습니다. (Web server, Application proxy 기능에만 충실함)(listen socket을 열어 놓고 요청이 들어오면 실행-loop로 채널에 write하고 proxy를 async, nonblocking으로 함 )
proxy 처리가 굉장히 타이트 함 (리버스 proxy 성능만을 위해 만들어진)
핵심 worker 모듈 (혹시 소스를 보시고 싶으시면 ngx_process_cycle.c가 핵심 처리 모듈임)
for ( ;; ) {
if (delay) {
if (ngx_sigalrm) {
sigio = 0;
delay *= 2;
ngx_sigalrm = 0;
}
if (ngx_reap) {
ngx_reap = 0;
ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "reap children");
//해당 부분이 실제 처리 로직 채널 열어 놓고 write 함, wirte 한 부분을 proxy 처리
live = ngx_reap_children(cycle);
}
}
참고로 1.9.1 개발버전에서 HTTP2.0 spec을 구현할려는 모습이 보입니다.
구글에서 만든 SPDY 네트워크 프로토 콜 부분에 대해 Stub 및 완전히 구현되어 있지 않은 imp이 있으며,
차후 버전에서 impl도 지속적으로 만들어질 것으로 보입니다. (SPDY 부분에 대해서도 한번 공유 드리겠습니다.)
Apache VS nginx
1) 처리 구조의 큰 차이
- Apache Http 서버는 요청 하나당 쓰레드가 처리하는 구조
- Nginx는 1개의 프로세스가 모든 요청을 처리하는 구조 (event-driven)
만약 Apache Http 서버의 프로세스가 blocking(DB나 파일)이 되면 요청을 계속 처리하지 못하고 처리 완료 때까지 대기하는 일이 생기며, 쓰레드가 많을 시 내부 리소스 할당에 많은 비용 소모
(context swithing 많은 비용 소모)
5. nginx로 할 수 있는 장점들
* Security 보안 기능 (DDOS Defense)- 외부 노출되는 인터페이스에 대해 nginx WAS 부분만 노출 가능하다.
public (nginx) , private (backend-server)으로 노출하여 외부에서 backend에 바로 진입을 할 수 없도록 처리 가능
1) client max connection 조절
2) 서버 (500 http status) 에러 handling 가능
3) prefix URI, 확장자별 처리 가능
4) header, body size filter 처리
* Backend-service 장애 대응 처리
- backend service에 대해 max fails, fail timeout 시 백업 서버로 진입할 수 있도록 처리 가능
* Load Balancing (TCP layer, Application layer)
- front, reverse proxy 기능 가능, image, stream 등에 대해 처리 가능
* Keep alive 제어
- keep alive = true 에 대해 max connection 수, 1개의 connection에 처리량 조절, keep alive timeout 처리
* sub domain (nginx) 관리 기능
- nginx에서 여러 도메인으로 접근할 수 있도록 셋팅 가능
* Size 큰 데이터 caching 처리 가능
- image 및 기타 콘텐츠 데이터에 대해 캐싱 expire로 제공 가능
