1. Web server
- HTTP 프로토콜 기반으로 동작한다.
- 클라이언트로부터 요청을 받아 정적 파일을 응답해준다.
- Web Application Server(WAS)가 너무 많은 역할을 담당하면 트래픽을 감당하지 못할 수 있다.
- WAS 앞에 Web Server를 둬서 정적 리소스는 Web Server가 처리하도록하고, 애플리케이션 로직 같은 동적인 처리를 WAS한테 요청해서 처리한다. (이를 통해 WAS 장애 발생 시 Web Server에서는 별도의 화면 처리가 가능하다.)
- 대표적으로 Apache와 Nginx가 있다.
2. Apache 동작 구조
- Apache는 Apache 웹 서버는 Process-Driven 방식이다. Apache의 MPM(Multi-Processing Module)은 클라이언트에 요청이 많을 경우 그때마다 새프로세스 또는 스레드를 생성하여 처리한다.
- 동시 접속 요청이 많아지면 그에 해당하는 스레드 생성 비용이 발생하게 되고, 시스템 자원이 고갈 된다는 문제점이 있다.
3. NginX 동작 구조
- Nginx는 Event-Driven 방식을 사용한다.
- Node.js가 대표적으로 이 방식을 사용하고 있는데, 싱글 스레드의 Event Loop가 계속해서 돌아가면서 Event Queue에 요청이 들어오면 Thread Pool에 분배하여 넣어 비동기적으로 처리하도록 한다.
- Apache와 같이 요청이 들어올 때마다 프로세스 & 스레드를 생성하지 않고, N개의 고정된 프로세스로 처리하기 때문에 프로세스 & 스레드에 대한 생성 및 제거 비용이 들지 않는다.
- 많은 요청이 한꺼번에 오더라도 무리 없이 서비스할 수 있다.
[실전 프로젝트에서 NginX 선택한 이유]
NginX는 event-driven의 비동기 구조이므로 채팅 기능이나 RTC기능에서 동시 접속자 수가 증가 할 때를 대비하여 적합한 방식의 웹 서버라고 생각했다. NginX는 이벤트 처리 방식, 비동기식 처리, 논블로킹 방식 처리를 통해 고속으로 처리하는 특징이 있고, 동시 접속자 수가 많아져도 Apache에 비해 메모리 사용률이 낮고, 처리하는 초 당 요청 수가 앞도적으로 높은 모습을 보여준다. 이러한 모습은 메모리를 좀 더 효율적으로 운영할 수 있는 결과를 가지고 온다. 또한 reverse proxy로 서버 확장에 용이하고 보안적으로 뛰어나기 때문에 사용하게 되었다. (웹 서버를 직접 노출 시키지 않고 사용자의 요청을 nginx를 통해 웹 서버로 전달해 주기 때문에 보안적으로 위험성이 적다.)