🧐 서론
나는 지금까지 Apache를 통한 웹 서버를 사용했었다.
그러나 주변에서 Ngnix를 웹 서버로 많이 사용한다는 이야기를 들었다.
나는 일반적으로 Apache를 웹 서버로 사용한다길래 별다른 이유 없이 그동안 사용을 했었다.
그렇기에 Apache가 내부적으로 어떻게 동작하는지, 특징이 무엇이고 장점은 무엇인지에 대해서 무지한 상태로 사용했었다.
이 때 둘의 특징과 장, 단점은 무엇이고 요즈음에는 왜 Ngnix를 웹 서버로 많이 사용하는지에 대해서 알아보고자 한다.
😉 본론
웹 서버
Apache와 Ngnix는 같은 웹 서버이다.
웹 서버를 쉽게 생각하면 클라이언트 요청(HTTP Request)을 WAS(Tomcat)에게 핸들링 하고, WAS에서 동적인 작업을 진행한 후 결과를 다시 클라이언트에게 응답(HTTP Response) 하는 역할을 한다.
나는 이를 음식점 홀 서버로 생각을 하였다.
- 음식점 홀 서버는 고객의 요청 사항을 그대로 주방장에게 전달한다.
- 주방장은 요청 사항에 맞게 음식을 정성껏 만들어 다시 홀 서버에게 전달한다.
- 홀 서버는 고객에게 음식을 전달한다.
음식점 홀 서버는 “Web Server”, 주방장은 “WAS”, 고객은 “Client”를 의미한다.
이는 위에 있는 과정을 예시로 든 것이다.
차이점에 대해서 알아보기 전에 추가적으로 Web Server에 대해서 알아야 하는 것에는 Proxy Server가 있다.
Proxy Server
Proxy Server란 클라이언트와 서버 사이의 중계 서버를 의미한다.
이 Proxy Server를 통해서 캐시, SSL HTTPS 적용, 트래픽 분산(Load Balancing)을 할 수 있다.
이러한 Proxy Server에는 Forward Proxy와 Reverse Proxy의 개념이 있다.
Forward Proxy
먼저 Forward Proxy를 이야기 해보자.
Foward Proxy와 Reverse Proxy의 구분 기준은 위치이다.
Foward Proxy는 Client - Foward Proxy - Internet - Server로 Client 단에 붙어 있다.
이는 서버 개발자는 관여하지 않는 위치이며, Internet Service Provider에서 Forward Proxy 역할을 하기도 한다.
이는 SK, KT, LG와 같은 ISP(Internet Service Provider)에서 캐싱, HTTPS 적용, 트래픽 분산등을 해줄 수 있다는 의미이다.
Reverse Proxy
Reverse Proxy 의 위치는 Client - Internet - Reverse Proxy - Server로 WAS 앞에 존재한다.
Reverse Proxy를 도입 할 경우에는 이러한 위치에서 도입할 수 있는 기술(캐싱, LB, HTTPS등)들이 이점으로 작용할 수 있다.
또한 Client에게 WAS의 실제 IP를 숨길 수 있다.
이 때 Client는 Reverse Proxy가 실제 Server라고 생각하고 접근하게 된다.
웹 서버에 대해서 기본적으로 이해 하였으니, 각자 웹 서버로서의 차이점에 대해서 이야기를 해보겠다.
🤪 Apache
이미지 출처 : https://velog.io/@moonyoung/Nginx와-Apache
Apache는 MPM(Multi Process Modules)이라 하는 처리 모듈이 있다.
이는 Apache 서버가 클라이언트에게서 받아들인 요청을 처리하기 위해 자식 프로세스들에게 분배하는 모듈을 칭한다.
MPM은 세부적으로 Prefork, Worker, Event로 아키텍쳐가 나눠진다.
Prefork 방식
Prefork은 하나의 자식 프로세스가 하나의 스레드를 갖는 구조(Single Thread)로, 자식 프로세스는 최대 1024개까지 가능하다.
즉 하나의 요청이 하나의 프로세스를 차지하는 방식이며, 그 프로세스 안에는 하나의 Thread가 있다.
Thread Pool과 비슷한 개념으로 여분의 Child Process를 미리 만들어서(Prefork) 요청이 들어올 때 새로 만들지 않도록 동작한다.
이 방식은 높은 성능이 필요할 때 사용하며, 하나의 프로세스가 정지해도 다른 프로세스에게 영향을 주지 않는다는 특징을 가지고 있다.
Worker 방식
Worker 방식은 하나의 자식 프로세스가 여러개의 스레드를 갖는 구조(Multi Thread)로 최대 64개의 스레드 처리가 가능하다.
이는 자식 프로세스들이 각각 여러 스레드를 사용하며, 각 스레드는 한번에 한 연결을 담당하다.
즉 하나의 요청이 하나의 스레드를 차지하는 방식이다.
이러한 멀티 스레드의 특징에 맞게 일반적으로 멀티 CPU 시스템에서 성능이 좋으며, 이에 따라 통신량이 많은 서버에서 적절한 형태를 지닌다.
Event 방식
후술할 Ngnix에서는 Event Driven 방식으로 유명세를 얻었는데, Apache는 그동안 Event 방식을 지원하지 않았었다.
Apache는 Event 방식을 도입하기 이전까지 한 개의 동접 클라이언트당 한 개의 프로세스 or 스레드 구조였다.
이로 인해서 클라이언트의 요청이 끝나지 않는 한 요청을 받은 프로세스 or 스레드가 죽지 않는(Keep Alive) 방식을 사용했다.
한정된 프로세스 or 스레드를 운용할 수 밖에 없는 입장에서 대량 접속에서는 효율이 급격히 떨어지는 문제점이 있었다.
이러한 문제를 해결하기 위해서 Apache는 2.4 버젼부터 Event MPM을 사용할 수있게 되었고, 이는 Ngnix를 이야기하며 자세히 이야기 할 Event-driven 방식과 유사하다.
🥸 Ngnix
이미지 출처 : https://velog.io/@moonyoung/Nginx와-Apache
Ngnix는 비동기 Event-Driven 기반의 구조이다.
스레드 기반은 하나의 커넥션 당 하나의 스레드를 생성하지만, Event-Driven 구조는 여러 커넥션을 Event Handler에서 비동기 방식으로 처리하여 먼저 처리되는 것부터 진행된다.
Ngnix는 하나의 Master 프로세스와 다수의 Worker 프로세스로 구성되어 실행된다.
Master 프로세스는 설정 파일을 읽고, 유효성을 검사하고 Worker 프로세스를 관리한다.
즉 모든 요청은 사실상 Worker 프로세스에서 처리한다.
Nginx는 Event-Driven 기반 모델을 사용하고 이를 통해 들어오는 Request를 Worker 프로세스들에게 효율적으로 분배하기 위해 OS에 의존적인 매커니즘을 사용한다.
Worker Process의 개수는 설정 파일에서 정의되며, 정의된 프로세스 개수와 사용 가능한 CPU 코어 숫자에 맞게 자동으로 조정된다.
이러한 흐름을 아래와 같이 정의할 수 있다.
Ngnix는 미리 Thread Pool에 Thread를 생성한다.
그 후 Client로부터 요청이 들어올 때 Worker Process가 해당 요청을 Request Queue에 저장을 한다.
그러면 Thread Pool에서 사용 가능한 Thread가 해당 Request Queue에서 작업을 가져와서 처리를 한다.
Event-Driven
Ngnix는 Event Driven 특성을 가지고 있어서 Event Loop 기반으로 요청에 대한 작업을 처리한다.
이는 TCP나 UDP Connection의 연결, 유저의 HTTP Request 처리, Connection 종료까지의 모든 절차를 Event라는 개념으로 취급하고 처리한다.
그리고 위에서 다뤘던 것처럼 이러한 Event의 요청들을 Worker 프로세스가 처리하게 된다.
🫠 Apache vs Ngnix
이러한 글의 흐름을 보면 Ngnix를 찬양하고, Apache를 까는(?) 듯한 글이 될 것 같지만 Apache도 장점이 많다.
Apache의 장점
- OS 안전성
Apache는 윈도우 환경에서도 Unix 계열의 환경에서와 동일한 성능을 보장한다. 그러나 Ngnix는 윈도우 환경을 완벽하게 지원하지 않는다.
- 디렉토리 별 추가 구성
.htaccess 파일을 통해서 디렉토리 별로 추가 서버 구성을 하는 것을 허용한다.
이를 이용하면 특정 페이지만 관리할 수 있게 하는 관리자 권한을 만들 수 있고, 각 디렉토리 별로 환경 설정을 따로 구성할 수도 있다.
Ngnix에서는 성능을 위해서 추가 구성을 허용하지 않는다.
- 동적 모듈의 지원
Apache는 Apache에서 지원하는 모듈에 대해서 오버라이딩을 허용한다.
이를 통해 개발자가 서버 구성에 대해 자유롭게 커스텀을 할 수 있다.
Ngnix에서는 개발자가 자유롭게 커스텀을 하기 제약이 있다고 한다.
Ngnix의 장점
- 같은 자원으로 처리할 수 있는 Connection의 수가 많다.
이는 Event-Driven 구조를 통해 가질 수 있는 장점이라고 할 수 있다.
처리할 수 있는 Connection의 수가 많은 이유는 위에서도 많이 서술했기에 별도로 기술하지는 않겠다.
- 동적으로 서버의 설정을 변경할 수 있다.
일반적으로는 서버가 이미 동작 중일 때 서버의 설정을 변경하고 이를 적용 시키고자 한다면 재 기동을 해야 한다.
그러나 Ngnix는 Event-Driven이라는 구조를 통해 서버가 동작 중일 때도 동적으로 설정을 변경할 수 있다.
이게 가능한 원리는 설정 파일 변경 후 service reload시에 Master 프로세스는 새로운 설정 파일을 읽어서 새로운 Worker 프로세스를 생성한다.
그리고 기존 동작하던 Worker 프로세스에게는 새롭게 이벤트를 할당하지 않고, 하고 있던 작업이 모두 종료되면 기존 Worker 프로세스는 종료된다.
그리고 새로운 Worker 프로세스들에게 이벤트가 전달된다.
