본문 바로가기

Development Log/Knowlege

헷갈리는 WS와 WAS

우리가 웹 페이지에 접속하면 일어날까요? 브라우저는 해당 웹 페이지를 표현하기 위해 필요한 정적 파일과 데이터를 웹 서버에 요청합니다. 웹 서버는 적절한 HTML, css, image와 같은 정적 파일 또는 데이터를 반환하고 브라우저는 이를 해석하여 페이지를 표현합니다. 즉, 웹 서버는 페이지에 대한 자원을 가지고 있으며 클라이언트의 요청에 따라 적절한 자원을 찾아서 전달해주는 역할을 합니다.

 

클라이언트와 웹 서버간의 통신

초기의 웹은 이런 간단한 기능으로도 충분했지만, 웹 기술이 진보함에 따라 서버 또한 변화를 꾀했고, 서버 역할을 하면서 응용 프로그램 수준의 기능을 수행할 수 있는 WAS(Web Application Server)가 등장합니다.

WS와 WAS의 비교

사실 둘의 차이는 모호합니다. 인터넷상에 떠도는 많은 포스팅에서는 WS는 정적인 데이터의 서빙, WAS는 동적 데이터의 서빙이라고 구분 짓지만, WS에는 동적 콘텐츠를 생성할 수 있는 스크립팅 언어(ASP,JSP, PHP, Perl)에 대한 플러그인을 지원하기 때문에 WS, WAS 모두 정적/동적 데이터 서빙이 가능합니다. 다만, WAS는 WS의 부하 분산을 위해 고안된 조금 더 고도화된 서버라고 일컫고 있습니다. 그리고 WS, WAS 모두 각각 독립적으로 존재할 수 있으며, WAS는 WS를 포함하고 있습니다.

서버간 대표적인 프레임워크
WS: Apache, NginX, IIS, WebtoB...
WAS: Tomecat, Jeus, WebSphere...

WAS의 동작 방식

WAS는 WS + Web Container로 구성됩니다. 즉, WAS는 WS의 기능을 하면서 Web Container를 추가로 가지고 있습니다. 따라서 클라이언트의 요청은 WS를 통해 받고, DB를 조회하는 등의 비즈니스 로직이 필요하다면 해당 작업을 Web Container로 전달합니다.

💡 Web Container
Java Servlet과 상호작용하는 WAS의 컴포넌트 중 하나입니다. 서블릿의 생명주기를 관리하며, 서블릿과 웹 서버가 통신할 수 있는 인터페이스를 제공합니다. 또한 멀티스레딩을 지원하여 동시에 하나 이상의 처리가 가능합니다. 이는 결과적으로 사용자의 요청에 따라 서버에서 미리 정의해둔 로직을 수행하고 그 결과에 따른 페이지를 호출할 수 있게 해 줍니다. 
WAS별로 다양한 종류의 컨테이너를 내장하고 있으며, 서블릿 컨테이너를 비롯한 JSP 컨테이너, EJB 컨테이너 등이 있습니다.

 

WAS의 구조

 

WS에서 필터 된 작업이 Web Container로 전달되면 아래와 같은 작업이 수행됩니다.

 

WAS 동작 방식

1. 컨테이너는 WS로부터 HttpRequrest를 전달받습니다.

2. 컨테이너는 배포 서술자(web.xml)를 참조하여 해당 서블릿에 대한 스레드를 생성하고, 요청/응답 객체를 생성합니다.

3. 컨테이너는 요청에 맞는 서블릿을 호출합니다.

4. 호출된 서블릿의 작업을 담당하는 스레드는 요청에 따라 doPost() 또는 doGet()을 호출합니다.

5. 4의 결과에 따른 동적 페이지를 응답 객체에 담아 컨테이너로 전달합니다.

6. 5에서 전달받은 응답 객체를 HttpResponse 형태로 변환하여 WS에 전달하고, 생성되었던 스레드, 응답/요청 객체를 삭제합니다.

 

WAS가 WS를 포함하면 이제 WS는 필요 없지 않나?

아닙니다. WAS가 WS를 포함하고 있기 때문에 WAS만으로도 웹 서버를 구축할 수는 있습니다. 그러나, 현재 보편적인 웹 서버 아키텍처는 WS와 WAS를 혼용해서 사용하고 있으며, 많은 개발자들이 이 방식을 권장하고 있습니다. 

보편적인 웹 서비스 아키텍처

처음에 설명했듯이 WAS는 WS의 부하 분산을 위해 고안된 서버입니다. 따라서, WS와 혼용하면서 각각의 용도에 맞게 분배하며 사용해야 합니다. WS는 최전방에 위치하여 클라이언트의 요청을 받고 비즈니스 로직이 포함되지 않는 정적인 파일에 대해서는 WAS 앞에서 즉각적으로 처리해줍니다. 반면에 동적인 페이지에 대한 요청은 WAS로 넘겨 WS는 다음 요청을 처리할 수 있도록 합니다.  

WAS를 조금 더 활용한다면 최전방에 있는 WS에 하나 이상의 WAS를 연결하여 로드 밸런싱할 수도 있습니다. 더불어, WS는 Reverse Proxy 구조를 갖기 때문에 비즈니스 로직이 포함된 WAS를 직접 노출시키지 않음으로써 유연하고 고성능의 서비스를 구축할 수 있습니다.

이렇게 되면 인터넷에 떠도는 많은 포스팅에서 얘기하는 것처럼 WS는 정적 파일을 서빙하고 WAS는 동적 파일을 서빙하는 형태가 됩니다.