Web Server와 WAS(web application server)란?

이번 포스팅에서는 Web Server와 WAS란 무엇인가? 에 대해 알아보려 한다.

 

 

우선 Web Server의 정의부터 알아보자

* Web Server란?

클라이언트로부터 HTTP 요청을 받아 HTML 문서나 각종 리소스(Resource)를 전달하는 컴퓨터

 

즉 어떤 요청을 받았을 때 정적인(static) 데이터를 반환해주는 컴퓨터라고 이해할 수 있다.

 

 

글로만 보면 이해가 안될 수 있기 때문에 위의 그림으로 설명을 해보겠다.

 

나 (= Computer)는 Video1.mp4와 Video2.mp4 그리고 Video3.mp4 이렇게 세 개의 동영상 파일을 가지고 있다. 

A, B, C는 각각 내 친구들이고 인터넷 연결망을 통해 모두가 연결되어 있다고 가정해 보겠다.

 

여기서 A라는 친구가 내 컴퓨터의 Video1.mp4가 보고 싶어서 나에게 보여달라고 요청을 보냈다.

 

요청 (Request) 에는 다음과 같은 정보가 포함되어 있어야한다. 

 

* IP주소

* url

 

IP주소는 내 컴퓨터의 주소이다. A라는 친구가 많은 컴퓨터중에 정확히 내 컴퓨터의 주소를 알고 있어야 나에게 요청을 보낼 수 있기 때문에 A의 요청에는 내 컴퓨터의 주소가 반드시 있어야 한다.

 

URL은 내 컴퓨터를 찾았으면, 내 컴퓨터에서 어떠한 데이터를 필요로 하는지 명시해주어야 한다.

 

따라서 요청은 간략히 표현하면 

Https://~~~(IP주소) / (데이터)

이런식으로 표현된다.

 

위의 컴퓨터와 같은 개념을 Web Server로 이해할 수 있다. 

대표적인 Web Server로 apache가 있다.

 

이제 Web Application Server(WAS)라는 개념을 살펴보자.

* WAS란?

Web Server + Web Container

웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임 워크

 

Web Server는 요청 시에 항상 사전에 정의된, 존재하는 정적인 데이터(html, css, images... 등등)만 반환할 수 있다.

 

즉 A, B, C는 WebServer 요청에서 Video들을 볼 수만 있는 것이지, 해당 데이터를 실시간으로 편집해서 새로 바꾸거나 하는 작업등은 할 수 없다.

이런 일련의 작업들을 클라이언트 입장에서 동적으로(dynamic) 하기 위해서 도입된 개념이라고 보면 된다.

 

자 만약에 url로 java file이 왔다고 해보자.

 

Web Server는 기본적으로 static data만 이해할 수 있기 때문에 해당 자바파일을 실행한 뒤, 그 결과를 정적인 데이터로 변경해주는 작업을 해주는 친구가 필요하다.

 

이를 도식화 하면 다음과 같다.

 

A라는 클라이언트가 WebServer에 java file request를 보냈다고 생각하면, 해당 파일에 대한 제어권을 WAS로 넘긴다.

 

그러면 WAS는 해당 파일을 컴파일한 뒤, 실행하여 그 결과를 Html로 변환, 그리고 다시 Web server가 이해할 수 있는 데이터로 변경해주는 작업을 도와준다.

 

이 WAS의 대표적인 예가 Tomcat이다.

 

근데, 여기서 하나의 의문점이 생길 수 있다.

 

아까 WAS의 정의에서 WAS가 Web server + Web container라면 굳이 따로 Web server 필요 없이 WAS안에서 모든 기능을 해결할 수 있지 않을까요?

 

맞다. 기능적으로 문제는 없다. 하지만 대규모 프로젝트에서는 Web server와 WAS를 분리한다.

 

그 이유는

 

1. WAS도 결국 하나의 서버의 개념이다. WAS에서는 DB 조회, 변경 등 여러 비즈니스 로직을 수행하게 된다. 만약에 web server를 따로 분리하지 않으면 서버의 부하가 발생할 수 있다. 속도면에서도 문제가 있을 수 있다.

 

즉 그냥 정적인 데이터에 대한 요청인데, 이것까지 WAS에서 처리를 하게 되면 WAS의 다른 기능들의 수행에 의해 간단한 요청도 지연될 수 있다.

 

2. WAS에서는 아까 말했듯이 DB에 관한 로직을 처리하게 된다.

만약에 단순하게 Client -> WAS 로 요청이 들어가게 되면 DB에 대한 보안이 한층 약해질 수밖에 없다.

Client -> Web Server -> WAS로 한번 복조화 시키는 것이 보안성 향상에 도움이 된다.

 

3. Load Balancing

만약에 카카x톡과 같은 전 국민이 사용하는 애플리케이션의 WAS가 마비되면 어떻게 될까?

상상하기도 싫은 문제이다. 따라서 보통 큰 프로젝트의 경우 여러 개의 WAS를 운용한다.

 

이렇게 되면 하나의 WAS가 마비되어도 다른 WAS에서 기능 수행을 하기 때문에 무중단 운영에 한층 유리해진다.

 

*저의 글에 대한 피드백이나 지적은 언제나 환영합니다.