WAS (Web Application Server) vs. Web Server

1. 톰캣(Web Application Server, 8080 port) : 

1) 의미 :

웹 서버 + 웹 컨테이너의 결합으로 다양한 역할을 수행한다. 

웹 컨테이너는 클라이언트의 요청이 있을 때 내부 프로그램을 통해 결과를 만들어내고 이것을 다시 클라이언트에게 돌려주는 역할을 한다. 

예를 들어 JSP와 서블릿 처리, 서블릿의 수명 주기 관리, 요청 URL을 서블릿 코드로 매핑, HTTP 요청 수신 및 응답, 필터 체인 관리 등

 

2. 아파치( Web Server, 80 port)

클라이언트의 요청을 기다리고 요청에 대한 데이터를 만들어서 응답하는 역할을 한다. 이때 데이터는 정적인 데이터(html, css 이미지 등으로 ) 한정된다. Nginx도 웹 서버에 해당한다. 

 

3. 아파치와 톰캣의 차이 (= 웹 서버와 웹 애플리케이션 서버의 차이)

웹 서버는 정적인 데이터를 처리하는 서버이다.  이미지나 단순 HTML을 처리하는 서버라면, 웹 서버가 적당하며 빠르고 안정적이다. 

반면, WAS는 동적인 데이터를 처리하는 서버로 DB 연결, 데이터 조작 등과 같은 처리는 WAS를 활용해서 한다.

 

4. 톰캣을 아파치 톰캣이라 부르는 이유?

 톰캣에서 아파치의 기능(웹 서비스 데몬, Httpd)을 포함하고 있기 때문이다. 하지만 아파치의 모든 기능을 포함하진 않음.

 

5. 토비의 스프링 저자 이일민에 의하면 

많은 개발자들이 애플리케이션 서버로 톰캣을 사용하는 경우에 스태틱 파일(css, js, html, 이미지)은 톰캣 앞에 아파치 웹 서버(Httped)를 두어서 처리하게 하는 것이 좋다고 생각한다. 외부 요청은 일단 Apache Httpd가 받고, 톰캣 내에서 처리할 자바 애플리케이션만 톰캣으로 다시 전달해서 처리하고 그 외의 리소스는 Apache Httpd가 직접 처리하게 만들어야 성능이 좋다고 생각한다. 자바로 만든 서버인 톰캣은 스태틱 파일 처리에서 Apache Httpd만 못하다는 것이 그 이유이다.

하지만 톰캣과 Httped의 개발자에 따르면 이는 개발자들이 잘못 알고 있는 미신이다. 아직도 톰캣 3을 사용하고 있는 것이 아니라면 말이다. 톰캣은 5.5부터 Httpd의 native모듈을 사용해서 스태틱 파일을 처리하는 기능을 제공한다. 이 경우 Httpd와 톰캣이 같은 모듈을 사용하는 셈이니 성능에서 차이가 날 이유가 없다. 실제 테스트한 결과를 봐도 톰캣에서 아파치 Native 모듈을 사용하는 것이 순수하게 아파치 Httpd만 사용하는 것과 비교해서 성능이 전혀 떨어지지 않는다. 

 따라서 단지 스태틱 파일 처리의 성능만을 위해서라면 굳이 톰캣 앞에 Apache Httpd를 두는 것은 불필요하다. 오히려 메모리만 많이 먹고 관리부 담은 커지고, 불필요한 부하만 걸릴 뿐이다.

 물론 Httpd의 다른 기능이나 모듈을 사용해야 할 필요가 있다면 그때는 Httpd를 앞에 두고 사용해야겠지만. 

예를 들어 하나의 서버에서 PHP 애플리케이션과 자바 애플리케이션을 함께 사용하거나, Httpd 서버를 간단한 로드밸런싱을 위해서 사용해야 하는 경우라면 Httpd를 앞에 두고 톰캣을 연결해서 사용하도록 하면 될 것이다.

 

6. Nginx vs.  Apache

1) Nginx란?

apache의  C10K 문제점(1만 개의 소켓을 열게 된다면 하드웨어가 충분한데도 불구하고 I/O 처리방식의 문제 때문에 프로세스가 제대로 처리하지 못한다는 것])  해결을 위해 만들어진 Event-Driven 구조의 웹서버이다. OSI7계층에서 applivation Level 아래의 수준에서 Nginx 같은 웹서버가 Http 통신을 담당한다. 

 

2) Apache란?

아파치는 MPM 방식으로 HTTP 요청을 처리한다. 

MPM : Multi-Process Module은 크게 두 가지 방식이 있다. 

 

a. PreFork MPM(다중 프로세스)

 자식 프로세스를 먼저 시작해 놓고, 클라이언트 요청에 대해 각각의 자식 프로세스가 통신을 담당하는 방식이다. 

따라서 자식 프로세스가 어떤 원인으로 정지하더라도 다른 자식 프로세스에 영향을 주지 않는다. 

 

b. Worker MPM(멀티 프로세스 - 스레드)

자식 프로세스에서 멀티 스레드로 실행되며, 클라이언트 요청을 스레드가 처리하는 방식이다. 하나의 프로세스가 멀티 스레드를 이용해 여러 요청을 담당하게 되어 prefork방식과 비교할 때 시작 시 프로세스 수를 줄일 수 있고, 메모리 사용량이 낮으며, 부팅 시간이 빠르다. 

 

c. Apache의 한계 : 

 클라이언트 접속마다 Process 혹은 Thread를 생성하는 구조이다. 1만 클라이언트로부터 동시접속 요청이 들어온다면 CPU와 메모리 사용이 증가하고 추가적인 Process/Tread 생성 비용이 드는 등 대용량 요청에서 한계를 보인다. 게다가, Apache 서버의 프로세스가 blocking 될 때 요청을 처리하지 못하고 처리가 완료될 때까지 대기상태에 있다. 이는 keep Alive(접속 대기)로 해결이 가능하지만, 효율이 떨어진다. 

 

3) 비교

a. Nginx

Nginx는 Event-Driven방식으로 동작한다. 즉, 프로그램 흐름이 이벤트에 의해 결정된다.

한 개 또는 고정된 프로세스만 생성하고, 그 내부에서 비동기적인 효율적인 방식으로 작업을 처리해서 cpu소모가 적다.

또한, Apache와 달리 동시접속자 수가 많아져도 추가적인 생성 비용이 들지 않는다.  구체적으로, Event-Driven방식은 작업을 하다가 I/O, socket read/write 등 CPU가 관여하지 않는 작업이 시작되면 기다리지 않고 바로 다른 작업을 수행한다. 그러다 진행 중인 I/O 등의 작업들이 끝나면 이벤트가 발생하여 그다음 작업을 처리하게 된다. 

반면,  Apache는 Nginx에 비해 모듈이 다양하다. 따라서 안정성, 확장성 호환성을 장점으로 든다. Nginx는 성능이 우세하다는 장점이 있다.

 

⊙ 참조 ⊙

http://www.opennaru.com/jboss/apache-prefork-vs-worker/ 

https://velog.io/@ksso730/Nginx-Apache-%EB%B9%84%EA%B5%90

https://youtu.be/Zimhvf2B7Es reverse proxy(cache), roadbalancing 더 조사