[Spring] WAS, 서블릿, 멀티 스레드와 스레드 풀

- 김영한 님의 '스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술'을 보고 정리한 글입니다 😊

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의

---

 

| 웹 애플리케이션이란?

- 웹은 기본적으로 HTTP를 기반으로 통신을 한다.

 

✔ 웹 서버

→ HTTP 기반으로 동작

→ 정적 리소스 제공 및 기타 부가 기능

→ 정적 (파일) HTML, CSS, JS, 이미지 영상을 파일을 두면, 서버가 해당 파일을 서빙함.

ex) NGINX, APACHE

 

 

✔ 웹 어플리케이션 서버 - WAS

→ HTTP 기반으로 동작

→ 웹 서버 기능을 대부분 포함함! + (정적 리소스 제공 가능)

→ 프로그램 코드를 실행해서 애플리케이션 로직 수행

: 사용자에 따라서 동적으로 다른 결과를 보여줄 수 있음.

: 동적 HTML, HTTP API(JSON) : 서블릿, JSP, 스프링 MVC

ex) 톰캣(Tomcat), Jetty, Undertow

 

 

✔ 웹 서버 vs WAS

- 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직까지 실행

- 하지만... 웹 서버도 프로그램을 실행하는 기능을 포함하기도 하고. WAS도 웹 서버의 기능을 제공하기는 한다.

- WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다고 생각하자.

 

 

✔ 웹 시스템 구성 - WAS, DB

- WAS, DB 만으로도 사실 시스템을 구성할 수 있다.  WAS는 정적 리소스, 애플리케이션 로직까지 커버할 수 있으니까.

 

🚩 그러면, WAS 하나만 두고 사용하면 안 될까?

- 근데, 이런 식으로 WAS가 너무 많은 역할을 담당하면 서버 과부하가 올 수 있다.

- 또한, WAS가 장애나면 오류 화면까지 노출을 못할 수 있다. 정적 리소스까지 담당을 해버리니까.

 

⭐ 그래서, 일반적으로 Client -> Web Server -> WAS -> DB 순으로 구성한다.

- 정적 리소스는 웹 서버가 처리 

- 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임 

- WAS는 중요한 애플리케이션 로직 처리를 맡는다.

 

🚩 이런 식으로 두면 뭐가 좋을까?

리소스 관리가 효율적이다.

정적 리소스가 많이 사용된다면 Web 서버를, 애플리케이션 리소스가 많이 사용되면 WAS를 증설하면서 조절하기.

또한, 보통 정적 리소스를 제공하는 웹 서버는 잘 죽지 않기 때문에, WAS가 장애났을 때 웹 서버가 대신 오류 화면을 제공해줄 수 있다.

---

| 서블릿이란?

- 서블릿을 사용하면 서버에서 비즈니스 로직 실행 + DB 접근에 더 집중할 수 있다.

: 웹 브라우저가 요청한 HTTP 메시지를 직접 파싱할 필요 없이, 서블릿 코드가 대신 수행해주는 것. (서블릿을 지원하는 WAS 사용하기)

 

✔ HttpServletRequest : HTTP 요청 정보를 편리하게 사용하도록 도와준다.

✔ HttpServletResponse : HTTP 응답 정보를 편리하게 제공하도록 도와준다.

- 즉, 개발자가 HTTP 스펙을 편리하게 사용할 수 있도록 도와주는 역할!

 

1. 클라이언트가 localhost:8080/hello로 요청을 진행.

2. WAS는 요청 메시지를 바탕으로 HttpServletRequest, HttpServletResponse 객체를 생성한다.

3. 서블릿 컨테이너에서 우리가 만든 함수 (여기에서는 HelloServlet이라고 붙였는데, 실 코드에서는 HttpServlet을 상속받은 커스텀 서블릿)을 실행한다.

: 서블릿 컨테이너는 서블릿 객체 (HelloServlet)를 생성 및 호출, 그리고 생명주기 관리를 해준다.

 : 서블릿 컨테이너는 WAS와 동일한 생명주기를 가진다.

4. 함수 실행 종료 후, HttpServletResponse 정보를 바탕으로 HTTP 응답 메시지를 만들어 브라우저에게 전달한다.

 

🚩 즉, 개발자는 Request 객체를 통해 HTTP 요청 정보를 꺼내서 사용하고, Response 객체를 통해 HTTP 응답 정보를 입력해주면 된다!

 

 

✔ 서블릿 컨테이너

- 흔히 사용하는 톰캣의 경우 서블릿을 지원하며, 이러한 WAS를 서블릿 컨테이너라고 한다.

