[WEB] WAS(Web Application Server)와 서블릿(Servlet)에 대하여

DyungE_100·2022년 4월 1일

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

0.1 정적 웹 페이지의 한계와 JSP

초창기 웹이 출현했을 때는 정적(Static)인 웹 페이지들이 많았고 그것들만으로도 의미 전달이 충분히 될 수 있었다. 하지만 정적 웹 페이지의 모든 내용은 정해져 있었기 때문에 각각의 사용자의 요구를 맞출 수가 없었고 동적(Dynamic)인 웹 페이지를 필요로 하게 되었다.

그래서 이 때 등장한 것이 CGI (Common Gateway Interface)였다. CGI는 정식 프로그래밍 언어나 스크립트는 아니었고 서버에서 수행 중인 일반 프로세스 사이에 정보를 주고 받는 규칙을 의미했다. CGI는 Perl, C, C++ 등의 언어를 지원하면서 웹 서버를 통해 요청을 받고 실행 결과를 다시 웹 서버를 거쳐 클라이언트의 브라우저로 보낼 수 있는 기능을 지닌다.

하지만 CGI 방식의 근본적인 문제점이 존재했는데, 각각의 클라이언트 요청에 대하여 독립적인 별도의 프로세스가 생성된다는 점이었다. 프로세스가 많아질수록 시스템에 많은 부하가 걸리게 되고, 이러한 경우 웹 서버는 똑같은 요청이라 할지라도 웹 브라우저에서 받은 요청 갯수만큼 동일한 시간에 같은 프로세스를 생성한다. 이는 프로세스가 많아질수록 서버의 메모리를 점유하기 때문에 비효율적이며, 또 다른 문제점으로는 OS에 종속되어 개발이 어렵고 유지 보수가 어려웠다.

0.2 CGI를 대안하는 기술의 등장

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

스크립트 엔진을 활용한 방식은 다수의 웹 브라우저가 같은 요청을 하더라도 스크립트에 대한 프로세스를 하나만 수행하고, 각 웹 요청에 대해서 쓰레드(Thread)로서 처리하는 방식이었다. 즉, 실제 프로그램 수행은 프로세스를 생성하여 메모리에 띄어 놓고 각 요청에 대한 쓰레드를 새로 생성하여 프로세스를 한 번씩 지나게 하여 원하는 응답을 얻어내는 기법을 활용한다는 것이다. 이러한 방식은 CGI 방식에 비하여 CPU 점유도나 메모리 점유도에 있어 상당히 효율적이었고, 이는 곧 안정적인 웹 서비스를 제공할 수 있는 기반인 웹 어플리케이션 서버(WAS, Web Applicaion Server)로 발전하였다.

cf.1) 또 다른 대안 기술로는 데몬(deamon) 프로그램을 활용하는 방법이었는데 동적 처리할 때 진행되는 프로그램을 미리 데몬으로 가동시켜 놓은 후, 요청을 데몬에서 처리하는 방식이었다.

cf.2) 컴파일 코드 방식은 프로그래머가 직접 코드를 컴파일 해야 해서 수정을 할 때 코드를 직접 다시 재컴파일 해야 하는 번거로움이 있었다. 그에 반해 스크립팅 코드 방식은 코드 구현 이후 컴파일 과정은 웹 요청 시 자동으로 수행된다. 따라서 스크립트 내에서 코드를 수정만 해주면 되었다. 서버 측 스크립팅 기술로 JSP, PHP, ASP가 있었다.

1. 웹 서버(Web Server)와 WAS

1.1 웹 서버(Web Server)

웹 서버의 의미는 하드웨어와 소프트웨어로 나뉘어 구분된다.
1) 하드웨어 : 웹 서버가 설치되어 있는 컴퓨터
2) 소프트웨어 : 웹 브라우저 클라이언트로부터 HTTP 요청을 받아들이고 HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램

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

1.2 WAS(Web Application Server)

웹 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로서, 주로 동적 서버 컨텐츠를 수행하는 것으로 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행한다.

WAS는 DB조회나 로직 처리를 요구하는 동적 컨텐츠를 제공하기 위해 만들어진 Application Server다.
웹 서버는 어플리케이션 서버(Application Server)와 직접적으로 통신하지 못해서 중간 다리 역할로 WAS(uwsgi, tomcat, jboss)를 두고, 각자에 맞는 방식으로 요청을 변환해주는 역할을 한다.
이 때, 클라이언트의 요청은 서블릿들(Servlets), JSP(JavaServer Pages) 파일들, enterprise beans, 그리고 그것들을 supporting하는 클래스들로 구성되어 있을 수 있다.
웹 컨테이너(Web Container) 혹은 서블릿 컨테이너(Servlet Container)라고도 불린다.
기능
- 프로그램 실행 환경과 DB 접속 기능을 제공한다.
- 여러 개의 트랜잭션(Transaction)을 관리한다.
- 업무 처리하는 비즈니스 로직을 수행한다.
대표적인 WAS로는 Apache TomCat, JBoss, Jeus, Resin , Uwsgi 등이 있다.

