[ASAC 06] WS와 WAS

이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.

WS와 WAS

WS와 WAS의 차이점

다음은 사용자가 웹 페이지를 요청하는 경우 WS와 WAS의 차이점이다.

• 웹 서버(WS, Web Server)
  -> 정적 웹 리소스 반환. 포장 햄버거
  • 사용자의 요청마다 다른 웹 페이지를 모두 개발해야 한다는 단점이 존재한다.
• 웹 애플리케이션 서버(WAS, Web Application Server)
  -> 동적 웹 리소스 반환. 수제 햄버거
  • 1개 컨트롤러 <-> 1개 뷰 템플릿 <-> N개 데이터에 따른 N개 뷰
    • MVC 패턴

WS와 WAS의 관계는 다음과 같이 설명할 수도 있다.

• 웹 서버 : 요청 -> 웹 페이지 반환
• 애플리케이션 : 요청 -> 연산 -> 반환
• 웹 서버 + 애플리케이션 = 웹 애플리케이션 서버
• *WAS 작동 방식

역할

• 컨트롤러 (Controller)
  -> 사용자의 요청을 가장 앞에서 받는다. 뷰 템플릿과 모델의 준비
  -> 컨트롤러가 내부적으로 뷰 리졸버를 호출한다.
  -> 뷰 리졸버로부터 뷰를 반환받아 사용자에게 반환한다.
• 뷰 리졸버 (View Resolver)
  -> 템플릿 엔진(ex. 타임리프)을 연결하고 뷰 템플릿을 찾는다.
  -> 뷰 템플릿과 모델을 합쳐서 뷰를 생성
  -> 컨트롤러에게 뷰를 반환

전반적인 동작

1. 사용자의 요청
2. 로직 수행 (컨트롤러)
3. 뷰 템플릿과 데이터를 합쳐서 뷰 생성 및 컨트롤러로 반환 (뷰 리졸버)
4. 사용자에게 뷰 반환 (컨트롤러)

WAS 장점

1. 공간 효율
   정적 웹페이지를 여러개 개발하면 용량을 많이 차지하게 된다.
   WAS를 사용해 하나의 뷰 템플릿과 로직을 작성하여 용량을 줄일 수 있다.
2. 실시간성
   DB의 데이터가 실시간으로 바뀌는 경우. 정적 웹페이지는 개발자가 수동으로 데이터를 바꿔줘야 한다.

초기 WAS와 현재 WAS 비교

초기 WAS - CGI 사용

CGI (Common Gateway Interface)는 웹 서버가 받은 요청을 애플리케이션으로 넘겨주는 역할을 한다.
웹 서버는 한 개지만, application 개발 언어는 여러 개 존재(php, perl, ruby, python)한다.
그렇기 때문에 CGI는 웹 서버와 다양한 애플리케이션 언어들을 연결해준다.

처음 CGI가 등장했을 때 애플리케이션 개발 언어는 컴파일 언어(Java, Python)이 아닌, 스크립트 언어였다.(Shell, Bash)
유명한 서버 사이드 스크립트 언어로는 PHP, Perl, Ruby 등이 존재한다.

현재 WAS

현재 대부분의 WAS는 서버 내부에 애플리케이션이 내장되어 있는 형태이다. (ex. 아파치 톰캣)
그렇기 때문에 CGI를 따로 사용할 필요 없이 WAS를 사용하여 웹 애플리케이션을 개발할 수 있다.

WAS의 요청 처리

하나의 애플리케이션에는 동시에 여러 개의 요청이 들어올 수 있다.
각각의 요청을 처리할 수 있는 방법은 프로세스 를 사용하거나, 스레드를 사용하는 것이다.

먼저 프로세스와 스레드의 차이를 알아보도록 하자.

프로세스와 스레드

• 프로그램 : 컴파일 후 정적인 파일(.exe)
• 프로세스 : 프로그램 내부에서 자원을 할당하고 실행된 프로그램.
• 스레드 : 다중(동시) 처리를 위해 실행 단위 축소한 것(light weight).
  스레드는 하나의 프로세스 내부에 여러 개 존재할 수 있다.
  -> 다양한 작업 + 동시 작업이 가능하다.

1개 프로그램에는 1개 프로세스만 존재하지만, 1개 프로세스에는 N개의 스레드가 존재할 수 있다.

OS는 자원을 할당한다. 컨텍스트 스위칭을 통해 CPU를 할당하고, heap과 stack에 메모리를 할당한다.

메모리 할당

• heap : 프로세스 단위로 할당된다.
• stack : 스레드 단위로 할당된다.
• 스레드마다 프로그램 카운터 (PC, 실행 위치) + 명령어 레지스터 (실행 함수) + 스택 영역 (실행 변수)를 가진다. 

WAS 요청 처리 - CGI 사용 시기

WAS에서 웹 서버와 애플리케이션이 분리되어 CGI를 사용할 때의 요청 처리 방식이다.

1. CGI 초기 = 1 요청 : 1 비상주 프로세스
   • 매 요청마다 프로세스에 자원이 할당되고 요청 수행 후 해제된다.
   • 생성 - 실행(반환) - 죽음
   • Stateless 비상태성 : 각각의 프로세스는 서로의 상태를 알 수가 없다. 독립적이다.
   • 장점 : 각 실행 프로세스마다 segregation이 잘 되어있다. -> 보안성이 좋다.
2. FCGI(Fast CGI) = 1 요청 : 1 상주 프로세스
   • 매 요청마다 이미 열려있던 프로세스가 웹 페이지를 만들고 반환한다. 프로세스는 계속 살아있는다. (OS 종료 혹은 프로세스 강제 종료 전까지 실행)
   • Stateful 상태성 : 아무리 많은 요청이 와도 기존 프로세스가 실행(반환)만 하기에 상태의 유지가 가능하다.
   • 장점 : 자원 효율성. 매번 실행 종료를 하기 위해서 자원 할당이 필요하기 때문이다.

WAS 요청 처리 - 현재

서버에 애플리케이션이 포함된 현재의 WAS는 어플리케이션으로 구동되어, 각각의 요청은 스레드로 처리가 된다.
이때 스레드풀을 사용한다.

스레드풀

스레드풀에는 종료되지 않는 스레드들이 존재한다. 스레드풀의 스레드는 다음 과정을 따른다.

1. 할당
2. 수행
3. 회수

1개 애플리케이션 스레드는 1개의 데이터베이스 스레드밖에 쓰지 못하기 때문에, 애플케이션 스레드 수에 맞춰서 데이터베이스 스레드 수를 유지해야 한다.

-> 서블릿 : JAVA 애플리케이션에서 요청에 따른 수행 단위
각각의 서블릿은 서블릿 컨테이너에 의해 관리되고, 스레드에 의해 처리된다. 서블릿 컨테이너는 스레드를 할당하고, 완료 뒤 회수한다. 

스레드풀을 사용하는 WAS 요청의 스레드 처리 방식은 CGI와 FCGI 각각의 장점을 합친 장점들을 가진다.

=> 상주 프로세스의 stateful 장점 + 비상주 프로세스의 stateless 장점

1. 보안성
   -> Stateless. 스레드마다 독립된 stack 영역을 가지며(분리됨), heap 영역은 서로 공유가 가능하다.
2. 자원 효율성
   -> 스레드풀에 이미 생성된 스레드를 사용 후 반환. 초기 스레드 생성 이후 반환된 스레드를 사용하기 때문에 자원 절약이 가능하다.