[Spring] 김영한 스프링MVC_ 섹션 2. 웹 애플리케이션의 이해

<출처 인프런>

 

 

SpringMVC에 본격적으로 들어가기전 기본적으로 알아야할 개념들을 섹션 2 강의에서 간단하게 설명했다. 강의를 들을 땐 개념에 대한 배경지식이 흐릿해서 수업을 듣고 있어도 수업의 흐름이 이해되질 않았다. 그래서 블로그에 WAS - 서블릿 - 서블릿 컨테이너 - 멀티쓰레드 - 쓰레드 풀이 어떤 식으로 연관을 갖는지를 중심으로 공부하고자 한다. 그리고 공부하면서 이해하는데 보충이 되는 개념과 설명이 있으면 함께 적고, 도중에 질문들이 생기면 그에 대한 답변도 찾아보고자 한다.

 

 

☘️ 

---

 

✔️  웹 - HTTP 기반으로 동작

• 서버 간에 데이터를 주고 받을 때 대부분 HTTP를 사용한다.
• 거의 모든 형태의 데이터 전송이 가능하다.

 

HTTP

: 웹 상에서 주고 받을 수 있는 프로토콜로 서버와 클라이언트 사이에 이루어지는 요청 응답 프로토콜이며, 주로 HTML 문서를 주고 받는데 사용한다.

 

웹 서버 (Web Server)

: HTTP 기반으로 동작하며 정적 리소스를 제공한다.

 

웹 애플리케이션 서버 (Web Application Server) 

: HTTP 기반으로 동작하며 프로그램 코드를 실행하여 애플리케이션 로직을 수행한다. 정적 리소스 제공도 가능하다.

 

 

 

Q. 웹 서버는 정적 리소스를 제공하고 웹 애플리케이션 서버는 애플리케이션 로직을 제공한다고 했다. 웹 페이지로 예시를 들면 어떤게 있을까?

A. 정적 리소스는 이미지, 동영상, CSS, HTML 등 이다. 웹 페이지에 로고가 있다면 로고는 이미지에 해당하니 웹 서버에서 제공하는 리소스가 될 것이다. 웹 애플리케이션 서버에서 제공하는 것은 로그인 페이지에서 사용자가 아이디와 비밀번호를 입력하면 입력된 데이터를 처리하여 로그인이 된 화면을 보여주는 이런 일련의 과정이라고 보면 될 것 같다. 단순히 보여주는 것에 끝나지 않고 로직을 수행하고 처리하는 과정이 웹 애플리케이션 서버가 행하는 일이다.

 

 

Q. 그런데 웹 애플리케이션 서버가 동적인 로직 뿐 아니라, 정적 리소스도 제공한다고 했다. 그러면 웹 애플리케이션 서버가 웹 서버가 하는 일도 처리하면 되지 않을까?

A. WAS는 비싼 비즈니스 로직을 수행한다. 예로 금전 거래, 개인정보관리, 주문 처리 등이 있을 수 있다. 이러한 로직은 처리 시간과 자원 소모가 크고 오류가 발생하게 된다면 서비스 전체에 심각한 영향을 줄 수 있다. 이런 복잡한 로직을 처리하는 WAS에게 정적인 리소스까지 제공하라고 한다면 정적인 리소스 제공을 처리하느라 중요한 로직의 처리가 미뤄질 수 있으며 요청을 받는 것 부터 처리까지 모든 것을 홀로 해야하는 WAS의 서버에 과부하가 올 수 있다. 그래서 웹 서버를 WAS의 앞에 배치시켜 요청이 오면 웹 서버에서 받게 한 후 동적으로 처리해야하는 부분만 WAS에게 요청을 위임한다.

 

 

 

---

 

 

 

 

✔️  서블릿과 서블릿 컨테이너

• 자바에서는 서블릿 컨네이터 기능을 제공하면 WAS라고 한다.

 

서블릿 (Servlet)

: 웹 상에서 주고 받을 수 있는 프로토콜로 서버와 클라이언트 사이에 이루어지는 요청 응답 프로토콜이며, 주로 HTML 문서를 주고 받는데 사용한다

 

서블릿 컨테이너 (Servlet Container)

