Web Server와 Web Application Server(WAS)

1. 동적 웹페이지의 탄생 배경과 역사

초창기 웹이 출현했을때는 정적(Static)인 웹 페이지들이 많았고 그것들만으로도 충분했다.
 
하지만 정적 웹 페이지의 모든 내용은 정해져있었기 때문에 각각의 사용자의 요구를 맞출 수 없었고 이로 인해 동적(Dynamic)인 웹페이지를 필요로 하게 되었다.
 
그래서 등장한 것이 CGI(Common Gateway Interface)였다.
CGI는 프로그래밍 언어나 스크립트는 아니었고, 서버에서 수행중인 일반 프로세스 사이에서 정보를 주고 받는 규칙을 의미했다.
CGI는 Perl, C, C++등의 언어를 지원하면서 1) 웹 서버를 통해 요청을 받고 2) 실행 결과를 다시 웹 서버를 거쳐 클라이언트의 브라우저로 보낼 수 있는 기능을 가지고 있다.

 
하지만 CGI 방식의 근본적인 문제점이 존재했다.
각각의 클라이언트 요청에 대하여 독립적인 별도의 프로세스가 생성된다는 점이었다.

 
프로세스가 많아질수록 시스템에 많은 부하가 걸리게 되고, 이러한 경우 웹 서버는 똑같은 요청이라 할지라도 웹 브라우저에서 받은 요청 갯수만큼 동일한 시간에 같은 프로세스를 생성한다.
이는 프로세스가 많아질수록 서버의 메모리를 점유하기 때문에 비효율적이며, 또 다른 문제점으로는 OS에 종속되어 개발이 어렵고 유지보수가 어렵다는 점이었다.

 

---

CGI의 대안으로 나온 것들 중 하나가 스크립트 엔진을 활용한 방법이었다.

 
스크립트 엔진을 활용한 방식은 다수의 웹 브라우저가 같은 요청을 하더라도 스크립트에 대한 프로세스 하나만 수행하고, 각 웹 요청에 대해서 쓰레드(Thread)로서 처리하는 방식이었다.
즉, 실제 프로그램 수행은 프로세스를 생성하여 메모리에 띄워놓고 각 요청에 대한 쓰레드를 새로 생성하여 프로세스를 한번씩 지나게 하여 원하는 응답을 얻어내는 기법을 활용하는 것이었다.
 

 
이러한 방식은 CGI 방식에 비하여 CPU 점유도나 메모리 점유율에 있어 상당히 효율적이었고,
이는 곧 안정적인 웹 서비스를 제공할 수 있는 기반인 웹 어플리케이션 서버(WAS, Web Application Server)로 발전하였다.

---

2. Web Server vs WAS

 
요약하자면 WAS는 기존의 정적인 페이지만 제공할 수 있었던 Web Server가
비즈니스 로직을 동반하는 동적인 컨텐츠까지 제공할 수 있도록 도와주는 것이다!
 

---

3. Web Server

클라이언트가 어떠한 페이지에 대한 요청을 하면 웹 서버에서 그 요청을 받아 정적 컨텐츠를 제공하는 서버를 의미.
 
여기서 정적 컨텐츠란 단순 HTML문서, CSS, JavaScript, 이미지, 파일등 즉시 응답 가능한 컨텐츠를 의미.
 
동적인 컨텐츠 제공을 위해 WAS로 클라이언트의 요청을 받아 처리한 결과를 클라이언트에게 응답하는 역할도 수행한다(프록시 역할도 수행)
 
대표적인 웹서버로는 Apache, Nginx 등이 있다.
 

---

4. WAS = Web "Application" Server

 
(웹서버에서 중간에 Application이라는 단어만 추가된 것이다. Application의 직접적인 비즈니스로직 처리가 필요해서 추가되었다고 생각하면 된다!)
 
웹 상에서 HTTP 프로토콜을 사용하여 어플리케이션을 수행해주는 미들웨어로서, 주로 동적 서버 컨텐츠를 수행하는 것으로 웹 서버와 구별되며, 주로 데이터베이스 서버와 통신한다.
 
WAS는 DB조회나 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server이다.
 
이때 클라이언트의 요청은 서블릿(Servlet), JSP(Java Server Page) 그리고 그것들을 supporting 하는 클래스들로 구성되어 있다.
 
1. 비즈니스 로직을 처리한다.
2. DB와 직접적인 통신을 한다.
 
대표적인 WAS로는 Apache TomCat이 있다.
 

---

Q: 그럼 웹서버가 할 수 있는 일을 WAS로도 전부 가능하다면, Web Server 안써도 되는거 아님??

 
정적인 컨텐츠만을 제공하는 웹사이트를 서버에 배포한다면 그저 Web Server 만으로도 충분함.
하지만 동적인 컨텐츠를 제공하는 웹서비스를 배포해야할때는 정적, 동적 요청 처리가 모두 가능한 WAS만을 사용해도 되지 않겠냐는 생각을 할 수 도 있음.

 
하지만 WAS는 DB 조회 및 다양하고 복잡한 비즈니스 로직을 처리하는데 집중해야함.
따라서 단순한 정적 컨텐츠는 웹 서버에게 맡기고,
동적인 컨텐츠에 대한 처리는 WAS에게 위임하는 식으로 기능을 분리해 서버 부하를 방지해야함.
 
