[Spring Web MVC] 웹 애플리케이션

 

 

 

웹은 HTTP 프로토콜을 기반으로 통신한다.

 

Web Server : 정적 리소스와 기타 부가기능을 제공한다. (APACHE, nginx)

Web Application Server : 웹 서버 기능 + 동적 리소스를 제공한다. (Tomcat) / 애플리케이션 코드를 실행하는데 특화됨.

 

스프링 MVC는 WAS 에서 동작한다.

 

 

웹 시스템은 WEB / WAS / DB로 구성된다.

 

웹 서버는 정적 리소스를 처리하고, 중요한 애플리케이션 로직은 웹 애플리케이션 서버가 담당한다.

WAS 하나로 두 작업을 함께 처리할 수도 있지만, 서버의 안정성과 효율적인 리소스 관리를 위해 이렇게 설계하는 편이 합리적이다.

이렇게 설계 시 웹 애플리케이션 서버가 죽더라도 웹 서버가 살아서 클라이언트에게 오류 메세지를 보내줄 수 있다.

 

 

 

 

 

서버는 클라이언트가 요청한 HTTP 메세지를 해석해 요청 메세지에 해당하는 작업을 수행 후 클라이언트에게 응답 메세지를 전송한다.

 

여기서 중요한 작업은 비즈니스 로직을 실행해 데이터베이스에 저장하는 작업인데...

중요한 작업 외에 처리해야 하는 귀찮은 작업들이 너무 많다.

 

서버의 작업을 도와주기 위해 서블릿이 도입됐다.

서블릿은 "의미있는 로직" 외에 모든 작업을 서버 대신 처리해준다.

 

 

 

 

클라이언트에서 서버로 요청이 왔을 때 서블릿 내부의 service가 실행된다.

HttpServletRequest 로 요청 정보를 편하게 읽고, HttpServletResponse 로 응답 정보를 편하게 제공한다.

 

서블릿은 HttpServlet 클래스를 상속받아서 만들어지고 몇 가지 메서드를 오버라이드해서 사용한다.

 

1. init : 최초로 호출될 때 한 번만 실행되는 메서드이다.

2. service : 클라이언트의 요청을 처리하는 메서드이다.

HTTP 요청 메서드에 따라 doGet(), doPost() 등으로 처리를 분기할 수 있다.

3. destroy : 메모리에서 제거될 때 한 번만 실행되는 메서드이다.

 

 

 

 

 

 

 

 

클라이언트에서 요청이 들어오면 요청 메세지를 기반으로 request 객체를 만든다.

이후 서블릿을 실행한 후 response 객체를 통해 응답 메세지를 만들고 클라이언트에게 전달한다.

 

서블릿 컨테이너 (Tomcat) 는 서블릿들을 생성하고 호출하고 관리해준다.

서블릿 객체는 싱글톤으로 관리되고, 동시 요청을 위한 멀티쓰레드 처리를 지원한다.

 

여기서 서블릿을 호출하는 대상이 바로 쓰레드이다. (https://13months.tistory.com/92 https://13months.tistory.com/94)

 

서블릿이 도입되기 전에는 CGI (Common Gateway Interface) 방식을 사용해 클라이언트의 동적 리소스 요청을 처리해줬는데... CGI 방식은 쓰레드 단위가 아닌 프로세스 단위로 작업을 처리하기에 여러 명의 요청을 처리하기 어려워 서블릿이 도입됐다고 할 수 있다. (스프링 컨테이너를 요청 하나하나에 대응해서 띄운다고 생각하면 된다)

 

 

 

 

 

쓰레드가 하나인데 여러 가지 요청이 들어왔다.

요청1이 쓰레드를 사용하는데 어떤 이유로 처리가 지연된다면.. 요청1과 요청2 모두 정상적으로 작동하지 않는다.

 

 

요청이 올 때 마다 쓰레드를 생성하도록 해서 문제를 해결할 수 있지만, 쓰레드의 생성 비용은 매우 비싸고 요청이 지나치게 많이 오면 CPU 메모리가 버티지 못하고 서버가 죽을 가능성이 있다.

 

 

 

 

 

쓰레드 풀을 사용해서 해당 문제를 해결했다.

쓰레드 풀에 미리 쓰레드를 적당히 만들어놓고, 요청에 따라 쓰레드를 할당해준다.

쓰레드 풀에 있는 쓰레드의 수보다 많은 요청이 오면 쓰레드를 더 만드는 대신 해당 요청을 대기시키거나 거절한다.

 

수강신청을 생각하면 이해하기 쉽다. 선착순으로 쓰레드를 하나씩 할당해주고 할당할 수 없는 경우 요청을 대기시킨다.

 

로직의 복잡도, CPU, 메모리 등을 잘 고려해서 쓰레드 풀의 적정 숫자를 설정하자.

 

 

 

 

---

 

 

 

서버가 서비스를 제공할 때 고민할 요소는 세 가지이다.

 

1. 정적 리소스를 어떻게 제공할까?

2. 동적으로 생성되는 HTML 페이지를 어떻게 제공할까?

3. HTTP API는 어떻게 제공할까?

 

 

 

 

클라이언트가 서버에게 주문 내역을 요청했다.

서버는 데이터베이스를 조회해서 HTML을 동적으로 생성한 후 클라이언트에게 전달한다. (JSP, Thymeleaf 사용)

 

서버 단에서 HTML을 생성해 SSR (Server Side Rendering) 이라고 부르고, 주로 정적인 화면을 구성할 때 사용한다.

 

 

 

 

 

1. 

클라이언트가 서버에게 주문 내역을 요청했다.

서버는 데이터베이스를 조회해 애플리케이션을 구동하는 자바스크립트를 클라이언트에게 전달한다.

 

2. 

클라이언트가 서버에게 자바스크립트를 요청한다.

서버는 클라이언트에게 자바스크립트를 전달하는데, 여기에 클라이언트 로직 / HTML 렌더링 관련 정보가 들어있다.

 

3.

클라이언트가 서버에게 데이터를 요청한다.

서버는 클라이언트에게 JSON 타입으로 요청한 데이터를 전달한다.

 

그 후 클라이언트는 얻은 정보들을 바탕으로 HTML을 만든다.

 

서버가 준 정보를 바탕으로 클라이언트 단에서 HTML을 생성하는 작업을 CSR(Client Side Rendering) 이라고 부르고, 동적인 화면을 구성할 때 사용한다.

 

 

물론, SSR을 쓰더라도 자바스크립트로 화면 일부를 동적으로 변환할 수 있고,  CSR SSR을 동시에 지원하는 경우도 있다.