[Spring MVC 1] - 웹 서버, 웹 어플리케이션 서버

Goal

1. 웹 서버 (web server)에 대해 알아본다
2. 웹 어플리케이션 서버(web application server)에 대해 알아본다
3. 웹서버와 was를 분리해야 하는 이유
4. Client > Web Server > WAS > DB 구조 및 동작과정을 알아본다

 

웹 서버와 WAS

 

 웹 서버 (Web Server)란?

클라이언트가 서버에 페이지 HTTP 요청을 하면 요청을 받아 정적 컨텐츠(.html, .png, .css등)를 제공하는 서버이다

 

특징

• 정적 리소스 제공 (정적(파일) HTML, CSS, JS, 이미지, 영상)
• 클라이언트에서 요청이 올 때 가장 앞에서 요청에 대한 처리를 한다.
• was를 거치지 않고 자원 바로 제공
• 어플리케이션 로직같은 동적인 처리가 필요시에는 was에 요청을 위임하고, WAS가 처리해준 컨텐츠를 받은 웹서버는 응답(response)을 해줌
• ex) nginx, apache

 웹  어플리케이션 서버 (Web Application Server)란?

동적 컨텐츠를 제공하기 위해 만들어진 애플리케이션 서버 (DB조회, 비지니스 로직처리가 요구되는 컨텐츠)이다.

HTTP 프로토콜을 기반으로 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로서, 주로 데이터베이스 서버와 같이 수행된다.

 

특징

• 웹 서버 기능 포함 + (정적 리소스 제공 가능) 
  • WAS = Web Server + Web Container
  • 현재는 WAS가 가지고 있는 WebServer도 정적인 컨텐츠를 처리하는데 성능상 큰 차이가 없다
• 동적 HTML, HTML API(JSON)
• JSP, Servlet와 같은 구동환경을 제공해주기 때문에, 서블릿 컨테이너 혹은 웹 컨테이너로 불린다.
• ex) 톰캣 (Tomcat) Jetty, Undertow, Jeus

WAS가 웹 서버의 기능을 가지고 있지만,웹 서버와 WAS를 분리해야 하는 이유 

1. 서버 부하 방지
   • WAS와 웹 서버는 분리하여 서버의 부하를 방지해야 한다
   • WAS는 DB 조회나 다양한 로직을 처리하고, 단순한 정적 컨텐츠는 웹 서버에서 처리해줘야 한다.
   • 만약 정적 컨텐츠까지 WAS가 처리한다면 부하가 커지게 되고, 수행 속도가 느려질 것이다.
   • 따라서 WAS 장애 시 대응할 정적 리소스가 올라갈 웹서버를 나누는 것이 효과적이다
2. 보안 강화
   • SSL에 대한 암호화, 복호화 처리에 웹 서버를 사용 가능
3. 여러 대의 WAS 연결 가능
   • 로드 밸런싱을 위해 웹 서버를 사용할 수 있다.
   • 여러 개의 서버를 사용하는 대용량 웹 어플리케이션의 경우 웹 서버와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다. 
   • 예를 들어, 앞 단의 web server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 인지하지 못하고 이용 가능하다
4. 여러 웹 어플리케이션 서비스 가능
   • 하나의 서버에서 PHP, JAVA 애플리케이션을 함께 사용할 수 있다. 

=> 즉, 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성 을 위해 Web Server와 WAS를 분리한다.
Web Server를 WAS 앞에 두고 필요한 WAS들을 Web Server에 플러그인 형태로 설정하면 더욱 효율적인 분산 처리가 가능하다.

 Web Service Architecture 

• 다양한 구조를 가질 수 있다.
  1. Client -> Web Server -> DB
  2. Client -> WAS -> DB
  3. Client -> Web Server -> WAS -> DB

Client > Web Server > WAS > DB 구조 및 동작과정

1. Web Server는 웹 브라우저 클라이언트로부터 HTTP 요청을 받는다.
2. Web Server는 클라이언트의 요청(Request)을 WAS에 보낸다.
3. WAS는 관련된 Servlet을 메모리에 올린다.
4. WAS는 web.xml을 참조하여 해당 Servlet에 대한 Thread를 생성한다. (Thread Pool 이용)
5. HttpServletRequest와 HttpServletResponse 객체를 생성하여 Servlet에 전달한다.
   • 5-1. Thread는 Servlet의 service() 메서드를 호출한다.
   • 5-2. service() 메서드는 요청에 맞게 doGet() 또는 doPost() 메서드를 호출한다.
   • protected doGet(HttpServletRequest request, HttpServletResponse response)
6. doGet() 또는 doPost() 메서드는 인자에 맞게 생성된 적절한 동적 페이지를 Response 객체에 담아 WAS에 전달한다.
7. WAS는 Response 객체를 HttpResponse 형태로 바꾸어 Web Server에 전달한다.
8. 생성된 Thread를 종료하고, HttpServletRequest와 HttpServletResponse 객체를 제거한다.
   
   

* 톰캣(WAS)에는 아파치(웹서버)의 기능(웹서비스데몬, Httpd)를 포함하고 있다.

- 일반적인 WAS, Web Server 구조가 아닌 걸로 알고 있음.

 

* WAS, Web Server를 따로 두고 쓰는 이유가 성능때문이라고 하는 건 잘못되었다.

톰캣5.5 이상부터는 httpd의 native모듈을 사용해서 정적파일을 처리하는 기능을 제공하는데 이것이 순수 아파치 Httpd만 사용하는 것과 비교해서 성능이 전혀 떨어지지 않기 때문이다.

그럼에도 톰캣앞에 아파치를 두는 이유는 하나의 서버에서 php애플리케이션과 java애플리케이션을 함께 사용하거나, httpd 서버를 간단한 로드밸런싱을 위해서 사용해야 할 때 필요하기 때문.

 

 

 

참고

@ 스프링 MVC 1편 - 백엔드 웹개발 by 김영한

https://jeong-pro.tistory.com/84

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

https://code-lab1.tistory.com/199