만약 WAS가 정적 컨텐츠 요청까지 처리하게 된다면, 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려짐.
이에 따라 페이지 로딩 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어지게 됨.
 

비효율적인 웹 시스템 구성

효율적인 웹 시스템 구성

 
이와 같이 Web Server를 앞단에 두고, WAS는 비즈니스 로직 중심의 task들만 수행하도록 하여 웹 서버와 함께 효율적으로 데이터를 전송해줄 수 있음.
 
따라서 웹 서비스는 상황에 따라 다음과 같은 다양한 구조를 가질 수 있음.
1. Client > 웹 서버 > DB
2. Client > WAS > DB
3. Client > 웹 서버 > WAS > DB
 

---

Q) 동적 컨텐츠는 어떻게 처리되는가?

 
웹서버가 사용자의 정보에 따라 HTML을 구성하기 위해서는 사용자에 따라 특정 정보를 DB에서 불러와 내부 로직을 통해 정보를 처리한 후 HTML에 넣어줘야 할 것이다.
하지만 기능에 따라 여러 DB에 다르게 질의를 하고 다르게 데이터를 가공하여 전달 해야할 것이다.
이렇게 되면 웹 서버 안에는 동적 데이터 생성을 하기 위한 부분과 client의 요청을 처리하고 이에 대해 응답하는 부분이 공존하게 되고 이 때문에서 서버에 로드가 커질 수 밖에 없다.
따라서 Web server에는 client의 요청과 응답에 대해서만 수행하는 부분만 남기고 다른 동적 컨텐츠를 위한 질의와 구성등은 WAS(Web Application Sever)로 분리하게 된 것이다.
 
따라서 전체적인 구조도를 보면 다음과 같이 구성되어진다.

 

---

HTTP Request to WAS

 
사용자(클라이언트)가 URL을 입력하면 HTTP Request가 Servlet Container로 전송합니다.
요청을 전송받은 Servlet Container는 HttpServletRequest, HttpServletResponse 객체를 생성합니다.
web.xml을 기반으로 사용자가 요청한 URL이 어느 서블릿에 대한 요청인지 찾습니다.
해당 서블릿에서 service메소드를 호출한 후 클리아언트의 GET, POST여부에 따라 doGet() 또는 doPost()를 호출합니다.
doGet() or doPost() 메소드는 동적 페이지를 생성한 후 HttpServletResponse객체에 응답을 보냅니다.
응답이 끝나면 HttpServletRequest, HttpServletResponse 두 객체를 소멸시킵니다.
여기서 우리가 처음 보는 용어는 Servelt Container라는 것이다.
서블릿 컨테이너는 앞써 말한 서블릿을 관리해주는 컨테이너이다.
 

---

Q) 왜 서블릿은 컨테이너를 필요로 할까? 

 
서블릿을 클라이언트가 동적 컨텐츠를 생성할 때마다 생기게 된다. 따라서 클라이언트가 많아 질수록 수많은 서블릿을 만들기는 어려울 수 밖에 없다. 이러한 서블릿을 관리해주는 부분을 서블릿 컨테이너라고 한다.
이러한 서블릿 컨테이너는 다음과 같은 특징을 가진다.
서블릿의 생명 주기를 관리한다.
사용자의 요청에 따라 서블릿을 생성하고 이에 대응되는 서블릿 메소드를 호출한다.
Http 통신을 지원한다.
멀티 쓰레딩을 지원한다.
서블릿의 요청에 따라 여러 프로세스를 만들어 관리를 한다면 요청마다 다수의 프로세스가 생성되고 이에 따라 서버의 로드가 커질 수 밖에 없다. 따라서 서블릿은 많은 서블릿 메소드에 대해 멀티 쓰레드로 관리를 하게 된다.

 

---

이제서야 이해되는 resources의 template 과 static 폴더

• templates/ 폴더:
  • Thymeleaf 같은 템플릿 엔진을 사용해서 동적으로 HTML을 생성하는 곳이야.
  • 컨트롤러에서 데이터를 모델에 담아서 넘겨주면, 템플릿이 그 데이터를 받아서 동적인 페이지를 만들어줘.
  • 예를 들어, hello.html 안에서 ${name} 같은 변수를 사용하면, 컨트롤러에서 넘긴 값에 따라 화면이 다르게 보일 수 있어.
• static/ 폴더:
  • 정적인 리소스(HTML, CSS, JS, 이미지 파일 등)를 보관하는 곳이야.
  • 컨트롤러 없이도 브라우저가 직접 접근할 수 있어.
  • 예를 들어, static/images/logo.png 파일을 넣으면 /images/logo.png 경로로 접근할 수 있어.

즉, templates/는 동적인 페이지를 위한 템플릿이 들어가는 곳이고,
static/은 웹 서버가 그대로 제공하는 정적 리소스가 들어가는 곳이야.