1.3 아파치 톰캣(Apache Tomcat)에 대하여

아파치 톰캣은 아파치 소프트웨어 재단에서 개발한 서블릿 컨테이너(또는 웹 컨테이너)만 있는 웹 애플리케이션 서버(WAS)이다.

톰캣은 웹 서버와 연동하여 실행할 수 있는 자바 환경을 제공하여 JSP와 자바 서블릿이 실행할 수 있는 환경을 제공하고 있다.
톰캣은 관리툴을 통해 설정을 변경할 수 있지만, XML 파일을 편집하여 설정할 수도 있다. 그리고, 톰캣은 HTTP 서버도 자체 내장하기도 한다.

1.4 웹 서버와 WAS를 구분하는 이유

웹 서버가 필요한 이유

이미지 파일과 같은 정적인 파일들은 웹 문서(HTML)가 클라이언트로 보내질 때 함께 보내지지 않는다. HTML 문서를 먼저 보내고 그에 맞게 필요한 정적 컨텐츠를 보내게 되는데, 이 과정에선 WAS까지 거치지 않고 앞단에서 빠르게 웹 서버에서 처리해줄 수 있다.

따라서 웹 서버에서는 정적 컨텐츠만을 처리하도록 기능을 분배하여 서버의 부담을 줄일 수 있다.

WAS가 필요한 이유

웹 페이지는 정적 컨텐츠 뿐만 아니라 동적 컨텐츠도 존재한다. 따라서 웹 서버만을 이용한다면 사용자가 원하는 요청에 대한 결과값을 모두 미리 만들어 놓고 서비스를 진행해야 한다.

자원은 한정적이므로 WAS를 통해 요청에 맞는 데이터를 DB에서 가져와 비즈니스 로직에 맞게 제공함이 자원을 효율적으로 사용할 수 있다.

2.1 서블릿(Servlet)이란?

서블릿은 클라이언트의 요청에 대해 동적 컨텐츠를 생성하는 자바 언어 기반의 웹 컴포넌트(Web Component)이다. 다른 자바 기반의 컴포넌트들처럼, 서블릿은 플랫폼(OS)으로부터 독립적인 자바 클래스들이다.

서블릿은 웹 클라이언트로부터 요청과 응답을 웹 서버를 통해 넘겨 받고 서블릿 컨테이너에 의해 실행되어 상호 작용을 한다.

2.2 서블릿 컨테이너(Servlet Container)란?

때로는 서블릿 엔진(Servlet Engines)이라고도 불리는 서블릿 컨테이너(Servlet Containers)는 서블릿들을 모아서 관리하고 웹 서버와 소켓으로 통신하는 역할을 한다. 대표적으로 톰캣이 있다.

웹 서버와 통신하여 상호 보완 작용한다.

서블릿의 생명 주기를 관리해주는 역할을 한다.

멀티쓰레드 지원 및 관리

보안 관리

서블릿이 동작하는 전형적인 일련의 과정을 본다면 다음과 같다.

1. 클라이언트(웹 브라우저)가 웹 서버에 HTTP 요청을 보낸다.
1. 웹 서버는 받은 요청을 서블릿 컨테이너(WAS)에 넘겨주고, 서블릿 컨테이너는 요청을 처리하게 된다.
1. 서블릿 컨테이너는 사용자가 요청한 URL로 어떤 서블릿을 호출할지 결정하고, 요청과 응답에 대응되는 객체들(HttpServletRequest, HttpServletResponse)을 생성하고 불러온다.
1. 서블릿은 HTTP 응답을 통해 요청 받은 객체(HttpServletResponse)를 클라이언트로 넘겨주고 두 객체(HttpServletRequest, HttpServletResponse)를 모두 소멸시킨다.

2.3 서블릿의 라이프 사이클(Life Cycle)

웹 서버가 구동되면 서블릿 파일들은 모두 실행 가능 상태로 전환되고 컨테이너가 해당 서블릿이 메모리에 있는지 확인한다.

init() 메서드에 의한 초기화 (클라이언트 최초 요청 시에 한 번만 실행)

service() 메서드 실행 >> Spring에서의 Controller 부분이 실행되고 종료된다.
이 과정에서 HttpServletRequest, HttpServletResponse 객체가 생성되고 넘겨준다.

destroy() 메서드에 의해 종료가 되고 메모리를 해제한다. (웹 서버가 종료될 때 한 번만 실행)