우선 웹 서버(Web Server)와 WAS(Web Application Server)의 차이에 대해서 이해하기 전에 먼저 알아둬야 할 것이 있습니다.
바로 Static 페이지와 Dynamic 페이지입니다.
Static 페이지, Dynamic 페이지
Static 페이지
동적인 작업없이 서버에서 별도의 처리가 없이, 사용자에게 바로 보여주어도 되는 페이지를 말합니다.
즉, static 페이지는 어떠한 사용자가 접근하던 간에 동일한 페이지를 보여주게 됩니다.
EX) html, image, css
Dynamic 페이지
서버에서 어떤 일련의 과정들을 거쳐서 데이터가 변할 수가 있는 페이지입니다. 주로 데이터베이스에서 데이터를 가지고 오는 페이지들이고, 이는 어떤 사용자인지에 따라서 다른 페이지가 보여줄 수 있게 됩니다.
이 둘을 먼저 이해하고 웹 서버(Web Server)와 웹 애플리케이션 서버(WAS)에 대해서 이해해보자. 앞으로 웹 애플리케이션 서버는 WAS로 줄여서 얘기하도록 하겠습니다.
Web Server와 WAS의 차이
Web Server
웹 서버는 위처럼 클라이언트가 요청한 정적인 콘텐츠를 HTTP 프로토콜을 통하여 제공해주는 서버입니다.
위에서 얘기한 Static 페이지를 보내주는 기능을 합니다.
만약 서버와 WAS가 분리되어 있을 경우 동적인 요청을 WAS의 컨테이너로 보내주는 역할도 제공합니다. 여기서 분리되어 있을 경우에 대해서는 뒤에서 자세히 설명하겠습니다.
웹 서버는 따라서 두 가지 기능을 한다고 볼 수 있습니다.
- 정적인 컨텐츠를 제공하고, WAS를 거치지 않고 자원을 바로 전달한다.
- 동적인 컨텐츠를 WAS에 전달하고, WAS가 처리한 결과를 받아서 클라이언트에게 응답 메시지를 전송한다.
EX) Apache, Nginx, IIS
위에서 웹 컨테이너라는 얘기가 나와서 웹 컨테이너에 대한 추가 설명을 드리겠습니다.
웹 컨테이너
웹 컨테이너는 동적인 데이터들을 처리하여 정적인 페이지로 생성해주는 소프트웨어 모듈입니다.
자바의 Servlet과 같은 것을 의미합니다.
웹 컨테이너의 동작 방식
- 클라이언트가 웹 서버로 HTTP 요청 메시지를 보냅니다.
- 웹 서버에서 동적으로 데이터가 변하는 부분이 있으면 이를 WAS에 전달합니다.
- WAS는 내용을 확인하고 처리를 담당하는 서블릿 컨테이너에 있는 서블릿에게 해당 요청을 처리하도록 합니다.
- 서블릿에서 비즈니스 로직을 수행 후 서블릿 컨테이너에 응답 메시지를 반환합니다.
- 컨테이너가 이 응답을 클라이언트에게 전달합니다.
위와 같은 방식으로 웹 컨테이너가 동작하게 됩니다. 이어서 WAS는 무엇인지 살펴보겠습니다.
WAS(Web Application Server)
WAS는 위에서 거듭 애기했듯 웹 서버로부터 오는 동적인 요청을 처리하는 서버입니다. 즉, 웹 서버와 컨테이너를 붙여놓은 서버 입니다.
EX) Tomcat, JBoss, Jeus, Web Sphere 등
WAS가 웹 서버의 역할을 같이 해주기 때문에 이렇게 보면 웹 서버는 필요없어 보입니다. 적은 트래픽이 요구된다면 WAS로도 충분할 수 있지만 WAS로만 운영했을 때의 커다란 문제가 있습니다.
웹 서버가 필요한 이유
WAS가 필요한 이유는 동적인 데이터를 처리해야 하기 때문에 동적인 웹 애플리케이션을 만들게 되면 필수적입니다. 이렇게 동적인 데이터를 처리하는 부분은 상당히 많은 자원을 사용하게 됩니다. 웹 애플리케이션을 처리하는 프로그램의 메모리도 생각을 해주어야 하고, 데이터베이스와의 커넥션 등 비즈니스 로직은 많은 자원들을 사용 해야합니다.
만약 WAS로 하나의 서버를 구성하게 된다면 WAS가 죽었을 때 큰 문제가 발생합니다. 하나의 서버로만 돌렸기 때문에 WAS에서 에러가 발생해서 멈추거나 WAS가 죽는 순간에는 비즈니스 로직을 처리하지 못하는 것도 문제지만 서버의 문제가 있다는 정적 페이지조차 띄우지를 못합니다. 따라서 서로 간의 역할을 확실히 분리하고, 정적 컨텐츠와 동적 컨텐츠를 각자의 서버가 따로 다룸으로써 부하를 줄일 수 있습니다. 또 분리했을 때의 또 커다란 장점이 있습니다.
웹 서버와 WAS를 분리했을 때의 장점
어느 날 정적인 페이지를 다루는 서버의 자원이 부족하다면 정적인 페이지를 다루는 웹 서버의 크기를 증가시키면 되고, 만약 비즈니스 로직을 처리하는 WAS 에서 자원이 부족하다면 WAS의 서버를 증설하면 됩니다.
서로 간의 책임을 분명히 하고 정적인 컨텐츠와 동적인 컨텐츠를 서로가 독립적으로 관리를 하게 되면서 유연한 설계가 가능해진 것입니다.
이 외에도 여러가지 장점이 있습니다.
1. 보안 강화
- SSL에 대한 암복호화 처리를 Web Server를 사용하여 처리한다.
2. 여러 대의 WAS를 연결한다.
- 가용성에 대한 부분입니다. 하나의 WAS가 죽더라도 다른 WAS가 웹 서버에서 요청한 데이터를 처리해주면 되기 때문입니다.
- AWS의 클라우드 서비스 같은 것들은 이러한 고 가용성을 위해 서버가 죽으면 다른 서버로 대체할 수 있도록 지원을 해주고 있습니다. 물론 비용은 지불해야 합니다.
3. 여러 웹 애플리케이션 서비스를 가능하게 해준다.
- 예를 들어서, 유저가 직접 처리해야 하는 API와 운영자 전용 API를 따로 나누어서 운영 할 수도 있습니다. 이런 경우에도 유용합니다.
Apache VS NGINX
Apache와 Apache의 단점을 해결하기 위해 등장한 NGINX 서버에 대해서 살펴보도록 하겠습니다.
NGINX가 물론 Apache의 단점을 해결하기 위해 등장했지만 분명히 둘 간의 장단점도 존재합니다.
Apache
Apache는 거의 모든 OS에서 실행되고, 다른 유명한 소프트웨어 프로젝트와의 문서화가 잘 되어있고 통합 지원 등의 이점이 있으며 개발자가 사용하기에 편리합니다.
Apache는 먼저 프로세스 기반 접근 방식으로 하나의 스레드가 하나의 요청을 처리하는 구조를 하고 있습니다.
이때 중요한 부분은 리눅스 관점에서는 프로세스와 스레드에 대한 처리를 거의 동일시 여기기 때문에 처리하기 위한 하나의 프로세스를 새로 생성하는 것으로 이해해도 무방합니다.
Apache는 클라이언트 요청당 하나의 스레드가 처리하는 구조입니다. 하지만 요청이 들어올 때마다 프로세스를 생성하는 것은 너무 많은 자원을 소모하게 됩니다. 따라서 Apache는 프로세스를 미리 생성해놓는 PreFork 방식을 택하여 그 비용을 줄였습니다.
이 때, 일정량의 생성된 자식 프로세스를 사용하다가 생성한 모든 자식 프로세스가 모두 할당되면 새로이 프로세스를 만들어서 할당해주어서 확장성이 매우 용이했습니다.
그러나 이 부분에서 큰 문제가 발생합니다.
결국 자식 프로세스를 생성하고 기본적으로 프로세스는 메모리를 공유하지 않는 방식을 택하고 있습니다.
이렇기에 여러 사용자가 요청을 하게 되면 그 만큼 독립적으로 처리를 해야하는데, 메모리 소모가 너무 크다는 단점이 발생하게 된 것입니다. 그렇게 1999년에 이르러 컴퓨터를 사용하는 사람이 많아지면서 서버의 트래픽량도 자연스럽게 증가되었습니다.
최종적으로는 트래픽이 너무 많아서 연결된 커넥션이 많아지게 되었을 때 커넥션을 형성하지 못하게 되는 순간이 생겼는데 이를 C10K 문제(Connection 10000 Problem) 이라고 부릅니다.
Apache 서버의 문제점
Apache 서버의 문제점을 정리해보면 다음과 같습니다.
- 커넥션마다 프로세스를 할당하기에 메모리 부족으로 이어집니다.
- 확장성이라는 장점이 오히려 프로세스의 리소스 양을 늘려서 무거운 프로그램을 만들게 됩니다.
- 많은 커넥션에서 요청이 들어오게 되면 CPU 부하가 높아집니다. -> 결국 프로세스이기 때문에 Context Switching 이 발생하고, 쓰레드와는 달리 메모리를 공유하지 않기 때문에 오버헤드가 더 많이 발생한다는 문제점이 있습니다.
수 많은 동시 커넥션을 감당하기에서는 아파치 서버의 구조가 좋지 않았던 것입니다.
NGINX의 등장
이러한 Apache 서버의 문제점을 해결하기 위하여 2004년에 새로운 구조를 채택한 소프트웨어인 NGNIX가 등장하게 됩니다.
초창기에는 아파치 서버와 NGINX는 함께 사용되었습니다. http1.1부터 채택된 keep-Alive로 연결을 유지하더라도 수 많은 동시커넥션을 NGINX 가 유지하면서, 정적 파일에 대한 요청은 NGINX가 해결하고 만약 동적인 파일을 처리해야 하는 경우에만 APACHE를 거쳐서 WAS에 전달하는 형태를 취했습니다.
NGINX
위에서 얘기한 Apache의 C10K 문제를 해결을 하기 위해 만들어진 NGINX는 Event-Driven 구조를 택한 웹 서버 소프트웨어 입니다.
즉 이벤트 기반으로 처리하는 것입니다.
NGINX는 위 처럼 한 개 또는 고정된 프로세스를 생성하고 여러 개의 Connection을 모두 Event-Handler를 통해 비동기 방식으로 처리를 합니다. 이에 관해 더 자세히 살펴보겠습니다.
NGINX가 실행을 하게 되면 마스터 프로세스로서 동작하고, NGINX의 설정 파일을 읽어서 워커 프로세스를 생성하는 형식으로 동작합니다. 설정 파일을 읽어서 생성된 워커 프로세스는 각자 지정된 listen 소켓을 배정받고, 해당 소켓에 클라이언트 요청이 들어오게 되면 커넥션을 형성하고 처리하는 방식입니다.
이러한 커넥션은 정해진 Keep Alive 시간만큼 유지가 되고, 워커 프로세스는 위처럼 하나의 커넥션 만을 담당하지 않고, 연결되어 있는 커넥션에 대해서 아무런 요청이 없으면 새로운 커넥션을 형성하거나 생성되어 있는 다른 커넥션으로 부터 들어온 요청을 처리하게 됩니다.
이러한 이벤트들은 OS 커널이 큐 형식으로 워커 프로세스에 전달하고, 각 이벤트들은 비동기 방식으로 대기하면서 수행됩니다. 또 큐에 담긴 요청 중에 하나가 오래 걸려서 호위 효과가 발생하게 되는 상황이 발생될 수 있는데 NGINX는 이러한 상황을 방지하기 위해 스레드 풀을 만드어 놓고 그 요청은 따로 수행하게 하여 다른 이벤트들의 처리가 지연될 수 있는 상황을 방지합니다.
NGINX는 결국 하나의 프로세스에 스레드가 여러 요청들을 처리하는 형태로 동작하니, 메모리를 공유할 수 있어서 실제로 Context Switching 비용도 줄어들게 되어 성능이 향상된다는 장점이 있습니다.
NGINX의 장점부터 먼저 더 살펴보겠습니다.
NGINX의 장점
NGINX의 장점을 정리해보면 다음과 같습니다.
- 동시 커넥션 양이 최소 10배 증가 (일반적으로 100 ~ 1000배 증가)
- 동일한 커넥션 수일 때 속도가 2배 증가
- 동적인 설정 변경 가능
- 개발자가 설정을 변경하고 난뒤 NGINX에 적용을 하면 기존에 형성되어 있던 워커 프로세스들을 바로 교체하는 것이 아니고, 설정이 변경된 것이 적용된 워커 프로세스들은 새로 생성하고, 기존의 워커 프로세스들은 새로운 요청을 받지 못하게 하면서 처리하는 이벤트가 없어지게 되면 해당 워커 프로세스를 종료시키는 방식으로 설정 변경이 가능합니다.
위의 부분도 장점이지만 개인적으로는 이 부분이 엄청난 장점이라고 생각합니다.
NGINX에서 일정량을 처리하는 도중에 WAS의 자원이 부족하게 되어서 WAS를 추가하게 되면 NGINX는 설정을 변경하고 새로운 워커 프로세스를 생성합니다. 하지만 NGINX는 이 과정에서 하나의 추가적인 역할을 더 하게 되는데, 바로 로드 밸런서의 역할을 담당하게 됩니다.
하지만 이러한 NGINX에도 단점이 존재합니다.
NGINX의 단점
개발자가 직접 모듈을 만들기가 까다롭다는 단점이 있다고 합니다. 아파치와 가장 상반되는 차이라고 볼 수 있습니다.
결론
Apache, Nginx 모두 서버로서는 강력하고 좋습니다. 하지만 사용하고자 하는 본인의 서비스 상태에 따라서 적절한 서버를 택해야 한다고 생각합니다.
Apache와 Nginx를 비교하는 표를 보여드리고 마무리 하겠습니다.
| 구분 | Apache | Nginx |
| 요청 당 프로세스가 처리하는 구조 | 비동기 이벤트 기반으로 처리 | |
| CPU 및 자원 낭비가 심함 | CPU 및 자원 낭비가 적음 | |
| 모듈이 다양하다. | 모듈이 상대적으로 적다. | |
| 안정성, 확장성, 호환성이 좋다. | 확장성은 떨어지지만 성능이 우세하다. |
2022년 기준으로는 nginx가 32.88% apache가 24.25% 정도 사용하고 있다고 합니다.
참고 출처
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-%EC%9B%B9-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%A1%B0-%EC%A0%95%EB%A6%AC
https://ssdragon.tistory.com/60
https://velog.io/@deannn/Apache%EC%99%80-NginX-%EB%B9%84%EA%B5%90-%EC%B0%A8%EC%9D%B4%EC%A0%90
https://sorjfkrh5078.tistory.com/289
'Computer Science > Network' 카테고리의 다른 글
| CORS 작동 방식 시나리오와 해결법 (0) | 2023.05.10 |
|---|---|
| CORS의 개념과 작동방식 (2) | 2023.05.09 |
우선 웹 서버(Web Server)와 WAS(Web Application Server)의 차이에 대해서 이해하기 전에 먼저 알아둬야 할 것이 있습니다.
바로 Static 페이지와 Dynamic 페이지입니다.
Static 페이지, Dynamic 페이지
Static 페이지
동적인 작업없이 서버에서 별도의 처리가 없이, 사용자에게 바로 보여주어도 되는 페이지를 말합니다.
즉, static 페이지는 어떠한 사용자가 접근하던 간에 동일한 페이지를 보여주게 됩니다.
EX) html, image, css
Dynamic 페이지
서버에서 어떤 일련의 과정들을 거쳐서 데이터가 변할 수가 있는 페이지입니다. 주로 데이터베이스에서 데이터를 가지고 오는 페이지들이고, 이는 어떤 사용자인지에 따라서 다른 페이지가 보여줄 수 있게 됩니다.
이 둘을 먼저 이해하고 웹 서버(Web Server)와 웹 애플리케이션 서버(WAS)에 대해서 이해해보자. 앞으로 웹 애플리케이션 서버는 WAS로 줄여서 얘기하도록 하겠습니다.
Web Server와 WAS의 차이
Web Server
웹 서버는 위처럼 클라이언트가 요청한 정적인 콘텐츠를 HTTP 프로토콜을 통하여 제공해주는 서버입니다.
위에서 얘기한 Static 페이지를 보내주는 기능을 합니다.
만약 서버와 WAS가 분리되어 있을 경우 동적인 요청을 WAS의 컨테이너로 보내주는 역할도 제공합니다. 여기서 분리되어 있을 경우에 대해서는 뒤에서 자세히 설명하겠습니다.
웹 서버는 따라서 두 가지 기능을 한다고 볼 수 있습니다.
- 정적인 컨텐츠를 제공하고, WAS를 거치지 않고 자원을 바로 전달한다.
- 동적인 컨텐츠를 WAS에 전달하고, WAS가 처리한 결과를 받아서 클라이언트에게 응답 메시지를 전송한다.
EX) Apache, Nginx, IIS
위에서 웹 컨테이너라는 얘기가 나와서 웹 컨테이너에 대한 추가 설명을 드리겠습니다.
웹 컨테이너
웹 컨테이너는 동적인 데이터들을 처리하여 정적인 페이지로 생성해주는 소프트웨어 모듈입니다.
자바의 Servlet과 같은 것을 의미합니다.
웹 컨테이너의 동작 방식
- 클라이언트가 웹 서버로 HTTP 요청 메시지를 보냅니다.
- 웹 서버에서 동적으로 데이터가 변하는 부분이 있으면 이를 WAS에 전달합니다.
- WAS는 내용을 확인하고 처리를 담당하는 서블릿 컨테이너에 있는 서블릿에게 해당 요청을 처리하도록 합니다.
- 서블릿에서 비즈니스 로직을 수행 후 서블릿 컨테이너에 응답 메시지를 반환합니다.
- 컨테이너가 이 응답을 클라이언트에게 전달합니다.
위와 같은 방식으로 웹 컨테이너가 동작하게 됩니다. 이어서 WAS는 무엇인지 살펴보겠습니다.
WAS(Web Application Server)
WAS는 위에서 거듭 애기했듯 웹 서버로부터 오는 동적인 요청을 처리하는 서버입니다. 즉, 웹 서버와 컨테이너를 붙여놓은 서버 입니다.
EX) Tomcat, JBoss, Jeus, Web Sphere 등
WAS가 웹 서버의 역할을 같이 해주기 때문에 이렇게 보면 웹 서버는 필요없어 보입니다. 적은 트래픽이 요구된다면 WAS로도 충분할 수 있지만 WAS로만 운영했을 때의 커다란 문제가 있습니다.
웹 서버가 필요한 이유
WAS가 필요한 이유는 동적인 데이터를 처리해야 하기 때문에 동적인 웹 애플리케이션을 만들게 되면 필수적입니다. 이렇게 동적인 데이터를 처리하는 부분은 상당히 많은 자원을 사용하게 됩니다. 웹 애플리케이션을 처리하는 프로그램의 메모리도 생각을 해주어야 하고, 데이터베이스와의 커넥션 등 비즈니스 로직은 많은 자원들을 사용 해야합니다.
만약 WAS로 하나의 서버를 구성하게 된다면 WAS가 죽었을 때 큰 문제가 발생합니다. 하나의 서버로만 돌렸기 때문에 WAS에서 에러가 발생해서 멈추거나 WAS가 죽는 순간에는 비즈니스 로직을 처리하지 못하는 것도 문제지만 서버의 문제가 있다는 정적 페이지조차 띄우지를 못합니다. 따라서 서로 간의 역할을 확실히 분리하고, 정적 컨텐츠와 동적 컨텐츠를 각자의 서버가 따로 다룸으로써 부하를 줄일 수 있습니다. 또 분리했을 때의 또 커다란 장점이 있습니다.
웹 서버와 WAS를 분리했을 때의 장점
어느 날 정적인 페이지를 다루는 서버의 자원이 부족하다면 정적인 페이지를 다루는 웹 서버의 크기를 증가시키면 되고, 만약 비즈니스 로직을 처리하는 WAS 에서 자원이 부족하다면 WAS의 서버를 증설하면 됩니다.
서로 간의 책임을 분명히 하고 정적인 컨텐츠와 동적인 컨텐츠를 서로가 독립적으로 관리를 하게 되면서 유연한 설계가 가능해진 것입니다.
이 외에도 여러가지 장점이 있습니다.
1. 보안 강화
- SSL에 대한 암복호화 처리를 Web Server를 사용하여 처리한다.
2. 여러 대의 WAS를 연결한다.
- 가용성에 대한 부분입니다. 하나의 WAS가 죽더라도 다른 WAS가 웹 서버에서 요청한 데이터를 처리해주면 되기 때문입니다.
- AWS의 클라우드 서비스 같은 것들은 이러한 고 가용성을 위해 서버가 죽으면 다른 서버로 대체할 수 있도록 지원을 해주고 있습니다. 물론 비용은 지불해야 합니다.
3. 여러 웹 애플리케이션 서비스를 가능하게 해준다.
- 예를 들어서, 유저가 직접 처리해야 하는 API와 운영자 전용 API를 따로 나누어서 운영 할 수도 있습니다. 이런 경우에도 유용합니다.
Apache VS NGINX
Apache와 Apache의 단점을 해결하기 위해 등장한 NGINX 서버에 대해서 살펴보도록 하겠습니다.
NGINX가 물론 Apache의 단점을 해결하기 위해 등장했지만 분명히 둘 간의 장단점도 존재합니다.
Apache
Apache는 거의 모든 OS에서 실행되고, 다른 유명한 소프트웨어 프로젝트와의 문서화가 잘 되어있고 통합 지원 등의 이점이 있으며 개발자가 사용하기에 편리합니다.
Apache는 먼저 프로세스 기반 접근 방식으로 하나의 스레드가 하나의 요청을 처리하는 구조를 하고 있습니다.
이때 중요한 부분은 리눅스 관점에서는 프로세스와 스레드에 대한 처리를 거의 동일시 여기기 때문에 처리하기 위한 하나의 프로세스를 새로 생성하는 것으로 이해해도 무방합니다.
Apache는 클라이언트 요청당 하나의 스레드가 처리하는 구조입니다. 하지만 요청이 들어올 때마다 프로세스를 생성하는 것은 너무 많은 자원을 소모하게 됩니다. 따라서 Apache는 프로세스를 미리 생성해놓는 PreFork 방식을 택하여 그 비용을 줄였습니다.
이 때, 일정량의 생성된 자식 프로세스를 사용하다가 생성한 모든 자식 프로세스가 모두 할당되면 새로이 프로세스를 만들어서 할당해주어서 확장성이 매우 용이했습니다.
그러나 이 부분에서 큰 문제가 발생합니다.
결국 자식 프로세스를 생성하고 기본적으로 프로세스는 메모리를 공유하지 않는 방식을 택하고 있습니다.
이렇기에 여러 사용자가 요청을 하게 되면 그 만큼 독립적으로 처리를 해야하는데, 메모리 소모가 너무 크다는 단점이 발생하게 된 것입니다. 그렇게 1999년에 이르러 컴퓨터를 사용하는 사람이 많아지면서 서버의 트래픽량도 자연스럽게 증가되었습니다.
최종적으로는 트래픽이 너무 많아서 연결된 커넥션이 많아지게 되었을 때 커넥션을 형성하지 못하게 되는 순간이 생겼는데 이를 C10K 문제(Connection 10000 Problem) 이라고 부릅니다.
Apache 서버의 문제점
Apache 서버의 문제점을 정리해보면 다음과 같습니다.
- 커넥션마다 프로세스를 할당하기에 메모리 부족으로 이어집니다.
- 확장성이라는 장점이 오히려 프로세스의 리소스 양을 늘려서 무거운 프로그램을 만들게 됩니다.
- 많은 커넥션에서 요청이 들어오게 되면 CPU 부하가 높아집니다. -> 결국 프로세스이기 때문에 Context Switching 이 발생하고, 쓰레드와는 달리 메모리를 공유하지 않기 때문에 오버헤드가 더 많이 발생한다는 문제점이 있습니다.
수 많은 동시 커넥션을 감당하기에서는 아파치 서버의 구조가 좋지 않았던 것입니다.
NGINX의 등장
이러한 Apache 서버의 문제점을 해결하기 위하여 2004년에 새로운 구조를 채택한 소프트웨어인 NGNIX가 등장하게 됩니다.
초창기에는 아파치 서버와 NGINX는 함께 사용되었습니다. http1.1부터 채택된 keep-Alive로 연결을 유지하더라도 수 많은 동시커넥션을 NGINX 가 유지하면서, 정적 파일에 대한 요청은 NGINX가 해결하고 만약 동적인 파일을 처리해야 하는 경우에만 APACHE를 거쳐서 WAS에 전달하는 형태를 취했습니다.
NGINX
위에서 얘기한 Apache의 C10K 문제를 해결을 하기 위해 만들어진 NGINX는 Event-Driven 구조를 택한 웹 서버 소프트웨어 입니다.
즉 이벤트 기반으로 처리하는 것입니다.
NGINX는 위 처럼 한 개 또는 고정된 프로세스를 생성하고 여러 개의 Connection을 모두 Event-Handler를 통해 비동기 방식으로 처리를 합니다. 이에 관해 더 자세히 살펴보겠습니다.
NGINX가 실행을 하게 되면 마스터 프로세스로서 동작하고, NGINX의 설정 파일을 읽어서 워커 프로세스를 생성하는 형식으로 동작합니다. 설정 파일을 읽어서 생성된 워커 프로세스는 각자 지정된 listen 소켓을 배정받고, 해당 소켓에 클라이언트 요청이 들어오게 되면 커넥션을 형성하고 처리하는 방식입니다.
이러한 커넥션은 정해진 Keep Alive 시간만큼 유지가 되고, 워커 프로세스는 위처럼 하나의 커넥션 만을 담당하지 않고, 연결되어 있는 커넥션에 대해서 아무런 요청이 없으면 새로운 커넥션을 형성하거나 생성되어 있는 다른 커넥션으로 부터 들어온 요청을 처리하게 됩니다.
이러한 이벤트들은 OS 커널이 큐 형식으로 워커 프로세스에 전달하고, 각 이벤트들은 비동기 방식으로 대기하면서 수행됩니다. 또 큐에 담긴 요청 중에 하나가 오래 걸려서 호위 효과가 발생하게 되는 상황이 발생될 수 있는데 NGINX는 이러한 상황을 방지하기 위해 스레드 풀을 만드어 놓고 그 요청은 따로 수행하게 하여 다른 이벤트들의 처리가 지연될 수 있는 상황을 방지합니다.
NGINX는 결국 하나의 프로세스에 스레드가 여러 요청들을 처리하는 형태로 동작하니, 메모리를 공유할 수 있어서 실제로 Context Switching 비용도 줄어들게 되어 성능이 향상된다는 장점이 있습니다.
NGINX의 장점부터 먼저 더 살펴보겠습니다.
NGINX의 장점
NGINX의 장점을 정리해보면 다음과 같습니다.
- 동시 커넥션 양이 최소 10배 증가 (일반적으로 100 ~ 1000배 증가)
- 동일한 커넥션 수일 때 속도가 2배 증가
- 동적인 설정 변경 가능
- 개발자가 설정을 변경하고 난뒤 NGINX에 적용을 하면 기존에 형성되어 있던 워커 프로세스들을 바로 교체하는 것이 아니고, 설정이 변경된 것이 적용된 워커 프로세스들은 새로 생성하고, 기존의 워커 프로세스들은 새로운 요청을 받지 못하게 하면서 처리하는 이벤트가 없어지게 되면 해당 워커 프로세스를 종료시키는 방식으로 설정 변경이 가능합니다.
위의 부분도 장점이지만 개인적으로는 이 부분이 엄청난 장점이라고 생각합니다.
NGINX에서 일정량을 처리하는 도중에 WAS의 자원이 부족하게 되어서 WAS를 추가하게 되면 NGINX는 설정을 변경하고 새로운 워커 프로세스를 생성합니다. 하지만 NGINX는 이 과정에서 하나의 추가적인 역할을 더 하게 되는데, 바로 로드 밸런서의 역할을 담당하게 됩니다.
하지만 이러한 NGINX에도 단점이 존재합니다.
NGINX의 단점
개발자가 직접 모듈을 만들기가 까다롭다는 단점이 있다고 합니다. 아파치와 가장 상반되는 차이라고 볼 수 있습니다.
결론
Apache, Nginx 모두 서버로서는 강력하고 좋습니다. 하지만 사용하고자 하는 본인의 서비스 상태에 따라서 적절한 서버를 택해야 한다고 생각합니다.
Apache와 Nginx를 비교하는 표를 보여드리고 마무리 하겠습니다.
| 구분 | Apache | Nginx |
| 요청 당 프로세스가 처리하는 구조 | 비동기 이벤트 기반으로 처리 | |
| CPU 및 자원 낭비가 심함 | CPU 및 자원 낭비가 적음 | |
| 모듈이 다양하다. | 모듈이 상대적으로 적다. | |
| 안정성, 확장성, 호환성이 좋다. | 확장성은 떨어지지만 성능이 우세하다. |
2022년 기준으로는 nginx가 32.88% apache가 24.25% 정도 사용하고 있다고 합니다.
참고 출처
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-%EC%9B%B9-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%A1%B0-%EC%A0%95%EB%A6%AC
https://ssdragon.tistory.com/60
https://velog.io/@deannn/Apache%EC%99%80-NginX-%EB%B9%84%EA%B5%90-%EC%B0%A8%EC%9D%B4%EC%A0%90
https://sorjfkrh5078.tistory.com/289
'Computer Science > Network' 카테고리의 다른 글
| CORS 작동 방식 시나리오와 해결법 (0) | 2023.05.10 |
|---|---|
| CORS의 개념과 작동방식 (2) | 2023.05.09 |