: 서블릿들을 모아서 관리하고 웹서버와 소켓을 통신하는 역할을 한다. 대표적으로 톰캣이 있다.

 

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) {
    }
}

/hello로 URL이 호출되면 그때 서블릿 코드가 실행된다. 서블릿이 주로 하는 것은 요청을 처리하고, 그에 맞는 응답을 보내는 것이다. 코드를 살펴보면 HttpServletRequest와 HttpServletResponse가 있다. 이는 각각 HTTP 요청 정보를 편리하게 사용하고, HTTP 응답 정보를 편리하게 제공하는 역할을 한다.

서블릿 컨테이너는 서블릿 객체를 싱글톤으로 관리한다. 사용자가 보내온 요청 객체와 응답 객체만 새롭게 생성한 후 이미 만들어져 있는 서블릿 객체를 재사용하여 성능을 최적화시킨다. 

 

 

Q. 왜 요청 객체와 응답 객체를 새롭게 생성하는걸까?

A. 사용자마다 요청하는 내용이 다르기 때문에 그에 대해 처리하는 응답도 달라질 것이다. 만약 같은 객체를 사용하게 된다면, 3만원을 결제한 사용자 A와 1만원 결제한 사용자 B에 대한 처리 응답이 섞일 것이다. 그래서 요청 객체와 응답 객체는 재사용하지 않으며 반드시 요청, 응답 관련 데이터는 HttpServletRequest와 HttpServletResponse 객체에 저장하고 사용해야 한다.

 

 

Q. 왜 서블릿 객체는 재사용해도 되는걸까?

A. 이 개념을 식당으로 비유해보고자 한다. 서블릿은 요리사라고 생각하고, 요청 객체와 응답 객체는 종업원이라고 생각하면 쉬울 것 같다. 요리사(서블릿)는 종업원(쓰레드)이 들고온 주문서(요청 객체)만 보고 요리를 만들고 종업원에게 내주기만 하면 된다. 요리사는 어떤 음식을 만들어야하는지만 확인하고, 이 음식을 몇 번 테이블에서 주문했고 이 음식을 요청한 테이블이 이전에 어떤 음식을 주문했는지는 몰라도 된다. 요리가 완성되어 나오면 종업원은 접시(응답 객체)를 들고 고객에게 줄 것이다. 서블릿 객체는 상태를 기억하지 않아도 되고, 그저 처리에만 집중하면 되기에 하나의 객체로 재사용할 수 있는 것이다.(어차피 종업원이 옮기는 거라 종업원이 몇 번 테이블에서 주문한 음식인지 기억한다. 테이블의 주문이 섞이지 않는다.) 한명의 요리사로 충분히 고객의 요청을 처리할 수 있다면 굳이 사장은 다른 요리사를 고용할 이유가 없다. 그리고 한 명의 요리사가 한 번에 하나의 요리만 하지 않고 여러 테이블에서 오는 요청을 동시에 처리할 수 있다. 여러 종업원글이 주문서를 들고 오는 것을 멀티쓰레드로 비유할 수 있을 것 같다. 

 

 

 

---

 

 

 

 

✔️  멀티쓰레드와 쓰레드 풀

 

멀티쓰레드 (Multi thread)

: 하나의 프로세스 내에서 둘 이상의 스레드가 동시에 작업을 수행한다.

 

쓰레드 풀 (Thread pool)

: 미리 일정 개수의 쓰레드를 생성하여 관리하는 기법이다.

 

 

 

요청 마다 쓰레드를 생성한 경우다. CPU나 메모리가 허용될 때 까지 동시에 요청된 것들을 처리할 수 있겠지만, 쓰레드의 생성 비용은 매우 비싸다. 고객이 요청할 때 마다 새로운 쓰레드를 생성하게 된다면 응답 속도가 늦어질 것이다. 또 쓰레드 생성에는 제한이 없다. 만약 고객의 요청이 너무 많이 오게 되면, CPU나 메모리 임계점이 넘어서 서버가 다운될 수 있다.

 