- 서블릿 객체는 싱글톤으로 관리하며, 최초 로딩 시점에 미리 만들어두고 이후 요청에 동일한 인스턴스를 접근하도록 한다.

    - 단, 싱글톤인 만큼 각 요청이 동시에 접근하는 필드 관리에 주의해야 한다.

- 서블릿 객체는 서블릿 컨테이너와 동일한 생명 주기를 가진다.

- JSP (Java Server Page) 역시 서블릿으로 변환되어 사용된다.

- 서블릿의 경우 동시 요청을 위해 멀티 스레드 처리를 지원해준다! (WAS가 알아서 처리해준다!)

 

🚩 즉, WAS는 Web Server  + Web Container (Servlet Container)로 이루어져 있다.

참고로, 서블릿의 경우 서버 설정에 따라 생성 시점이 다르다. 로딩 시점에 생성할 수도 있고, 최초 요청 시점에도 생성이 가능하다.

여기서, 서블릿 로딩 시점은 서블릿 컨테이너가 서블릿 객체를 생성하고 init() 메서드를 호출하는 과정이다.

: init() 메서드를 사용해서 필요한 초기화 작업을 수행할 수 있다.

: 서블릿을 커스텀 초기화하기 위해서 init() 메서드를 오버라이딩하여 재구현해주면 된다.

웬만하면 초기화 작업은 오래 걸리기 때문에 (상대적) 요청 시점 말고 로딩 시점에 생성하는 게 좋다. (디폴트는 요청 시점)

: 생성 시점으로 바꾸려면 @WebServlet(loadOnStartUp=0) 이런 식으로 우선순위를 지정해주면 된다.

 

위 그림에서 service() 메서드는 서블릿이 브라우저의 요청을 처리하는 단계이며, doGet(), doPost()는 각각 GET, POST 같은 HTTP 요청을 처리하는 과정이다. init()은 객체 생성 후 1회지만, doGet(), doPost()는 요청이 들어올 때마다 매번 호출된다고 볼 수 있다.

 

---

| 동시 요청과 멀티 스레드

- 클라이언트가 요청을 하면 서버에서는 servlet을 호출해서 응답을 줘야 하는데, 이를 누가 호출해줄까?

- 바로, 스레드가 호출을 해준다!

 

 

✔ 스레드란?

- 애플리케이션 코드를 하나하나 순차적으로 실행하는 것

- 자바에서는 main이라는 이름의 스레드가 가장 처음 실행되며, 스레드는 한 번에 하나의 코드 라인만 수행된다.

- 그렇기 때문에, 동시 처리가 필요하면 스레드를 추가로 생성해야 한다.

 

[단일 요청 상황 - 단일 스레드 사용] 

1. 클라이언트가 요청을 하면, 해당 요청에 대한 스레드가 할당이 된다.

2. 해당 스레드를 이용하여 서블릿을 실행한다.

3. 응답까지 진행한 다음, 스레드는 휴식에 들어간다.

 

[다중 요청 상황 - 단일 스레드 사용]

1. 요청이 들어왔을 때 스레드를 생성하여 서블릿을 호출하였다.

2. 만약, 어떠한 해당 서블릿이 어떠한 처리를 하고 있을 때 또 다른 요청이 들어온다면 대기 상태에 들어간다.

3. 이렇게 되면 요청1은 처리 지연, 요청 2는 대기하다 보니 둘 다 timeout으로 죽어버린다.

 

[다중 요청 상황 - 다중 스레드 사용]

- 요청마다 스레드를 생성하기. 당연히 동시 처리가 가능하다.

- 하지만, 위 방법은 비용적으로도 비싸고, 컨텍스트 스위칭 비용 문제, 그리고 CPU, 메모리 사용량에 따라 서버가 죽어버릴 수도 있다.

- 그렇기 때문에, 스레드 풀을 사용해보자.

 

 

✔ 스레드 풀

- 요청이 오면 스레드 풀에게 요청을 하고, 스레드 풀에서 가져다 쓴 다음 끝난 후 반환하기.

- 스레드 풀보다 더 많은 요청이 들어오면 대기하거나 거절된다.

- 생성 가능한 스레드의 최대치를 관리할 수 있다. (톰캣은 기본적으로 200개)

- 스레드가 미리 생성되어 있기 때문에 스레드 생성 및 종료 비용이 절약되며, 응답시간이 비교적 빠르다.

 

🚩 WAS에서 최대 스레드 수를 어떻게 두는지가 중요하다. 

최대 스레드 수가 너무 작으면 서버는 여유롭지만 클라이언트는 응답 지연이 계속 나타날 것이고,

