더 이상 물러설 곳이 없다

서블릿 객체는 쓰레드에 의해 호출되어진다. 그리고 여러 요청을 동시에 처리하기 위한 멀티 쓰레드는 필수적이다.

멀티 쓰레드를 지원하는 두 가지 방식이 있다.

1. 요청마다 생성

말 그대로 요청이 들어올 때마다 해당 요청을 처리하기 위한  쓰레드를 새로 생성한다.

이 경우 요청이 늘어남에 따라 컨텍스트 스위칭 비용이 무한정으로 늘어날 수 있다는 단점이 있다.

2. 쓰레드 풀

WAS 내부에서 사용할 일정 개수의 쓰레드들을 쓰레드 풀에 미리 생성한다.

요청이 들어오면 이 쓰레드 풀에서 쓰레드를 할당받아 요청을 처리한다.

사용이 완료된 쓰레드는 다시 풀에 반납한다.

쓰레드 풀의 쓰레드가 모두 사용중일 경우에 새로 들어오는 요청은 거절하거나 특정 수만큼 대기하도록 할 수 있다.

쓰레드 풀 방식을 사용하기 위해 최대 쓰레드 수를 얼마로 설정하는지가 중요하다. (톰캣은 최대 200개의 쓰레드가 디폴트 값이다.)

적절한 CPU 사용률을 유지할 수 있도록 MAX thread를 적절하게 설정해줘야 한다.

서블릿이 없다면?

서블릿 없이 서버 개발자가 모든 기능을 전부 코딩해야 한다면 다음과 같은 로직들을 전부 구현해야 한다.

1. TCP/IP 대기, 소켓 연결

2. HTTP Request 메세지 받아서 분석

3. 비즈니스 로직 실행

4. DB 처리

5. HTTP Response 메세지 생성

6. TCP/IP를 통해 Response 전달

서블릿은 이러한 작업을 대신 처리하여 개발자의 업무 부담을 덜어준다 (3, 4는 직접 해야한다.)

서블릿 기능을 지원하는 WAS를 '서블릿 컨테이너'라고 칭한다.

서블릿 컨테이너는 서블릿 객체의 생명주기를 관리해주며 서블릿 객체는 싱글톤 패턴으로 관리된다.

서블릿 컨테이너는 동시 요청을 위한 멀티 쓰레드 처리를 지원한다.

WAS와 서블릿의 동작 방식

1. WAS가 HTTP Request를 받는다.

2. 요청 정보를 토대로 HttpServletRequest, HttpServletResponse 객체를 생성하여 서블릿 객체를 호출한다.

3. 서블릿은 비즈니르 로직 수행 후 HttpServletResponse를 적절하게 수정하여 반환한다.

4. WAS는 반환받은 정보를 토대로 HTTP Response를 반환한다.

Web Server

1. HTTP 기반으로 동작

2. 단순 '정적 리소스'를 제공

(ex : apache, nginx)

WAS

1. HTTP 기반으로 동작

2. Web Server 기능을 포함 (정적 리소스 제공)

3. 프로그램 코드를 실행하여 애플리케이션 로직 수행 (동적 처리 가능. Servlet, JSP, 스프링 MVC 등)

(ex : tomcat, jetty, undertow)

Web Server가 동적 기능까지 포함하는 경우도 있기 때문에 둘의 경계는 매우 모호하다.

그래도 굳이 정리하자면 

웹서버는 정적 리소스 담당, WAS는 정적 리소스 + 동적 기능 담당 정도로 생각할 수 있다.

WAS + DB만으로 시스템을 구성할 수는 있지만 이 경우 WAS의 역할이 너무 많아지고 서버 과부하의 위험이 있다.

정적 리소스 제공 역할을 수행하느라 정작 중요한 애플리케이션 로직의 수행에 어려움을 겪을 수 있다.

또한, WAS가 모든 역할을 맡게 되면 WAS가 죽었을 때 오류 화면을 노출해주는 것도 할 수 없게 된다.

이러한 문제들을 해결하기 위해 일반적으로 정적 리소스 처리만을 위한 웹서버를 따로 두고 WAS는 동적 기능에만 집중하는 식의 구성을 취한다.

이렇게 역할을 구분해놓으면 효율적인 리소스 관리가 가능하단 장점도 있다.

(정적 리소스 사용이 많으면 웹서버 증설, 애플리케이션 리소스 사용이 많으면 WAS 증설)

만약 화면을 띄워줄 필요 없이 API 통신으로 데이터만 넘겨주면 되는 경우라면 WAS만으로 구성하여도 문제될 것이 없다.