요청이 올 때마다 쓰레드를 만드는 것은 효율이 떨어지기 때문에 미리 쓰레드를 만들어둔다. 그걸 쓰레드 풀이라고 한다. 톰캣은 주로 200개를 기본 설정한다. 그럼 200개가 모두 다 사용하게 된다면, 남은 요청은 큐에서 대기하도록 한다. 쓰레드를 필요할 때 만들어서 쓴 경우는 생성에 제한이 없기 때문에 CPU나 메모리의 임계점이 넘어버려 서버가 죽을 수 있지만 쓰레드 풀로 쓰레드를 관리하면 과도한 요청들은 대기하도록 만들어 서버 폭주를 방지한다.

 

 

Q. 요청이 들어왔을 때 쓰레드를 만드는 것과 미리 쓰레드를 만드는 것은 결국 둘 다 쓰레드를 만드는 것인데 왜 성능에 차이가 나는걸까?

A. 쓰레드는 식당에서 일하는 종업원에 비유할 수 있다. 여러 종업원이 주문서와 요리 서빙을 동시다발로 하면 그 행위가 멀티쓰레드가 된다. 사장이 종업원을 여러명 고용한 후 손님의 요청이 많아지면 종업원을 내보내고 요청이 적어지면 다시 풀로 들어와 기다리게 한다. 그렇게 종업원을 고용하고 해고하기를 반복하는 것이 아니라, 이미 여러명을 고용해둔 뒤 풀이라는 대기실에서 기다리게 한 후 요청의 수만큼 돌린다고 생각하면 될 것 같다. 종업원을 고용하고 해고하기를 반복하면 당연히 더 많은 시간과 비용이 들 것이다. 이미 고용한 후 필요한 만큼 종업원을 돌리고 필요하지 않다면 대기하게 한 후 요청이 새롭게 들어오면 같은 종업원이 나가 요청을 처리하도록 하는 것이 바로 응대가 가능하기에 훨씬 효율적이다.

 

 

개발자는 쓰레드 풀의 숫자를 적정하게 설정하는 것이 매우 중요하다. 쓰레드 풀의 수를 너무 낮게 설정하면 요청은 대기 상태가 되고 고객의 요청에 대한 응답은 지연된다. 쓰레드 풀의 수를 너무 높게 설정하면 동시 요청이 많이 발생했을 때 CPU와 메모리의 임계점을 초과하게 되어 서버가 다운될 것이다. 적정 숫자를 찾는 방법은 로직이 얼마나 복잡한지, CPU와 메모리 그리고 IO 리소스 상황에 따라 다르기 때문에 아파치ab, 제이미터, nGrinder 툴로 성능 테스트를 시도하는 것이 좋다.

 

 

 

---

 

 

 

✔️  HTML 페이지와 HTML API 그리고 WAS가 어떻게 작성되는지

 

HTML 페이지

: 동적으로 필요한 HTML 파일을 생성해서 전달한다. 주로 사용자가 보는 홈페이지를 의미한다.

로그인 화면 예시

<form action="/login" method="post">
  <input name="username">
  <input name="password" type="password">
  <button type="submit">로그인</button>
</form>

사용자가 로그인을 할 수 있도록 보이는 페이지이며 사용자가 버튼을 누르면 /login 경로로 데이터가 post 방식으로 보내질 것이다.

 

 

HTML API

: HTML이 아닌 JSON이나 XML 형식으로 주고 받으며 프로그램이 데이터를 주고 받기 위한 인터페이스다.

자바스크립트의 로그인 API

fetch('/api/login', {
  method: 'POST',
  body: JSON.stringify({ username: 'sori', password: '1234' }),
  headers: { 'Content-Type': 'application/json' }
})
.then(response => response.json())
.then(data => console.log(data));

로그인 버튼이 눌렸을 때 화면에 적힌 데이터를 Controller까지 전달해주는 것이 HTML API(웹 API 혹은 REST API)가 하는 일이다. fetch 함수의 인자에는 들어온 경로와 어떤 방식으로 보내는지 어떤 내용을 어떻게 처리하여 보낼건지에 대해 적는다. 위의 코드는 login 경로로 들어온 정보를 POST(새로운 자원 요청)방식으로 보내며 username과 password는 JSON 문자열로 반환한다는 내용이 들어있다. 이 API 요청은 WAS의 Controller가 받아 처리한다.