너무 많으면 서버가 쉽게 다운될 수가 있다는 점이 존재한다. 그래서 성능 테스트를 잘 수행해보는 게 중요.

 

아무튼, WAS에서는 멀티 스레드 관련 코드를 알아서 신경쓰기 때문에 개발자는 크게 신경쓰지 않아도 된다. (싱글 스레드 프로그래밍처럼 코드 짜기) 멀티 스레드 환경이기 때문에 싱글톤 객체 - 서블릿, 스프링 빈은 주의해서 사용하면 된다.

 

🚩 스레드 풀 동작 과정

- 초기에 스레드를 최대치만큼 생성해둔다. (server.tomcat.threads.max로 설정)

- 요청이 들어올 때마다 작업 큐에 담아두고, idle 상태인 스레드가 존재한다면 큐에서 꺼내 스레드에게 작업을 할당한다.   

    - 만약, idle인 상태의 스레드가 없다면 큐에서 대기하고, 이 상태가 지속되어 큐가 꽉 차면 새로운 스레드를 생성한다.   

- 만약 스레드까지 최대 사이즈가 된다면 connection-refused를 반환한다.- 요청 작업이 종료되면 스레드는 idle 상태가 된다.

 

- Connector : 소켓 연결 및 데이터 패킷을 획득하여 HttpServletRequest 객체로 변환, Servlet 객체에 전달해주는 역할.   

- Acceptor에서 while문을 통해 대기하며 port listen을 통해 소켓 연결을 얻는다.   

- 소켓 연결로부터 얻은 데이터를 파싱해서 HttpServletRequest 객체를 생성한다.   

- 서블릿 컨테이너에 해당 객체를 전달하고, 컨테이너는 서블릿을 찾아 요청을 처리한다.

 

- 톰캣 8.5부터는 기본적으로 NIO Connector를 채택하였다.

- NIO Connector의 경우 Poller라는 별도의 스레드가 커넥션을 처리하는데,

Socket을 캐시로 들고 있다가 데이터 처리가 가능할 때만스레드를 할당하여 idle 상태로 남는 걸 최대한 줄여주는 것이다.

 

🚩 Acceptor에서 소켓 연결 얻기 -> 소켓에서 소켓 채널 객체를 통해 톰캣의 NIOChannel 객체로 변환 -> PollEvent라는 객체로 캡슐화하여 큐에 전달 -> 스레드는 큐에 있는 객체를 꺼내서 사용

---

 

| HTML, API, CSR, SSR

✔ 정적 리소스

- 고정된 HTML 파일, CSS, JS, 이미지, 영상 등 제공. 요청이 오면 이미 생성되어 있는 파일을 리턴한다.

 

✔ HTML 페이지

- 동적으로 필요한 HTML 파일을 생성(JSP, 타임리프 등 적용)해서 전달하며, 웹 브라우저는 HTML 파일을 해석하여 띄워준다.

 

✔ HTML API

- HTML이 아니라 데이터를 전달하는 방식으로, 주로 JSON 형태로 전달한다.

- 웹 브라우저는 JSON 형태로 데이터가 오면 별도의 해석 없이 그대로 화면에 보여준다.

- 데이터만 주고받기 때문에 UI가 필요하다면 클라이언트가 별도로 처리해야 한다.

 

🚩 개발자는 정적 리소스를 어떻게 제공할 것인지, 동적으로 제공되는 HTML 페이지를 어떻게 제공할 것인지,

HTTP api를 어떻게 제공할 것인지 고민하면 된다.

 

 

✔ SSR (Server-Side Rendering)

- 다 만들어진 HTML을 받아와서 렌더링하는 방법.

- 웹 서버에 계속 새로운 페이지에 대한 요청을 진행하는 방법이다.

- 초기 로딩 속도는 빠르지만, 매번 요청할 때마다 새로고침이 되기 때문에 이후 서버에 부하가 간다.

- JSP, 타임리프 등을 사용할 수 있다.

 

✔ CSR (Client-Side Rendering)

- HTML 결과를 자바스크립트를 활용하여 웹 브라우저에서 동적으로 생성하여 적용하는 방법.

- 초기 로딩 시 HTML, static 파일들을 받기 때문에 (비어있음) 비교적 느리지만, 그 이후 필요에 따라 서버에게 요청하기 때문에 부하가 적다.

- React, Vue.js 등을 사용할 수 있다.

 

 

- 다음 포스팅부터는 스프링에서 제공하는 서블릿에 대해서 본격적으로 알아보자!