WAS와 Web Server
Web Server
Web Server는 웹 브라우저(클라이언트)로부터 HTTP 요청을 받아 HTML 문서와 같은 정적 컨텐츠를 제공하는 프로그램을 말한다.
정적 컨텐츠란, 요청 인자 값에 상관없이 달라지지 않는 컨텐츠(html, css, image 등) 즉, 어느 사용자의 요청이든 항상 동일한 컨텐츠를 일컫는다. 대표적인 Web Server로는 Apache와 Nginx가 있다.
하지만 클라이언트로부터 동적 컨텐츠를 보여주어야 한다면 어떨까? 이때, 필요한 것이 바로 WAS다.
WAS
WAS는 Web Application Server의 약자로 DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 프로그램이다. 동적 컨텐츠란, 정적 컨텐츠와 반대로 요청 인자에 따라 바뀔 수 있는 컨텐츠를 말한다. 물론 대부분의 WAS는 Web Server를 내장하고 있기 때문에 정적 컨텐츠 처리도 가능하다.
WAS와 Web Server를 함께 사용했을 때의 장점
그럼 혹자는 WAS만으로 정적 컨테츠와 동적 컨텐츠 처리를 모두 할 수 있는데 왜 Web Server를 사용해야 하는지 의문을 가질 수 있다. 물론 WAS만을 사용해서 모든 요청을 처리해도 되지만 Web Server를 함께 사용할 경우, 여러가지 장점이 존재하기 때문이다!
- 책임 분할을 통한 서버 부하 방지
정적 컨텐츠는 Web Server가 부담하고 동적 컨텐츠는 WAS를 사용하여 책임을 분할 할 수 있다. WAS 앞단에 Web Server를 배치하여 정적 컨텐츠 요청 시에는 WAS까지 가지 않고 Web Server를 통해 처리함으로써 서버 부하를 방지할 수 있는 것이다.
2. 여러 대의 WAS 로드 밸런싱
Web Server는 로드 밸런싱 기능을 갖고 있다. 그래서 WAS 앞단에 Web Server를 두어 여러 대의 WAS가 처리해야 하는 요청을 여러 WAS가 나누어 처리할 수 있도록 설정할 수 있다.
Servlet (서블릿)
서블릿은 클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술이다.
서블릿 컨테이너
톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다. 서블릿 컨테이너는 클라이언트의 요청을 받아주고 응답할 수 있도록 웹서버와 소켓으로 통신하는 역할을 한다. 이러한 기능을 알아서 처리함으로써, 개발자가 비즈니스 로직에 대해서 집중할 수 있도록 해준다. 서블릿 컨테이너는 서블릿 객체의 생명주기를 관리하며 동시 요청을 위한 멀티 쓰레드 처리를 지원한다.
쓰레드 풀
쓰레드는 한번에 하나의 코드 라인만 수행한다. 때문에 동시 처리가 필요하면 쓰레드를 추가로 생성해야 한다. 이를 해결하기 위해 쓰레드를 매 요청마다 생성한다면 쓰레드를 생성하는 비용으로 인해 응답 속도가 늦어지고 컨텍스트 스위칭 비용이 발생하게 된다는 문제가 발생하게 된다. 또한 이러한 방법은 고객의 요청이 너무 많이 오게 된다면 CPU와 메모리 임계점을 넘어가 서버가 죽을 수 있다.
이러한 문제점을 해결하기 위해서 대부분의 WAS 내부에는 쓰레드 풀이 존재한다. 미리 생성된 쓰레드들을 쓰레드 풀 안에 보관하고 있다가 요청이 올 경우, 필요한 쓰레드를 꺼내서 사용하는 방식이다. 쓰레드 사용이 종료되면 다시 쓰레드 풀로 반납하는 방식으로 동작한다. 쓰레드가 미리 생성되어 있기 때문에 쓰레드를 생성하고 종료하는 비용이 절약되고 응답 시간이 빠르다. 또한 생성 가능한 쓰레드의 최대치가 존재하므로 과도한 요청이 들어와도 기존 요청에 대해서는 안전하게 처리할 수 있다. 톰캣의 경우, 생성 가능한 쓰레드의 최대치로 200개가 기본으로 설정되어 있다고 한다. (변경 가능하다.)
SSR과 CSR
SSR
SSR(Server Side Rendering)은 HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달하는 방식이다. SSR 방식은 요청 시 서버에서 즉시 HTML을 만들어 응답하기에 데이터가 달라지거나 자주 바뀌어서 미리 만들어 두기 어려운 화면 즉, 정적인 화면을 만들 때 주로 사용한다. JSP, 타임리프 등이 대표적인 기술이다.
CSR
CSR(Client Side Rendering)은 쉽게 말해 클라이언트 측에서 렌더링 하는 방식이다. HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용하는 방식으로 주로 동적인 화면에 사용한다. React나 Veu.js가 CSR의 대표적인 기술이다.
Request
HTTP Servlet Request
Servlet은 HTTP 요청 메시지를 파싱한 결과를 **HttpServletRequest**객체에 담아 제공한다.
HTTP 요청 데이터
HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달하는 방법에는 주로 3가지 방법이 있다.
- GET - 쿼리 파라미터
- 검색, 필터, 페이징 등에서 많이 사용하는 방식으로 메세지 바디 없이 URL의 쿼리 파라미터에 데이터를 포함해서 전달하는 방식이다. 해당 방식은 메세지 바디를 사용하지 않기 때문에 content-type은 null 값 즉, 존재하지 않는다.
- POST - HTML Form
- 메세지 바디에 쿼리 파라미터 형식으로 데이터를 전달하는 방식이다. HTTP 스펙 상, POST 요청만 가능하다. HTTP 메세지 바디에 데이터를 포함해서 전송할 경우, 바디에 포함된 데이터가 어떤 형식인지 반드시 지정해주어야 한다. 때문에 content-type을 application/x-www-form-urlencoded으로 지정해주어야 한다. 또한 앞서 설명한 쿼리 파라미터와 형식이 같다. 클라이언트 입장에서는 두 방식은 차이가 있지만 서버 입장에서는 두 방식의 형식이 동일하므로 쿼리 파라미터 조회 메서드를 그대로 사용할 수 있다.
- HTTP message body
- 주로 HTTP(REST) API에서 사용하는 방식으로 메세지 바디에 데이터를 직접 담아서 요청하는 방식이다. 데이터 형식으로는 주로 JSON을 사용한다. 만약 JSON 결과를 파싱하여 사용할 수 있는 자바 객체로 변환하기 위해서는 Jaskson과 같은 JSON 변환 라이브러리가 필요하다. 스프링 부트로 Spring MVC를 선택하면 기본으로 Jaskson 라이브러리(Object Mapper)를 함께 제공해준다. 폼 방식과 마찬가지로 메세지 바디에 데이터가 존재하기 때문에 content-type을 application/json로 지정해주어야 한다.
Response
HTTP Servlet Response
Servlet은 HttpServletResponse객체에 Content Type, 응답코드, 응답 메시지 등을 담아서 전송한다.
'Spring' 카테고리의 다른 글
스프링 MVC 2편 - 섹션 4~5 (0) | 2025.03.17 |
---|---|
스프링 MVC 1편 - 섹션 4~7 (0) | 2025.03.17 |
스프링 핵심 원리 기본편 - 섹션 9~10 (0) | 2025.03.17 |
스프링 핵심 원리 기본편 - 섹션 7~8 (0) | 2025.03.17 |
스프링 핵심 원리 기본편 - 섹션 4~6 (0) | 2025.03.17 |