Nginx

Nginx란?

웹 서버이며, 리버스 프록시, 로드밸런서, http 캐시로도 이용될 수 있도록 하는 소프트웨어이다. 요청에 응답하기 위해 이벤트 기반 구조를 채택하고 있다라고 정의할 수 있다. 그렇다면 우리는 다음과 같은 질문을 들을 수 있을 것이다.

이벤트 기반 구조? Apache HTTP Server와는 어떻게 다르지?

Nginx를 왜 사용하지?

이를 이해하기 위해서는 Nginx의 출연 배경을 알아봐야 한다. 이를 위해 Apache HTTP Server와 비교해서 설명을 하겠습니다.

Apache HTTP Server

이는 1995년에 당시에는 NCSA HTTPd로 유닉스 계열에서 최초의 웹 서버로 개발자들이 사용했지만 이는 버그가 많아서 이를 보완하고, 기능을 변경하면서 태어난 것이 Apache HTTP Server이다.

구조

요청이 들어올 때마다 Connection을 형성하기 위해 새로운 Process를 생성하게 된다. 유닉스 기반의 OS가 네트워크 커넥션을 형성하는 모델을 그대로 적용한 형태이다. 프로세스를 생성하는 것이 시간이 오래 걸리는 작업이다보니 미리 프로세스를 생성해두는 형태가 되었다. 이에 요청이 올 때마다 이를 활용하게 된다.

이러한 방식은 확장성이 쉽다는 장점을 가지고 개발자는 이에 개발에 용이하게 되어 이를 가지고 다양한 모듈을 만들어서 서버에 빠르게 추가할 수 있게 되었다.

C10K (connection 10,000 problem)

1999년대에 인터넷이 본격적으로 보급되면서 인터넷 사용자가 급격하게 늘면서, 다음과 같은 문제가 생겼는데, 다수의 클라이언트가 요청을 보내는 갯수가 급격히 늘면서 문제가 발생하게 되었다. 일정 이상의 커넥션을 형성 했을 때 더이상의 커넥션을 생성할 수 없는 경우가 발생하게 되었다. 이를 C10K 문제라고 한다.

이때 동시 커넥션 수란?

동시 커넥션 수는 한 클라이언트에서 여러 개의 요청을 보낼 수 있고 커넥션이 연결된다면, 오랜 시간 유지될 수도 있기 때문에, 서버가 얼마나 빨리 처리하는지에 대한 초당 요청 처리수와는 다른 지표를 의미한다.

오랜시간 커넥션이 유지되는 이유는 클라이언트에서 한번 연결된 커넥션을 활용하기 위해 연결이 된다면 이를 정해진 시간 내에 다른 요청들도 수행할 수 있도록 한다.

(이때 활용되는 것이 HTTP 해더 중에 keep-Alive timeout이라는 해더를 통해 이시간동안 연결을 유지하게 된 것이다.)

이러한 커넥션 문제가 생긴 것은 Apache 구조에 따라 발생하게 된 것이다.

아파치 서버는 이러한 수많은 동시 커넥션을 유지하기에 구조적으로 적합하지 않았다. (이후에 이를 보완하기 위해 성능 개선이 지금까지 이어지고 있다.)

NginX 출현

이러한 문제를 해결하기 위해 Apache를 보조의 역할로 처음 나타나게 되었다.

아파치 서버 앞단에 NginX를 둠으로써 문제를 해결할 수 있다. 기존에 유지해야했던 동시 커넥션을 NginX가 대신해서 유지할 수 있게 된다. 또한 NginX 자체가 웹 서버이기 때문에, 정적파일에 대한 요청(HTML, CSS, JS, 이미지, 등)은 스스로 처리가 가능하다. NginX에서는 동적 파일에 대한 요청에 대해서만 Apache 서버에 해당 요청을 전달하게 된다. 이는 Apache에 자원을 Connect에 사용하지 않고 로직에 대한 처리만을 할 수 있도록 돕는다.

구조

위와 같은 구조로 되어 있으며, 이는 OS 커널이 이벤트들을 큐에 담게 된다. 이벤트들은 큐에 담긴 상태에서 워커 프로세스가 수행하기 전까지 비동기 방식으로 대기하게 된다. 이때 워커 프로세스는 하나의 스레드에서 이벤트를 꺼내서 처리하게 된다. 이러한 방식으로 워커 프로세스는 쉬지 않고 계속 일을 할 수 있게 된다. 아파치를 비교했을 때 사용하지 않은 프로세스는 방치되는 방식과 대조적이다.

