Nginx - 웹 서버와 WAS

Nginx는 흔히 WEB Server라고 알고 있다.

 

실제로 아래의 Nginx Docs 사이트에 정의된 바에 의하면

 

https://nginx.org/en/

nginx

" 엔진엑스는 HTTP 와 리버스 프록시 서버, 메일 프록시 서버 그리고 TCP/UDP 프록시 서버입니다. " 라고 되어있다

 

여기서 웹서버라는건 알 수 있는데,

 

백엔드 개발자라면 이런 생각을 가질 수 있다.

 

"Nginx 도 웹 서버라고 하고 Springboot 도 한번씩 웹 서버라고 하는것 같은데? 도대체 둘은 무슨차이지?" 라는 생각

 

우선 우리가 흔히 개발하는 웹의 구조를 생각해보자

 

원래는 네트워크 지식까지 포함한다면 아래와 같이 단순화된 구조는 아니다.

 

 

요즘과 같이 프론트 서버 (React 나 Node js 등) 가 존재하지 않았던 세상에서는

 

웹서버라는 개념이 정적 리소스 요청에서는 정적 리소스도 제공하고,

 

서비스로직을 통한 데이터 요청일때에는 해당요청에 응하기 위해서 필요하다면 DB단 까지 사용하여 데이터를 제공하였다.

 

이런 구조의 단점은 웹 서버가 해야 할 일이 너무많다는 것이다.

 

따라서 " 정적파일 처리등의 리퀘스트를 처리하는 서버를 분리하자 " 하여 탄생한 구조는 아래와 같다

 

이제 웹서버는 정적리소스 요청에 대하여 리소스를 제공해주는 역할을 수행하고

 

만약 브라우저(클라이언트)에서의 요청이 서비스 로직이 필요한 요청이다 하면 WAS에게 전달하게 된다.

 

여기서 웹서버와 WAS가 나뉘게 된다.

 

Nginx는 위의 그림에서 웹서버의 역할을 수행하게 되고, WAS는 예를 들자면 스프링부트가 된다.

 

Nginx : HTTP 리버스 프록시 서버

위의 Nginx의 수행역할들 중 주의 깊게 살펴 볼 역할들은

 

HTTP 리버스 프록시 서버라고 볼 수 있다.

 

먼저 리버스 프록시서버가 뭔지 알아보자.

 

리버스 프록시 서버

리버스 프록시서버에 대해 아래의 링크 내용을 요약 해 보면

 

브라우저(클라이언트)에서 어떤 주소로의 요청이 들어가면 인터넷을 거쳐서 

 

해당주소에 대한 리버스 프록시 서버가 요청을 가로채고, 서비스 제공자의 내부망에 있는 알맞은 WAS로 요청을 보내어 

 

응답 데이터를 인터넷을 거쳐 클라이언트에게 제공한다. 

 

리버스 프록시 서버가 있다는것은 즉, 포워드 프록시서버도 있다는 것을 의미할텐데

 

포워드 프록시서버는 리버스 프록시랑 똑같이 요청은 가로채지만

 

반대점으로는 클라이언트단과 같은 네트워크에 속해있다는 점이다.

 

각각의 특징으로

 

포워드 프록시 서버는 클라이언트단과 함께 있어, 인터넷 서버로 가기전 클라이언트의 요청사항을 가로채기 때문에

 

인터넷 사용에 대한 보안이 필요한 상황(회사 내 망)에 유용하게 사용된다.

 

리버스 프록시 서버는 결국 브라우저의 요청이 인터넷을 거쳐서 리버스 프록시 서버에 의해 요청이 가로채지기 때문에

 

SSL 인증을 리버스 프록시 서버에다가 설정해두면 해당 요청은 모두 SSL 인증을 통해서만 데이터가 오고 갈수 있게 된다.

 

그밖에 자세한 내용은

 

https://www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html 를 참고

 

결국 Nginx는 리버스 프록시서버를 지원한다.

 

따라서 Nginx는 서버단에서 클라이언트의 요청을 가로채서 어떤 요청인지 파악하고 

 

