Apache 와 NginX 의 차이점
Apache 서버
1. 커넥션 생성
Apache 서버는 요청이 들어오면 커넥션을 형성하기 위해 프로세스를 생성하여, 새로운 클라이언트의 요청이 들어올 때마다 새로운 프로세스를 생성한다.
2. Prefork 방식 채택
프로세스를 만드는 작업은 시간이 많이 소비되는 작업이기 때문에 요청이 들어오기 전에 미리 프로세스를 만들어 두는 PreFork 방식을 채택하여, 새로운 클라이언트 요청이 들어오면 미리 만들어 놓은 프로세스를 사용하고, 만약 프로세스가 모두 할당되었다면, 추가로 새로운 프로세스를 만들었다.
이러한 구조로 인해 개발하기 쉬운 장점이 있고, 다양한 모듈을 만들어서 서버에 적용하여 확장성 이 좋다.
3. 단점
클라이언트에서 서버로 동시에 연결되는 커넥션이 많아졌을 때 더이상 커넥션이 연결되지 않는 현상 이 발생하였다. (C10K 문제 라고 한다.)
** C10K 문제란?
서버의 초당 요청 처리수 는 서버가 1초당 얼마나 많은 요청을 처리할 수 있는지를 나타내는 지표이고, 동시에 연결된 커넥션 수 는 요청을 처리하기 위해 서버가 클라이언트와 연결된 커넥션 수를 나타내는 지표이다.
한 클라이언트는 하나의 커넥션을 통해서 여러개의 요청을 보낼 수 있고, 하나의 커넥션은 긴 시간동안 유지될 수 있기 때문에 두 지표는 같다고 볼 수 없다.
이 당시에는 각 요청마다 매번 커넥션을 만들기엔 비효율적이었고, 따라서 이미 만들어진 커넥션이 있다면 재활용하자는 생각을 하게된다.
HTTP 프로토콜의 헤더 중 Keep-Alive 가 존재하는데, 이 헤더에 적힌 시간만큼 커넥션을 유지한다.
이렇게 커넥션이 길게 유지되는 상태에서 커넥션 수가 1만단위 로 넘어가는 순간 서버는 새로운 커넥션을 생성하지 못하는 문제 가 발생한다.
하드웨어 문제가 아닌 Apache 서버의 구조적 문제 로 발생하였다.
동시에 처리하는 프로세스가 많아지면 서버의 메모리 부족 으로 이어지며, Apache 의 확장성은 프로세스가 차지하는 리소스 양 을 늘렸으며, 많은 커넥션의 요청이 들어오기 시작하면 CPU 코어가 프로세스를 변경하는 컨텍스트 스위치의 양이 증가하며 CPU의 부하 가 걸리게되었다.
쉽게 이야기해서 Apache 의 구조는 수많은 커넥션을 감당하기에는 부적합한 구조였다.
이러한 문제를 해결하기 위해 생긴 것이 Nginx 서버이다.
Nginx
1. 등장 이유
최초의 Nginx 는 Apache 서버와 함께 사용하기 위해 만들어졌다.
Apache 서버가 감당해야했던 수 많은 커넥션을 Nginx 가 앞단에서 대신해서 유지하도록 하였다.
Nginx 는 그 자체가 웹 서버이기 때문에 정적파일 에 대한 요청을 스스로 해결 할 수 있다.
Apache 는 클라이언트가 동적파일 에 대한 요청을 받았을 때만 커넥션 을 형성한다.
Apahce 서버의 리소스를 커넥션 유지에 사용하지 않고, 개발자가 원하는 로직 처리 를 위해 사용하는 것이다.
2. 동시 커넥션이 가능한 이유
만들어지는 프로세스의 수의 차이에 있다.
Master Process 는 설정 파일을 읽고 해당 내용으로 Worker Process 를 생성하는 프로세스이다.
Worker Process 가 실제로 작업을 하는 프로세스인데, 생성될 때 각자 지정된 Listen Socket 을 지정받는다.
해당 Socket 에 새로운 클라이언트로부터 요청이 들어오면 커넥션을 형성하고 요청을 처리한다. 해당 커넥션은 정해진 Keep-Alive 기간만큼 유지된지만, Worker Process 는 해당 커넥션의 아무런 요청이 없으면 새로운 커넥션을 형성하거나 이미 만들어진 다른 커넥션으로부터 요청을 처리한다.
Nginx 에서는 이러한 커넥션 형성, 커넥션 제거, 새로운 요청을 처리하는 것을 이벤트 라 한다.
이러한 이벤트 들은 OS 커널이 큐 형식 으로 Worker Process 에게 전달되며, 처리될 때까지 비동기 방식 으로 대기한다.
Worker Process 는 하나의 쓰레드로 이벤트를 꺼내서 처리한다.
이러한 구조는 Worker Process 가 계속해서 일을 처리한다는 장점이 있다. (Apache 서버는 요청이 없다면 방치되기 때문에 서버 리소스를 훨씬 효율적으로 사용할 수 있게 된다.)
단, 이러한 이벤트 요청 중 하나가 시간이 오래 소요되는 작업 일 경우에는 요청이 처리되는 시간동안 블로킹 될 것으로 예상되지만, Nginx 는 이러한 상황을 방지하기 위해 시간이 오래 소요되는 작업들을 수행하는 쓰레드 풀 을 만들어서 그곳에서 수행 하도록 한다.
Worker Process 가 처리 중 시간이 오래 소요될 것으로 판단하면, 쓰레드 풀 에 해당 이벤트를 위임하고, 다른 이벤트를 처리한다.
이러한 Worker Process 는 일반적으로 CPU 의 수 만큼 생성한다. 이러면 코어가 담당하는 프로세스의 수를 변경하는 과정을 줄일 수 있다. CPU 가 프로세스를 바꾸는 부가적인 일(컨텍스트 스위칭)을 하지 않아도 되기 때문에 수행능력이 향상된다.
이를 Nginx 의 이벤트 기반 구조라고 한다.
3. 단점
개발자가 기능추가를 시도했다가 돌아가는 Worker Process 를 종료하는 상황이 생길 수 있다.
해당 Worker Process 가 관리하고 있던 커넥션과 요청을 더 이상 처리할 수 없게 된다.
따라서, Nginx 는 개발자가 직접 모듈을 만들기 까다롭다.
4. 장점
- 동시 커넥션 양 최소 10배 증가(일반적으로 100 ~ 1000배 증가)
- 동일한 커넥션 수일 때 속도 2배 향상
- 프로세스를 적게 만들다보니 가볍다.
- 동적 설정 변경
- 프로세스를 적게 만들기 때문에 설정파일을 변경하고 적용하면
Master Process는 설정에 맞는Worker Process를 별도로 생성하고, 기존의Worker Process는 새로운 커넥션을 형성하지 않도록 차단한다. 시간이 지나 기존의Worker Process들의 이벤트가 종료되면 해당 프로세스를 종료한다. - 이러한 동적 변경은 여러 동시 커넥션을 관리하던 중 뒷 단의 서버가 추가되는 상황이 발생할 수 있고, 이때 Nginx 는
로드밸런서의 역할을 담당하게 된다. 요청을 여러 서버로 분산하는 작업을 수행한다. 동적으로 설정파일을 변경할 수 있기 때문에 가능한 방식이다.
5. 추가적인 기능
SSL 터미네이션
Nginx 가 클라이언트와는 HTTPS 로 통신하고, 서버와는 HTTP 로 통신하는 것을 의미한다.
이러한 구조로 서버가 복호화하는 과정을 하지 않도록 할 수 있다.
서버가 비즈니스 로직을 처리할 수 있도록 리소스를 줄여준다.
일반적으로 Nginx 와 서버는 같은 네트워크에 있는 경우가 많기 때문에 http 통신을 해도 보안적 위험이 비교적 적다.
캐싱
HTTP 프로토콜을 통해 전달하는 컨텐츠를 캐싱할 수 있다. 캐싱을 하는 경우에는 클라이언트와 가깝게 배치한다. 한번 서버로 부터 받은 응답을 스스로 보관하고 클라이언트에 전달한다.
ETC
HSTS, CORS 처리, TCP/UDP 커넥션 부하 분산, HTTP/2
Nginx 설정 템플릿
https://github.com/h5bp/server-configs-nginx
참고