HTTP API는 브라우저 같은 UI 클라이언트와 통신할 때만 사용하는 것이 아니다.서버와 서버 간에도 HTTP API를 통해 데이터를 주고받는다. 사용자가 상품을 주문한 뒤 결제 단계로 넘어가는 경우, 주문 서버와 결제 서버가 HTTP API를 통해 필요한 정보를 주고받는 방식으로 통신한다.

 

 

WAS의 Controller

@RestController
@RequestMapping("/api")
public class LoginController {

    @PostMapping("/login")
    public ResponseEntity<LoginResult> login(@RequestBody LoginRequest request) {       
       // 로직 수행 코드...
        return ResponseEntity.ok(new LoginResult("success", "Welcome!"));
    }
}

로그인을 처리하는 Controller다. @RequestMapping("/api")는 이 클래스의 모든 요청은 api로 시작된 경로만 처리하겠다는 의미이다. @PostMapping은 /api/login 경로 중 post 요청만 처리한다는 의미이다. 이렇게 경로를 통해 들어온 정보를 가지고 일련의 비즈니스 로직이 실행된다. 

실행되는 경로에 대해 다시 정리해보자면, HTML 페이지에 사용자가 로그인 관련 정보를 입력하여 버튼을 누르면, HTML API는 데이터를 어떤 형태로 어떤 경로로 보낼건지 정리하여 WAS로 보낸다. 그러면 WAS 내에 있는 Controller 중 @RestController가 API 요청을 받고 서블릿 컨테이너(예로 톰캣)가 요청을 전달한다. 전달된 요청에 맞춰 로그인 처리 로직이 수행되고 JSON 데이터로 생성된 결과는 API 응답으로 브라우저로 전달된다. 로그인이 제대로 처리되었다면 그에 맞는 화면을 사용자가 받게 될 것이다.

 

 

 

---

 

 

 

✔️  브라우저 렌더링, 서버사이드 렌더링, 클라이언트 사이드 렌더링

 

브라우저 렌더링

: 브라우저가 서버로부터 요청해 받은 내용을 브라우저 화면에 표시해주는 작업을 말한다.

 

 

SSR (서버사이드 렌더링)

:  정적인 화면에 사용하며, HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달한다.

 

서버사이드 렌더링 방식은 보통 백엔드 지향 개발자들이 Spring과 Thymeleaf 등을 사용해 화면과 로직을 함께 처리하며, 간단한 프로젝트를 만드는 데 자주 활용되는 방식으로 보면 적합할 것 같다.

 

 

CSR (클라이언트 사이드 렌더링)

: 동적인 화면에 사용하며, HTML 결과를 자바스크립를 사용해 웹 브라우저에서 동적으로 생성해서 적용한다.

 

클라이언트 사이드 렌더링 방식이 웹 프론트엔드와 백엔드가 나뉘어 프로젝트를 수행하는 것으로 생각하면 될 것 같다. Vue.js, React를 사용하여 동적인 화면을 제공하고 백엔드 개발자는 데이터 API와 비즈니스 로직 등을 처리한다.

 

 

 

---

 

 

아래에 출처를 남겨두겠습니다.
블로그엔 제가 최대한 이해한 내용까지만 적는거라
출처에 들어가시면 더 많은 내용이 있어 공부하시는데 도움되실겁니다.

 

🪽

틀린 내용이 있다면 댓글로 알려주세요

 

 

 

---

 

 

- 웹서버와 웹 애플리케이션 서버의 차이

[Web] Web Server와 WAS의 차이와 웹 서비스 구조 - Heee's Development Blog

 

- 웹과 HTTP

WEB과 HTTP / (특징, 구조, 동작 과정 예시)

 

- WAS와 서블릿

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

 

- fetch와 post

fetch 함수: POST Request

 

- fetch

[JavaScript] fetch 함수 쓰는 법, fetch 함수로 HTTP 요청하는 법

 

- 브라우저 렌더링, CSR과 SSR

클라이언트 사이드 렌더링(CSR) vs 서버 사이드 렌더링(SSR)