요청에 따라 분기되어 정적인 데이터를 보내거나, 필요하다면 WAS로 요청을 흘려보낸다.

 

지금까지 Nginx와 리버스 프록시 서버가 어떤 역할을 수행하는지 알아보았다.

 

마지막으로 웹서버에는 Nginx 뿐만아니라 원래 유명했던 Apache 웹서버가 있는데, 이 둘의 차이점을 확인하자

 

 Nginx vs Apache

Nginx 이전에 원래 Apache재단에 Apache HTTP Server 가 있었다.

 

두 웹서버의 주요 기능차이만 알아보자.

 

https://velog.io/@deannn/Apache%EC%99%80-NginX-%EB%B9%84%EA%B5%90-%EC%B0%A8%EC%9D%B4%EC%A0%90

 

 

Apache HTTP Server는 요청 당 스레드 또는 프로세스가 처리하는 구조로서

 

하나의 요청을 처리하기 위해 자식 프로세스 혹은 스레드가 연결되기 때문에 

 

CPU 로드율이 급상승 할 수도 있다.

 

이러한 단점을 극복하기 위해 Nginx는 이벤트 기반의 웹 서버 구조를 택했다.

 

Nginx 는 하나의 master 프로세스와 하나 혹은 그이상의 worker 프로세스들로 운용된다.

 

만약 Nginx에 Content Cache기능을 켠다면, cache 로더와 메니저 프로세스들도 시작과 동시에 작동한다.

 

master 프로세스의 주 목적은 worker프로세스들을 운영하는것과 설정파일들을 읽는것이다.

 

worker 프로세스들은 실제 요청처리를 수행한다.

 

Nginx는 OS-dependent 메커니즘을 사용하여 효율적으로 worker 프로세스들에게 요청들을 분산시킨다.

 

여기서 OS-dependent 매커니즘이란 다양한 운영체제에 최적화된 방식으로 동작하도록 설계되어있다는 것을 의미한다.

 

즉, 현재 nginx가 running중인 운영체제에 특성을 이용하여 요청을 처리할 worker 프로세스를 효율적으로 선택하고 분산시킨다.

 

따라서 요청마다 Apache처럼 스레드 혹은 프로세스를 만들 필요가 없기에 CPU소모가 적으며

 

적은양의 스레드로 인해 컨텍스트 스위칭 비용이 적다.

 

또한 네트워크 I/O의 경우 Nginx는 모든 I/O작업을 이벤트 리스너로 미루기 때문에 비동기처리를 할 수 있어

 

패킷을 보내고 난 뒤에도 다른작업을 수행할 수 있다.

 

Apache는 Nginx비해서는 좀더 안정성 측면에서도 뛰어나고, 관련 커뮤니티가 예전부터 크게 형성되어있다는 상대적? 장점은 있다고 한다.

 

모듈 이식성에서도 Nginx는 어느정도 정해진 아키텍쳐로 움직여야 하기 때문에 추가 모듈이식이 Apache에 비해 자유롭지 못하다.

 

마지막으로 동적 콘텐츠 처리 측면에서 Apache 는 PHP, Python등의 다양한 언어를 지원하는 모듈이 있기 때문에

 

동적 컨텐츠 처리에 Nginx에 비해 유리하다.

 

여기서 말하는 동적 컨텐츠란 요청이 있을 때 마다 서버에서 동적으로 생성되거나 변경되는 컨텐츠를 말하며

 

사용자의 요청에 따라 DB I/O 등을 통해 서비스로직에 의해 변경되는 콘텐츠가 해당된다.

 

결론

우리가 지금까지 Springboot 로 개발하던것은 엄연히 따지면 WAS를 개발한다는 것이 맞고

 

Nginx가 HTTP 리버스 프록시 서버의 역할을 수행하여 정적컨텐츠를 처리하는 역할을 수행한다는 점

 

Apache와는 달리 이벤트 기반 구조로 작동하여 속도 측면에서 빠르다는점을 이해했다.

 

다음엔 Nginx를 통해 정적파일이나 WAS를 실행시키는 것을 실습해 볼것이다.