웹 공부를 하면서 웹서버와 웹어플리케이션서버에 대해 대략 이런것이다~라는것만 알았지, 구체적인 차이점과 장단점이라던가 왜 WAS를 쓰면서도 WS를 따로 두는 것일까 그 이유에 대해서 제대로 알지 못하고 있었다. 이번 기회에 확실히 하면 좋을 것 같아서 공부하게 되었다.
웹서버(WS)와 웹어플리케이션 서버(WAS)
서버-클라이언트 구조에서 클라이언트는 서버에게 정보를 요청하여 응답받은 결과를 사용하게 되는데, 웹서버와 웹브라우저가 대표적으로 서버-클라이언트 관계이다.
그리고 DBMS가 있다. DBMS는 사용자들이 DB내의 데이터에 접근할 수 있도록 도와주는 소프트웨어이다. DBMS는 보통 서버 형태로 서비스를 제공하기 때문에 클라이언트측에서 DBMS에 접근하여 동작하는 프로그램이 많이 만들어졌다.
하지만 이런 형태는 클라이언트 측에서 로직이 많아지고 프로그램의 크기가 커져 클라이언트 측 부담이 많아진다는 문제점이 있다. 게다가 프로그램은 배포해서 사용되었는데, 로직이 변경될때마다 배포를 새로 해야 했고, 로직이 클라이언트에 포함되어있는 만큼 보안성에도 문제가 있었다.
그래서 미들웨어가 등장했다.
클라이언트와 DBMS사이에 비즈니스 로직을 수행해주는 또 다른 서버를 두는 방식이다.
즉, 클라이언트는 단순히 요청만 이 미들웨어에게 보내고, 미들웨어는 클라이언트가 부담했던 로직을 수행하고, 로직 수행 시 데이터를 조작할 일이 생기면 DBMS에게 부탁한다. 그리고 결과를 다시 클라이언트에게 전송한다.
이로써 클라이언트가 해야했던 복잡한 로직이 사라졌고, 프로그램의 크기도 작아졌으며 프로그램 변경시 마다 배포해야 했던 번거로움을 해결했다.
웹 서버(Web Server)
WS에서는 웹 브라우저같은 클라이언트로부터 HTTP요청을 받아들이고, HTML문서와 같은 웹 페이지를 정적으로 처리해 반환한다. 단순히 저장되어 있는 웹 페이지를 클라이언트로 전달하고, 클라이언트로부터 컨텐츠를 전달받아 저장하거나 처리하는 역할을 담당한다.
뿐만 아니라 인증, 정적 컨텐츠 관리, HTTPS지원, 컨텐츠 압축, 가상 호스팅, 대용량 파일 지원, Bandwidth Throttling(대역폭 제한:인터넷 서비스를 의도적으로 느리게 하는 것) 등의 기능도 지원한다.
아파치 웹 서버, IIS(Internet Information Server, 엔터프라이즈 서버 등이 있다.
www, 임베디드 장치, 근거리 통신망 등에서도 사용된다. 보통 시스템의 모니터링 또는 장치 관리를 위한 목적으로 사용된다. 클라이언트에 추가적인 소프트웨어 설치 없이 대부분의 운영체제에 포함된 웹 브라우저만으로 서비스를 제공할 수 있다.
웹 어플리케이션 서버(Web Application Server)
WAS는 WS와는 가장 큰 차이점으로 동적 서버 콘텐츠를 수행한다. HTTP를 통해 컴퓨터나 장치에 어플리케이션을 수행해주는 미들웨어라고 보면 된다. 웹 서버 + 웹 컨테이너로, 웹 상에서 사용하는 컴포넌트를 올려놓고 사용하게 되는 서버이다. 즉 프로그램 실행 환경과 DB접속기능을 제공하고, 여러 개의 트랜잭션을 관리하며, 요청된 비즈니스 로직을 수행한다.
Tomcat, Web Logic, Jeus, JBoss 등이 있다.
웹 컨테이너 (Web Container)
JSP와 Servlet을 실행시킬 수 있는 소프트웨어로,
웹 서버에서 JSP를 요청하면 톰캣에서 JSP파일을 서블릿으로 변환 후 컴파일을 수행하는 역할을 한다.
자카르타 톰켓(JSP), RESIN, Web Logic, WebtoB 등이 있다.
그렇다고 웹 서버와 웹 어플리케이션 서버는 다른것이냐, 하면 꼭 그런 것은 아니다.
웹 어플리케이션 서버는 기본적으로 웹 서버의 기능을 제공한다. 대중적으로 사용되는 톰캣의 경우를 봐도 웹서버를 따로 설치하지 않고도 사용할 수 있는 이유이기도 하다. 톰캣이 자체적으로 가지고 있는 웹서버가 충분한 기능을 제공하고있기 때문에 굳이 아파치같은 웹서버를 설치하지 않아도 되는 것이다.
그러면 웹서버는 쓸모가 없는 것일까?
웹 어플리케이션 서버에서도 충분히 웹 서버의 기능을 수행할 수 있고, WAS등장 초창기에는 아파치와 톰캣을 같이 설치해서 실행해야 했으나, 요즘은 많이 발전되어 톰캣 자체만으로도 충분한 동작이 가능하니 웹서버는 필요없는 게 아닐까.. 했지만
웹서버가 WAS 앞단에 존재하면 좋은 이유가 있다.
사람들이 많이 접속하는 대용량 WAS인 경우, 서버의 수가 여러 대일 수 있다. 만약 사용 중 WAS에서 문제가 생겨 WAS를 재시작해야 하는 경우가 생긴다. 이 때 재시작하기 위해 앞단의 웹서버에서 WAS를 사용하지 못하도록 요청을 차단한 후 WAS를 재시작한다면, 사용자들은 WAS에 문제가 발생한지 모르고 이용이 가능하다. 이런 처리를 장애극복기능이라 한다.
즉 규모가 커질수록 웹서버와 웹앱서버를 분리하는 것이다.
그리고 자원을 이용함에 있어서 효율성, 배포 및 유지보수 편의성을 위해 대체로 분리하여 둔다.
웹 서비스 구조
즉 다음 구조들을 가질 수 있다.
- Client → WS → DB
- Client → WAS → DB
- Client → WS → WAS → DB
마지막 구조는 아래와 같다.
- 웹서버는 클라이언트로부터 HTTP요청을 받는다.
- 웹서버는 클라이언트의 요청을 WAS로 보낸다.
- WAS는 관련 Servlet을 메모리에 올린다.
- WAS는 web.xml을 참조하여 해당 Servlet에 대한 Thread를 생성한다.
- HttpServletRequest와 HttpServletResponse객체를 생성하여 Servlet에 전달한다
- Thread는 Servlet의 service() method를 호출한다.
- service()메서드는 요청에 맞게 doGet() / doPost()등 method를 호출한다.
- doGet(), doPost() method는 인자에 맞게 생성된 동적 페이지를 Response객체에 담아 WAS에 전달한다.
- WAS는 Response객체를 HttpResponse형태로 바꾸어 웹서버에 전달한다.
- 생성된 Thread를 종료하고, HttpServletRequset와 HttpServletResponse객체를 제거한다.
참고
https://logical-code.tistory.com/30
https://sphere-sryn.tistory.com/entry/Web-Server%EC%99%80-WASWeb-Application-Server%EC%9D%98-%EC%B0%A8%EC%9D%B4-feat-%EB%AF%B8%EB%93%A4%EC%9B%A8%EC%96%B4