만약 시간이 오래걸리는 작업이 들어오면, 뒤에 요청은 계속 대기하게 되는가?

이는 threadPool를 만들어두고, 그 이벤트를 수행할 수 있도록 위임하고, 다른 이벤트를 수행하게 된다.

워커 프로세스는 CPU의 코어수 만큼을 생성하게 되므로, 코어가 바뀌는 연산을 대폭 줄일 수 있는데, 이는 CPU의 컨텍스트 스위칭 사용을 줄일 수 있다.

이러한 방식이 Event - dirven model(이벤트 기반 구조)이라고 한다.

• 동시 커넥션 양 최소 10배 증가 (일반적으로 100 ~ 1000배 증가)
• 동일한 커넥션 수일 때 속도가 대폭 향샹
• 프로세스가 적게 생성하기 때문에 가볍고, 이러한 부분은 Master Process에서 동적 설정이 가능

만약 서버에서 새로운 기능이 추가되는 상황이 있을 수 있는데 이때 NginX가 로드벨런서역할을 수행할 수 있는데 이는 요청을 여러 서버로 분산하는 작업을 수행하게 된다. 이때문에 우리가 NginX를 종료하고 새로 시작하는 대신에 계속 연결을 유지할 수 있게 된다. 이런게 가능한 것은 앞전에 얘기했던 Master Process가 새로운 설정에 맞게 Warker Process를 생성하고 기존에 Process의 담긴 작업들이 끝나면 Process를 새로운 Warker Process로 동작하게 한다.

그러나, 단점도 존재하는데 이는 개발자가 기능 추가를 시도했다가 돌아가고 있는 워커 프로세스를 종료하게 되는 상황이 있을 수 있는데, 이때 해당 워커프로세스들이 큐에 담고 관리하고 있던 커넥션과 이벤트를 더 이상 처리할 수 없게 된다. 이에 개발자가 직접 모듈을 개발하기엔 어려움이 존재한다는 단점을 가지고 있다.

이러한 혁신을 가지고 있지만 많이 이용되지 않았다.

인터넷 대중화

2008년쯤 인터넷이 대중화되면서 브라우저도 발전하여 하나의 클라이언트에서 여러개의 커넥션을 동시에 형성하도록 진화하고 각각의 커넥션을 통해 여러개의 요청을 주고 받게 되었다. 이때 대규모의 서비스를 제공하고 있는 큰 회사들의 개발자들이 NginX을 찾게 된다. ( 이때 Apache도 MPMs라는 것을 통해 성능 개선 )

NginX vs Apache

NginX

• 이는 웹 서버 보완 (특히 , C10K 동시 커넥션 문제를 해결하기 위해)
• 그러나 윈도우에서는 제대로된 성능을 발휘하지는 못한다.

이외에도 지원하는 기능

• 웹 서버
• 로드 밸런서
• SSL 터미네이션 - Client와는 https 통신을 하고, server와는 http 통신을 하게 된다. 이를 통해 서버가 복호화하는 과정을 중간에 해독하면서 생략할 수 있게 된다. ( 대체로 NginX와 서버가 같은 네트워크사에 존재한 경우가 많기 때문에 보안적인 문제가 생기지 않는다. )
• 캐싱 - 기존에 서버로 요청해서 응답받은 요청을 저장해둘 수 있다.
• HSTS -Web Site에 접속할 때, 강제적으로 HTTPS Protocol로만 접속하게 하는 기능이다. 즉 HTTPS Protocol을 지원하는 Web Site 에서, 자신은 HTTPS Protocol만 사용해서 통신할 수 있음을, 접속하고자 하는 Web Browser에게 알려 주는 기능입니다. 이를 통해, 보안을 강화시킬 목적으로, Web Browser에게 HTTPS Protocol만 사용하도록 강제하는 기능입니다.
• CORS 처리
• TCP/UDP 커넥션 부하 분산
• HTTP/2 등을 지원

Apache

• 확장성이 좋기 때문에 다양한 모듈을 생성할 수 있고, 호환성이 좋다.
• 다양한 모듈을 제공하고 있다.