Web Server, WAS

Web Server는 정적인 리소스에 해당하는 정보들을 처리해서 클라이언트에게 반환한다. 스프링에서 예를 들면 resource패키지내에 있는 static파일들을 그대로 반환할 때, Web Server가 작동을 한다. 즉,html, css,이미지 파일 처럼 dynamic 하지 않은 파일을 제공할 때, Web Server가 사용이 된다. 그렇다면 dynamic한 경우에는 어떨까?

우리가 일반적으로 사용하는 어플리케이션은 다양한 사용자에게 다양한 기능을 제공한다. 따라서 브라우저에게 제공해야하는 파일 역시 매우 동적일 수 밖에 없다. 이런 동적인 경우에는 WebServer가 WAS(Web Application Server)에게 동적인 요청을 해달라고 요청한다.
브라우저단에서 온 동적인 요청에 따라서 WAS는 DB와의 상호작용,외부 API 요청등을 통해서 브라우저에게 제공할 요청을 생성하고, 이를 브라우저에게 제공한다. 스프링에서는 이러한 was요청을 내장 Tomcat을 통해서 받고, 이를 DispatcherServlet으로 보낸 후, controller단으로 정보를 보내서 브라우저에게 보낼 데이터를 생성한다.

실제 WAS는 위처럼 WS를 포함하고 있는 형태로 지원된다.

왜 구분?

아니 그러면 굳이 어차피 WAS를 거쳐야하는데 왜 구분하는 걸까 라는 생각이 들 수도 있다.

WAS에서 해줘!

그냥 WASS에서 모든 요청을 다 처리한다고 가정해보자.

예를 들어서 정적인 요청 2개와 동적인 요청 3개가 와서 총 5개의 요청이 왔다고 가정해보자.
동적인 요청은 위에서 말했다 싶이, DB와의 상호작용,외부 API 요청등을 이용해서 정보를 생성하므로, 상대적으로 부하가 생길수 밖에 없다. 하지만 WS와 WAS를 구분한다면 정적인 요청은 Web Server에서 처리하기에 Web Container에서는 몰라도 되고, 이는 부하가 생길수 밖에 없는 동적인 요청에서 부담을 덜 수 있을 것이다.

Web Server에서 해줘!

되겠냐고
무수히 많은 요청들에 맞는 html을 만들기란 불가능에 가까울 것이다.

위 두가지 케이스 모두 쉽지 않은 상황이다. 따라서 WAS와 web server를 구분에서 정적인 요청은 ws에서 처리하고, 그 보다 복잡한 동적인 처리는 WAS에서 처리하여, 서로의 기능을 분리한 것이다.

기능을 분리 할 수 있다는 말은 아래와 같이도 구조를 바꿀 수 있다는 말이다

• 요청-> ws->DB
• 요청-> WAS->DB
• 요청 -> WS->WAS-> DB

이것은 본인의 비즈니스로직에 따라서 구조를 선택할 수 있다는 말이고, 마지막의 경우는 로드 밸런싱을 통해서 WAS의 부담을 더욱 덜 수 있을 것이다.